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.
(cherry picked from commit 97189d41f3)
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.
The release name, as provided by FORGEJO_RELEASE, is used to build OCI
images and binary files. Although it can be the same as the Forgejo
version, it is not a requirement.
When the FORGEJO_RELEASE environment variable is set, use it as a
default for naming the binary file instead of FORGEJO_VERSION. For
instance, when building from the forgejo branch here is what is desired:
FORGEJO_VERSION=7.0.0-g2343
GITEA_VERSION=1.22.0
VERSION=vforgejo-test
The name of the release is also displayed with forgejo --version
for sanity check purposes.
Before:
FORGEJO_VERSION is the computed version
GITEA_VERSION is set manually
VERSION defaults to FORGEJO_VERSION
forgejo --help does not display VERSION
After:
FORGEJO_VERSION is the computed version
GITEA_VERSION is set manually
RELEASE_VERSION defaults to FORGEJO_VERSION
VERSION defaults to RELEASE_VERSION
forgejo --help displays VERSION
* forgejo & v*/forgejo branches are mirrored to the forgejo-integration repository on every commit
* re-build a test release every time that happens
* forogejo => vforgejo-test
* v1.21/forgejo => v1.21-test
* v1.22/forgejo => v1.22-test
* etc.
Michael Kriese