-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
github-actions executable updated itself #187009
Comments
For what it's worth: according to GitHub's documentation on the subject, and my perusing of the code, this behavior does not seem intentional, and the @aanderse Can you reliably reproduce this? If so, we should probably file a bug upstream. |
I'm controlling versions with |
I coincidentally just updated github-runner on release-22.05:
Is this related to this bug or rather a candidate for a separate bug report? |
Looks like this is an unrelated bug, @yayayayaka -- unless your runner self-updated beforehand, do your logs show that? |
Oh, indeed it did. I was just not looking back enough in the journal. |
Separate bug. I saw this occur here: #182189 (review) But I was not able to reproduce it when I dug into it a few days later. I assumed it was a PBKAC with the way I tested it the first time 😥 Edit: just read the rest of the comments, maybe not a separate bug then? I'll dig in more later |
I think it is a good guideline to always backport. We could also think about applying the patch again that I used before the |
I think we can all agree on this, given the nature of the package. I think we should look more into this, and inform upstream at some point, falling back to that patch as a last resort if needed. I believe this is the best course of action because faking the version data to GitHub's servers is probably not the best idea given how the program works, so we should definitely strive to not do that if we don't have to. For example, if GitHub conditionally sends something based on the version of the runner, our nonexistent high version could cause invalid data to be sent to an older version. (Even though upstream warns against not updating for long periods of time, this is definitely still something to consider.)
|
Definitely makes sense! This is why I removed the patch as soon as the |
Turns out this is a separate issue, or this symptom can appear as a result of more than this self-updating issue. I experienced this again after updating nix, which included the latest github-runner package updates. My runner logs show no signs of attempting to self-update. Strangely this was only experienced with my I'll file an issue for this when I have time to describe it more intelligently then "it no work", if anyone else has time to triage before then please file an issue 😄 |
As mentioned in #189203 (comment) I continue to run into issues where |
I do not have any issues with my runners, but I also have this patch in my NixOS overlays. I think it would be a good idea to reapply this patch. Another possible solution is to let this run in an FHS environment and update itself. |
When did you put this patch in your overlays? Do you have automation to keep up with upstream releases in your local deploys, or you just keep an eye out and manually update ASAP?
Or run |
I added it when @veehaitch made the comment, seemed like a good idea to keep things working. I do also have automation to update the NixOS flake for all my systems. |
I realize I completely misunderstood what you meant by this. You meant the
I agree. Are you able to make a PR? We could use that to resolve this issue. |
Opened a PR at #189909 |
I still think we should try to open an issue upstream, as this seems like a bug they'd want to address. Having this patch applied longterm is probably not the best idea, so we should see what upstream thinks. |
Does someone want to open an issue, or should I? |
Is this what we want? actions/runner#2201 |
Either way, updates for the package stopped being backported to 22.05 due to merge conflicts. Combine that with this option being ignored, and GHA is basically completely broken atm in stable. |
Sadly, no -- we call config.sh directly. I'm going to go ahead and open an issue upstream for this myself (in a few hours from now). |
Sorry for the late reply. Thank you so much @winterqt! |
Is this fixed? |
I'm not sure... I setup automatic updates to run daily so I can't tell. |
We are still getting this every time the config changes and the script tries to re-authenticate:
|
@Profpatsch maybe related to #217721 |
@veehaitch I think we figured out what caused this, the short time runner registration tokens are active; when switching to fine-grained PATs, this is fixed. I created a PR which improves the documentation of the module in this regard: #217827 |
Regarding the original issue brought up in this thread, we’ve been running the runner for over a year, and it has never tried to update itself in that time. So I would close this, feel free to reopen. |
Describe the bug
A clear and concise description of what the bug is.
I was running the
services.github-runner
service and the service managed to update itself and doesn't work anymore.Despite our NixOS service passing the
--disableupdate
flag the service will attempt to update itself 30 days after any new release is out. See https://github.blog/changelog/2022-02-01-github-actions-self-hosted-runners-can-now-disable-automatic-updates/ for details.TODO:
github-runner
package should be backported, always, probably without exception (similar to how we always updateyoutube-dl
and the policies we have that allow for this)services.github-runner.enable
(or some other suitable place) that users need to keep up to date with the latest softwareNotify maintainers
@veehaitch @newAM
cc @winterqt because she's always so helpful and I appreciated her discussing this with me 😄
The text was updated successfully, but these errors were encountered: