The ARG RELEASE_VERSION set in the build-env image does not propagate
to the images that follow. As a result the value of the version label
is always empty.
This should have been caught by the test in the CI but although it
notified the problem in the output, it did not fail. Upgrade to the
forgejo-build-publish version that fixes this false positive.
* no-auto-squash: true so it DTRT for merged & squashed PRs
* target-branch-pattern: replaces the ad-hoc logic to determine the
target branch name
It also now supports backporting to multiple branches. This is not
going to be immediately useful but will greatly help in three months
when there are two releases receiving backports.
It was necessary in the debug period to help with a faster debug
loop. Now that it works reliably, there is no need for renovate
updates more than once a day.
It will still possible to force a run, should it be necessary, by
re-running the last scheduled job.
The intention was good initially but the expression was wrong for two
reasons:
* When a pull_request event is received for a labeled action, the
match should be github.event.action == 'label_updated' and not
'labeled'
* The event does not have a github.event.label field and
contains(github.event.label.name, 'backport/v') will always be
false.
Since the expression is only evaluated in the context of a merged pull
request, either because it was just closed or because it was labeled
after the fact, the only verification that is needed is to assert that
there is at least one `backport/v*` label.
strategy: ort
The strategy is changed from "recursive" to "ort", which is the
default for git >= 2.43.2 and claims to reduce the likelyhood of
conflicts according to man git-merge:
> This has been reported to result in fewer merge conflicts without
> causing mismerges...
strategy-option: find-renames
The default option are the same for both strategies and "theirs" will:
> This option forces conflicting hunks to be auto-resolved
> cleanly by favoring their version.
"their" being whatever is not in the commits being cherry-picked.
In the context of Forgejo backports, this is not what is desired:
whenever a conflict happens it needs to be manually resolved and
prefering whatever is in the stable branch will not lead to a sane
backport.
It is changed back to "find-renames" which is documented to be the
default:
> Turn on rename detection, optionally setting the similarity
> threshold. This is the default.
Fixes: https://codeberg.org/forgejo/forgejo/issues/2886
Now that Forgejo has its own release number, use the Makefile as a
reference.
Also document and improve support for debugging this
pull_request_target workflow by using a branch in the repository.
Now that semantic versions are used, the major version must be used
instead of major.minor to distinguish releases with breaking changes.
Before:
Forgejo v1.21.1-0, tags 1.21.1-0 and 1.21
Forgejo v1.21.2-0, tags 1.21.2-0 and 1.21
Forgejo v1.22.1-0, tags 1.22.1-0 and 1.22
After
Forgejo v7.0.0 tags 7.0.0 and 7
Forgejo v7.0.1 tags 7.0.1 and 7
Forgejo v7.1.2 tags 7.1.2 and 7
Forgejo v8.0.1 tags 8.0.1 and 8
Also ignore the *-test tags when figuring out the Forgejo version,
they exist in the integration repository and experimental repository
for daily releases.
