Update code.forgejo.org/forgejo/runner Docker tag to v11 #2
Loading…
Add table
Add a link
Reference in a new issue
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 MR contains the following updates:
5.0.4->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
MR: 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.
MR: 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 changev8.0.1Compare Source
v8.0.0Compare Source
Existing workflows can be verified and fixed before upgrading by using
forgejo-runner exec --workflows path-to-the-workflow. For instance in a workflow whereruins-onwas typed by mistake instead ofruns-on: 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.docker://node:22-bookworminstead ofdocker://node:20-bullseyeorhost.lxcscheme is set with no argument, it defaults tolxc://debian:bookworminstead oflxc://debian:bullseye.hostschema cannot have any argument, it can no longer behost://-self-hostedbashinstead ofshwhen a container image is explicitly specified in the step. If a workflow depens on that behavior, it will need to be modified to explictly set the shell tosh.[^A-Z0-9-]+. They will be sanitized and a message displayed in the logs showing the sanitized name. The service can either be renamed to match the constraint so it can be used as is. Or the sanitized name can be used. For instance of a PostgreSQL service runs asdata.baseit will be sanitized asdata_base.v7.0.0Compare Source
forge.FORGEJO_REPOSITORYis the same asgithub.GITHUB_REPOSITORY. TheGITHUB_*environment variables are preserved indefinitely for backward compatibiliy with existing workflows and actions. A workflow that previously set presetFORGEJO_*variables in any context, they will be overridden by this naming change. For instance ifsecrets.FORGEJO_TOKENwas set, it will be set to the automatic token and instead of the value from the secrets of the repository. The same is true forforge.FORGEJO_REPOSITORYetc.v6.4.0Compare Source
Do not use, it contains a regression fixed in 7.0.0.
v6.3.1Compare Source
v6.3.0Compare Source
v6.2.2Compare Source
v6.2.1Compare Source
v6.2.0Compare Source
container.optionsallows--hostname.v6.1.0Compare Source
[container].force_rebuildconfig option to force rebuilding of local docker images, even if they are already present.--one-jobflag to execute a previously configured runner, execute one task if it exists and exit. Motivation herev6.0.1Compare Source
[container].optionsconfig file setting was ignored.v6.0.0Compare Source
Configuration
📅 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 MR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this MR and you won't be reminded about this update again.
This MR has been generated by Renovate Bot.
mentioned in issue #1
mentioned in commit
1d18d227f3