GITHUB_TOKEN does not have permission to write the repository and is
not allowed to edit or comment on pull requests because of that. A PAT
from a regular user who does **not** have permission to write to the
repository either but who is in a the contributors team will have
permissions to do that because there is a "write pull request"
permission given to the team.
If the 'worth a release-note' label is set, add a release note entry
to the description of the pull request as a preview.
* use the `release-notes/<pr-number>.md` file if any
* otherwise use the pull request title
Refs: https://code.forgejo.org/forgejo/release-notes-assistant
When a new go version is published, it takes about 24h for
https://github.com/actions/go-versions to be updated (see
https://github.com/actions/go-versions/pull/102 for example).
In the meantime the setup-go action that depends on it will install a
version of go that fails golang.org/x/vuln/cmd/govulncheck.
Move the security check to be the last step of the test job instead of
the first. It will still block the PRs from being merged but it will
allow the PR authors to keep working and look at the test results in
the meantime.
Fixes: https://codeberg.org/forgejo/forgejo/issues/4294
For #4082.
~~Per the discussion in the issue, the current plan will likely involve duplicating the redis library calling code once for each cacher, as neither garnet nor redict guarantee continued compatibility with redis.~~
See discussion below for details.
## Tasklist
- [x] Write workflow to run cache-specific unit test(s) only (cache, session, queue, nosql) for each cacher
- [x] Check whether garnet and redict pass unit tests with no code modification (gauge required work)
- both passed, but that is because there were very few tests that test the remote cache store
### Out of scope for this PR
- Improve test coverage
- `modules/cache` against a server
- `modules/session` against a server (also needs tests in general)
- _(?) Duplicate implementation for each cacher_
- _Restructure redis usage in `modules/cache` and `modules/settings/cache`_
- _Restructure `modules/session` and its settings_
- _Restructure `modules/queue` and its settings_
- _Restructure `modules/nosql` and its settings_
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4138
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Elias Elwyn <a@jthv.ai>
Co-committed-by: Elias Elwyn <a@jthv.ai>
This updates the mapping definition of the elasticsearch issue indexer backend to use `long` instead of `integer`s wherever the go type is a `int64`. Without it larger instances could run into an issue.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3982
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
There is no need to pin a specific patch version for testing. The
worst that can happen in this context is that the CI fails and it can
be addressed in this context. It will not impact releases.
For security reasons, scoping access to a redis server via ACL rules is
a good practice. Some parts of the codebase handles prefix like cache[^1]
and session[^2], but the queue module doesn't.
This patch adds this missing functionality to the queue module.
Note about relevant test:
I tried to keep the PR as small as possible (and reasonable), and not
change how the test runs. Updated the existing test to use the same
redis address and basically duplicated the test with the extra flag. It
does NOT test if the keys are correct, it ensures only it works as
expected. To make assertions about the keys, the whole test has to be
updated as the general wrapper doesn't allow the main test to check
anything provider (redis) specific property. That's not something I
wanted to take on now.
[^1]: e4c3c039be/modules/cache/cache_redis.go (L139-L150)
[^2]: e4c3c039be/modules/session/redis.go (L122-L129)
Signed-off-by: Victoria Nadasdi <victoria@efertone.me>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3836
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Victoria Nadasdi <victoria@efertone.me>
Co-committed-by: Victoria Nadasdi <victoria@efertone.me>
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.
