-
Notifications
You must be signed in to change notification settings - Fork 959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workflow run is blocked at the automatic update for the self-hosted runner application #422
Comments
Was it an intermittent issue? Or is it still failing? Try downloading |
In this ticket, the customer reported that his workflows always run failed at the automatic update for the self-hosted runner application. Last time, when the runner application was trying to update to version '2.169.0' during the workflow run, he get the error like as below:
I suggested the customer to manually download the latest version '2.263.0' of the runner application at that time, and re-install the runner on his machine. |
I'm not the original reporter that BrightRan opened this issue for, but i'm having similar issues when my self-hosted agents try to auto-update. This has happened on 2 successive version updates, -> 2.267.1 & -> 2.273.0 both times from the previous versions. seems to me there's a final step either missing or unable to run in the auto-update process where the old bin & external folders are not replaced by the new versions, whether through some symlinking or straight up overwriting |
Same here, old version is Had to completely remove the old version then re-config the new version to make it work. Also for thoes who get stuck by Apple's GateKeeper, remember to close it before run the config script. |
When using infrastructure as code, containers and recipes, pinning versions for reproducibility is a good practice. Usually docker container images contain static tools and binaries and the docker image is tagged with a specific version. Constructing a docker image of a runner with a specific runner version and then self-updating itself doesn't seem that natural, instead the docker image should use whatever that binary was built/tagged to. Additionally to this - this concept doesn't play well when using ephemeral runners and kuberentes. First of all, we need to pay the price of downloading/self-updating every single ephemeral pod for every single job which causes delays in execution. Secondly this doesn't work well and containers may get stuck Related issues that will be solved with this: - actions#1396 - actions#246 - actions#485 - actions#422 - actions#442
When using infrastructure as code, containers and recipes, pinning versions for reproducibility is a good practice. Usually docker container images contain static tools and binaries and the docker image is tagged with a specific version. Constructing a docker image of a runner with a specific runner version and then self-updating itself doesn't seem that natural, instead the docker image should use whatever that binary was built/tagged to. Additionally to this - this concept doesn't play well when using ephemeral runners and kuberentes. First of all, we need to pay the price of downloading/self-updating every single ephemeral pod for every single job which causes delays in execution. Secondly this doesn't work well and containers may get stuck Related issues that will be solved with this: - actions#1396 - actions#246 - actions#485 - actions#422 - actions#442
Going to close this out since its been a while since its been reported, if we see this again we can reopen. |
In this ticket, the user has installed a self-hosted macOS runner and also set the proxy configuration.
when he uses this runner to run the workflow, the workflow run is blocked at the automatic update for the self-hosted runner application.
The following is the debug logs shared by the user:
Looks like, there are some problems cause the download of the latest runner application package to be failed, and then it goes to try the download again and again.
The text was updated successfully, but these errors were encountered: