When you hover over the link:
This PR:
Fixes#9413
## Testing
1. Go to any issuelist with at least one issue.
2. Hover the cursor over the link, which contains a `#` followed by the issue number.
3. Observe, where the link ends, by seeing what gets underlined.
4. Notice, that this includes the space after the issue number without this PR, but not with this PR.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12591
Reviewed-by: Beowulf <beowulf@beocode.eu>
Fixes#2325.
This introduces a way to download downsized versions of the user and repository avatars:
* `/avatars/123abcd` still serves the full-size avatar
* `/avatars/123abcd?size=64` serves it at size 64x64 px
Those downsized versions are computed on demand when requested for the first time and cached. The caching is done in a storage location configurable in the instance settings, just like the storage locations for the full-sized avatars are. The sizes of the downsized images are restricted to a fixed set of sizes, so that the cache doesn't grow too big. The caching and resizing logic is exposed in a way that could potentially be reused for other types of images (such as user uploads in issue discussions).
Luckily, the Go templates already specify in many places which size those avatars should be rendered, even if this information was only used for external avatar providers (such as Gravatar) until now.
The range of sizes requested by the HTML templates is rather wide: the table below lists all the sizes I could find, and the corresponding size served by the backend with the logic I implemented. The scaling factor of 2 was already used for requesting resized external avatars, and likely exists to make sure that users with display scaling enabled get a sharper picture.
| Size requested in the template | After scaling (x2) | Size of the image served |
|---------|---------|---------|
| 256 px | 512 px | original (512 px) |
| 140 px | 280 px | original (512 px) |
| 48 px | 96 px | 128 px |
| 40 px | 80 px | 128 px |
| 32 px | 64 px | 64 px |
| 28 px | 56 px | 64 px |
| 24 px | 48 px | 64 px |
| 20 px | 40 px | 64 px |
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11242
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
- Validate and sanitize topics.
- Cap topics at 25 (limit used elsewhere, now unified constant).
- Add more details and rephrase common user-facing error messages.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12577
The bleve indexer included a fast path to consider a single token to be of MUST rather than should.
However, the condition missed an additional check and would erroneosly include a NOT as a MUST.
This was not spotted by the tests as such exclude queries were usually made along with another term to avoid noise.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12589
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
When a forking target organization was supplied, the API handler only verified
org membership. This is asymmetric with the rest of the codebase, as
CanCreateOrgRepo is used everywhere else.
## 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
(can be removed for JavaScript 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.
- [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.
*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.
Co-authored-by: jvoisin <julien.voisin@dustri.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12442
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
The session cookie has no Max-Age, so it is lost when the browser closes. The password flow compensates via a "Remember me" checkbox issuing an LTA cookie; OAuth2/OIDC sign-in had no such UI.
Issuing a regular LTA cookie after an OAuth callback would skip the IdP for LOGIN_REMEMBER_DAYS. Instead, this introduces a separate LongTermAuthorizationSSO purpose: the cookie is opt-in via the existing "Remember me" checkbox, and when presented without a session, autoSignIn redirects through the IdP with OIDC prompt=none for silent re-auth. On login_required / interaction_required / consent_required / account_selection_required
we transparently fall back to interactive sign-in.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12321
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
The race condition on the test is happening because, we are immediately
calling `page.goto()` after the `Commit changes` button is clicked
without waiting for the previous redirect to finish. This interruption leads
to the error: `Error: page.goto: Target page, context or browser has been
closed`.
By adding the `await expect(page).toHaveURL`, Playwright waits for the
redirection and verifies the URL and then finally go to the next `await
page.goto()` to go to the `edit` page of the file.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12554
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Forgejo erroneously links to Forgejo Actions artefacts that have been deleted due to expiration. The commit message of 460a2b0edf that introduced the feature describes the desired behaviour: "artifacts link in actions view should be non-clickable text when expired."
Resolves https://codeberg.org/forgejo/forgejo/issues/3653.
## 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
(can be removed for JavaScript 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
### Tests for JavaScript changes
(can be removed for Go 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 (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### 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/12550
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Fixes https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/112.
Currently boolean `workflow_dispatch` values are being passed as strings during Forgejo's job parsing, causing both true & false to have the same behaviour when evaluated in a condition like this:
```
on:
workflow_dispatch:
inputs:
win32:
type: boolean
jobs:
job1:
strategy:
matrix:
runner: ${{ fromJSON(inputs.win32 == 'true' && '["win32", "win64"]' || '["win64"]') }}
steps: # ...
```
## 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...
- [ ] 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...
- [ ] `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/12539
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
### Context
Following the feedback in forgejo/discussions#170 (and my ambitious attempt in forgejo/forgejo#10985), it appears that having an easy-to-use factory package would greatly help get rid of the global fixtures.
I think that the global fixtures are quite harmful (recent example: https://codeberg.org/forgejo/forgejo/pulls/9906#issuecomment-10826066):
- hard to write (contributor must know where to add them)
- hard to change (may break some unrelated tests)
- hard to review (not located near the test code)
- they require the tests to execute sequentially
### Proposed way forward
The `forgery` package (the name represents faking/crafting and sounds good with Forgejo) is meant to replace global yaml fixtures with local go factories. The forgery can currently:
- create users
- create repos
- create organisations
This allowed me to drop `CreateDeclarativeRepoWithOptions` (and deprecate `CreateDeclarativeRepo`).
I think that further changes should be delayed to other PRs (I have a local branch to create `Project`)
### 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.
*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/11356
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
These tests are failing in the Last Two Days in the latest test report.
Error:
```
61 |
62 | // A modal dialog appears
> 63 | await expect(page.locator('#add-member-modal')).toBeVisible();
| ^
64 |
65 | // Fill in the name of the user to add
66 | await page.locator('#search-user-box input').fill('user5');
at /workspace/forgejo/forgejo/tests/e2e/org-members.test.e2e.ts:63:51
```
The `page.goto` in the tests are unawaited, which leads to the page not
fully loaded to proceed with the next lines to check for visibility.
The fix is to add `await` on `page.goto()` in all the missing places in
this test file - `org-members.test.e2e.ts`.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12525
Reviewed-by: Otto <otto@codeberg.org>
Forgejo Actions keeps one set of artifacts per workflow run -- those of the latest workflow run. If a particular workflow run is rerun, Forgejo is supposed to remove outdated artifacts. However, it does not do that. As a result, the user is presented a mix of outdated and new artifacts, even within the same archive.
This is remedied by wiping the artifacts before each rerun. The same happens when only one or more jobs are rerun, which also matches the behaviour of GitHub Actions. In the example below, when only rerunning `artifacts-two`, `many-artifacts-one` would disappear and a new version of `many-artifacts-two` would be made available.
Reproducer:
```yaml
on:
push:
jobs:
artifacts-one:
runs-on: ubuntu-latest
steps:
- run: mkdir -p artifacts-one
- run: |
if [[ "${{ github.run_attempt}}" == 1 ]] ; then echo "${{ github.run_attempt}}" > artifacts-one/ONE; fi
echo "${{ github.run_attempt}}" > artifacts-one/TWO
- uses: forgejo/upload-artifact@v4
with:
name: many-artifacts-one
path: artifacts-one/
artifacts-two:
runs-on: ubuntu-latest
steps:
- run: mkdir -p artifacts-two
- run: |
if [[ "${{ github.run_attempt}}" == 1 ]] ; then echo "${{ github.run_attempt}}" > artifacts-two/ONE; fi
echo "${{ github.run_attempt}}" > artifacts-two/TWO
- uses: forgejo/upload-artifact@v4
with:
name: many-artifacts-two
path: artifacts-two/
```
Resolves https://codeberg.org/forgejo/forgejo/issues/12163.
## 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
(can be removed for JavaScript 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
### Tests for JavaScript changes
(can be removed for Go changes)
- I added test coverage for JavaScript changes...
- [ ] 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 (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### 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/12523
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This change renders file links in org-mode like `./module.el::20` as a link to the 20th
line, for example. It also strips off other search types that are not currently supported
in forgejo like regex search to avoid generating invalid URLs.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12496
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
# Feature Request: Admin API route to manage access tokens for any user
## Problem
The existing API route to create access tokens (POST /api/v1/users/{username}/tokens) requires Basic authentication (username + password) via the reqBasicOrRevProxyAuth() middleware. This is by design: a token should not be created from another token.
However, this creates a blocker for environments where Basic authentication is disabled (ENABLE_BASIC_AUTHENTICATION = false), typically when authentication is delegated to an external SSO provider (e.g., OpenID Connect).
In such setups, bot/service accounts are provisioned by an external system that needs to:
Create a user via POST /api/v1/admin/users (works fine with an admin token)
Create an access token for that user (currently impossible without Basic auth or direct CLI/DB access)
The only workaround today is to SSH into the Forgejo server and run:
This is not suitable when the provisioning system has no direct access to the Forgejo host.
## Proposed solution
Add new admin-only API routes under the existing /api/v1/admin/users/{username} group to manage access tokens:
| Method | Route | Description |
|:-------- |:--------:| --------:|
| GET | /api/v1/admin/users/{username}/tokens | List access tokens for a user|
|POST | /api/v1/admin/users/{username}/tokens | Create an access token for a user|
|DELETE | /api/v1/admin/users/{username}/tokens/{id} | Delete an access token for a user|
These routes would:
Require a site admin token (reqToken() + reqSiteAdmin()) — no Basic auth needed
Use the AccessTokenScopeCategoryAdmin token scope
Reuse the existing handler logic from user.CreateAccessToken / user.ListAccessTokens / user.DeleteAccessToken
Accept the same request/response payloads as the existing user-facing routes
### Why this belongs in the admin API
It follows the existing pattern: admins can already create users, repos, orgs, SSH keys, and emails for any user via the admin API
It does not weaken security: only site administrators can call it, and it requires a valid admin-scoped token
It fills a gap: the admin CLI command forgejo admin user generate-access-token already provides this capability, but only locally
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12323): <!--number 12323 --><!--line 0 --><!--description ZmVhdChhcGkpOiBhZGQgYWRtaW4gcm91dGVzIHRvIG1hbmFnZSB1c2VyIGFjY2VzcyB0b2tlbnM=-->feat(api): add admin routes to manage user access tokens<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12323
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Add the ability to remove workflow runs, either using the UI or the HTTP API. Workflow runs can only be removed once a workflow run has completed. For security reasons, only a repository administrator or a token with `write:repository` permissions can remove runs.
Resolves https://codeberg.org/forgejo/forgejo/issues/2184.
## 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
(can be removed for JavaScript 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
### Tests for JavaScript changes
(can be removed for Go changes)
- I added test coverage for JavaScript changes...
- [ ] 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 (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12478): <!--number 12478 --><!--line 0 --><!--description bWFrZSBpdCBwb3NzaWJsZSB0byByZW1vdmUgd29ya2Zsb3cgcnVucw==-->make it possible to remove workflow runs<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12478
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
There are two test groups in `issue-sidebar.test.e2e.ts` which behaves
flaky on CI:
- Toggle WIP
- Dependency dropdown
1. **Toggle WIP**:
There is a race-condition happening with this test execution, when we
toggle the WIP status "Still in progress?" / "Ready for review?", there
is a page reload that happens once we select either of the option and
when we use window.WaitForLoadState('domcontentloaded')` it just check
the state of the current dom and not the reloading of the page.
To mitigate this, we need to use a promise call with
`page.WaitForEvent('load')` wherever necessary. This change has been
applied in the `setTitle` and `toggle_wip_to` helper functions.
Also there is a refactor logic where we remove the repetitive call for
click and save events on `manual edit` and `maximum_title_length` and
consistently use the setTitle.
2. **Dependency dropdown**
There is flakiness with this code:
```
await input.fill('1');
await expect(items.first()).toContainText(first);
```
We register the issues via `postIssue` in the `declare_repo_test.go`
file. And the catch is about this issue popping up for the above logic:
```
postIssue(repo, user, 500, "first issue here", "an issue created earlier")
postIssue(repo, user, 400, "second issue here (not 1)", "not the right issue, but in the right repo")
```
On each issue creation, the frontend shows the index as `#1`, `#2`,
respectively.
The issue is when we search for 1, the indexer implementation finds the
highest scoring with relevant sorting order. These are the two issues
that pops up in the first two results.
```
#1 first issue here
#2 second issue here (not 1)
```
In the above results, sometimes the #2 issue will be shown as the first
item in the dropdown results because it contains the exact match `1` in
(not 1). Hence the solution is to remove the `(not 1)` from the second
issue to fix this flakiness behaviour.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12473
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Sign the distributed version of `.well-known/security.txt`, just like https://forgejo.org/.well-known/security.txt is signed.
```
$ gpg --verify ./security.txt
gpg: Signature made Sat 09 May 2026 05:59:29 PM MDT
gpg: using EDDSA key 1B638BDF10969D627926B8D9F585D0F99E1FB56F
gpg: Good signature from "Forgejo Security <security@forgejo.org>" [unknown]
Primary key fingerprint: 1B63 8BDF 1096 9D62 7926 B8D9 F585 D0F9 9E1F B56F
```
In the future this signature will have to be updated before the key expires; but as the expiry is already documented in the file this isn't significantly different than the current state.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12502
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Add `gnupg` as part of the Nix-based development environment, which is a dependency for a small number of integration tests like `TestInstanceSigning`. Bumps `flake.lock` from its current 2025-11-12 to current 2026-05-05 pin, bringing updated tools referenced in `shell.nix`.
```
$ nix flake update
• Updated input 'nixpkgs':
'github:nixos/nixpkgs/c5ae371f1a6a7fd27823bc500d9390b38c05fa55?narHash=sha256-4PqRErxfe%2B2toFJFgcRKZ0UI9NSIOJa%2B7RXVtBhy4KE%3D' (2025-11-12)
→ 'github:nixos/nixpkgs/549bd84d6279f9852cae6225e372cc67fb91a4c1?narHash=sha256-hGdgeU2Nk87RAuZyYjyDjFL6LK7dAZN5RE9%2BhrDTkDU%3D' (2026-05-05)
```
## 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).
### 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/12497
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
The cancelJobsForRun function is redundant with the killRun function and has bugs:
- It does not use a transaction and may fail in a non-recoverable way
- It does not update the commit status of the run
- It does not set NeedRemoval to false if needed
Remove the cancelJobsForRun function and use killRun instead (fixing forgejo/forgejo#12386). Both calls are covered by existing tests:
- TestCancelPreviousJobs
- TestCancelPreviousWithConcurrencyGroup
A new integration test TestActionsPullRequestTrustPushCancel is added to verify that the NeedApproval field is set to false whenever a run is cancelled (fixing forgejo/forgejo#12350).
Closesforgejo/forgejo#12350Closesforgejo/forgejo#12386
---
Reverting the change fails the test at
https://codeberg.org/limiting-factor/forgejo/src/commit/b6178e5634c230006a3c2b791ec8e06f09367e2d/tests/integration/actions_trust_test.go#L520-L533
with:
```
TAGS='sqlite sqlite_unlock_notify' make 'test-sqlite#TestActionsPullRequestTrustPushCancel'
...
actions_trust_test.go:523:
Error Trace: /home/limiting-factor/forgejo/tests/integration/actions_trust_test.go:523
/home/limiting-factor/forgejo/tests/integration/git_helper_for_declarative_test.go:98
/home/limiting-factor/forgejo/tests/integration/actions_trust_test.go:476
Error: Should be false
Test: TestActionsPullRequestTrustPushCancel
```
## 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
(can be removed for JavaScript 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- User Interface bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12366): <!--number 12366 --><!--line 0 --><!--description V2hlbiB0aGUgYXV0aG9yIG9mIGEgcHVsbCByZXF1ZXN0IGlzIFtkZW5pZWQgdGhlIHJpZ2h0IHRvIHJ1biBBY3Rpb25zXShodHRwczovL2Zvcmdlam8ub3JnL2RvY3MvbmV4dC91c2VyL2FjdGlvbnMvc2VjdXJpdHktcHVsbC1yZXF1ZXN0LykgYnkgY2xpY2tpbmcgb24gdGhlICJEZW55IiBidXR0b24gb24gdGhlIHB1bGwgcmVxdWVzdCB0cnVzdCBtYW5hZ2VtZW50IHBhbmVsLCB0aGUgd29ya2Zsb3cgcnVucyBjcmVhdGVkIGZvciBhbGwgY29tbWl0cyBwdXNoZWQgdG8gdGhlIHB1bGwgcmVxdWVzdCBhcmUgY2FuY2VsbGVkLiBCZWZvcmUgdGhhdCwgcnVucyB0aGF0IHdlcmUgYXV0b21hdGljYWxseSBjYW5jZWxsZWQgYmVjYXVzZSBhIG5ld2VyIGNvbW1pdCB3YXMgcHVzaGVkIHRvIHRoZSBwdWxsIHJlcXVlc3QgW3dlcmUgc3R1Y2sgaW4gYSBzdGF0ZSB3YWl0aW5nIGZvciBhcHByb3ZhbF0oaHR0cHM6Ly9jb2RlYmVyZy5vcmcvZm9yZ2Vqby9mb3JnZWpvL2lzc3Vlcy8xMjM1MCku-->When the author of a pull request is [denied the right to run Actions](https://forgejo.org/docs/next/user/actions/security-pull-request/) by clicking on the "Deny" button on the pull request trust management panel, the workflow runs created for all commits pushed to the pull request are cancelled. Before that, runs that were automatically cancelled because a newer commit was pushed to the pull request [were stuck in a state waiting for approval](https://codeberg.org/forgejo/forgejo/issues/12350).<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12366
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
