chore(deps): update code.forgejo.org/forgejo/runner docker tag to v11 - autoclosed #3
Reference in New Issue
Block a user
No description provided.
Delete Branch "renovate/code.forgejo.org-forgejo-runner-11.x"
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?
This PR contains the following updates:
8.0.1->11.1.2Release Notes
forgejo/runner (code.forgejo.org/forgejo/runner)
v11.1.2Compare Source
Release Notes
Forgejo-Cache-Hostwhen ACTIONS_CACHE_URL is overridden.v11.1.1Compare Source
Release Notes
verboseto onv11.1.0Compare Source
Release Notes
v11.0.0Compare Source
Release Notes
The breaking change in this release is not technical, it is the change of the license which is now GPLv3-or-later.
v10.0.1Compare Source
Release Notes
v10.0.0Compare Source
Release Notes
PR: fix(security): prevent on: pull_request actions from mutating caches of other workflow events
forgej-runner currently creates a safer execution environment for workflows triggered by pull requests by denying those workflows access to the repository's secrets, preventing pull requests from compromising the confidentiality of the secrets.
Workflows do have access to write to the action cache, which is shared with future workflow executions, including executions that may have access to repository secrets. This was assumed safe as the cache is a "write-once" operation based upon the cache key; if an execution writes to that cache, it will be read by other workflows only if a matching key parameter is provided, and it can not be modified again. These assumptions were identified as weak security practices with known workarounds.
It is possible for a malicious pull request to mutate the shared cache and embed untrusted artifacts, which may later be executed in workflow executions with access to secrets, risking the confidentiality of those secrets.
In order to eliminate this risk, workflows executing with the
pull_requestandpull_request_targetevents have their write operations to the cache isolated to future workflow executions from the same pull request. They can continue to read from the shared cache if applicable.If using an external cache server configuration, both the cache server and other instances of the runner must be running the same software version. The recommended upgrade procedure in this configuration is to bring all runners offline, upgrade the cache server to the latest release and bring it online, and then bring all other runners online.
PR: fix(security): ensure unique names for container images created by actions
Without this fix, when a workflow ran a local docker action (e.g. the example in the end-to-end tests), it used an image tag that could collide with other workflows that happen to use the same name. The workaround for older runner versions is to set
[container].force_rebuild: truein the runner configuration file.job_levelandlevelgithub.com/pkg/errorsv9.1.1Compare Source
Release Notes
v9.1.0Compare Source
Release Notes
[runner].timeoutexpiresshellon a task step if it referenced a matrix variablev9.0.3Compare Source
Release Notes
job.<id>.services.<id>.optionsv9.0.2Compare Source
v9.0.1Compare Source
v9.0.0Compare Source
Workflows and actions go through a schema validation and the runner will not start a job if they do not pass. Some existing workflows or actions may have syntax errors that did not prevent them from running with versions 7.0.0 and below but they will no longer work with versions 8.0.0 and above.
Existing workflows can be verified and fixed before upgrading by using the new
forgejo-runner validatecommand. For instance, the following will try to validate workflows and/or actions found in the Git repository athttps://example.com/my/repo(a local directory at the root of a Git repository can also be used):If the error is not immediately obvious, please file an issue with a copy of the failed workflow and revert to using version 7.0.0 until it is resolved.
forgejo-runner validatecommand can be used to verify if an action or a workflow is conformant with the expected schema.forgejo-runner validate --repository https://example.com/my/repositorywill validate all the workflows and actions a Git repository contains. Alternativelyforgejo-runner validate --path myaction/action.yml --actionorforgejo-runner validate --path .forgejo/workflows/test.yml --workflowcan be used to validate a single file. It is recommended to use these commands to verify existing actions and workflows pass before upgrading to Forgejo runner v8.0.0 or above to not disrupt existing workflows.contrib/forgejo-runner.servicehostschema in 8.0.0 is a breaking changeConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.
chore(deps): update code.forgejo.org/forgejo/runner docker tag to v11to chore(deps): update code.forgejo.org/forgejo/runner docker tag to v11 - autoclosedPull request closed