local reusable workflow showing "file does not exist" #132
Labels
No Label
kind
bug
kind
build
kind
dependencies
kind
docs
kind
enhancement
kind
feature
kind
help wanted
kind
proposal
kind
refactor
related
act
related
environment
related
exec
related
gitea
related
workflow
reviewed
confirmed
reviewed
duplicate
reviewed
invalid
reviewed
needs feedback
reviewed
wontfix
reviewed
workaround
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/act_runner#132
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I am using act_runner v0.1.2 and gitea v1.19 in my personal instance. I have a workflow file
.gitea/workflows/push.yaml
that looks like this (just to test reusable workflows - it doesn't do anything):The
.gitea/workflows/test.yaml
file definitely exists in the repo, but I'm seeingfile does not exist
in the logs for the build job and the step always fails. I looked through the existing issues and saw #80 which looks very similar, but was apparently resolved already.The error message is not clear enough, I will try to improve it.
According to the documentation, if you want to reuse a workflow as a job, your workflow should be like:
If you use
uses
insteps
, it means you want to use an action, not a workflow.Could you please edit the .gitea/workflows/push.yaml workflow file and test again?
Oooooh. I see. That's unfortunate because what I really wanted to do was kick it off conditionally based on a prior step like this:
I think I can work around that though.
It still doesn't really seem to work with that syntax either though. I changed it to this:
and now the "Set up job" step is seems to just be stuck spinning. There's no output in the web interface. Looking at the logs it seems to be complaining about no steps:
and no further output for a long time now.
After almost 15 minutes job fails/times out. Web interface still shows nothing at all to go on. No additional logs on runner container.
It's probably still something on my end at fault, but there's very little for me to go on to even determine what might be wrong. I've already changed it to
level: debug
in the config file in the hopes of increased verbosity.Do you want to avoid repeating jobs? Otherwise you can write composite actions to avoid repeating steps
action.yml
https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
action.yml
file to your repo- uses: ./build-steps
(expects to findbuild-steps/action.yml
)I remember to read somewhere that Gitea maintainer are planning to implement adding reusable worksflows as steps, but that doesn't exists in GitHub Actions
I have never tried to use reusable workflows in gitea/act_runner
The log looks weird. Since you have already called another reusable workflow in
dispatch
job, the number of steps won't be checked so there shouldn't be aNo steps found
log.Could you please paste the related workflow files here? You could remove all secret info from the workflow files and only keep the code that you think may affect.
It's a bug related to #126. This bug may cause the errors in
Set up job
not to be reported to the Gitea instance. It should have been fixed in #126.Hi.
In the latest build there is more output reported to Gitea but reusing local workflows is still broken. Currently our daemon is restarting when it comes to the point of using the workflow:
Workflows are very simple due to testing. Parent workflow is echoing some text and should then use the second workflow. The second workflow should run when the
workflow_call
event is triggered and should echo another string.i've figured out the problem. Maybe it's my fault because i don't read the documentation well...
Segfaults:
Works but gives no output on the steps (maybe expected?)
Difference is the
on:
partHi @dwillbrandt , thanks for your bug report. It's a bug caused by an unchecked nil pointer. I'll send a PR to fix it.
Since the bug you commented is different from this issue, I opened a new issue (#138) to discuss the bug. Please comment anything related to the bug in the new issue :)