Unable to run Actions on push with basic workflow file. #12518

@CakePost commented on GitHub (Feb 23, 2024):

I investigated if I could get something working with act_runner directly instead of using Docker. Still unable to get a job to actually run on push... I think one culprit might be my nginx configuration so I'll look into that just to reduce some variables.

@CakePost commented on GitHub (Feb 23, 2024): I investigated if I could get something working with act_runner directly instead of using Docker. Still unable to get a job to actually run on push... I think one culprit might be my nginx configuration so I'll look into that just to reduce some variables.

GiteaMirror commented

@CakePost commented on GitHub (Feb 24, 2024):

I've looked through my nginx access and error logs and have not been able to find any smoking guns or indications that it shouldn't be working. These connections show the routing for the two runners I have set up; one I'm running locally on my desktop using the act_runner library and the other is deployed using the docker image as described above.

@CakePost commented on GitHub (Feb 24, 2024): ![image](https://github.com/go-gitea/gitea/assets/94595995/d838d826-1808-4f64-bcfd-55074b99f629) I've looked through my nginx access and error logs and have not been able to find any smoking guns or indications that it shouldn't be working. These connections show the routing for the two runners I have set up; one I'm running locally on my desktop using the act_runner library and the other is deployed using the docker image as described above.

GiteaMirror commented

@CakePost commented on GitHub (Feb 26, 2024):

I would like to continue investigating but I've run out of ideas for places to look:

Gitea logs look fine
Runner logs look fine
Nginx logs look fine and corroborate the gitea logs
Docker logs look fine

Maybe I'm missing a setting to expose some more verbose logs that might be showing the issue? I've looked at the firewall for the server to verify that it wasn't blocking anything- it's pretty permissive with the respective ports entirely open:

22
80
443

@CakePost commented on GitHub (Feb 26, 2024): I would like to continue investigating but I've run out of ideas for places to look: - Gitea logs look fine - Runner logs look fine - Nginx logs look fine and corroborate the gitea logs - Docker logs look fine Maybe I'm missing a setting to expose some more verbose logs that might be showing the issue? I've looked at the firewall for the server to verify that it wasn't blocking anything- it's pretty permissive with the respective ports entirely open: - 22 - 80 - 443

GiteaMirror commented

@yp05327 commented on GitHub (Feb 27, 2024):

IIRC, we have a similar issue before: if the server has no public internet access, workflow will not run.

Edited:
I see you mentioned it, #28277.
That issue, finally, he worked when move Gitea(or runner? not remember clearly) to another server which has public internet access.
But it is hard to say that it is the real reason.
see: https://github.com/go-gitea/gitea/issues/28277#issuecomment-1836113521

@yp05327 commented on GitHub (Feb 27, 2024): IIRC, we have a similar issue before: if the server has no public internet access, workflow will not run. Edited: I see you mentioned it, #28277. That issue, finally, he worked when move Gitea(or runner? not remember clearly) to another server which has public internet access. But it is hard to say that it is the real reason. see: https://github.com/go-gitea/gitea/issues/28277#issuecomment-1836113521

GiteaMirror commented

@CakePost commented on GitHub (Feb 27, 2024):

@yp05327 What exactly qualifies my server as offline, though? Is it that it's deployed in a docker container? The reverse proxy? If connectivity is this issue that suggests that perhaps there's some undocumented ports that need opening?

When I have some time I'll try finding a MWE of this failure perhaps locally.

@CakePost commented on GitHub (Feb 27, 2024): @yp05327 What exactly qualifies my server as offline, though? Is it that it's deployed in a docker container? The reverse proxy? If connectivity is this issue that suggests that perhaps there's some undocumented ports that need opening? When I have some time I'll try finding a MWE of this failure perhaps locally.

GiteaMirror commented

@yp05327 commented on GitHub (Feb 27, 2024):

What I wanted to say is that the root reason of #28277 is not This is because your labels are not matched.
And it seems that the offline server caused it, but this reason is so strange, as workflows should be detected whatever server is online or offline, so I don't think that is the root reason, and #28277 should keep opening.
If your server is online, then maybe it is caused by other reasons or the same unknown reason in #28277.
I will try to contact @zhangbaojia, and try to look into this issue.

@yp05327 commented on GitHub (Feb 27, 2024): What I wanted to say is that the root reason of #28277 is not `This is because your labels are not matched.` And it seems that the offline server caused it, but this reason is so strange, as workflows should be detected whatever server is online or offline, so I don't think that is the root reason, and #28277 should keep opening. If your server is online, then maybe it is caused by other reasons or the same unknown reason in #28277. I will try to contact @zhangbaojia, and try to look into this issue.

GiteaMirror commented

@zhangbaojia commented on GitHub (Feb 27, 2024):

I haven't followed up on this issue since, but I've continued to use gitea. The previous version of gitea was 1.19.3, and now I am installing 1.20.6. I'll try again this week.

@zhangbaojia commented on GitHub (Feb 27, 2024): I haven't followed up on this issue since, but I've continued to use gitea. The previous version of gitea was 1.19.3, and now I am installing 1.20.6. I'll try again this week.

GiteaMirror commented

@zhangbaojia commented on GitHub (Feb 27, 2024):

I haven't followed up on this issue since, but I've continued to use gitea. The previous version of gitea was 1.19.3, and now I am installing 1.20.6. I'll try again this week.

I still have reservations about servers without WAN

@zhangbaojia commented on GitHub (Feb 27, 2024): > I haven't followed up on this issue since, but I've continued to use gitea. The previous version of gitea was 1.19.3, and now I am installing 1.20.6. I'll try again this week. I still have reservations about servers without WAN

GiteaMirror commented

@wolfogre commented on GitHub (Feb 28, 2024):

I'm sure it's no business about the runner since there are no runs listed on the page.

Unfortunately, I cannot reproduce it in my env.

I would appreciate it if someone could provide trace logs. Please:

Update app.ini to enable trace log:

[log]
LEVEL = trace

Restart Gitea.
Push some commits to the repository which should trigger workflows but not, please push a few more times to trigger more logs.
Finally, paste the logs into this issue. If you trust me, you could send the entire log file to my email. I'll check it line by line.

@wolfogre commented on GitHub (Feb 28, 2024): I'm sure it's no business about the runner since there are no runs listed on the page. Unfortunately, I cannot reproduce it in my env. I would appreciate it if someone could provide trace logs. Please: 1. Update `app.ini` to enable trace log: ``` [log] LEVEL = trace ``` 2. Restart Gitea. 3. Push some commits to the repository which should trigger workflows but not, please push a few more times to trigger more logs. 4. Finally, paste the logs into this issue. If you trust me, you could send the entire log file to [my email](https://github.com/go-gitea/gitea/blob/274c0aea2e88db9bc41690c90e13e8aedf6193d4/MAINTAINERS#L46). I'll check it line by line.

GiteaMirror commented

@CakePost commented on GitHub (Feb 28, 2024):

Thanks for looking into this @wolfogre - I've sent an email with un-redacted trace logs as requested.

@CakePost commented on GitHub (Feb 28, 2024): Thanks for looking into this @wolfogre - I've sent an email with un-redacted trace logs as requested.

GiteaMirror commented

@soul-walker commented on GitHub (Feb 29, 2024):

I've encountered the same issue. After multiple attempts, I believe the problem here is that the SHA isn't updating during the push, and there are no corresponding push records. It's as if the push didn't trigger the push event. However, I don't understand why it didn't trigger. Interestingly, I couldn't replicate the issue when testing the service locally in the same way as it's done online.

new push：
SHA is not update:
main page don't have push event:

@soul-walker commented on GitHub (Feb 29, 2024): I've encountered the same issue. After multiple attempts, I believe the problem here is that the SHA isn't updating during the push, and there are no corresponding push records. It's as if the push didn't trigger the push event. However, I don't understand why it didn't trigger. Interestingly, I couldn't replicate the issue when testing the service locally in the same way as it's done online. - new push： ![image](https://github.com/go-gitea/gitea/assets/31162815/809f1aaa-bf76-48c8-9d66-d634b65a7c78) - SHA is not update: ![image](https://github.com/go-gitea/gitea/assets/31162815/c32ba8f1-c920-4205-a644-d401979c3e66) - main page don't have push event: ![image](https://github.com/go-gitea/gitea/assets/31162815/397610eb-09ad-4755-bbd4-8c52c57b3206)

GiteaMirror commented

@wolfogre commented on GitHub (Feb 29, 2024):

According to the trace log provided by @CakePost, I believe the problem is that the hooks of Git are broken. That's why actions, code indexer, and activities cannot work.

It could be fixed by regenerating the hooks, but before that, I would appreciate it if you could zip the hook directory of the repository and paste it to this issue. Don't worry, all files in it are just some hook scripts generated by Gitea. This will help to figure out what happened.

The location is [GIT_DATE_REPO_DIR]/[owner]/[repo].git/hooks, for example:

For @CakePost, it's [GIT_DATE_REPO_DIR]/actionsdebugtest/actionsdebugtest.git/hooks
For @soul-walker, it's [GIT_DATE_REPO_DIR]/ceshi1/bj-rtsts-server-go.git/hooks

Then you can fix the hooks by running gitea admin regenerate hooks. If all is well, it should go back to normal. Once the hooks have been fixed, it will be difficult to check what happened. So, please consider giving us a dump following the above steps.

@wolfogre commented on GitHub (Feb 29, 2024): According to the trace log provided by @CakePost, I believe the problem is that the hooks of Git are broken. That's why actions, code indexer, and activities cannot work. It could be fixed by regenerating the hooks, but before that, I would appreciate it if you could zip the hook directory of the repository and paste it to this issue. Don't worry, all files in it are just some hook scripts generated by Gitea. This will help to figure out what happened. The location is `[GIT_DATE_REPO_DIR]/[owner]/[repo].git/hooks`, for example: - For @CakePost, it's `[GIT_DATE_REPO_DIR]/actionsdebugtest/actionsdebugtest.git/hooks` - For @soul-walker, it's `[GIT_DATE_REPO_DIR]/ceshi1/bj-rtsts-server-go.git/hooks` Then you can fix the hooks by running `gitea admin regenerate hooks`. If all is well, it should go back to normal. Once the hooks have been fixed, it will be difficult to check what happened. So, please consider giving us a dump following the above steps.

GiteaMirror commented