You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current Behaviour
We provide a few runner images of which only the latest tag is continously updated to have the latest runner software in it automatically whilst retaining the same tag. There is no ability to pull in an alternative runner software version in any image.
Suggestion
Produce a solution to allow an end user to download and install the latest version of the runner software on container startup and use the baked in version as a fallback should this process fail.
Rationale
Containers don't always play with the self-update process, additionally, it's not ideal having to reference a public container (latest) from a community maintained open source project to always stay on the latest runner software. By providing an alternative bootstrap process enabled via a feature flag people can mitigate the self-update issues without the need to either constantly sync latest to their registry or have to rely on our image.
Furthermore, if you run a custom runner image you currently have to provide some solution for automatically pushing out a new version of your image when our image gets bumped.
Issues to Resolve:
If we call the GitHub release API every container restart we'll very quickly consume the 5000 authenticated API calls / hour rate-limit on even semi busy environments. Calls will need to be cached (to a configurable period) probably by sending them through a Go HTTP proxy sidecar implementation instead of going directly to Github.
toast-gear
changed the title
Enable Fetching and Installing Runner Software On Container Start
Enable Fetching and Installing Latest Runner Software On Container Start
Oct 13, 2021
Current Behaviour
We provide a few runner images of which only the
latest
tag is continously updated to have the latest runner software in it automatically whilst retaining the same tag. There is no ability to pull in an alternative runner software version in any image.Suggestion
Produce a solution to allow an end user to download and install the latest version of the runner software on container startup and use the baked in version as a fallback should this process fail.
Rationale
Containers don't always play with the self-update process, additionally, it's not ideal having to reference a public container (
latest
) from a community maintained open source project to always stay on the latest runner software. By providing an alternative bootstrap process enabled via a feature flag people can mitigate the self-update issues without the need to either constantly synclatest
to their registry or have to rely on our image.Furthermore, if you run a custom runner image you currently have to provide some solution for automatically pushing out a new version of your image when our image gets bumped.
Issues to Resolve:
The text was updated successfully, but these errors were encountered: