Forgejo only added the legacy `gitea_default_actions_url`.
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13406
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This PR moves the release assets above the code archives on the releases page, as the assets are likely what the user is looking for compared to the code archive.
resolves#12534.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13038
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
The admin system status template wraps the server start time in
<relative-time format="duration"> intending to display elapsed time as
a bare duration ("two months"), but the custom element ignored the
format attribute and always rendered "two months ago". Implement the
duration mode using Intl.NumberFormat with style: "unit" so the same
calendar-aware diffing produces a localized, suffix-free string.
Resolves https://codeberg.org/forgejo/forgejo/issues/12078
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12415
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
- Fix migrating https://github.com/charlesrocket/freebsd-collection. It
has 2 issues and 43 pull requests.
- This creates the interesting situation: len(issues) = 45. perPage = 45
thus no stop condition. But! resp.After is empty, so on the next request
the same list of issues is requested and then runs into unique
constraint failure.
- Make the stop condition based if resp.After is empty, thus indicating
its the last page.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13331
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
I noticed that when generating a repo from a template repo, if a file in the template repo contains an unrecognized variable reference (not part of the set of variables that Forgejo replaces), it attempts to expand it anyway, and ultimately replaces it with just the variable name, stripping off the `$` or `${}`. For example, if a file contains `Authorization: Bearer ${ACCESS_TOKEN}`, in the generated repo this will be changed to `Authorization: Bearer ACCESS_TOKEN` which is unexpected and undesired.
I considered whether it would be possible to fix this by simply making the function passed to `os.Expand()` return `${VARIABLE_NAME}` instead of just `VARIABLE_NAME` for unrecognized keys, but this wouldn't work because it's not possible to distinguish between `$VARIABLE_NAME` and `${VARIABLE_NAME}` syntax, so some variable references would get mangled anyway. Instead, I fixed it by adding a simple regex and using that to perform the replacements instead of `os.Expand()`. I added unit tests and updated one of the generated repo integration tests to validate the functionality.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12917
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Continuation of #10598Closes#7254
Implement repo granular watch selection
I adopted a lot of the frontend from #10598 while redoing the entire back-end. I propose this new model:
- Remove the WatchMode enum.
- Add the WatchSelection struct, which represents the granular selection. Notice that there is no `watching` bool. I tried very hard to keep the structure as simple and redundancy-free as possible. Therefore, people not watching a repo at all either don't have a watch record or one with an entirely unselected WatchSelection struct.
- Add the WatchSource enum. It replaces the WatchMode enum and has a single purpose: determine whether a watch was explicitly or automatically initiated.
Notice that replacing this
```go
And("`watch`.mode<>?", WatchModeDont).
```
with this is correct:
```go
And(
builder.Or(
builder.Eq{"`watch`.watch_selection_issues": true},
builder.Eq{"`watch`.watch_selection_pull_requests": true},
builder.Eq{"`watch`.watch_selection_releases": true},
),
).
```
That's because there are four modes: dont, none, auto and normal. When `<>` with dont, we look for auto and normal, because there are no records with none. Therefore, the old code looks for records that indicate watching. The code I replaced this with does so, too, just more granular.
Also notice that I've prepared a future `user preset` in a few places. See below for a little more info on that.
## Next PR
I plan to continue working on this. I want to implement a `user preset` option. The user sets that `user preset` in her settings and may use them in any repo.
<details>
- rename account settings to account and notifications
- user preset (always use this preset for newly accessible repos (according to AutoWatchOnChanges and AutoWatchNewRepos))
</details>
## Further PRs
- make api able to granular watch
- move (email) notifications to new notifications tab
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10927
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
- adjusted the starting for the acme HTTP handler to use `net.JoinHostPort` to join host and port
- Resolves#12274
- I tested on my server which only had ipv6 enabled.
- Log message before fix: `...s/graceful/server.go:76:ListenAndServe() [E] Unable to GetListener: address [[::]:443]:443: too many colons in address`
- Log message after fix: `...s/graceful/server.go:50:NewServer() [I] Starting new Let's Encrypt HTTP Challenge server: tcp:[::]:80 on PID: 31302`
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13367
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Forgejo's git pre-receive hook validates whether the authenticated user can write to the target branch during a push operation. A caching performance optimization in the hook caused the pre-receive hook to validate only the first branch reference in the push. While typically a push operation has the same rights for all branches on a repository, some exceptions exist which could allow a user to push to a branch, pass the validation, and then bypass checks on additional references due to the cache. The cache has been removed, forcing all references to be validated for code write permissions.
Thanks to Gitea for identifying this issue in https://github.com/go-gitea/gitea/pull/38103/changes/f25811942cea35233299efdbdfeec40663d4807a. This effort has been re-engineered for Forgejo, consistent with Forgejo's AI Agreement.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13370
Reviewed-by: Beowulf <beowulf@beocode.eu>
Adds an extra check to ensure the `keyId` and `actorId` included in signed requests and actor records point back to the originating host.
This check prevents server-side request forgery (SSRF) attacks where a carefully crafted request could be used to trick a federation server into making requests to arbitrary hosts and ports.
Further refactors can make these checks more robust, but would better fit after other existing refactor PRs are merged.
Related: https://codeberg.org/forgejo/forgejo/issues/11779
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11795
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Resolves https://codeberg.org/forgejo/forgejo/issues/13319.
### Tests for Go changes
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13338
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This is a monster transaction, it touches a lot of tables and happily
locks many rows which results in all other operations waiting on this
transaction to finish. In a lot of cases this operation is fast and for
many this wouldn't be a problem, however on Codeberg we've observed that
when large (many issues, comments and PRs specifically) repository is
being deleted it can result in the instance being unreachable to do any
other modification to it.
This is not fixable for SQLite (although if you get such large
repositories and has many concurrent writes, then maybe SQLite is no
longer a good choice) as transactions are always of the SERIALIZABLE
level.
PostgreSQL default isolation level is READ COMMITTED and seems to me
the observed behavior on Codeberg wouldn't happen here unless the
default isolation level is to be made REPEATABLE READ or SERIALIZABLE.
MySQL/MariaDB default isolation level is REPEATABLE READ and that gets
the behavior of rows being locked (even those that aren't being
modified). And this is where this patch is effective to make this
transaction a bit less of a monster.
There's a small risk of making this transaction READ COMMITTED, there's
a window where new records can be created for this repository which will
then not be deleted. These will eventually be solved by foreign keys,
currently most can still be removed after the fact by the
`check-db-consistency` doctor check.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12856
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
follow-up to #13306
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org).
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13340
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
- Use context.ReferencesGitRepo to populate `GitRepo`.
- Add two extra query fields in swagger.
- Simplify how infos is parsed.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13314
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Job logs now render OSC 8 hyperlink escape sequences as clickable links in the Actions log viewer, so the Forgejo log has clickable links. A workflow step opts in by emitting the OSC 8 sequence (`ESC ] 8 ; ; <url> ESC \ <text> ESC ] 8 ; ; ESC \`), which is the same escape code terminals already use for links.
Hardens the anchors `ansi_up` emits: adds `rel="noopener noreferrer nofollow"` and `target="_blank"`, and drops any link whose scheme is not http or https.
## Checklist
### Tests for JavaScript changes
- I added test coverage for JavaScript changes...
- [x] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server.
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13085
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
fixes#13305
### Tests for Go changes
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13306
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
fixes#13295
### Tests for Go changes
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13299
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
- separate test cases from fixtures
- testcase.go: A `testCase` describes a test using `testData`
- fixture.go: `fixture*` are function that creates the conditions for this test case to run
- move the testData closer to the beginning
- update the README.md
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13271
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Regression in #12776 -- `[service].REQUIRE_SIGNIN_VIEW` and `[service.explore].REQUIRE_SIGNIN_VIEW` values were being cached into a constructed middleware during module initialization, before the `settings` object had been initialized by reading settings from the config. As a result, neither setting applied to the middleware. Apparently zero automated tests cover this capability.
Fixed by changing the bool into a closure for realtime access to the setting. Added automated tests. Verified that the tests failed when broken.
### Tests for Go changes
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
- Prerelease regression.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13304
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This will allow us to enforce RTL-friendly logical CSS properties in the go template files.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13216
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This ensures we use the right go toolchain on docker build even if there is an older image already cached.
Tested manually:
- `docker buildx build --progress plain -f Dockerfile.rootless .` currently is up-to-date
- change `build-env` image to `golang:1.24-alpine3.22` and run again: see `go: downloading go1.25.3 (linux/amd64)` in output
```diff
diff --git a/Dockerfile.rootless b/Dockerfile.rootless
index 2dbcd6ddd2..8c6ac5f266 100644
--- a/Dockerfile.rootless
+++ b/Dockerfile.rootless
@@ -1,6 +1,6 @@
FROM --platform=$BUILDPLATFORM data.forgejo.org/oci/xx AS xx
-FROM --platform=$BUILDPLATFORM data.forgejo.org/oci/golang:1.25-alpine3.22 AS build-env
+FROM --platform=$BUILDPLATFORM data.forgejo.org/oci/golang:1.24-alpine3.22 AS build-env
ARG GOPROXY
ENV GOPROXY=${GOPROXY:-https://proxy.golang.org,direct}
@@ -10,10 +10,13 @@ ARG TAGS="sqlite sqlite_unlock_notify"
ENV TAGS="bindata timetzdata $TAGS"
ARG CGO_EXTRA_CFLAGS
+RUN go env
+
# it's set to local by default in the base image
# we want to use auto to let go choose the right toolchain
ENV GOTOOLCHAIN=auto
+
#
# Transparently cross compile for the target platform
#
@@ -37,6 +40,9 @@ RUN apk --no-cache add build-base git nodejs npm
COPY . ${GOPATH}/src/forgejo.org
WORKDIR ${GOPATH}/src/forgejo.org
+
+RUN set -ex; go env;
+
RUN make clean-no-bindata
RUN make frontend
RUN go build contrib/environment-to-ini/environment-to-ini.go && xx-verify environment-to-ini
```
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9837
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
The rationale for this decision is the apparent confusion regarding the number of issues that were presented.
For a query such as `foo bar` the natural expectation would be results that contain both `foo` and `bar` not either `foo` or `bar`.
However, for a query such as `+foo bar` the result MUST contain `foo`, while `bar` affects only the scoring of issues.
A downside of such an approach is the inability to fully represent `foo OR bar` as the current implementation imposes that the query must contain atleast one MUST (or MUST NOT) term.
closes#12935
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13025
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
The username used for the activitypub server actor, "actor" (internal userid -3), was freely available to be registered for any user.
With this patch, it's added to the reversed username list to prevent future creations of such accounts.
Existing users will not be impacted and need to be manually resolved.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13077
Close#13250
ExtraLinesCount was not send to reply template
### Tests for Go changes
- I added test coverage for Go changes...
- [X] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [X] `make pr-go` before pushing
### Documentation
- [X] I did not document these changes and I do not expect someone else to do it.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13258
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Test failure: https://codeberg.org/forgejo/forgejo/actions/runs/174007/jobs/2/attempt/1 Have only observed once and can't reproduce locally, but likely caused by #13263 / #13289.
```
--- FAIL: TestGetDiffPreview (0.20s)
--- FAIL: TestGetDiffPreview/empty_branch,_same_results (0.02s)
diff_test.go:132:
Error Trace: /workspace/forgejo/forgejo/services/repository/files/diff_test.go:132
Error: Received unexpected error:
unable to run diff-index pipeline in temporary repo: exec: canceling Cmd: invalid argument
Test: TestGetDiffPreview/empty_branch,_same_results
FAIL
```
pidfd_open is [documented](https://www.man7.org/linux/man-pages/man2/pidfd_open.2.html) to return the EINVAL (invalid argument) error if the pid is not valid, which could happen if the process terminates itself before Forgejo sends `SIGTERM`. This PR adds a check for that error and stops `Cancel`, with a minor refactor to avoid code duplication.
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13293
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
For debugging running `make coverage-run-sqlite` does not need to always run migration tests. Split the target so integration coverage can be called independently from migration coverage.
Add the `coverage-reset` target to dispose of previous coverage data that will interfere if the goal is to verify the coverage percentage, for instance.
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13168
Reviewed-by: Clouds <me@cloudsftp.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Some files excluded from the nilnil lint and listed in https://codeberg.org/forgejo/forgejo/issues/11261 contain no violations of the lint anymore. I removed them from the list. They are
- `routers/api/packages/container/auth.go`
- `routers/api/packages/nuget/auth.go`
- `routers/web/repo/setting/runners.go`
- `services/issue/commit.go`
- `services/migrations/onedev.go`
Other files contained lints that are triggered by returning `nil` for maps. This can be mitigated easily by returning `make(map[...]...)`. All except one of those return statements are already covered by tests. I list the ones that have coverage now, the statement that has no coverage was not changed.
### Tests for Go changes
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13230
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Enables the title of workflow runs to be defined from the `run-name` value in the workflow. This is the Forgejo side of the `run-name` implementation, started on forgejo/runner in PR [1575](https://code.forgejo.org/forgejo/runner/pulls/1575).
### Tests for Go changes
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Documentation
- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [ ] I did not document these changes and I do not expect someone else to do it.
See docs PR [2020](https://codeberg.org/forgejo/docs/pulls/2020)
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/13114): <!--number 13114 --><!--line 0 --><!--description ZmVhdChhY3Rpb25zKTogYWRkIHN1cHBvcnQgZm9yIHVzaW5nIHdvcmtmbG93IGBydW4tbmFtZWAgYXMgcnVuIHRpdGxl-->feat(actions): add support for using workflow `run-name` as run title<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: klausfyhn <klausfyhn@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13114
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Refs forgejo/design#63
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13277
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Close#13239
Implement the same behaviour as the gitea_uploader
### Tests for Go changes
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [X] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
### Documentation
- [X] I did not document these changes and I do not expect someone else to do it.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13257
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
