Allow to optionally skip self-update #1444
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
|
I doubt this PR solves #422, you don't apply the update which leads to #422. I noticed this scenario
An unsupported scenario to avoid #422
|
|
I cannot see how the hack with the fake |
Not for me :/, otherwise this change would be perfect for this usecase. Runner version 2.283.3 ( + this PR ) becomes a zombie. And this is only a minor update to 2.284.0 |
|
See your point. Is the one with the hack hanging because there is some API version check which fails as the fake client version is higher than the server (e.g 3.0.0 > 2.284.0)? |
|
The logs are about the proposed change of this Pull Request without changing the runner version at all. Changing the runner version to 3.0.0 doesn't hang for me |
|
@ChristopherHX Now I see, thanks |
|
FWIW I'm using the "lie about runner version as 3.0.0" trick (thanks @ChristopherHX ) to run my forked runner, and it works well with GitHub Enterprise also. I put the file-override hack into the Dockerfile I use to build my custom image - so I don't have rebase clashes when syncing with upstream changing the version number properly. |
|
Thanks for the PR @fgalind1 - as @ChristopherHX noted, the service will still not queue jobs on outdated runners, so we'll need to make some changes to the service to support this fully. I outlined our plans to support you in this issue: #1396 (comment) We've started this work and I look forward to adding this support. |
thanks for helping on this 👍 ! I'm closing this PR |
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 (e.g. https://github.com/actions-runner-controller/actions-runner-controller). 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:
This will optionally skip self update logic if runner the environment variable
GITHUB_ACTIONS_SKIP_SELF_UPDATEis set to a truly value