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.
The user that caused the notification to re-evaluates the
schedules is not the one that will trigger the workflows. They are
background tasks that are authored by the action user (id -2).
Such a mis-assignment is problematic when the user that caused the
notification is deleted.
Fixes: https://codeberg.org/forgejo/forgejo/issues/3211
* Split TestPullRequest out of AddTestPullRequestTask
* A Created field is added to the Issue table
* The Created field is set to the time (with nano resolution) on creation
* Record the nano time repo_module.PushUpdateOptions is created by the hook
* The decision to update a pull request created before a commit was
pushed is based on the time (with nano resolution) the git hook
was run and the Created field
It ensures the following happens:
* commit C is pushed
* the git hook queues AddTestPullRequestTask for processing and returns with success
* TestPullRequest is not called yet
* a pull request P with commit C as the head is created
* TestPullRequest runs and ignores P because it was created after the commit was received
When the "created" column is NULL, no verification is done, pull
requests that were created before the column was created in the
database cannot be newer than the latest call to a git hook.
Fixes: https://codeberg.org/forgejo/forgejo/issues/2009
It is used in the CI to verify the S3 backend works. It has no
security or feature requirements and upgrading would only be required
when a major version is published, which cannot be deduced from the
version number.
Making that upgrade available from the dashboard and dealt with when
and if it gets the attention of a developer, even if once a year, is
good enough.
* 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.
They are bound to change. The worst that can happen is that the same
error happens somewhere else and is ignored although it should
not. Which is not worse than the previous situation which was to
ignore all errors anyway.
Also be more liberal about what is ignored. Some error messages are
very long and may contain elements with some variance. It is enough to
have an ignored that is specific.
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
Instead of failing or do things that could be damaging, this script
prints a deprecation notice. It fixes the unnecessary breaking
change introduced in `[I18n] tooling and process`.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/version-management/forgejo/default.nix#L80
$ make merge-locales
NOT NEEDED: THIS IS A NOOP AS OF Forgejo 7.0 BUT KEPT FOR BACKWARD COMPATIBILITY
$ go run build/merge-forgejo-locales.go
NOT NEEDED: THIS IS A NOOP AS OF Forgejo 7.0 BUT KEPT FOR BACKWARD COMPATIBILITY
Also remove the build/crowdin-to-weblate.sh script that was never
needed.
Existing Forgejo packages may rely on setting GITEA_VERSION to specify
the version to build if:
* they do not build from the git repository with the proper tag
* they build from a source tarbal that does not have a VERSION file
With 7.0 the logic of setting the version was modified in the
`[RELEASE] Gitea version is for interoperability only` commit and
ignores this variable which creates an unecessary breaking change.
If GITEA_VERSION is set, the versions will be set on 7.0 exactly as
they would have with version before and included 1.21.
* If GITEA_VERSION is not set, all versions are the same
* If GITEA_VERSION is set, there is a distinction between the version
set in the binary are returned by the Gitea API and the
version returned by the Forgejo API which includes metadata.
Before:
$ make GITEA_VERSION=7.0.0 show-version-full
7.0.0-dev-1809-cd6fa771ab+gitea-1.22.0
$ make GITEA_VERSION=7.0.0 show-version-api
7.0.0-dev-1809-cd6fa771ab+gitea-1.22.0
After:
$ make GITEA_VERSION=7.0.0 show-version-full
7.0.0
$ make GITEA_VERSION=7.0.0 show-version-api
7.0.0+gitea-1.22.0
The fix against the race incorrectly assumes the sha of the commit being
pushed belongs to the base repository. It finds the highest possible
pull request ID from the head repository instead of looking it up in
the base repository.
Figuring out if a PR was created in the future based on the highest
index of the base repository would require collecting all of them
because there is no way to know in advance which repository may be
involved in the race.
Fixing this race can be done either by:
* Introducing a new field in the pull_request table https://codeberg.org/forgejo/forgejo/pulls/2842
which feels more like a hack than a real solution
* Refactoring the logic
which would be a significant undertaking
The race has been in the codebase for a very long time and manifests
itself in the CI, when events happen in quick succession. The only
concrete manifestation was however fixed by https://codeberg.org/forgejo/forgejo/issues/2009
Since this race now only exists in theory and not in practice, let's
revert this bugous commit until a proper solution is implemented.
Fixes: https://codeberg.org/forgejo/forgejo/issues/2817
This reverts commit 036f1eddc5.
Conflicts:
services/pull/pull.go
5143ebb507 Add rel="nofollow" to issue filter links
has a test that fails because it assumes the link starts with the link
where it now starts with a ?
See also: [GITEA] Enable mocked HTTP responses for GitLab migration test
make GITLAB_READ_TOKEN=XXXX GO_TEST_PACKAGES='code.gitea.io/gitea/services/migrations/... -test.v' FLAGS= 'test#TestGitlabDownloadRepo'
to update the captured GitLab HTTP requests used for offline testing.
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.
Use setting.AppWorkPath instead of filepath.Dir(setting.AppPath). It
is the common denominator between:
* models/unittest/testdb.go:MainTest
* tests/test_utils.go:InitTest
which makes it usable in unit tests as well as integration tests.
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
Gitea versions are
* A.B.C
* A.B.C+rc-0
* A.B.C+dev-5-g4fb9056
If Forgejo versions are:
* X.Y.Z+A.B.C
* X.Y.Z-rc0+A.B.C
* X.Y.Z-dev-1232-g4fb905687+A.B.C
It is non trivial for a client trying to sort out if the server
responding to `/api/v1/version` is Forgejo or Gitea. The Forgejo
version changes to be:
* X.Y.Z+gitea-A.B.C
* X.Y.Z-rc0+gitea-A.B.C
* X.Y.Z-dev-1232-g4fb905687+gitea-A.B.C
and a client can now:
* Split the version with +
* If the second part (the metadata) exists and contains "gitea", the
answer server is Forgejo
* Otherwise it is Gitea
The release number displayed by the API and the CLI becomes:
7.0.0+1.22.0
instead of
1.22.0
It would otherwise be inconsistent to have different version number depending on the interface. With the current implementation `/api/forgejo/v1/version` would return `7.0.0+1.22.0` while `/api/v1/version` would return `1.22.0`. The release would be announced as `7.0.0+1.22.0` but the web API would display `1.22.0`.
It may cause some tools that are Gitea specific to not behave as they should in the future if they expect a Gitea version number and activate some features depending on what it is. They would need to be patched to strip the leading Forgejo version number before asserting the Gitea version.
Refs: https://codeberg.org/forgejo/forgejo/issues/2425
Split prepareWorkPathAndCustomConf out of the actions sub-command.
In the CLI prepareWorkPathAndCustomConf is a preparation step that is
needed before running the sub-command actions in the Forgejo CLI. It
is currently specific to this sub-command but it will be useful for
other sub-commands such as F3.
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.
Refactor locale&string&template related code has .Title be
template.HTML and "Improve HTML title on repositories" needs to check
the prefix with StringUtils.HasPrefix
Forgejo now has its own lifecycle and its version is derived from the
tag. The Gitea tags are no longer found in the Forgejo codebase and
can no longer be used for that purpose.
When a Forgejo release is published, for interoperability with the
existing tools in the ecosystem, it advertises the supported Gitea
version via /api/v1/version. It is set in the Makefile manually and
cannot be automatically set.
https://codeberg.org/forgejo-contrib/delightful-forgejo#packaging
Existing Forgejo packages rely on the Makefile to build and the change
must be done in a way that tries to not break their assumptions. From
the point of view of a Forgejo package build, the following will
happen on the next major release:
- The package version will bump from v1.21.x to v7.0.0
- /api/v1/version will bump from v1.21.x to v1.22.0
- /api/forgejo/v1/version will bump from v6.x to v7.0.0
The Makefile uses the following variables:
GITEA_VERSION is returned by /api/v1/version
FORGEJO_VERSION is returned by /api/forgejo/v1/version
VERSION is used in the name the binary file and the source archive
Before:
GITEA_VERSION is the computed version
FORGEJO_VERSION is set manually
VERSION defaults to GITEA_VERSION
After:
FORGEJO_VERSION is the computed version
GITEA_VERSION is set manually
VERSION defaults to FORGEJO_VERSION
When the version is computed, it comes from:
- The content of the VERSION file if it exists. It is inserted in
the source archive because it does not contain a git repository
- Otherwise the output of `git describe`
Skip a HookEventPullRequestSync event if it has the same CommitSHA as an existing HookEventPullRequest event in the ActionRun table. A HookEventPullRequestSync event must only create an ActionRun if the CommitSHA is different from what it was when the PR was open.
This guards against a race that can happen when the following is done in parallel:
* A commit C is pushed to a repo on branch B
* A pull request with head on branch B
it is then possible that the pull request is created first, successfully. The commit that was just pushed is not known yet but the PR only references the repository and the B branch so it is fine.
A HookEventPullRequest event is sent to the notification queue but not processed immediately.
The commit C is pushed and processed successfully. Since the PR already exists and has a head that matches the branch, the head of the PR is updated with the commit C and a HookEventPullRequestSync event is sent to the notification queue.
The HookEventPullRequest event is processed and since the head of the PR was updated to be commit C, an ActionRun with CommitSHA C is created.
The HookEventPullRequestSync event is then processed and also has a CommitSHA equal to C.
Refs: https://codeberg.org/forgejo/forgejo/issues/2009
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2314
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
Earl Warren