-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove the ability to use the --once
flag entirely only allowing --ephemeral
to be set
#1196
Labels
enhancement
New feature or request
Milestone
Comments
Closed
mumoshu
added a commit
that referenced
this issue
Apr 25, 2022
mumoshu
added a commit
that referenced
this issue
Apr 25, 2022
mumoshu
added a commit
that referenced
this issue
Apr 27, 2022
Although we are going to eventually remove the ability to use the legacy --once flag as proposed in #1196, there might be folks still using legacy GHES versions 3.2 or earlier. This commit removes the existing feature flag to opt-in for --ephemeral, while adding another feature flag RUNNER_FEATURE_FLAG_ONCE to opt-in for --once so that folks stuck in legacy GHES versions can still use ARC. Since this change every user starts using --ephemeral by default. If they see any issues on legacy GHES instance, RUNNER_FEATURE_FLAG_ONCE=true can be set to opt-in to keep using --once, which gives one more ARC release until they upgrade their GHES instance. But beware, we won't support legacy GHES instances forever as it's going to be a maintenance nightmare. Please upgrade! Ref #1196
toast-gear
pushed a commit
that referenced
this issue
May 11, 2022
… legacy --once for GHES older than 3.3 (#1384) * runner: Remove the ability to use the deprecated `--once` flag Ref #1196 * runner: Ability to opt-out of using --ephemeral Although we are going to eventually remove the ability to use the legacy --once flag as proposed in #1196, there might be folks still using legacy GHES versions 3.2 or earlier. This commit removes the existing feature flag to opt-in for --ephemeral, while adding another feature flag RUNNER_FEATURE_FLAG_ONCE to opt-in for --once so that folks stuck in legacy GHES versions can still use ARC. Since this change every user starts using --ephemeral by default. If they see any issues on legacy GHES instance, RUNNER_FEATURE_FLAG_ONCE=true can be set to opt-in to keep using --once, which gives one more ARC release until they upgrade their GHES instance. But beware, we won't support legacy GHES instances forever as it's going to be a maintenance nightmare. Please upgrade! Ref #1196
We ended by making |
Let's keep this open until we completely remove the support for |
mumoshu
added a commit
that referenced
this issue
Jun 29, 2022
mumoshu
added a commit
that referenced
this issue
Jun 29, 2022
mumoshu
added a commit
that referenced
this issue
Jun 29, 2022
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment you can pick between where your ephemeral runners will be configured witwh the legacy
--once
flag or the supported new--ephemeral
flag. We are not aware of any reason to use the--once
flag, the only discussion we've seen on it is here actions/runner#1339 and it is centred around rate limiting which we don't think will be an issue.We also state in the docs that ARC requires => 3.3 which supports the
--ephemeral
flag.If you are running a GHES environment you need to upgrade your GHES instance to => version 3.3 if you wish to maintain an ARC upgrade path and not have down time. In order to remove the --once flag we will need to remove the logic from our runner container [1] [2], this will be done at the point of the linked milestone being released and so if you are using the latest tag or build a custom container from ours you will be impacted effectively at a random time. Migration notes:
ephemeral: false
, this will create a significant change in behaviour and so has impacts you may not desire.--once
flag as part of your images entrypoint (don't expect tonnes of help from ARC if you go this direction)This issue is to be done in the subsequent release to #1189
The text was updated successfully, but these errors were encountered: