Is there a config option to force pull? #62
Labels
No labels
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: forgejo/runner#62
Loading…
Reference in a new issue
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?
Maybe more of a bug for
forgejo/forgejo
but, the whole reason I ran into #61 is because I was trying to get forgejo actions to pull my docker image before running the job, which I couldn't figure out how to do.I ended up patching the runner, maybe I should've been patching act, idk. I'd expect a
force_pull
option incontainer
maybe, next toimage
?For now it seems like runner hardcodes ForcePull to false:
ForcePull: false,
That would be an improvement, I ran into this as well. There is a proposed semantic here https://github.com/actions/runner/issues/791#issuecomment-1572296966
@dachary Is this something we would want upstream to figure out/implement, or would we be willing to implement this in our fork? It seems like there are some PRs made against upstream to do this, but there was little input from maintainers.
https://github.com/actions/runner/pull/800
https://github.com/actions/runner/pull/1086
I assume we want to stay pretty close to upstream but this may be an instance where an optional field isn't too much of a divergence.
It depends what the upstream is in this case: there are a few 😄 Some inspiration comes from GitHub but since it is not Free Software it is difficult to figure out why this option was never implemented. One may guess that there is so much horsepower that it just always pulls and be done with it. The core of the implementation of the runner comes from https://github.com/nektos/act/ and it could be implemented there, to offer better control over the cache. Although the target audience is only people running locally so they can always rm -fr the cache if needed. Then there is the Gitea act_runner where most of the code in the Forgejo comes from which may work on this particular issue as well.
AFAIK there has not been any activity in this area in the past weeks and if you want to give it a shot, noone will stand in your way. If I was to do it I think I'll start with implementing that as a patch to https://code.forgejo.org/forgejo/act.
Heh, yeah, good point. There's a lot of layers to this. I'll see if this is something I can pick up for Forgejo's own runner.
It is Free Software written in C#... how did I not know that.