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.
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.
(cherry picked from commit 848685d68d8bf7b7a38fea221db5e474cd30ea79)
(cherry picked from commit e8021f281f905e4499db4e67c91326932bfd613f)
(cherry picked from commit 2a4b3a2a4327c8000f0b583d91575c800c6035c4)
(cherry picked from commit 9cd0b93ad243f05e7dd17055782ac922dc91b6f0)
(cherry picked from commit ef1ddf0568444f2e9ea05a0e03d7e9d89f501cef)
(cherry picked from commit cd264666220a69d0159ce0ee996104ff25b4a5f2)
(cherry picked from commit 22d8ed2544a385cfa8621d4db2b436c376226c56)
(cherry picked from commit 22abd100cbab75673c53e4fb36fa574ada660aee)
(cherry picked from commit 4e2c30cb5bcd7a4e2b2385a774062492e741a9e9)
(cherry picked from commit 1ddc08747c8819e8967c95d54d3e273ef3831570)
(cherry picked from commit ba3df0131412c2eb41a3312558bc4df5881caad5)
(cherry picked from commit 644f7cb7338ae09b5ea7021132e93c70ba8fc771)
(cherry picked from commit f67a3f952cac7b9390b9dd2752bdf215a82e04b0)
(cherry picked from commit 23502a9b9fa92013d91295d8c9278601b31228c5)
(cherry picked from commit f8f345ae188fbf8f62e1471e7cc62a2db33d3e0e)
(cherry picked from commit e00eb6d9b32cbb294defb420e0305c544b9af239)
(cherry picked from commit f5f5eb53fa8cbd79473b3c6feccf54251c332f82)
(cherry picked from commit ab37e03bf34800a7780a653e998ad6f7a97f08f4)
(cherry picked from commit 2b527169f1f73574bcd5cb49e43ee87986f85996)
(cherry picked from commit 5fed32742e62315e0b0f483563f6f3f3e57af0fa)
(cherry picked from commit 861c05c2f308b0e7f4300b3f743830bb010588a3)
(cherry picked from commit fd0ebd1a6518b3b81f71c928a02903df655e5a74)
(cherry picked from commit 430f7d651902ab1e3e44ae27d9821d9132ee8a63)
(cherry picked from commit b33f3e2fe82d1e8d5368024938333e6a8c907e76)
(cherry picked from commit 5d4f9e47165a3c0adb30a078e6605b62cadbfc50)
(cherry picked from commit 33b4f02d90fec41d8525b22f312afa564c955067)
(cherry picked from commit fe783424e1e7c999446277f5d34f3885c861092f)