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>
Related issue: https://codeberg.org/forgejo/forgejo/issues/8581
This should be a nice first step towards RTL support. Future PRs can look at updating the tailwind classes, changing some of the icons (arrow left might need to become arrow right in some cases for example, and updating the template files)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12491
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Fairly new to Forgejo but I just ran into this when trying to create a couple repositories.
I noticed that the input field for the repository name in several areas of the UI is prone to have annoying auto-capitalization, spellchecking and other browser features which try to correct the user input.
I as a user would like to not have the browser interfere with my input especially in dialogs where I want to have something "custom".
For fields where the repo name is used to validate an action (Danger Zone) this is even more frustrating.
So, to me, this is a quality of live improvement fix.
I checked the docs for these three attributes and none of them seem to have a negative side effect for the user:
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocorrect
2. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocapitalize
3. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/spellcheck
## List of URLs where this applies:
1. `/repo/migrate`
2. `/repo/create`
3. `/<user>/<repo slug>/settings`
4. In general things in the "Danger zone" section where the repo name is used to validate the action
5. …
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12506
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Adds new Authorized Integration claim comparison rules for "in a list" and "in a list of globs", which would be required to permit multiple Forgejo Action events to match a JWT (per [design work](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-14510514), [comment](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-14512185)).
## 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.
- [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/12482
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>
Use notify as systemd service in the example configuration.
Notifying systemd on successful startup is supported since
Forgejo 1.20.0 already.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10212
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 endpoint returning individual activities was missing access control checks, since IDs are sequential, this is not ideal.
Fixes#12333
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12382
Reviewed-by: Gusted <gusted@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
b6178e5634/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>
Include `run_id` in the responses emitted by all `...actions/runners/jobs` endpoints. Helps with correlating pending jobs with other jobs and the runs they belong to.
## 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12480
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This is a implementation of #4277.
The core idea is that any activity (where activity is defined as anything that ends up in the `action` table) will be wrapped in an `ap.Note`, and sent to followers. Similarly, the inbox of local users now accepts such Notes. Additionally, there's now a "Feeds" tab on the user profile page, which displays the received notes.
# Preview
# How to Try?
The PR can be tried using a single Forgejo instance, but two distinct ones probably shows how it works better. For the sake of simplicity, lets try with a single instance. This is how to get started:
1. Enable federation
2. Subscribe one user to another (or to themselves):
```
curl -s -H "authorization: Bearer ${TOKEN}" -XPOST \
http://localhost:3000/api/v1/user/activitypub/follow \
--json '{"target": "http://localhost:3000/api/v1/activitypub/user-id/1"}'
```
This makes the first user follow themselves.
3. Create a repo, open an issue, or basically do anything that results in an activity recorded.
4. Visit `http://localhost:3000/{username}?tab=feed` to see the feed in action.
If you want to try with multiple instances, then it's very similar: you just change the `actor_id` to the IRI of the user you want to follow the first instance's user with, and then you can look at the feed tab of this user on the second instance, after you performed some activity on the first.
## Trying with Mastodon / GoToSocial
To try with Mastodon or GoToSocial, you will likely need to bring your Forgejo instance public, and behind https. Once your Forgejo instance is up, you can search for `@yourusername@forgejo.your.domain.example.com`, and simply follow your Forgejo account. Creating any activity will then happily federate to Mastodon & GoToSocial.
You can also copy & paste the Forge user's web profile URL (eg, `https://forgejo.your.domain.example.com/yourusername`) into your fedi client of choice, and it will discover the profile that way too.
# Testing
* test: https://codeberg.org/meissa/federation/src/branch/federated-user-activity-following/doc/user-activity-following/manual-test.md
* Proof of gts->forgejo: https://social.meissa-gmbh.de/@meissa/114499541149466596
* Proof of forgejo->gts: https://social.meissa-gmbh.de/@meissa/114505225265720094
## Architecture decisions
There are a number of ways user activity federation could be implemented. One way - which I explored first - is to wrap each activity, and send those, and let the client render it. The advantage of this would be that we'd be able to have references to other objects (comments, repos, etc). The disadvantage is that doing this requires making all of these things addressable, and that's a lot of work. Another disadvantage is that this requires every client to know how to display it.
Another way, chosen here, is to send a rendered HTML `ap.Note` instead, with an `AttributedTo` (`ap.Person`) property, which describes the activity that happened in a HTML note. This is much simpler to implement, and has the huge advantage that it is also easier to display. In fact, once we have http signatures, we should be able to federate user activity to Mastodon, too! (Though this also requires figuring out how Mastodon wants to follow a user...)
Since user activity federation is mostly cosmetic, as in, it's there for the user to see, rather than for programs to take actions based upon this activity, I believe that sending an `ap.Note` is preferable over a more machine-oriented approach.
## Limitations & TODO
### FederatedUser
We should be caching the Avatar in a similar way. For that, though, we also need to store the last activity of a federated user, so we can expire old avatars from the cache. The avatar refresh part will be covered by #4778.
### Notes
While sending out notes, the `AttributedTo` property is set to an `ap.Person`, based on the originating local user. This is currently unused. The idea is that once following is implemented properly (see above), we'll be able to link this to a FederatedUser (and thus to ExternalUser & User), which will allow us to display avatars and such, too.
### Display
The template used for displaying the received activities is currently incredibly simplistic. That's probably ok, it doesn't need to be fantastic.
### TODO
- [x] Fix the crashes on certain ops:
- [x] Issue/PR close & reopen
- [x] Figure out a better way to implement follows
- [x] Store the `AttributedTo` part of the note, too, the ID of it.
- [x] Make sure only those activities are sent out that need to be.
Currently, pretty much any activity is sent out, even private ones. We should be a bit smarter about that.
- [x] Make the ids used in the AP messages deterministic
The IDs used in the AP messages are currently UUIDs, and we do not store them, so all the IRIs are "invalid": the objects they refer to don't exist outside of the AP message itself. We should be able to reconstruct the Note objects and Create activities from their IDs.
- [x] Make it possible to follow Forgejo account from Mastodon and GtS
- [x] Mastodon without `AUTHORIZED_FETCH` works
- [x] GoToSocial can follow
- [x] Mastodon with `AUTHORIZED_FETCH` can follow
- ~~Create a cron job to refresh federated user avatars~~
- [x] Implement unfollowing
- [x] Add a `<link rel="alternate" type="application/activity+json" href="...">` to profile pages
This lets Mastodon & most other Fedi frontends discover the AP profile just by pasting a Forgejo user's web profile page into a search box, without having to know the corresponding AP actor URL
- [x] Make it easier to make a local user follow a remote AP actor
- ~~Rebase on top of #4778 by @realaravinth, once that is ready~~
- [x] Create an API endpoint to list the AP feed
- [x] Create a DB migration for the new stuff
- [x] Make swagger stuff happy
- [x] Clean up the commit history
- [x] ~~Tests~~ Opting for manual testing for now.
Co-authored-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-authored-by: jerger <jerger@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4767
Reviewed-by: jerger <jerger@noreply.codeberg.org>
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
The dialog element shrink wrap up to the max-width boundary. The
`long-modal` is set to strictly fit the `800px` width in the test.
However with Playwright minor font rendering differences makes the
dialog modal width resulting in `797px`.
Test fails at: [expect(width).toBe(800);](6132d0e406/tests/e2e/modal.test.e2e.ts (L103))
The fix is to increase the content of the `#long-model` element in
`templates/demo/model.tmpl` to 300 characters length instead of the
current `100` characters length ensures that the dialog modal will always
hit the `800px` max-width.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12469
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Some notes:
- I didn't write integration tests because it's a pure bugfix that addresses implementation details of the model layer.
- I can see interpretations of "it involves interactions with a live Forgejo server" that would cover this PR, but they don't make sense to me in context.
- I didn't add anything to the documentation because it's a pure bugfix - the system should always have worked this way
- there's no value in confusing people trying to figure out how the system works now with how it didn't work in the past
- However, there IS value in informing people who may have gotten bitten by this in the past, so I think a release note makes sense
- These fixes are closely related, and the changes small, so I decided to make just one PR.
- From a user perspective, this is just one issue, and I think in terms of release notes, it makes more sense to have just this one.
- Technically, fixing only one of the underlying issues would be enough. Since this is a case of invalid states being representable, it makes sense to both try to prevent it happening in the first place, and deal with it gracefully if it does happen.
- At the very least, fixing #12245 is required unless we want to live with data generated in the past being broken
Fixes#12243Fixes#12245
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12302
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
For Agit-flow pull requests, `head.label` was explicitly set to an empty
string. The head branch name (which contains the Agit topic,
e.g. `user2/my-topic`) was already populated from `pr.HeadBranch` but then
discarded.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12352
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Cyborus <cyborus@disroot.org>
While the changes were conveyed in the pull request in its entirety, the commit
history of a pull request having more than one commit was bugged and the log
would have shown just the presence of the most recent commit event, having the
entire changes contained in a pull request.
This is a problem that was mostly noticed in the closed pull request, so it is
not as bad as it looks. Even then, if we are migrating closed pull requests, we
should do it the right way. We do not want to retain these pull requests for
archival purposes if they are not accurate.
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
Fixes https://forge.fedoraproject.org/forge/forge/issues/556
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12433
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This changes the ReqHTTPSignature middleware to cover the entire activitypub
route group to not miss any new routes again in the future. Further, this adds
a tests iterating through all activitypub routes to test that the signature
verification is actually done.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12339
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
See #12353 for more details
## 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
### 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.
- [ ] 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/12441
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
- Regression of forgejo/forgejo!11776 (and forgejo/forgejo!11881)
- Scope of the transaction is moved to a per-package cleanup rule basis.
This is also a enhancement for scaling (already deployed on Codeberg for a while).
- Package cleanup is now run with `RetryTx`, because rebuilding
repository files runs `RetryTx` and it could indicate to retry the whole
transaction.
- Previously it would error and say running `RetryTx` in a
transaction was not possible, this is now possible. Nested `RetryTx` is
always allowed, matching of which errors to retry is still the responsible
of the inner `RetryTx`.
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12446
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This pr PR is fixing a type introduced in #10397. In case of an error during the creation of the centralised hooks `git.InitFull` would have returned early, missing some of the configuration 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
(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...
- [ ] 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.
- [ ] 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/12427
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
In the case you hit some API error (Github ratelimit was often a problem) or the instance restarted in the middle of your migration, you would be left with data on the disk and/or database. Upon retrying the migration the migration code would (rightfully) fail because it's trying to migrate stuff that already exists.
This was hit so often on Codeberg it was better to force people to delete and start whole migration process again: 28ee60c91f
Delete the repository data before retrying to solve this.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12370
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Follow-up to https://code.forgejo.org/forgejo/runner/pulls/1509 -- improves the UX in Forgejo when a reusable workflow is skipped, marking the workflow as skipped rather than succeeded.
## 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.
- [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/12412
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
User interfaces for authorized integrations will benefit from having a name field, to allow a list of authorized integrations to have an identifiable user-entered label.
I've also added a "description" column which is a `LONGTEXT` field. My thought for this field is that if I were creating authorized integrations, I'd like to be able to write down where they're used, what they're used for, and how the remote system is configured. For example, if it was an authorized integration to allow AWS -> Forgejo integration, the AWS side can be complicated -- IAM roles which are assumed, resources like EC2 instances or Lambdas that can access the roles -- and this would provide a natural place to make some notes to help me remember how the remote is configured. I expect to represent this as a `<textarea>` in the Authorized Integration, optional, possibly markdown-formatted to allow links & bullet-points.
Manually tested migration with PG backend, and manually tested creation of authorized integrations with the CLI updates.
## 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.
- [ ] 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/12413
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Both #12355 and #12364 passed CIs individually, but when combined a new test added in #12364 was broken by the change in #12355. Fixes the authorized integration test to use the new immutable subject format.
## 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...
- [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/12401
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Protect OIDC tokens generated by Forgejo Actions from threats arising when users or repositories are renamed or deleted, freeing their names up for reuse by another user. In this threat environment, relying on the name of users and repositories in validating JWT claims is unsafe because they can change.
Adds three new claims to Actions' OIDC tokens:
- `actor_id` -- the immutable identifier of the actor who triggered an Action run
- `repository_id` -- the immutable identifier of the repository on which the Action is running
- `repository_owner_id` -- the immutable identifier of the owner of the repository on which the Action is running
Repositories will change their subject (`sub`) OIDC claims to include these immutable identifiers. Existing repositories will not change, in order to maintain compatibility with existing JWT usage. The new format will be applied to new repositories, or can be applied by disabling and enabling the Actions unit. The new format embeds the identifiers:
- **Existing repos:** `repo:my-org/my-repo:ref:refs/heads/main`
- **New repos:** `repo:my-org-123456/my-repo-456789:ref:refs/heads/main`
Fixes#12244.
## 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
- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- New fields will be added to documentation soon.
- [ ] 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/12355
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
## Fix: `GET /api/v1/repos/{owner}/{repo}/git/tags/{sha}` returns empty verification for signed tags
### Problem
When an annotated tag is signed (GPG or SSH) but the underlying commit is **not** signed, the API endpoint `GET /repos/{owner}/{repo}/git/tags/{sha}` returns an empty `verification.signature` field.
This is because `ToAnnotatedTag` was calling `ToVerification(ctx, c)` with the **commit** object, which checks the commit's signature — not the tag's own signature. Since the commit is unsigned, the API returns `signature: ""` and `verified: false`.
This causes issues for tools that rely on the tag signature from the API to validate that a tag push event is from a trusted source.
### Fix
`ToAnnotatedTag` now checks if the tag has its own signature (`t.Signature != nil`). If so, it uses `ParseTagWithSignature` to verify the tag's signature and populates the `verification` field from the tag. Otherwise, it falls back to the commit signature (existing behavior for unsigned/lightweight tags).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12351
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Allows user to assign organization projects to their new issues, using the project sidebar selector, even when repository's projects are disabled.
Moreover, the project sidebar selector is now hidden if no projects (repository-wide + organization-wide) are available.
Fixesforgejo/forgejo#5666
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7999
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Allows us to make use of Go features introduced in v1.26.
I require a feature from v1.26 for a PR I want to make later.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12369
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Having tooltip only for `lfs_pointers.accessible` is fine in English, but not in other languages. For other languages the text is truncated.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12139
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
github.com/robfig/cron is used for parsing cron schedules of scheduled Forgejo Actions workflows. It has not seen an update in roughly six years and looks abandoned. There are multiple code paths that trigger panics instead of errors. It is replaced by github.com/gdgvda/cron, which is one of the few maintained forks. github.com/gdgvda/cron was picked because its behaviour is fully backwards-compatible and the developers are responsive.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12365
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Allow JWTs that are generated by Forgejo Actions to be validated within Forgejo in-memory. Without any special support for this internal access situation, these problems would occur:
1. Forgejo would need to make an HTTP request to itself to get the valid public key for the JWT, in order to validate its signature. This is a waste of resources, and introduces a self-DoS risk.
2. Forgejo would need to be available via TLS in order for Actions to make service calls to Forgejo with that JWT, due to the TLS requirement for public key fetching. This would be a blocker for writing end-to-end tests for Forgejo, but also would affect users who do not host Forgejo with TLS.
3. Authorized Integrations would need to be saved with the `issuer` URL of Forgejo. If Forgejo's own `setting.AppURL` changed, all the persisted records in the database would become incorrect.
## 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.
- [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/12364
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
This idea is perhaps a bit more far-fetched. It implements the ability in `lint-locale-usage` to basically fully handle "printf" invocations by transforming format strings to regexps when "%" wildcards are present.
Currently, it doesn't cache the transformation from format string to compiled regex because this doesn't make a performance difference (yet), given that most of these wildcards are only hit once or twice.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12013
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Was not required until ce0a376723 added extra checks which did require `repo_id` of the attachment to be set correctly.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12357
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
I had some trouble getting the devcontainer run. I use docker buildx / BuildKit.
Error was: `docker buildx build failed: ERROR: failed to build: invalid tag "gitea_-5cc3cd41d1b58674-features": invalid reference format`.
I renamed the container to not contain spaces and then it worked.
AI agreement:
I asked Claude code (Sonnet 4.6) to analyze the problem and it told me that buildx/BuildKit seems to check more strict for names.
So it guided me to the solution to rename the container.
I then myself changed the name and verified that the devcontainer starts.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12356
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
`handleRefreshToken` never checked `token.Type == TypeRefreshToken`. When
`InvalidateRefreshTokens` is disabled, an access token could be submitted as a
`refresh_token` and exchanged for a new token pair.
## 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.
Co-authored-by: jvoisin <julien.voisin@dustri.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12291
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
I've observed intermittent failures in [`TestAPIAuthWithAuthorizedIntegration`](https://codeberg.org/forgejo/forgejo/actions/runs/156485/jobs/8/attempt/1#jobstep-5-1950):
```
auth_authorized_integration_test.go:70:
Error Trace: /workspace/forgejo/forgejo/tests/integration/integration_test.go:657
/workspace/forgejo/forgejo/tests/integration/auth_authorized_integration_test.go:70
/workspace/forgejo/forgejo/tests/integration/auth_authorized_integration_test.go:117
Error: Not equal:
expected: 200
actual : 401
Test: TestAPIAuthWithAuthorizedIntegration/authorization_reducer/specific_repo_access_token
Messages: Request: GET /api/v1/repos/user2/repo1/compare/master...master
auth_authorized_integration_test.go:70: Response length: 1801
```
I *suspect* that the cause is time-related errors in the Authorized Integration JWT, but I can't validate this because I can't reproduce the issue in local testing, and the response isn't displayed, and is just "Response length: 1801". This PR increases the size of responses that the integration tests' `logUnexpectedResponse` will output.
## 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.
- [ ] 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/12348
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
This PR extends Forĝejo's PyPI package index to support [the simple JSON repository API](https://packaging.python.org/en/latest/specifications/simple-repository-api/#json-serialization). Since the existing implementation was for the HTML serialization of the same simple API, no new endpoint has been added. Instead, Forĝejo chooses between serialization schemes based on the "Accept" header in the request. This, together with CORS, will make Forĝejo compatible with [micropip](https://github.com/pyodide/micropip).
## 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 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.
- [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/12095): <!--number 12095 --><!--line 0 --><!--description SG9zdGVkIFB5UEkgcGFja2FnZXMgbWF5IGJlIGFjY2Vzc2VkIHZpYSB0aGUgW3NpbXBsZSBKU09OIEFQSV0oaHR0cHM6Ly9wYWNrYWdpbmcucHl0aG9uLm9yZy9lbi9sYXRlc3Qvc3BlY2lmaWNhdGlvbnMvc2ltcGxlLXJlcG9zaXRvcnktYXBpLyNqc29uLXNlcmlhbGl6YXRpb24pIGluIGFkZGl0aW9uIHRvIHRoZSBzaW1wbGUgSFRNTCBBUEkgYWxyZWFkeSBhdmFpbGFibGUu-->Hosted PyPI packages may be accessed via the [simple JSON API](https://packaging.python.org/en/latest/specifications/simple-repository-api/#json-serialization) in addition to the simple HTML API already available.<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12095
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
When attempting to render a markdown code block that does not have a language set in it, Forgejo will fail to render and log an error:
```
2026/04/29 08:47:47 ...markdown/markdown.go:162:func1() [W] Unable to render markdown due to panic in goldmark: runtime error: invalid memory address or nil pointer dereference
```
This is a regression introduced by #12056.
## 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.
- [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.
- pre-release regression
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12325
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Enables and tests the usage of Authorized Integrations to access the package registries. Specific testing includes:
- Container registry -- automated testing and manual testing
- Generic registry, w/ detailed authorization tests -- automated testing
- Conan registry -- automated testing (uses an "authenticate" endpoint that required updates)
- npm registry -- manual testing with a Forgejo Action publishing packages
For the container & conan registeries, where the client uses an authentication endpoint to request a temporary access token, the expiry of the temporary access token is restricted to the expiry of the authorized integration's JWT for the authorized integration in order to prevent an escalation of privileges.
## 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.
- [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/12310
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
When a pull request is opened, the author is able to mark that pull request to "Allow edits from maintainers", which grants the maintainers of the pull request's repo access to edit the pull request branch contents. It is possible to create a pull request where the pull request author does not have the ability to edit the pull request branch. Due to a missing security check for this case, maintainers of the pull request repo would be granted the ability to edit the pull request branch, even if the author of the pull request did not have that ability. By exploiting this missing security check, a user can edit any branch in a repository if they're able to fork that repository. The issue is being fixed by restricting the scope of "Allow edits from maintainers" to only grant that access if the pull request author also had access to edit the branch.
Thanks to Arvin Shivram of Brutecat Security for discovering and responsibly disclosing the vulnerability.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12292
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Allows the creation of an authorized integration as a Forgejo administrator, either for development testing or to support server-automation. Clipping out the CLI config options, looks like:
```
NAME:
forgejo admin user create-authorized-integration - Create an authorized integration for a specific user
USAGE:
forgejo admin user create-authorized-integration [options]
OPTIONS:
--username string, -u string Username
--issuer string JWT issuer ('iss' claim), example: https://forgejo.example.org/api/actions
--claim-eq string=string [ --claim-eq string=string ] Zero-or-more claim equality checks, formatted as claim=value, example: "actor=someuser"
--claim-glob string=string [ --claim-glob string=string ] Zero-or-more claim glob checks, formatted as claim=value, example: "sub=repo:forgejo/*:pull_request"
--scope string [ --scope string ] One-or-more scopes to apply to access token, examples: "all", "read:issue", "write:repository" (default: "all")
--repo string [ --repo string ] Zero-or-more specific repositories that can be accessed, or "all" to allow access to all repositories, example: "owner1/repo1" (default: "all")
```
As an example, this will create an authorized integration that will permit Codeberg's Forgejo Actions to generate trusted JWTs that can access the local user `mfenniak`:
```bash
$ ./forgejo admin user create-authorized-integration \
--username mfenniak \
--issuer https://codeberg.org/api/actions \
--claim-eq sub=repo:mfenniak/forgejo-runner-testrepo:pull_request \
--scope read:user
{
"message": "Authorized integration was successfully created.",
"issuer": "https://codeberg.org/api/actions",
"audience": "u:1:c97d83bc-fa4e-4db3-b898-414cd5b6ce33",
"claim_rules": [
{
"description": "\"sub\" = \"repo:mfenniak/forgejo-runner-testrepo:pull_request\"",
"claim": "sub",
"compare": "eq",
"value": "repo:mfenniak/forgejo-runner-testrepo:pull_request"
}
]
}
```
The output is a JSON document to aid in use in automation. The `audience` field is the audience generated by Forgejo that must be used by the remote to generate the JWT. Continuing this example to the client-side, a matching Forgejo Action like this in the `mfenniak/forgejo-runner-testrepo` repo, for a `pull_request` event, then it will be able to access the Forgejo server that the authorized integration was created on like this:
```yaml
on:
pull_request:
enable-openid-connect: true
jobs:
job1:
runs-on: docker
steps:
- name: Fetch JWT
id: jwt
run: |
set -eux -o pipefail
set +x
jwt=$(curl --fail \
-H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=u:1:c97d83bc-fa4e-4db3-b898-414cd5b6ce33" \
| jq -r ".value")
echo "::add-mask::$jwt"
set -x
echo "jwt=$jwt" >> $FORGEJO_OUTPUT
- name: API call to Forgejo
run: |
curl \
-v --fail \
-H "Authorization: bearer ${{ steps.jwt.outputs.jwt }}" \
"https://example.org/api/v1/user" | jq
```
CLI command is tested manually. Supporting functions have associated unit tests.
## 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.
- [x] I did not document these changes and I do not expect someone else to do it.
- CLI update should be automatic in docs -- more detailed Authorized Integration documentation is on my project plan.
### 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/12299
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
@viceice was getting error 500 trying to post this PR an hour ago. This commit is solely authored by him.
Co-authored-by: viceice <michael.kriese@gmx.de>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12304
Enhances authorized integrations (#12261) with a cache of the remote OpenID Connect descriptor file and JSON Web Key Set (JWKS), improving runtime performance and reducing intermittent reliability risks. By default a 10 minute cache is used, configurable through `[authorized_integration].CACHE_TTL`.
To mock the cache for testing, mockery code generation is added, and a previous manually generated mock for `AuthorizationReducer` was replaced with the code generation.
## 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.
- [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.
- [ ] 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.
- Authorized integrations are not yet exposed to end-users.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12275
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
## 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...
- [ ] `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.
- [ ] 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/12296
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This change introduces a Path method on the TreeEntry struct, that
collects the path by moving upwards in the tree.
The existing FollowSymlink(s) methods interface has been changed, the
previously returned string has been removed, as after the fix it wasn't
used anywhere.
Fixes: #9931
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12246
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
... from #11194 / 0034e55965
Revert a test code change left over from an intermediate development step which is not needed, because the LFS JWT config is tested in lfs.TestAuthenticate()
Fixes#12263
## 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12281
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This PR is replacing repository based hooks hooks with centralised files, this way the files don't need to be copied into every repository, only one line of config need to be added in the repository.
Closes: #3523
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10397
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Previous similar PR: https://codeberg.org/forgejo/forgejo/pulls/11879.
Moved strings from INI to JSON. Some directly, some with keys updated to be consistent. The latter was done carefully, making sure all usages are updated, and was tested locally.
There are more deletions than insertions because some languages also had some extra empty lines removed.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12280
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
This PR contains the following updates:
| Update | Change |
|---|---|
| lockFileMaintenance | All locks refreshed |
🔧 This Pull Request updates lock files to use the latest dependency versions.
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- Between 12:00 AM and 03:59 AM, only on Monday (`* 0-3 * * 1`)
- Automerge
- Between 12:00 AM and 03:59 AM (`* 0-3 * * *`)
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMzkuMCIsInVwZGF0ZWRJblZlciI6IjQzLjE0MS42IiwidGFyZ2V0QnJhbmNoIjoiZm9yZ2VqbyIsImxhYmVscyI6WyJkZXBlbmRlbmN5LXVwZ3JhZGUiLCJ0ZXN0L25vdC1uZWVkZWQiXX0=-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12279
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Built on #12266; one commit added.
Adds the ability to reduce the authorization scope of an authorized integration to public-only resources and repo-specific resources. Backend only -- no frontend created yet.
## 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...
- [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/12267
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Built on #12261; one commit added.
Adds an integration test verifying that access to the API can be authenticated by an authorized integration.
## 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...
- [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/12266
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Authorized Integrations is a new feature to allow users to define external systems which can generate JSON Web Tokens (JWTs) that Forgejo will trust in order to perform API access on behalf of that user. This is an authentication mechanism that requires zero preconfiguration of shared secrets, and instead establishes trust through short-lived secrets (JWTs) that are signed by the issuer, signatures are validated by comparison with published public keys, and a public-keys retrieved through well-known HTTP endpoints secured with TLS verification.
The primary goal of Authorized Integrations is to support a mechanism for Forgejo Actions to receive elevated, but controlled, additional access to Forgejo. More details as to what the end result will look like are available in the [design proposal](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-13268004) on #3571.
This PR adds the core database storage and authentication verification for Authorized Integrations, with these capabilities:
- An Authorized Integration is resolved by a unique key of an "issuer" and an "audience". The value of "issuer" is defined by the remote integration, and the value of "audience" will incorporate a unique identifier generated by Forgejo.
- Example issuer: `https://token.actions.githubusercontent.com/` is the issuer for GitHub JWTs
- Example audience: `https://forgejo.example.org/-/mfenniak/authorized-integration/6cc55ba0` is the expected format for a random audience field that Forgejo will generate.
- JWTs can contain any number of claims, which are represented as a JSON object; Forgejo can validate these with a flexible policy.
- eg. a claim may be `{"sub": "repo:coolguy/forgejo-runner-testrepo:pull_request"}` indicating that an OIDC token was received from an Actions execution in a specific repo on a specific event.
- Authorized Integrations support a `ClaimRules` system which allows claim equal, glob, and nested object inspection.
- `{"claim":"sub","comparison":"eq","value":"repo:mfenniak/forgejo-runner-testrepo:pull_request"}` -- would validate that `sub` exactly equals the specific value
- `{"claim":"sub","comparison":"glob","value":"repo:mfenniak/forgejo-runner-testrepo:*"}` -- would validate that `sub` matches the given string prefix but allow any event
- When a JWT is received on an incoming API call, Forgejo retrieves the Authorized Integration from the DB (if present), validates the token signature against a remote JWKS, validates the claims, and grants API access as the user with a permission scope defined on the Authorized Integration.
In addition to the unit testing provided here, this PR has been manually integration tested against three JWT issuing systems: Forgejo Actions, GitHub Actions, and AWS STS GetWebIdentityToken.
Careful consideration has been made of these security concerns:
- SSRF attacks against Forgejo are prevented by:
- having a blocklist on remote HTTP validation requests which prevent access to internal network resources,
- ensuring that authorized integrations are created by users with matching issuers, before attempting to validate tokens
- Resource utilization attacks against Forgejo are reduced by limiting the possible size of external metadata requests; when fetching `/.well-known/openid-configuration` and `jkws_uri`'s from remote, untrusted servers, a maximum response size of 16 kB is enforced
- Only well-known secure assymmetric JWT signing algorithms are supported -- in particular, the sketchy `none` JWT algorithm isn't supported.
- JWT validation is covered by extensive unit tests, covering validation of all JWT timestamps, validation of the issuers, validation of the issuer's documented supported signing algorithms.
This PR serves as a core, and many enhancements are required for this to be a usable system for users.
## 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...
- [ ] `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.
- Documentation updates for new config entries will be authored.
- [ ] 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.
- Marking not visible as there's no mechanism to interact with this backend yet.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12261
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Fixes#9371. Manually reproduced and tested by setting `action_run.triggering_user_id` to a non-existent user ID. Manually tested that runs can be cancelled in this state as well.
## 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.
- [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/12271
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Unintentionally fixesforgejo/forgejo#11812 per tip https://codeberg.org/forgejo/forgejo/pulls/12232#issuecomment-13580345
---
This is a second attempt to fix https://codeberg.org/forgejo/forgejo/issues/11116. The [first attempt](https://codeberg.org/forgejo/forgejo/pulls/11846) introduced a [regression](https://codeberg.org/forgejo/forgejo/issues/12082) and needed to be [reverted](https://codeberg.org/forgejo/forgejo/pulls/12088).
What's different about this attempt is that several days of extra work have been invested in amending the CSS to ensure that no visual changes slip through as a side-effect of the structural changes to the HTML. This was surprisingly challenging, and I documented much of the journey in https://codeberg.org/henrycatalinismith/forgejo/issues/1.
In summary, the existing version of the "latest commit" row leans heavily on global styles that are universally applied to all `thead` elements inside `table` elements with the `ui` and `table` classes. The nature of the structural HTML changes necessary to fix the accessibility bug (this row can't be inside `thead`) is such that those universal styles no longer apply to this element and must be duplicated into new element-specific styles. Similarly, existing styles applying to non-`thead` table content has unwanted effects on this element once it moves into the `tbody` which needed to be counteracted.
The original PR already lays out the accessibility impact of this pull request in a good amount of details and so instead I'm going to use the space here to focus on comparing the visuals in the `forgejo` branch with those in this PR. There follow a few pretty boring identical before & after screenshots that are pixel-for-pixel identical with each other. I don't think you'll be able to spot any bugs by glancing at these and am more sharing them to provide an insight into where my attention has been during testing: the 380px wide mobile viewport, a larger desktop viewport, and the "commit message too long to fit in the available space" case. If you know of other troublesome cases for this code that aren't covered by what you see in these images then that could be a good thing to explore here.
Before | After
-|-
 | 
 | 
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12232
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Forgejo's `basic` and `oauth2` authentication methods perform five distinct types of authentication:
- Username and password authentication
- Personal access tokens
- OAuth2 access tokens
- Forgejo Action's `${{ forgejo.token }}` -- task-based static tokens
- Forgejo Action's `${{ env.ACTIONS_RUNTIME_TOKEN }}` JWT, which is the authentication method used for `upload-artifact` (mirroring GitHub's implementation)
`basic` and `oauth2` both supported almost all of these methods, resulting in quite a bit of code duplication between them. This PR splits personal access tokens into `access_token.go`, Action's task-based tokens into `action_task_token.go`, and Action's JWT tokens into `action_runtime_token.go`.
**Note:** There is one peculiar side-effect that is worth discussing. Previously, `Authorization: Basic ...` was handled by one complex code path in basic.go, and `Authorization: Bearer ...` was handled by another in oauth2.go, and if authorization failed and a 401 was returned, a single error message would be returned to the user. Now, as multiple authorization methods may look at `Authorization: Basic ...` and provide their own reason why authorization didn't work, a 401 response has multiple reasons for a lack of authorization listed:
```
401 Unauthorized
...
failure to authenticate with oauth2 access token: not a JWT
Basic authorization is not allowed while having security keys enrolled
access token does not exist [sha: notpassword]
task with token "notpassword": resource does not exist
```
A couple tests have been adapted to check that the result contains their expected response, rather than is equal-to or prefixed-with their expected result. This is caused by the "auth group" joining together any "invalid credentials" errors, and, to a certain extent it is useful to understand why the authorization request failed. But it's a bit obscure as well.
## 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.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- Relying on integration testing for regression checks.
- 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/12236
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
## 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...
- [ ] 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
- [ ] 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/12142
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
#12202 began a refactor of Forgejo's authentication implementations by providing structured data on an authentication success. However, error cases were maintained as-is in that refactor, leaving a complex situation: what does returning an error from an authentication method mean?; does it mean that the authentication failed, or that a server error occurred? Can another authentication still be tried?
This PR changes authentication methods so that they can return one of four things:
- `AuthenticationSuccess` with an authentication result.
- `AuthenticationNotAttempted` which indicates that no credentials relevant for this authentication method were presented. If every method returned `AuthenticationNotAttempted`, then you would have an unauthenticated access.
- `AuthenticationAttemptedIncorrectCredential` which indicates that credentials were present and failed validation -- a situation indicating a `401 Unauthorized`.
- `AuthenticationError` which indicates that an internal server error occurred and failed authentication -- indicating a `500 Internal Server Error`.
This paves the way for one more refactor coming next: `basic.go` and `oauth2.go` perform 3-4 different authentications each (access tokens, oauth JWTs, actions tokens, actions JWTs, and username/password). With the capability to return these more precise responses, these authentication methods can be split up into separate logic that isn't intertwined together.
## 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.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- Relying on existing test suite, with changes for any compile errors -- the next refactor will simplify the auth methods so that they can be unit tested easily.
- 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/12231
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Currently authentication methods return information in two forms: they return who was authenticated as a `*user_model.User`, and then they insert key-values into `ctx.Data` which has critical impact on how the authenticated request is treated. This PR changes the authentication methods to return structured data in the form of an `AuthenticationResult`, with all the key-value information in `ctx.Data` being moved into methods on the `AuthenticationResult` interface.
Authentication workflows in Forgejo are a real mess. This is the first step in trying to clean it up and make the code predictable and reasonable, and is both follow-up work that was identified from the repo-specific access tokens (where the `"ApiTokenReducer"` key-value was added), and is pre-requisite work to future JWT enhancements that are [being discussed](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-13268004).
## 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.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- All changes, at least in theory, are refactors of existing logic and are not expected to have functional deviations -- existing regression tests are the only planned testing.
- 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/12202
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
If one or more of a workflow expansion's inner jobs are status "skipped", consider that as a success, rather than a failure. Fixes https://code.forgejo.org/forgejo/runner/issues/1490.
## 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.
- [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/12224
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Fixes: #12212
Sorry for this bug, I introduced it by not testing !10682 better. Now the `forbiddenPrefixPattern`-regex is compliant to the docu:
```
It cannot start with FORGEJO_, GITEA_, GITHUB_, or a number.
```
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12213
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: zokki <zokki.softwareschmiede@gmail.com>
Co-committed-by: zokki <zokki.softwareschmiede@gmail.com>
## Context
the three commits in this series are the first step towards the goal of removing the special casing around `JWT_SECRET`, which is used for various modules via `GetGeneralTokenSigningSecret()`. Ultimately, I want to work towards enabling seamless migration away from general use of the common secret. To enable this, we need proper secret/key rotation support, that is, we need to allow for configuration of additional secrets/keys which are accepted for token validation, but not used to issue tokens.
I have this _Verifier_ support basically implemented, but this PR is not it.
This PR contains cleanup refactoring which I worked on before writing the _Verifier_ support, because I noticed that the existing secret/key handling across modules was inconsistent and required duplicated code.
I am submitting this part now to allow for incremental review of not too large a diff, and because these commits remained unchanged during two weeks since I moved on the the next task.
## The problem being addressed
Configuration of JWT signing secrets/keys was inconsistent:
Under `[oauth2]` the full configuration set was supported:
- `JWT_SIGNING_ALGORITHM` configured the algorithm
- `JWT_SECRET` configured a literal secret for symmetric algorithms
- `JWT_SECRET_URI` configured a `file:` uri of a secret for symmetric algorithms
- `JWT_SIGNING_PRIVATE_KEY_FILE` configured a file for asymmetric algorithms
For `[server]`, the LFS module only supported `LFS_JWT_SECRET`, and the signing method was hardcoded to `HS256`
For `[actions]`, only asymmetric signing methods were supported via `ID_TOKEN_SIGNING_ALGORITHM` and `ID_TOKEN_SIGNING_PRIVATE_KEY_FILE`.
## ini unification
The proposed code centralizes ini parsing to always support the following ini keys:
- `[pfx]SIGNING_ALGORITHM` determines the algorithm
- `[pfx]SECRET` is a literal secret for symmetric algorithms
- `[pfx]SECRET_URI` is the uri of a secret for symmetric algorithms
- `[pfx]SIGNING_PRIVATE_KEY_FILE` is a file with a private key for asymmetric algorithms
`[pfx]` is specific to the module and chosen to support the existing ini keys
Centralizing this code and unifying the ini keys will come handy for at least the following reasons:
- consistent behavior across modules is easier to understand
- less duplicated code
- easier to expand later, which is my main motivation
## implementation notes
as might be apparent by the _take3_ branch name, this is the third iteration of this patch series. The main reason why I abandoned the other two is that I first tried to move all the key initialization into the code called from settings.go when the ini file is parsed. But that lead to a lot of friction with test cases, because private key files which are configured, but do not exist will get created and hence require a writable `AppDataPath` and additional clean up.
To avoid a lot of noise and complications in test cases, I kept the existing two stage process, where
- the settings component creates missing symmetric signing keys and writes them to the .ini
- the settings component creates a simple configuration struct
- which is then used from the module init to create the actual key, which also includes creating a private key file if asymmetric crypto is configured and the key file does not exist.
I would have wished this patch was a net negative in terms of LOCs, but I hope it contributes to clarity and many added lines are in test cases.
## Commits
Because sometimes PRs are merged as squashes with the PR text remaining, I am repeating here the individual messages of the individual commits for future reference:
### Refactor signing key initalization and oauth2 use of it
This commit is the first in a series towards the goal of addressing the
FIXME comment in modules/setting/oauth2.go to remove
GeneralTokenSigningSecret
To do it properly, the task also requires addition of signing secret/key
rotation: We ultimately want to be able to change a signing key, but
continue to accept the previous one. This is particularly relevant to
offer a path from GeneralTokenSigningSecret aka JWT_SECRET to new,
specific component key configuration, where it should be possible to add
the former JWT_SECRET as a key accepted for verification to enable a
seamless transition.
This perspective, in turn, calls for refactoring of the existing secret
initialization code to centralize the common functions of parsing
signing key related configuration directives: The oauth2 module
currently is the only component accepting symmetric and asymmetric keys,
with the limitation of the symmetric key being also the
GeneralTokenSigningSecret. Other components either enforce HS256 or
public key algorithms.
We should really give the choice of algorithm selection and avoid code
duplication in other places, so this commit
- generalizes setting parsing into a configuration struct: A prefix can
be provided, with which the common configuration directives are
processed:
- [pfx]SIGNING_ALGORITHM determines the algorithm
- [pfx]SECRET is a literal secret for symmetric algorithms
- [pfx]SECRET_URI is the uri of a secret for symmetric algorithms
- [pfx]SIGNING_PRIVATE_KEY_FILE is a file with a private key for asymmetric algorithms
- which is then accepted by jwtx.InitSigningKey() to create an actual
signing key
The reasons for the two stage process are explained in a long-ish
comment in modules/setting/security.go. In short, other options would
either violate sensible module boundaries or cause too much friction.
These other options have actually been tried, this is take 3 of the
proposed changes.
### Refactor services/lfs: Change token code to use SigningKey
This now also enables use of token algorithms other than HS256.
In this case, signing key initialization also happens during settings
initialization, because LFS is also used in CLI commands.
### Refactor api/actions to use new signingkey API
This now also enables use of symmetric token algorithms.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11194
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Closes: #12204
The underlying git option was already changed in git 2.0.0 to use format `<mode>,<object>,<path>`. See ec160ae12b.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12214
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
## 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...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
(not applicable — Go-only change)
### 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.
## Summary
Add public REST API endpoints under `/api/v1/` for listing, inspecting, downloading, and deleting Actions artifacts. Previously, artifacts could only be accessed through the web UI or the internal runner API.
### New endpoints
| Method | Path | Description |
|--------|------|-------------|
| `GET` | `/repos/{owner}/{repo}/actions/artifacts` | List all artifacts for a repository |
| `GET` | `/repos/{owner}/{repo}/actions/runs/{run_id}/artifacts` | List artifacts for a workflow run |
| `GET` | `/repos/{owner}/{repo}/actions/artifacts/{artifact_id}` | Get artifact metadata |
| `GET` | `/repos/{owner}/{repo}/actions/artifacts/{artifact_id}/zip` | Download artifact as zip |
| `DELETE` | `/repos/{owner}/{repo}/actions/artifacts/{artifact_id}` | Delete an artifact |
- List endpoints support `page`, `limit`, and `name` query parameters
- Both v1-v3 (multi-file, zip on-the-fly) and v4 (single zip) artifact backends are supported
- Expired artifacts are listed with `expired: true` but cannot be downloaded
- Delete requires write permission; all other endpoints require read permission
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12140
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: ShellWen <me@shellwen.com>
Co-committed-by: ShellWen <me@shellwen.com>
Move the logic for handling reruns of Forgejo Action workflows and individual jobs to services. That is a prerequisite for adding the corresponding HTTP API endpoints.
## 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
### 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
- [ ] 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/12141
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Resources in Forgejo can also be owned by predefined system users like Ghost or Forgejo Actions. Those have negative user IDs, for example, -2 in the case of Forgejo Actions. `OwnerID` checks oftentimes do not take these users into account, because their existence and how they work isn't well known. A [semgrep](https://semgrep.dev/) check is added that flags such suspicious `OwnerID` checks.
See https://codeberg.org/forgejo/forgejo/pulls/12144 for background.
## 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...
- [ ] 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
- [ ] 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/12184
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Followup to https://codeberg.org/forgejo/forgejo/pulls/6203
Currently it is logging an error wherever a template is rendered in language that doesn't have all plural strings covered. For example, Esperanto isn't well maintained.
Since more plural strings were migrated in v15 to new format, these errors became much more common. However, for all languages but the base one (English) they are completely harmless and just indicate an incomplete translation.
However, for base (English) they indicate a bug in either template or en-US.json, which should be still logged as an error.
The error is being logged by `LookupPluralByForm`, which is called by `TrPluralStringAllForms` and (`TrPluralString` through `LookupPluralByCount`). I originally intended to just pass log func directly to `LookupPluralByForm` from both, but since `TrPluralString` isn't calling `LookupPluralByForm` directly, it didn't look clean, so I went with passing a flag around instead and implemented logging logic in `LookupPluralByForm` itself.
I little concern is with that the so-called "default lang" is configurable, and if it is configured to something with less than 100% completion, it will cause fallback bugs, as well as a lot of logging of this as an error. But this is why changing "default lang" is a bad idea in the first place, and broken fallbacks should be greater concern than junk in the logs.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12183
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
- The documentation has the correct behavior about `linguist-detectable`: In cases where a file should be considered for language statistics, regardless of its category, the linguist-detectable attribute can be used.
- This patch follows that behavior by not skipping the file even if some heuristic would've said to skip the file.
- Document the conditions in more natural language.
- Resolvesforgejo/forgejo#11248
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11685
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Fixes#11590
When viewing a user's SSH keys, SSH principals are now excluded from the output. This would previously either result in a panic in [OmitEmail](cfd4d53e32/models/asymkey/ssh_key.go (L67)), if the principal name didn't contain any spaces, or truncate the principal name, if it did contain spaces.
The TestExportUserSSHKeys test was also updated and fails if the fix(commit cfcbc33af0) is reverted.
## 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...
- [x] `make pr-go` before pushing
- [x] `make test`
- [x] `make test-sqlite#TestExportUserSSHKeys`
I have also manually tested the change.
The full integration tests(`make test-sqlite`) report some errors, but I get the same errors without this PR(tested on commit [6a5dda7116](6a5dda7116)).
I have not tested with the other database backends.
### 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/12079
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Alec Walsh <code@alecwalsh.name>
Co-committed-by: Alec Walsh <code@alecwalsh.name>
I tried a lot, but this seems to work. I know it is ugly, but checking and waiting after every action seems to make it stable. At least it succeeded five times in a row and the CI seemed to be under load due to the dependency updates. Maybe it is worth a try...
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12151
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Allow for filtering users with 2fa enabled as admin. So that it is easy to audit users' settings compliance with iso27001, etc.
Resolves#11800
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12091
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Dominik Zyla <zylad@noreply.codeberg.org>
Co-committed-by: Dominik Zyla <zylad@noreply.codeberg.org>
API calls to `.../api/v1/repos/search?uid=-2&archived=false` currently do not apply the filter `uid` because of the negative value. This can occur when APIs are interacting with `${{ forgejo.token }}` and believe they're operating as the Forgejo Actions user, which has UID -2.
In combination with the security checks that occur in the `/repos/search` API to validate that repositories accessed are visible to the user, this can result in 500 error responses when a more correct expectation would be to receive no repositories:
da8898822c/routers/api/v1/repo/repo.go (L237-L242)
## 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...
- [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/12144
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Prevent continued execution of some APIs with error responses that didn't correctly interrupt execution, resulting in bizarre outputs and possibly leaking secure data:
```
> GET /api/v1/repos/search?uid=-2&archived=false HTTP/2
> Host: example.org
> user-agent: curl/7.88.1
> accept: */*
> authorization: bearer ***
>
< HTTP/2 500
< server: nginx
< date: Thu, 16 Apr 2026 14:20:09 GMT
< content-type: application/json;charset=utf-8
< cache-control: max-age=0, private, must-revalidate, no-transform
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
<
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"message":"","url":"https://example.org/api/swagger"}
{"ok":true,"data":[{"id":68,"owner":{"id":1,"login":"mfenniak", ...
```
As these errors only occur on situations that shouldn't be reproducible (minus software bugs), test automation isn't practical.
## 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.
- [ ] 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
- [ ] 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/12143
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Cyborus <cyborus@disroot.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This was missed in https://codeberg.org/forgejo/forgejo/pulls/11098.
See https://github.com/go-gitea/gitea/pull/17846 for why this was added in the first place.
Note that this is not backwards compatible. For users with a custom `app.ini`-config this won't work. But it also didn't work with the previous config. This change only aligns it with the default app.ini-path.
Co-authored-by: Jakob Linskeseder <jakob@linskeseder.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11720
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: jaylinski <jaylinski@noreply.codeberg.org>
Co-committed-by: jaylinski <jaylinski@noreply.codeberg.org>
`TestMirrorPull` is currently failing when run on git 2.34.1 in the `testing-integration.yml` workflow: https://codeberg.org/forgejo-integration/forgejo/actions/runs/16661/jobs/1/attempt/1#jobstep-5-2539 Began to fail after #11909 when additional checks on pull mirror configuration was added.
This PR addresses the issue and has been manually tested against the same git version:
```
$ git --version
git version 2.34.1
$ make test-sqlite#TestMirrorPull 2>&1
...
=== TestMirrorPull/migrate_from_repo_config_credentials (tests/integration/mirror_pull_test.go:238)
PASS
```
## 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/12134
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
- shrink runner list width (use icons, move details link to runner name)
- add owner to runner details on admin view
- #11516 removed a lot details which makes it much harder for an admin to find a specific runner
---
### admin list
### admin org runner details
### admin repo runner
### individual list
### individual runner details
### tooltips for edit and delete
 
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12113
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
While developing tests for #12092, I came across a case where making a comment on a single-commit doesn't include the correct diff for the comment. This is because code comment placement occurs between the PR's base and the commit being viewed, but, that diff could be different from the commit's parent to the commit, which is what is being viewed on a single-commit diff.
Similar to #12055, this PR changes code comments to be more precise in their diff generation by providing the backend with both the base commit (`before_commit_id`) and head commit (`after_commit_id`) currently being viewed. As a result, the diffs attached to comments should exactly match the diffs being viewed by the user when the comment was placed.
## 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...
- [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/12107
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
- It's quite hard to determine when and why this was added here, my best
guess is that this being the "oldest" subcommand at some point loading
the configuration was not unified. Now it is unified in
`prepareWorkPathAndCustomConf` which is run before any subcommand is
run. It determines the work path, custom path and (custom) config and
then loads the settings by calling `LoadCommonSettings`.
- Between `prepareWorkPathAndCustomConf` being called and
`serveInstalled` being called the `setting.CustomConf` is not changed.
There was a possibility this being necessary for install page ->
installed, but the install code already ensures that the new config is
loaded and used.
- Thus calling to load the settings again here is not necessary. There's
a small possibility some settings loading code was written to only work
after being loaded the second time. That's a bug that needs to be fixed,
because all other subcommands does not load the settings twice and would
see a different view of the settings in that case. I don't fear such
code being present here.
- Resolvesforgejo/forgejo#11024
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12111
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
First round of patches to re-enable some lints from my side.
This PR also refactors the general key fetching code quite a bit due to the way it currently worked
with relying on some values being nil sometimes.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11253
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-committed-by: famfo <famfo@famfo.xyz>
With the completion of #12015, when a comment is left on a changed line in a pull request, we track the comment against the line of code with `git blame` and then identify where it currently is in any diff with `git blame --reverse`. However, this strategy only works for the *modified* lines of code -- eg. the `+...` in diffs, and not the `-...` in diffs. The reason is that `git blame --reverse` can't track a line of code's location past the commit that it was removed in.
To permit comments that are left on lines of code that are removed to appear correctly in the UI, a separate approach is required for those comments. This PR performs two major changes, which have been complex to figure out, but are reasonably easy to understand:
- When a comment is placed on a removed line in a PR, perform a `git blame --reverse` from the PR's base to the currently viewed commit, and use this information to record in the comment:
- the **last commit that the line of code existed in** (stored in the `commit_sha` field)
- the **line of code as of that commit** (stored in the `line` field, negative, to indicate that the comment is on a removal).
- the **patch** where the comment was placed (stored in the field `patch`); existing functionality unchanged in this PR
- When viewing any diff in the PR, for each comment on a removal, perform a diff from the `commit_sha` (last commit that the line of code existed in) to the current commit being viewed, and verify that within that diff the left-hand-side line removal still exists at the same line of code in the diff, by comparing the current diff with the stored patch.
- If present, place the commit in the UI at the line number.
- If the line of code no longer exists in the diff at that point (for example, it was removed, commented upon, and then re-added in a later commit), then the comment is considered outdated and isn't displayed.
The algorithm used for marking a comment as "outdated" is also updated to use this approach.
## 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.
- [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/12092
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes https://codeberg.org/forgejo/forgejo/issues/12082 by reverting commit dd968f147d.
## 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...
- [ ] `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.
- [ ] 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/12088
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
Currently, forgejo does not support syntax highlighting code-blocks that have comma separated attributes after the language. This is a pattern sometimes seen in Rust code blocks, with tests like this:
\`\`\`rust
#[test]
fn run_this_test() { /* ... */ }
\`\`\`
\`\`\`rust,ignore
#[test]
fn skip_this_test() { /* ... */ }
\`\`\`
Currently, forgejo only does syntax highlighting in the first case:
```rust
#[test]
fn run_this_test() { /* ... */ }
```
```rust,ignore
#[test]
fn skip_this_test() { /* ... */ }
```
An example of this causing problems can be seen in this commit (5be9c5b7d2) causing the following issue (https://codeberg.org/zesterer/ariadne/issues/188).
This PR fixes fixes the second case not getting proper syntax highlighting.
Co-authored-by: TurtleArmy <44322335+TurtleArmyMc@users.noreply.github.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12056
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Ellen Εμίλια Άννα Zscheile <fogti@noreply.codeberg.org>
Co-authored-by: TurtleArmy <turtlearmy@noreply.codeberg.org>
Co-committed-by: TurtleArmy <turtlearmy@noreply.codeberg.org>
This is hopefully the final part of PR #4767, rebased and squashed.
More thorough federation tests are at https://code.forgejo.org/forgejo/end-to-end/pulls/1276 but the mock has been extended to hopefully cover a good chunk as well.
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-authored-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
Co-authored-by: zam <mirco.zachmann@meissa.de>
Co-authored-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10380
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-committed-by: famfo <famfo@famfo.xyz>
When performing `git blame` to identify the commit that a line of code came from, limit the blame to the commit that is currently being viewed in the UI. Before this change, the blame always occurred on the current head of the PR, causing these problems:
- When you click ➕ to load the comment form, the form that is dynamically loaded would have it's commit field pulled from the current PR head. That may not actually reflect the code that you were viewing at the time you authored the comment -- it could be a newer commit that occurred by the author while you were reviewing.
- When viewing a specific commit within a PR and leaving a comment, the blame would occur from the head -- if the file was changed in a later commit and the line-of-code moved up or down, the comment would be misplaced.
## 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12055): <!--number 12055 --><!--line 0 --><!--description d2hlbiByZXZpZXdpbmcgaW4gUFJzLCBtYWtlIGNvbW1lbnRzIHJlbGF0aXZlIHRvIHRoZSB2aXNpYmxlIGNvZGUncyBjb21taXQ=-->when reviewing in PRs, make comments relative to the visible code's commit<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12055
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Currently when a commit is pushed to a branch, code comments are marked as Outdated if a `git blame` on the current commit's code returns the same commit as the `git blame` did when the comment was originally created. This implementation doesn't make sense:
- It doesn't handle the case correctly where the same line of code exists unaltered in the new commit, but it has been relocated (eg. new lines entered or removed above the location).
- It falsely keeps the commit valid if the line of code that the comment was made upon has been removed, if, coincidentally, the line of code that now exists at the commit came from the same source commit. For example, if the line of code that the comment was on was deleted, but the next line of code came from the same commit, the comment will be kept as valid.
This PR uses the logic introduced in #12015, using a `git blame --reverse` -- the commit & line that was identified as having the comment on it is reversed, and if it still exists in the new head, then the comment is considered valid. Otherwise it is marked as outdated.
Automated tests are added primarily by revising the automated tests in #12015 -- a comment in an existing test case was marked as outdated, even though it shouldn't have been.
## 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...
- [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-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12054): <!--number 12054 --><!--line 0 --><!--description bWFyayBjb2RlIGNvbW1lbnRzIGFzIE91dGRhdGVkIGJhc2VkIHVwb24gbGluZS1vZi1jb2RlIGV4aXN0ZW5jZSBpbiBjdXJyZW50IFBSIGNvbW1pdA==-->mark code comments as Outdated based upon line-of-code existence in current PR commit<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12054
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
When a review comment is placed on a PR in Forgejo, Forgejo performs a `git blame` to identify which commit originated the line, and records that commit and line number in the comment's database record. Later when the review is viewed, Forgejo currently makes no effort to place that comment in the correct *current* location, which may vary -- for example, if a PR had two commits and the comment was made on a line in the first commit, but the second commit changes line numbers in that file, the comment will appear in the incorrect location.
This PR adds the usage of `git blame --reverse` to calculate the correct location to display the comment in the current view (whether reviewing the PR commit-by-commit, or "Files changed"). It certainly does not fix all problems with comment placement (see comments).
Another major addition in this PR is a test harness for making relatively complex PRs and reviewing the diffs on the per-commit view and PR-diff views.
## 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.
- [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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/12015): <!--number 12015 --><!--line 0 --><!--description cmVsb2NhdGUgUFIgcmV2aWV3IGNvbW1lbnRzIHVzaW5nIGBnaXQgYmxhbWUgLS1yZXZlcnNlYCwgaW1wcm92aW5nIGNvbW1lbnQgcGxhY2VtZW50-->relocate PR review comments using `git blame --reverse`, improving comment placement<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12015
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [data.forgejo.org/forgejo/forgejo](https://forgejo.org) ([source](https://codeberg.org/forgejo/forgejo)) | patch | `11.0.11` → `11.0.12` |
---
### Release Notes
<details>
<summary>forgejo/forgejo (data.forgejo.org/forgejo/forgejo)</summary>
### [`v11.0.12`](https://codeberg.org/forgejo/forgejo/releases/tag/v11.0.12)
[Compare Source](https://codeberg.org/forgejo/forgejo/compare/v11.0.11...v11.0.12)
See <https://codeberg.org/forgejo/forgejo/src/branch/forgejo/release-notes-published/11.0.12.md>
</details>
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- Between 12:00 AM and 03:59 AM (`* 0-3 * * *`)
- Automerge
- Between 12:00 AM and 03:59 AM (`* 0-3 * * *`)
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMDQuNCIsInVwZGF0ZWRJblZlciI6IjQzLjEwNC40IiwidGFyZ2V0QnJhbmNoIjoiZm9yZ2VqbyIsImxhYmVscyI6WyJkZXBlbmRlbmN5LXVwZ3JhZGUiLCJ0ZXN0L25vdC1uZWVkZWQiXX0=-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12084
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Renovate Bot <bot@kriese.eu>
Co-committed-by: Renovate Bot <bot@kriese.eu>
If Forgejo encounters an Actions workflow with unknown jobs in a needs definition, Forgejo will ignore those and run the job anyway. That is bad. For example, releases could be published without any testing because the name of the testing job was misspelt.
Workflow that demonstrates the problem:
```yaml
on:
push:
workflow_dispatch:
jobs:
build:
runs-on: debian
steps:
- run: |
echo "OK"
test:
runs-on: debian
needs: [does-not-exist]
steps:
- run: |
echo "OK"
```
Now, before a workflow is run, Forgejo will check whether all jobs referenced in `needs` exist. If any of them does not, it raises a pre-execution error which fails the workflow immediately. It also displays an appropriate error to the user, for example:
```
Workflow was not executed due to an error that blocked the execution attempt.
Job with ID test references unknown jobs in `needs`: does-not-exist.
```
Futhermore, workflows with pre-execution errors can no longer be rerun, which was previously possible.
Original issue: https://code.forgejo.org/forgejo/runner/issues/977.
## 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
### 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.
- [ ] 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/12046
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Followup of !11115, it was not checked against the the modernizer linter.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12065
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Fixes#6438
When a protected branch requires signed commits and no signing key is available, fast-forward-only merges should still be allowed because they do not create a new commit.
This patch applies signing checks by merge behaviour/style instead of one global gate:
- pass `mergeStyle` through `CheckPullMergeable(...)` in web/API/automerge paths
- require signing for commit-creating styles (`merge`, `rebase`, `rebase-merge`, `squash`)
- bypass signing precheck only for `fast-forward-only`
- align merge UI options with backend behaviour so signing-dependent styles are unavailable when signing cannot happen
- add Go unit tests for merge-style signing requirements
- add frontend unit coverage for the no-allowed-merge-styles guard
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11403
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: abdo <dev@abdo.wtf>
Co-committed-by: abdo <dev@abdo.wtf>
Fixes#9282
Adds a new admin panel category for federation related administration.
Includes views for:
- Instance Federation Configuration
- List of Federation Hosts
- (Per-Instance) List of Federated Users
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11115
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
Reviewed-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Florian Pallas <mail@fpallas.com>
Co-committed-by: Florian Pallas <mail@fpallas.com>
Display the version of Forgejo Runner on the runner's detail page. That is useful for diagnostics.
Originally, the version was displayed on the overview page, but removed in https://codeberg.org/forgejo/forgejo/pulls/11516 due to space constraints. It should have been moved to the details page, but that never happened.
## 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...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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
- [ ] 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/12059
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
This reverts commit 79ed45d39a.
Testing has shown that it breaks Docker 26 which is the version included in Debian Trixie.
It was originally introduced with https://codeberg.org/forgejo/forgejo/pulls/11678.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12058
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Since https://codeberg.org/forgejo/forgejo/pulls/11750, the attempt number of a Forgejo Actions job is set eagerly. When an job is ultimately not run, for example, because its `needs` weren't satisfied, it leads to discontinuous attempt numbers of completed attempts that the component for viewing action logs could not handle. This has been rectified by actually determining the number of the last attempt.
Resolves https://codeberg.org/forgejo/forgejo/issues/11994.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12021
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Fixes https://codeberg.org/forgejo/forgejo/issues/6163
Fixes https://codeberg.org/forgejo/forgejo/issues/3343
The merge base doctor check & fix was broken and could introduce irreversible "fixes" to wrong merge bases for PRs using the `fast-forward` and `rebase-and-merge` strategies.
The mergebase fix was originally introduced in a migration [0] to fix an existing issue [1] in the merge code in 2020.
Later added as a doctor command without explanation [2].
We decided to remove this check, as there is no apparent reason for it to still be necessary or any PR merge base state being out of sync with the current implementation.
It does more harm to keep the code in and there is no way to fix `fast-forward` and `rebase-and-merge` PRs, due to their merge implementation.
`fast-forward`: The git state inherently cannot reconstruct a merge base in this scenario by design.
`rebase-and-merge`: Is rebased on a temporary repository clone and thus might receive a different merge base, depending on how far the target branch is ahead.
[0]: 4a2b76d9c8
[1]: 4a2b76d9c8
[2]: d26885e2bf (diff-84d6d60112991392d6ba2cae4cd919fb3ee8afb8)
## 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
- [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/12023
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Saibotk <git@saibotk.de>
Co-committed-by: Saibotk <git@saibotk.de>
When using Forgejo's `enable-openid-connect: true`, a URL is generated into the actions under `$ACTIONS_ID_TOKEN_REQUEST_URL` that can be used to generate a JWT for accessing third-party resources authenticated as the action executing in this server on this repo. However, the endpoint of that url (`.../idtoken`) had unintentionally missed a `return` on an internal server error, and was missing a check that the action actually had `enable-openid-connect: true` on it. As a result, it was possible to generate a JWT for accessing third-party resources from an action that wasn't expected to be generating JWTs.
In terms of real-world vulnerability, the most likely risk is that the JWT could be generated from a forked pull request. By not using the `$ACTIONS_ID_TOKEN_REQUEST_URL` and instead going directly to the `.../idtoken` endpoint, and parsing a generated JWT response that will be mixed with an error response, it's possible to retrieve a JWT in a forked pull request. It would require a slight misconfiguration on a third-party system to allow that JWT access, but it's a plausible risk.
As this is a feature in Forgejo 15 that hasn't been released, it will be fixed in-public.
## 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
- [ ] 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.
- Feature is not yet released.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12030
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes https://codeberg.org/forgejo/forgejo/issues/11880.
Adding `hx-on::after-settle="this.querySelector('button').focus()"` restores focus after the content has been swapped and the DOM has been setled. I tried `hx-on::after-swap` first since it's mentioned more often in https://github.com/bigskysoftware/htmx/issues/1869, but it didn't work.
The demo attached in `focus.mp4` runs through a series of repeated clicks on both buttons. You can hear the screen reader announce the button's new label when focus is restored.
### 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.
*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/11932
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
https://codeberg.org/forgejo/forgejo/issues/11116
To understand the impact of this you really need to listen to the before and after screen recordings attached. https://codeberg.org/forgejo/forgejo/issues/11116 is a really great bug report, and I was surprised by how disorienting this actually was when testing manually compared to my expectation after reading the issue. This is an impactful improvement!
This is my first time adding new translation strings. Excited to learn more about that if I've guessed wrong about how to do it.
To summarise, what we're doing here is as follows.
1. Address the core issue by changing the existing `<th>` elements to `<td>` so that screen readers stop semantically associating them with each row and reading them out for every table cell.
2. Replace them with real `<th>` elements that communicate the true semantic role of each column.
3. Add a `<caption>`. This serves a dual purpose: it gives the table an accessible name which improves the navigability of the page, and it gives us a place to explain to the user that the first row of the table is a little bit different because it's the latest commit rather than a file in the repo.
4. Visually hide the new caption and headings so that only screen reader users get them.
## 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 JavaScript 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.
- [ ] 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/11846
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
https://codeberg.org/forgejo/forgejo/pulls/11851 introduced tests that verify the scheduling of Forgejo Actions workflows during daylight saving time (DST) changes. Unfortunately, one test didn't test what it was supposed to because it used a reference time in UTC that was already after the clock change has happened.
This change also adds tests that verify that `NewActionScheduleSpec()` respects time zones when calculating the initial execution time of a scheduled workflow.
## 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
### 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
- [ ] 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/12007
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
This PR is a minimal implementation to add `/actions/runs/{id}/jobs` (#11859).
This endpoint is also required by `/actions/jobs/{id}/logs`.
The pagination, filtering, custom sorting, more response fields are left to future work.
## Usage
```
curl -X 'GET' \
'https://hostname/api/v1/repos/{owner}/{repo}/actions/runs/{id}/jobs' \
-H 'accept: application/json'
```
## 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.
- [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.
Co-authored-by: elbaro <elbaro@users.noreply.github.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11915
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: elbaro <elbaro@noreply.codeberg.org>
Co-committed-by: elbaro <elbaro@noreply.codeberg.org>
`DefaultMaxInSize` is an internal parameter for limiting the size of `field IN (...)` clauses in DB queries, which is a reasonable thing to do -- in addition to the errors noted when [originally introduced](https://github.com/go-gitea/gitea/pull/4594), there are technical limits that apply to each of PostgreSQL, MySQL, and SQLite which would prevent an unbounded size for a query like this. However: the size is incredibly small at 50, and, the implementation of `DefaultMaxInSize` is really wasteful with copy-and-paste coding.
This PR:
- introduces `GetByIDs` which fetches a `map[int64]*Model` from the database for an array of ID values, while respecting `IN` clause size limits
- introduces `GetByFieldIn` which fetches a `map[int64][]*Model` from the database for an array of field values, while respecting `IN` clause size limits
- uses `slices.Chunk` for other locations where queries are too complex for these implementations
- bumps the `DefaultMaxInSize` parameter from 50 to 500, a conservative increase well under known limits, but 10x the current value:
- PostgreSQL supports up to 1GB query text size with 65,535 parameters, but I've experienced performance degradation at high value counts
- MySQL supports 64MB query text size without known limits of parameter count
- SQLite supports 32,766 parameters in a query
## 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.
- Refactored functions are assumed to be covered by existing tests to some extent; that assumption is probably wrong but the changes here are relatively easily reviewed for correctness as well.
- [ ] 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/11999
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#11968.
Adds deadlocks to the package `RetryTx` operations, and bumps the attempt count to 3. Technically this affects production code, not just test code, but the resulting failure is only likely to occur in highly concurrent operations when uploading packages to the debian registry for the first time for a user, which is more of a test artifact than a production likelihood.
Manually tested by modifying the `Makefile` to add the `-test.count=25` option to the test command. This failed consistently on my dev system before this change, failed consistently after the deadlock err was added, and then succeeded consistently (multiple runs) after both changes were combined, giving me confidence that the intermittent failure is squashed.
## 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.
- Fixing a test failure, so no new tests added, but they already failed.
- 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/11997
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Optimize loading pull request review comments, which currently perform separate database queries for each comment in order to load the resolver of the comment, and the reactions on that comment, and the users on each reaction of the comments.
I stumbled across this ugly code, which enticed me to look into this:
80d840c128/routers/web/repo/pull.go (L1107-L1120)
It appeared to load the attachments from each comment on the pull request review page in separate database queries. It turned out to be a noop, as the attachments are already loaded in bulk:
80d840c128/models/issues/comment_code.go (L120-L122)
but the `findCodeComments` method loads the "resolver doer" and the reactions one-by-one for each comment. So I fixed that instead, and removed the ineffective deeply nested for loop.
## 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.
- [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/11988
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
GitHub recently added the ability to [specify a time zone for scheduled workflows](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onschedule), thereby making it possible to run scheduled workflows at a certain local time, no matter whether daylight saving time (DST) is currently active or not. Example copied from GitHub's documentation:
```yaml
on:
schedule:
- cron: '30 5 * * 1-5'
timezone: "America/New_York"
```
The workflow would run at 05:30 each morning in the America/New_York timezone every Monday through Friday. `timezone` accepts IANA time zone names. If `timezone` is absent, `Etc/UTC` is used. GitHub runs workflows that were scheduled during DST jumps forward, for example, between 2 o'clock and 3 o'clock, directly after the clock jumped forward. In this case, that would be 3 o'clock.
Forgejo already supports time zones by prepending cron schedules with `TZ=<zone-id>` or `CRON_TZ=<zone-id>`:
```yaml
on:
schedule:
- cron: 'CRON_TZ=America/New_York 30 5 * * 1-5'
```
However, that capability is not documented. Workflows that are scheduled to run during DST changes are skipped when the clock jumps forward and run twice when it jumps backward.
This two-part PR adds support for `timezone` to improve compatibility with GitHub. `TZ` and `CRON_TZ` continue working. When both `timezone` and `TZ` or `CRON_TZ` are present, `timezone` takes precedence. When neither `timezone` nor `TZ` nor `CRON_TZ` are present, `Etc/UTC` is used as before. Because `TZ` and `CRON_TZ` were already supported by Forgejo before GitHub introduced `timezone`, `timezone` behaves during DST changes as previous versions of Forgejo, thereby deviating from GitHub. That means that workflows that are scheduled to run during DST changes are skipped when the clock jumps forward. And they run twice when it jumps backwards. However, it is generally recommended not to schedule workflows during the time of day when DST changes occur.
This part of the PR integrates the [workflow validation and parsing of the `timezone` field](https://code.forgejo.org/forgejo/runner/pulls/1454) supplied by Forgejo Runner.
## 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
- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- https://codeberg.org/forgejo/docs/pulls/1853
- [ ] 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/11851): <!--number 11851 --><!--line 0 --><!--description c3VwcG9ydCBgdGltZXpvbmVgIGluIHNjaGVkdWxlZCB3b3JrZmxvd3M=-->support `timezone` in scheduled workflows<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: Renovate Bot <bot@kriese.eu>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11851
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
When two goroutines attempt to access the content of the buffer log writer, they must be made thread safe with a write mutex.
The buffer log writer is only used in testing.
## Checklist
### 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...
- [ ] `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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11962
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: limiting-factor <limiting-factor@posteo.com>
Co-committed-by: limiting-factor <limiting-factor@posteo.com>
Fixes#9629.
New pull mirrors have credentials stored encrypted in the database, the same as push mirrors, rather than in the repository's `config` file. `git fetch` on the pull mirror is updated to use the credential store. Pull mirrors will have their credentials migrated to the encrypted storage in the database as they're synced or otherwise accessed via the web UI.
## 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...
- [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/11909
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [https://data.forgejo.org/actions/setup-forgejo](https://code.forgejo.org/actions/setup-forgejo) | action | patch | `v3.1.8` → `v3.1.9` |
---
### Release Notes
<details>
<summary>actions/setup-forgejo (https://data.forgejo.org/actions/setup-forgejo)</summary>
### [`v3.1.9`](https://code.forgejo.org/actions/setup-forgejo/compare/v3.1.8...v3.1.9)
[Compare Source](https://code.forgejo.org/actions/setup-forgejo/compare/v3.1.8...v3.1.9)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My45OS4xIiwidXBkYXRlZEluVmVyIjoiNDMuOTkuMSIsInRhcmdldEJyYW5jaCI6ImZvcmdlam8iLCJsYWJlbHMiOlsiZGVwZW5kZW5jeS11cGdyYWRlIiwidGVzdC9ub3QtbmVlZGVkIl19-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11980
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Renovate Bot <bot@kriese.eu>
Co-committed-by: Renovate Bot <bot@kriese.eu>
This copy button on the pull request page lacks an accessible name. You can hear the screen reader announce it as just "button" in the screen recording `button.mp4`, and then hear the amended version in `copy.mp4` where it's announced as "copy, button".
The most relevant WCAG success criteria here is [1.1.1 Non-text content](https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html).
### 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.
*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/11895
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
https://codeberg.org/forgejo/forgejo/pulls/11750 missed a place where the attempt number is incremented independently. This caused the job view to break when running a reusable workflow with workflow expansion.
## 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
- [ ] 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/11956
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
* migrate 17 strings related to repository migrations from INI to JSON
* changed templates to get rid of unhelpful prefix `repo`
* migrate 4 strings related to counters
* also changed templates to get rid of `repo`, but it had to be done anyway to use `TrPluralString`
* Unhardcode the header on migraiton type selector page, which I haven't noticed in https://codeberg.org/forgejo/forgejo/pulls/6795 or in two other PRs I did on this template since
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11879
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Picks the update commit from https://codeberg.org/forgejo/forgejo/pulls/11200 and fixes the new incompatibilities.
I ran full end-to-end tests against Forgejo and basic end-to-end tests against GoToSocial which appear to be working.
Co-authored-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11301
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-committed-by: famfo <famfo@famfo.xyz>
Fixes#11919.
## 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...
- [ ] `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.
- Will be a fix before the feature is released, therefore not "visible to users".
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11927
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Antonin Delpeuch <wetneb@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#11842.
The `once: true` was likely added to prevent multiple concurrent
submissions of the same form. This could still be worth preventing,
but I suspect it would require wrapping the supplied `onApprove`
callback with the corresponding logic, implemented manually, as I
am not aware of any native API to prevent concurrent executions of
callbacks.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11843
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Fixes https://codeberg.org/forgejo/forgejo/issues/7668.
This was simpler to fix than my theory I posted on https://codeberg.org/forgejo/forgejo/issues/7668 about needing to patch the upstream package. When testing in Firefox with the developer console open and warnings enabled, I noticed a `Empty string passed to getElementById()` warning coming from `@github/combobox-nav` while attempting to manage the `aria-activedescendant` attribute. Then I found this in the [README for that project](https://github.com/github/combobox-nav).
> Markup requirements:
> - Each option needs to have role="option" and a unique id
This was easy to miss, as we're using `@github/text-expander-element` and the combobox-nav package is one of _its_ dependencies. Without a unique ID on each dropdown menu item, `@github/text-expander-element` is unable to set an appropriate `aria-activedescendant` attribute on the textarea. Once that's in place, the screen reader announcements come to life beautifully.
While working on it I noticed the emoji picker combobox was affected by the same problem and patched that as well.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11860
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
Fixes https://codeberg.org/forgejo/forgejo/issues/9894.
The dropdown menu items are being hidden with `.tw-hidden`. The Fomentic dropdown makes items with `.disabled` and `.filtered` unselectable by default but can be [easily configured](https://fomantic-ui.com/modules/dropdown.html#/settings) to broaden this selector.
In the before & after GIFs attached, there is an archived label between "duplicate" and "help wanted". In the before GIF, focus disappears momentarily between the two, which is when the hidden, archived label has been programmatically focused by Fomentic. In the after GIF, focus hops instantaneously between the two selectable labels because of the broader `unselectable` selector.
### 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.
- [ ] 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/11858
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
Fixes https://codeberg.org/forgejo/forgejo/issues/6621.
The attached screen recording `before.mp4` demos the problem as described by https://codeberg.org/forgejo/forgejo/issues/6621. And `after.mp4` is the fixed version.
### 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.
*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/11878
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
By setting `aria-current="page"` on the active navbar item we make the information about which one corresponds to the current page available in a non-visual way. Both the attached screen recordings were produced on http://localhost:3000/pulls, so the "Pull requests" link is the active one. In `before.mp4` all the links are announced identically, and in `after.mp4` the "Pull requests" link is announced like this.
> current page, visited, link, Pull requests
### 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.
*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/11887
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
The authentication provider's name (`$provider.DisplayName`) is not URL-encoded, so any illegal characters (e.g., '/') will be put in the link's href attribute verbatim.
For example, if the provider's name is `foo/bar` (valid name), the href attribute will point to `/user/oauth2/foo/bar` instead of `/user/oauth2/foo%2Fbar`, resulting in a "404 Not found" error.
This patch fixes this behaviour by URL-encoding the provider's DisplayName before appending it to the href attribute.
Signed-off-by: doasu <me@doasu.dev>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10301
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: doasu <me@doasu.dev>
Co-committed-by: doasu <me@doasu.dev>
Fixes an intermittent test failure in `TestPackageDebianConcurrent`, [example](https://codeberg.org/forgejo/forgejo/actions/runs/148747/jobs/9/attempt/1#jobstep-5-981), introduced by testing in #11776. This one is caused by duplicate writes to `user_setting` to store a GPG key (questionable place for that...).
Confirmed reproduced in local testing and test now passes:
```
=== TestPackageDebianConcurrent (tests/test_utils.go:344)
=== TestPackageDebianConcurrent/Concurrent_Upload (tests/integration/api_packages_debian_test.go:334)
... other duplicate key violations ...
// TestPackageDebianConcurrent/Concurrent_Upload
"2026/03/29 10:31:57 ...dels/user/setting.go:210:func1() [E] [Error SQL Query] INSERT INTO \"gtestschema\".\"user_setting\" (\"user_id\",\"setting_key\",\"setting_value\") VALUES ($1,$2,$3) RETURNING \"id\" [2 debian.key.private -----BEGIN PGP PRIVATE KEY BLOCK-----\n\n...snip...\n-----END PGP PRIVATE KEY BLOCK-----] - ERROR: duplicate key value violates unique constraint \"UQE_user_setting_key_userid\" (SQLSTATE 23505)",
PASS
```
No additional test required as it is already tripping a test failure.
## 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.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. (already present and failing)
- 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/11881
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Prevent access to "current" application models and services from migrations via `golangci` config:
eg:
```
models/forgejo_migrations/v14a_ap-change-fedi-handle-structure.go:18:2: import 'forgejo.org/models/user' is not allowed from list 'migration-isolation': Migrations must not import application models. Application models will be the most recent schema for Forgejo, while migrations will be operating against the database schema that existed when they were authored. (depguard)
user_model "forgejo.org/models/user"
^
models/forgejo_migrations/v14a_ap-change-fedi-handle-structure.go:21:2: import 'forgejo.org/services/user' is not allowed from list 'migration-isolation': Migrations must not import application services. Application services will reference application models which will use the most recent schema for Forgejo, while migrations will be operating against the database schema that existed when they were authored. (depguard)
user_service "forgejo.org/services/user"
```
Fixes an existing migration issue where it isn't possible to add a new column to the `User` table ([test errors that occur](https://codeberg.org/forgejo/forgejo/actions/runs/148633/jobs/10/attempt/1#jobstep-5-323)), but also guarantees that future migrations don't stumble into the same issue by inadvertently referencing live application code from historical migrations.
Originally identified and draft fix by @codecat w/ proposed fix in #11870.
## 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.
- [ ] 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.
Co-authored-by: Melissa Geels <melissa@nimble.tools>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11872
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#1529.
This adds an "Add member" button to the list of members of an organization, offering a more intuitive way to add a user to an organization (instead of going through the list of teams).
This follows the design proposed in #1529. This PR can already be reviewed as such, but I plan to work on follow-up improvements:
- adding a confirmation dialog when adding the new member to the "Owners" team, since they get absolute rights on the org
- adding a text input to filter the list of teams, making it easier to select the desired teams when there are many of them
- potentially, improving the team creation link so that it brings the user back to the modal dialog once the team is created (but I'm not sure there's a ton of value behind this added complexity, since currently, creating a team will lead the user to the team page, which is a good place to add the member to the team)
This new way of adding members does not support issuing email invites, since we decided in #9884 that the invite feature hasn't got good enough of a UX to advertise it yet. Following [this discussion](https://codeberg.org/forgejo/discussions/issues/441), I am planning to work on enabling invites everywhere (potentially even making it the default).
## Checklist
### 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
### Tests for JavaScript changes
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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 plan to update https://docs.codeberg.org/collaborating/create-organization/#people once we are ready to take final screenshots of the feature.
### 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.
### Screenshots
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11848): <!--number 11848 --><!--line 0 --><!--description IkFkZCBtZW1iZXIiIGJ1dHRvbiBpbiBvcmcgbWVtYmVycyBsaXN0-->"Add member" button in org members list<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11848
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Use `--token-url` instead of `--token` in the runner setup instructions. `--token-url` is more secure. It was also decided [not to implement `--token`](https://code.forgejo.org/forgejo/runner/pulls/1457). The new instructions look as follows:
```
$ echo -n "a3bac733-079f-4917-ae9f-4acb99f1827b" > /path/to/runner-token
$ forgejo-runner daemon \
--url http://192.168.178.62:3000/ \
--uuid 5982831f-8ee7-42c7-abcc-49c7d6dba586 \
--token-url file:///path/to/runner-token \
--label docker:docker://node:lts
```
`--label` is also new because Forgejo Runner is inoperable when neither a runner configuration nor `--label` are present.
## 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...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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
- [ ] 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/11874
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Fixes#11438.
Whenever a "unique constraint violation" error is encountered by package mutation, detect if a `xorm.ErrUniqueConstraintViolation` error occurs. If it does, retry the entire transaction.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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...
- [ ] `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/11776
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
If the HTTP request to `/user/repo/pulls/N/merge` is cancelled by the user agent, don't stop work once we've passed validation and started to merge the PR. Go will automatically cancel the context if the user-agent disconnects, but that can leave Forgejo in an inconsistent state -- the `git` command can be cancelled at an arbitrary location, the `branch` database table update may not be completed, timers may not be stopped, cross-references may not be populated, etc.
Added test `TestMergeHTTPRequestCancellation` stress-tests the fix by cancelling merge requests, and then verifying that the in-database repository state and in-repository database state are consistent. I've verified that this test fails if the fix is removed -- the in-database commit and commit messages don't match the repository in all PRs.
This is a problem that likely affects other Forgejo endpoints. For example, even the PR merge API would be impacted. But this will be one of the most common real-world places for it to occur, so my thought is we'll see how well this fix works and what (if any) side-effects it has. We can apply a similar pattern in other areas if they are identified as problems.
## 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/11821
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This pull fixes the issue described in https://codeberg.org/forgejo/forgejo/issues/11427 .
The api handler of link/unlink packages use escaped path params to find packages. It causes errors when it comes to npm packages, which contains characters like `@` and `/`.
## 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.
*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/11822
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Guangxiong Lin <hi@gxlin.org>
Co-committed-by: Guangxiong Lin <hi@gxlin.org>
ToDo: After merge schedule a PR to remove v14 when it is EoL
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11823
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
Forgejo Runner can optionally ask for a particular job. Example: `forgejo-runner one-job --handle 9d52c7d8-aebe-426b-b015-dd453aacaada`. This change adds the necessary job filtering to Forgejo.
See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/76 for the motivation and design considerations.
PR for the extension of the runner protocol: https://code.forgejo.org/forgejo/actions-proto/pulls/18
Related change in Forgejo Runner with usage example: https://code.forgejo.org/forgejo/runner/pulls/1443
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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/11676): <!--number 11676 --><!--line 0 --><!--description YWxsb3cgcnVubmVycyB0byByZXF1ZXN0IGEgcGFydGljdWxhciBqb2I=-->allow runners to request a particular job<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11676
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Forgejo CI is currently failing due to changes in debian testing packaging that are not compatible with installing `git` from testing onto a bookworm system (https://codeberg.org/forgejo/forgejo/actions/runs/147815/jobs/2/attempt/1#jobstep-3-144).
Where `git` was being installed from testing it is replaced with just using trixie's `git 2.47.3`. Where `git-lfs` was being installed, it's been inlined with a simple `update` and `install`.
### 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/11801
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Previously, a scheduled run would appear like a run triggered by a push. That could be confusing, especially if a scheduled run was unrelated to that particular commit. Now, either the workflow's name (taken from the field `name:`) is displayed or the path to workflow file, matching the behaviour of `workflow_dispatch`.
As a side-effect, the description of all run types were improved. They are no longer pieced together from individual translations. `workflow_dispatch` also no longer misattributes commits to the user that triggered the workflow.
Resolves https://codeberg.org/forgejo/forgejo/issues/11688.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11770
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Adds a user interface for creating repo-specific access tokens (#11311). When the new option "Specific repositories" is selected, a search option appears. Each repository in the search result has an "Add" button to include it on the access token, and once included, a repository can be removed with the "Remove" button. This is a JS-free form.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
### Tests for JavaScript changes
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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)).
- Technically there are no "JavaScript changes" in this PR, but e2e tests were added for browser interaction testing.
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- TODO: planning to create documentation in https://forgejo.org/docs/next/user/token-scope/; there is none for public only tokens but I think this seems like a good place to add both.
- [ ] 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/11696
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
So far, Forgejo's UI only allowed to create Forgejo Actions secrets. But renaming or replacing their value wasn't possible. With this change, users can do both. The existing secret value is never revealed for security reasons.
Additionally, a confusing behaviour is removed. If a user created a new secret whose name matched an existing secret, the existing secret was silently updated. That does no longer happen. The new secret is rejected instead.
Resolves https://codeberg.org/forgejo/forgejo/issues/5707.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11732
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
https://codeberg.org/forgejo/forgejo/issues/11512
Restoring default whitespace behaviour seems sufficient to resolve this. The `display: block` property is necessary because `<small>` is an inline element and otherwise the `padding-left` only applies to the first line. There's a description in one of the default label packages affected by the issue so I've used that for the before/after screenshots below.
| Before | After |
|-|-|
|  |  |
The issue doesn't just affect long descriptions though. In fact even the nice, short defaults are affected. Vision impairment is one of the most common disabilities, and increasing the text size is a typical way in which people adapt their computing environment to accommodate their disability. Even the short default label descriptions are cut off in this use case.
| Before | After |
|-|-|
|  |  |
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11607
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
A Forgejo Action job should be uniquely identifiable by its `ID` and `Attempt` number. Each time a particular job is (re-)run, its `Attempt` number is incremented while its `ID` remains static. Unfortunately, `Attempt` is not incremented when the (re-)run is triggered, but right when Forgejo Runner requests the job. That makes identifying a particular run much harder, because the attempt number is changed in the midst of an attempt. Furthermore, it requires taking the job's `Status` into account. This is fixed by setting the correct attempt number right when a (re-)run is triggered. That means that the `Attempt` number remains static for the duration of a single attempt.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
### 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.
- [ ] 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/11750
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Last known backend change for #11311, fixing up some loose ends on the repository APIs related to repo-specific access tokens.
Adds automated testing, and aligns permissions where necessary, to ensure that repo-specific access tokens can't change the administrative state of the repositories that they are limited to.
Repo-specific access tokens cannot be used to:
- convert a mirror into a normal repo,
- create a new repository from a template,
- transfer ownership of a repository
- create a new repository (already protected, but test automation added),
- delete a repository (already protected, but test automation added),
- editing a repository's settings (already protected, but test automation added).
**Breaking**: The template generation (`POST /repos/{template_owner}/{template_repo}/generate`) and repository deletion (`DELETE /repos/{username}/{reponame}`) APIs have been updated to require the same permission scope as creating a new repository. Either `write:user` or `write:organization` is required, depending on the owner of the repository being created or deleted.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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...
- [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/11736
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR improves and clarifies linter error reporting vs. dead code reporting.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11217
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Add more HTTP status codes returned by the API to the API documentation.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
- [ ] 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11717
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: hwipl <hwipl@noreply.codeberg.org>
Co-committed-by: hwipl <hwipl@noreply.codeberg.org>
The virtual session doesn't unconditionally call `Read` of the provider,
which means it's possible for a session to not exists (created by the
call to `Read`). To avoid that the call to `Destroy` fails with that the
session does not exists, do also the exists check for `Destroy`.
The permission check for editing the attachments of a comment (adding or removing them) is changed to be the same as when editing the textual body of the comment.
The poster of a comment can always edit it via the web UI, which includes the ability to remove or add attachments. It does not require write permission on the issue or pull unit of the repository.
The API is consistent with the web UI in how it [verifies permissions for editing comments][0] when modifying the textual content. However, when adding or removing the attachments of a comment, it [also requires write permissions][1] on the issue or pull unit, which is inconsistent with the web UI and more restrictive.
[0]: a581059606/routers/api/v1/repo/issue_comment.go (L606)
[1]: a581059606/routers/api/v1/repo/issue_comment_attachment.go (L359)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11623
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: limiting-factor <limiting-factor@posteo.com>
Co-committed-by: limiting-factor <limiting-factor@posteo.com>
Instead of going with a single extension, extracted by `filepath.Ext()`,
all possible extensions are now generated for a given filename, by
splitting the filename using a "." separator, starting with the
longest candidate. Moreover, each extension candidate is matched
against the actual set of known renderers (`extRenderers`), and
only the longest matching extension is used.
Resolves https://codeberg.org/forgejo/forgejo/issues/5190.
Co-authored-by: Michael Hanke <michael.hanke@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11439
Reviewed-by: Ellen Εμιλία Άννα Zscheile <fogti@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Matthias Riße <matrss@0px.xyz>
Co-committed-by: Matthias Riße <matrss@0px.xyz>
Add information about the git repository for wiki pages to the
Repository response in the API:
- has_wiki_contents: info whether wiki git repository already exists
- wiki_clone_url: the git clone URL of the wiki git repository
- wiki_ssh_url: the git SSH URL of the wiki git repository
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11589
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: hwipl <hwipl@noreply.codeberg.org>
Co-committed-by: hwipl <hwipl@noreply.codeberg.org>
We are updating the user's personal access token page (`/user/settings/applications`) to allow the creation of repo-specific tokens, adding a third option to "Repository and Organization Access". In preparation for this new UI, this PR moves the creation of access tokens to a new page accessed by "New access token".
This also resolves a pet-peeve: the "Select permissions" dropdown on the inline edit form hides a *required* input for an access token. This section is expanded on the new dedicated page. (The Vue component used here is replaced with a JS-free alternative as well. This form component used to lose selected values when an error occurred, and it didn't make sense as a Vue component, so it has been translated into an HTML template instead.)
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
- [ ] 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
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11659
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
https://codeberg.org/forgejo/forgejo/issues/11711 discovered that headers from the container registry are leaking into the other registries. That was introduced by https://codeberg.org/forgejo/forgejo/pulls/11393. This PR fixes the problem and adds a regression test to the Maven repository.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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/11733
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Improves the performance of the `/repo/search?uid=N` API call, which is used on the user's dashboard to load a repo list. More detailed notes are in https://codeberg.org/forgejo/forgejo/issues/11702.
Removes a redundant query condition (that a user was part of a team in an organization which could see a repo), and a condition that seems incorrect (that a repo could be seen just by being public within a private org, which is incorrect because that doesn't mean the user is a collaborator on the repo).
Covered by over 30 test cases in `repo_list_test.go` which did not fail from these changes. Mutation testing (removing the remaining "2." condition) verified that the codepath is covered as tests did fail.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
- [ ] 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/11729
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR fixes a bug where the previously-implemented functionality to delete the `.gitea/template` or `.forgejo/template` file when generating a repository from a template was not working. The issue happened because the code was using `util.Remove()` with a relative path, but this resolves against the process working directory instead of the temporary clone directory. The fix was to use `root.Remove()` which is based on an `os.OpenRoot()` anchored at `tmpDir`.
Updated integration tests and verified that they pass with this change and fail without it.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11691
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Brandon Rothweiler <bdr9@noreply.codeberg.org>
Co-committed-by: Brandon Rothweiler <bdr9@noreply.codeberg.org>
Closes#11400
Overflow is handled by javascript to show a button instead of horizontally scrolling, this is not the case when javascript is disabled. Add CSS to handle overflow, does not interfere with the javascript.
## Testing
1. Go to any repository.
2. Turn off javascript.
3. Make viewport width small.
4. Observe that repository menu under the repository header doesn't overflow.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11614
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Artyom Bologov <git@aartaka.me>
Co-committed-by: Artyom Bologov <git@aartaka.me>
- fix: show oauth2 retrieve error
- `true` indicates it only should be shown when the page is rendered
directly via `ctx.HTML` and not propagated if it redirects. As you can
see this always redirects and means the error is not shown.
- Has the funny behavior that you get redirected to `/user/login`
without any indication what went wrong, no errors in the logs either.
- fix: pre-process OAuth2 client ID and secret
- Spaces should are not appropriate for these input, remove them.
- Manually copying and pasting client ID and secret from Github OAuth2
applications seems prone to introduce whitespaces.
- The error of having a incorrect client ID is more noticeable (404 page
for the user).
- The error of having a incorrect client secret is not noticeable (404
page for the goth library but no mention it's the wrong secret).
Reported-by: marijnh
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11715
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- Delete blocked users entries.
- Organization cannot get blocked, it can block other people however.
- Delete following entries.
- Organization cannot follow, it can be followed by users.
- Resolvesforgejo/forgejo#11416
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11699
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
As requested in https://codeberg.org/forgejo/forgejo/pulls/11516#issuecomment-11430034, the headings of the list of recent tasks that were executed on a particular runner now indicate that only tasks are listed that originated in the current scope.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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.
- [ ] 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/11690
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Expose the attempt number of `ActionRunJob` in the HTTP API. It is required to uniquely identify a job run.
Example:
```
$ curl -u andreas --basic http://192.168.178.62:3000/api/v1/repos/andreas/test/actions/runners/jobs
```
```json
[{"id":63,"attempt":2,"repo_id":1,"owner_id":1,"name":"test","needs":null,"runs_on":["debian"],"task_id":0,"status":"waiting"}]
```
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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/11687
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Followup to https://codeberg.org/forgejo/forgejo/pulls/11516 which I didn't have time to review. Some consistency fixes.
Haven't done anything with the [actions in the table](https://codeberg.org/attachments/5a7eb4f2-c45c-4189-b952-ca4cd4085eb5) but something will need to be done. Like an ellipsis menu.
## Preview
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11675
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
After the [first attempt](https://codeberg.org/forgejo/forgejo/pulls/11393) to introduce a separate challenge for HTTP Basic Authentication failed and had to be [backed out](https://codeberg.org/forgejo/forgejo/pulls/11616) because two challenges in a single header field were not widely supported, we're trying it again. This time a second header `WWW-Authenticate` header is emitted.
Example:
```
$ curl -v -u andreas --basic http://192.168.178.62:3000/v2
Enter host password for user 'andreas':
* Trying 192.168.178.62:3000...
* Connected to 192.168.178.62 (192.168.178.62) port 3000
* using HTTP/1.x
* Server auth using Basic with user 'andreas'
> GET /v2 HTTP/1.1
> Host: 192.168.178.62:3000
> Authorization: Basic *****
> User-Agent: curl/8.15.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 401 Unauthorized
< Content-Length: 50
< Content-Type: application/json
< Docker-Distribution-Api-Version: registry/2.0
< Www-Authenticate: Bearer realm="http://192.168.178.62:3000/v2/token",service="container_registry",scope="*"
* Basic authentication problem, ignoring.
< Www-Authenticate: Basic realm="Forgejo Container Registry"
< Date: Sat, 14 Mar 2026 15:09:50 GMT
<
{"errors":[{"code":"UNAUTHORIZED","message":""}]}
```
Tested with Docker 29.1.3, Podman 5.8.0, and Apple container 0.9.0.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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...
- [ ] `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/11678
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Followup to https://codeberg.org/forgejo/forgejo/pulls/11604
These strings are used in similar contexts and can be reused. Fixed capitalization consistency (`specific_repo_access` inherited capitalization from `repo_and_org_access` which was nearby in the UI)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11683
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Came across a coding error from #11504 while working on adding a UI for repo-specific access tokens. I couldn't find a practical way to test this fix as there are no expected error conditions that will be returned here, just database-level errors, and the `SetFaultInjector` capability in testing is only integrated into unit tests, not integration tests.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11682
Reviewed-by: Cyborus <cyborus@disroot.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Add a `visible=true|false` flag to the HTTP API endpoints that return runners (`/user/actions/runners` and friends). Previously, all endpoints (except the one for admins) only returned the runners owned by the respective repository, user, or organization. The endpoint for admins returned all runners.
With this change, all endpoints only return the runners directly owned by the repository, user, organization, or instance by default (`visible=false`). With `visible=true`, the API returns the same runners as the UI. That means, for example, that `/repos/{owner}/{repo}/actions/runners?visible=true` returns all runners owned by the repository, its owner, and the instance.
Additionally, the behaviour of the endpoint for getting a single runner was altered. With this change, it permits accessing all _visible_ runners, thereby matching the UI. Previously, only runners directly owned by the repository, user, or organization could be obtained, whereas the admin could obtain all. Furthermore, existence probing is no longer possible.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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/11670
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Forgejo Runner [identifies runners by their UUID](https://code.forgejo.org/forgejo/runner/pulls/1380), not by their name. That means users should be able to find a runner in Forgejo not only using its name, but also using its UUID. With this change, when a user enters a (partial) UUID into the search bar on top of the list of runners, all matching runners will be found.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
### 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/11671
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
When fetching runners, the option `WithAvailable` can be enabled to fetch all runners that can be used by a repository, user, or organization, not only those that are owned by the respective repository, user, or organization. In the instance scope, `WithAvailable` has no meaning. You always get _all_ runners. This means it is impossible to only fetch runners that are owned by the instance, but no others.
This PR replaces `WithAvailable` with `WithVisible`. For repositories, users, and organizations, it has the same semantics as `WithAvailable`. For the instance scope, `WithVisible=true` equals today's default behaviour (i.e., return _all_ runners), whereas `WithVisible=false` is new and would only return the runners owned by the instance itself.
The advantage of `WithVisible` is that it has a consistent meaning across all scopes. This also lays the groundwork for the introduction of a `with-visible` (tentative name) flag in the HTTP API.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- [ ] 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/11657
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
When creating an access token via API, if `"repositories": []`, then it is expected that the intent of the user was to create a repo-specific access token, but the API currently creates an all-access access token instead. `"repositories": []` is expected to be an error, instead of an unexpectedly wide grant.
Reported by @aahlenst during testing: https://codeberg.org/forgejo/forgejo/pulls/11604#issuecomment-11569816
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- [ ] 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.
- Bugfix in unreleased feature.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11653
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
- Deleting attachments are also seen as updating attachments due to the frontend always sending a field to edit the name even if the name didn't change. This was not reflected in the unit tests.
- Refactor the updating attachment logic to be more flexible if a attachment does not exist, because it was just deleted or because someone is being malicious.
- Resolvesforgejo/forgejo#11636
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11642
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Forgejo Runner is deprecating the runner registration token. It is too powerful, requires tooling, and is unnecessary. https://codeberg.org/forgejo/forgejo/pulls/10677 added an HTTP API for runner registration. https://codeberg.org/forgejo/forgejo/pulls/11516 added the ability to manage runners using Forgejo's web interface and marked the runner registration token in the UI as deprecated. This PR deprecates the HTTP endpoints for obtaining the runner registration token by updating the API documentation. The implementation and all the tests remain in place and untouched.
See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/88 for context.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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...
- [ ] 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/11650
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
When an access token is repository specific, display the repositories that it can access when expanded in the UI (token **test** in this screenshot):
Default, collapsed view is unchanged:
Bulk loading of repositories is refactored out of the access token API endpoint into a `BulkGetRepositoriesForAccessTokens` method that can be used in both this UI, and the original API location.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11604
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Forgejo Runner is deprecating the runner registration token. It is too powerful, requires tooling, and is unnecessary. As a consequence, users need new mechanisms for managing runners in Forgejo. https://codeberg.org/forgejo/forgejo/pulls/10677 added an HTTP API for runner registration. This PR adds the ability to manage runners using Forgejo's web interface.
Runners can be added, modified, and deleted. It is also possible to regenerate a runner's token. When a runner is added or a runner's token is regenerated, setup instructions are displayed. They explain how to alter Forgejo Runner's configuration file or how to launch `forgejo-runner daemon` (yet to be implemented). The existing details page has been overhauled and is now accessible to all users that are allowed to use a particular runner. The details page displays additional information that had to be removed from the list of runners due to space constraints. The task list is filtered. That means it only lists jobs of the respective repository, user, or organization.
The runner registration token has been marked as deprecated.
See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/88 for context and design considerations.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
- [x] 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/11516
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
This is based on https://code.forgejo.org/go-chi/session/pulls/80.
The remainder of this message is largely copied from there:
For interoperability with reverse proxies and CDNs, setting a session
cookie for no good reason (login is a good reason) is a PITA, because it
makes caching of content for anonymous (not logged-in) users very hard,
requiring all kinds of special casing and error prone workarounds.
In particular in an age of exploitative AI bot crawling, being able to
serve content for anonymous users from a fast, efficient page cache is
an important option.
This patch lays a foundation by using an option added to go-chi/session
to not create session cookies always, but rather only when the
respective session is non-empty.
Test cases are included there and omitted here.
https://codeberg.org/forgejo/forgejo/pulls/11393 introduced a second challenge, one for HTTP Basic Authentication, to the existing `WWW-Authenticate` header sent by Forgejo's container registry in response to missing or invalid credentials. However, that led to unexpected compatibility issues with some clients. For example, it broke Renovate (see https://github.com/renovatebot/renovate/discussions/41774).
To be extra-safe, the decision was taken to revert that particular change without introducing a second header field (i.e., sending two `WWW-Authenticate` headers). That effectively restores the old behaviour.
```
$ curl -v -u andreas --basic http://192.168.178.62:3000/v2
Enter host password for user 'andreas':
* Trying 192.168.178.62:3000...
* Connected to 192.168.178.62 (192.168.178.62) port 3000
* using HTTP/1.x
* Server auth using Basic with user 'andreas'
> GET /v2 HTTP/1.1
> Host: 192.168.178.62:3000
> Authorization: Basic *****
> User-Agent: curl/8.15.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 401 Unauthorized
< Content-Length: 50
< Content-Type: application/json
< Docker-Distribution-Api-Version: registry/2.0
< Www-Authenticate: Bearer realm="http://192.168.178.62:3000/v2/token",service="container_registry",scope="*"
< Date: Tue, 10 Mar 2026 17:00:21 GMT
<
{"errors":[{"code":"UNAUTHORIZED","message":""}]}
```
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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/11616
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Fixes#11573
### 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.
- [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/11588
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Currently:
- In the database, `NULL` is used in `action_runner_token.owner_id` & `.repo_id` to represent an absent value, as required by the foreign key
- In the code, `0` is used in `ActionRunnerToken.OwnerID` and `.RepoID` to represent an absent value
This PR replaces the `int64` fields with `optional.Option[int64]` which allows a single data type to be used for both cases, and removes the usage of the value `0` as a placeholder.
This change has a limited scope -- although `ActionRunnerToken` uses `NULL` values in the database, the related table `ActionRunner` still uses zero-values for `OwnerID` and `RepoID`. This means a lot of code interacting with both of these tables still uses `0` values, such as the UI. The changes here were stopped at a reasonable point to avoid cascading into all places that use the `ActionRunner` table. (I'll continue this work in the future to enable foreign keys on `ActionRunner`, but likely after #11516 is completed to avoid serious conflict resolution problems.)
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11601
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
One of the security patches released 2026-03-09 [fixed a vulnerability](https://codeberg.org/forgejo/forgejo/pulls/11513/commits/d1c7b04d09f6a13896eaa1322ac690b2021539da) caused by a misapplication of Go `case` statements, where the implementation would have been correct if Go `case` statements automatically fall through to the next case block, but they do not. This PR adds a semgrep rule which detects any empty `case` statement and raises an error, in order to prevent this coding mistake in the future.
For example, code like this will now trigger a build error:
```go
switch setting.Protocol {
case setting.HTTPUnix:
case setting.FCGI:
case setting.FCGIUnix:
default:
defaultLocalURL := string(setting.Protocol) + "://"
}
```
Example error:
```
cmd/web.go
❯❯❱ semgrep.config.forgejo-switch-empty-case
switch has a case block with no content. This is treated as "break" by Go, but developers may
confuse it for "fallthrough". To fix this error, disambiguate by using "break" or
"fallthrough".
279┆ switch setting.Protocol {
280┆ case setting.HTTPUnix:
281┆ case setting.FCGI:
282┆ case setting.FCGIUnix:
283┆ default:
284┆ defaultLocalURL := string(setting.Protocol) + "://"
285┆ if setting.HTTPAddr == "0.0.0.0" {
286┆ defaultLocalURL += "localhost"
287┆ } else {
288┆ defaultLocalURL += setting.HTTPAddr
```
As described in the error output, this error can be fixed by explicitly listing `break` (the real Go behaviour, to do nothing in the block), or by listing `fallthrough` (if the intent was to fall through).
All existing code triggering this detection has been changed to `break` (or, rarely, irrelevant cases have been removed), which should maintain the same code functionality. While performing this fixup, a light analysis was performed on each case and they *appeared* correct, but with ~65 cases I haven't gone into extreme depth.
Tests are present for the semgrep rule in `.semgrep/tests/go.go`.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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/11593
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
The new filters are especially useful for status monotoring like kuma to have more relevant results.
The wrong status check seems to be a regression of #6300
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
### 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.
- [ ] 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/11584
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
AccessTokenError is never used as a Go error. In fact, it is returned
as a *AccessTokenError (which would result in a `nil` error when cast).
Rename the struct to a more accurate name and remove the unused
`Error() string` method to prevent future confusion.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11595
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Oliver Eikemeier <eikemeier@fillmore-labs.com>
Co-committed-by: Oliver Eikemeier <eikemeier@fillmore-labs.com>
Previously, issues were deleted from the indexer only when the repository was deleted.
Individually deleting issues would not remove them from the indexer.
Instead, they were merely hidden due to their IDs being absent from the DB.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11585
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
## What is broken
Quota on packages is not enforced when pushing to an organisation.
`enforcePackagesQuota()` calls `EvaluateForUser(ctx.Doer.ID, ...)` — it checks how much space the **uploader** personally owns, not the org being pushed to. Since packages accumulate under `package.owner_id = org_id`, the uploader always shows 0 bytes used and the check always passes.
This also means site admins bypass quota entirely when pushing to orgs (they get the service-layer admin bypass on top of the 0-byte measurement).
OCI/container routes (`/v2/...`) have the same problem but worse — `enforcePackagesQuota()` was not called on them at all.
## Fix
Check quota against `ctx.Package.Owner.ID` instead of `ctx.Doer.ID`. The package owner (the org or user being pushed to) is already available via `ctx.Package.Owner`, populated by `PackageAssignment()` before this middleware runs.
For individual user namespaces nothing changes — `ctx.Package.Owner` is the user themselves.
Also wired `enforcePackagesQuota()` into the missing OCI upload routes: `InitiateUploadBlob`, `UploadBlob`, `EndUploadBlob`, `UploadManifest` — both in the named `/{image}` group and the wildcard `/*` handler.
## Tested
Kind cluster, org `maw2` with 1 GiB quota, 2.6 GiB of container images already pushed:
- pushing a generic package to `maw2` as SA user → was 201, now 413
- pushing a generic package to `maw2` as `gitea_admin` → was 201, now 413
- initiating OCI blob upload to `maw2` as SA user → was 202, now 413
- pushing to own user namespace within quota → still 201
Co-authored-by: azhluwi <lukasz.widera@convotis.ch>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11442
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: wejdross <wejdross@noreply.codeberg.org>
Co-committed-by: wejdross <wejdross@noreply.codeberg.org>
When merging #9254 I didn't make the mental note that v14 is already out and the migration would now apply to v15. Document this mistake.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11144
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Leftover of #7680
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11587
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
Adds support for `optional.Option[T]` to be used on an xorm schema struct to represent nullable fields. The `optional.None[T]()` value will be stored in the database as `NULL`.
```go
type OptionString struct {
ID int64 `xorm:"pk autoincr"`
StringField optional.Option[string]
}
```
Before this change, it is possible to represent a nullable field in two reasonable ways: , or as a `sql.Null[T]` (eg. `StringField sql.Null[string]`). The problems with these are:
- as a pointer (eg. `StringField *string`) -- but this introduces the risk of panics when `nil` values are dereferenced, and makes it difficult to use literals in structure creation (although `new()` in Go 1.26 would reduce this issue when Forgejo is upgraded to it)
- as a `sql.Null[T]` -- but this "leaks" references to the `database/sql` package for anything that interacts with Forgejo models, and it's API is awkward as nothing gates you into checking the `Valid` field before you access and use the `V` field
`optional.Option[T]` addresses these points and provides a single way to use an optional primitive type, with a safe check-before-access interface, which can be used consistently throughout model code and other application code. Figuring out the best way to handle this became a blocker to me for [adding foreign keys to nullable fields](https://codeberg.org/forgejo/discussions/issues/385#issuecomment-10218316) in database models, which is what drove me to implement this solution.
## Notes: Filtering on `Option[T]` Fields
It is supported and functional to perform queries with xorm beans with non-None `Option` values. For example:
```go
cond := &OptionString{
StringField: optional.Some("hello"),
}
err := db.GetEngine(t.Context()).Find(&arr, cond)
```
will generate a database query `WHERE string_field = 'hello'`, and correctly filter the records.
It is **not** supported to perform queries with `None` values, for two reasons:
- xorm cannot distinguish between an explicit `&OptionString{ StringField: optional.None[string]() }`, and `&OptionString{}`. Both of them have the `StringField` field set to the zero-value of `Option[String]`.
- For this SQL query to be formatted correctly, it would require `WHERE string_field IS NOT NULL`, not `WHERE string_field = NULL`. This is not how xorm generated bean-based queries.
This is similar to the risk that exists with any other field querying on its zero-value with xorm. It's an unfortunate structural limitation of xorm, and can lead to developers believing database queries are performing filtering that they are not.
(perhaps we can mitigate this risk with semgrep or other automated tooling in the future)
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11553
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [https://data.forgejo.org/actions/setup-forgejo](https://code.forgejo.org/actions/setup-forgejo) | action | patch | `v3.1.6` → `v3.1.7` |
---
### Release Notes
<details>
<summary>actions/setup-forgejo (https://data.forgejo.org/actions/setup-forgejo)</summary>
### [`v3.1.7`](https://code.forgejo.org/actions/setup-forgejo/releases/tag/v3.1.7)
[Compare Source](https://code.forgejo.org/actions/setup-forgejo/compare/v3.1.6...v3.1.7)
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/actions/setup-forgejo-->
- other
- [PR](https://code.forgejo.org/actions/setup-forgejo/pulls/908): <!--number 908 --><!--line 0 --><!--description VXBkYXRlIGRlcGVuZGVuY3kgZm9yZ2Vqby9ydW5uZXIgdG8gdjEyLjcuMQ==-->Update dependency forgejo/runner to v12.7.1<!--description-->
<!--end release-notes-assistant-->
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My41Mi4wIiwidXBkYXRlZEluVmVyIjoiNDMuNTIuMCIsInRhcmdldEJyYW5jaCI6ImZvcmdlam8iLCJsYWJlbHMiOlsiZGVwZW5kZW5jeS11cGdyYWRlIiwidGVzdC9ub3QtbmVlZGVkIl19-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11559
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Renovate Bot <bot@kriese.eu>
Co-committed-by: Renovate Bot <bot@kriese.eu>
Naming is less confusing this way, might not give the impression this will sanitize HTML to safe HTML.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11481
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Έλλεν Εμίλια Άννα Zscheile <fogti+devel@ytrizja.de>
Co-committed-by: Έλλεν Εμίλια Άννα Zscheile <fogti+devel@ytrizja.de>
- For small modals fomantic tried to add a `scrolling` class using a function that was not implemented, this function is now stubbed.
- There's not really a need to conditionally change the behavior of scrolling or not, we can specify `overflow-y: auto` which is more than enough to take care of this. We do add some layout changes to ensure the modal is fully scrollable.
- Refactor to nested CSS.
- Resolvesforgejo/forgejo#10991
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11547
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
This PR is part of a series (#11311).
Adds support for reading and creating repo-secific access tokens through the API via the `GET /users/{username}/tokens`, `POST /users/{username}/tokens`, and `DELETE /users/{username}/tokens/{id}` APIs.
Validation rules are included to [restrict repo-specific access tokens to specific scopes](https://codeberg.org/forgejo/design/issues/50#issuecomment-11093951).
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
### 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-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11504): <!--number 11504 --><!--line 0 --><!--description cmVhZCwgY3JlYXRlLCAmIGRlbGV0ZSByZXBvLXNwZWNpZmljIGFjY2VzcyB0b2tlbnMgdmlhIEFQSQ==-->read, create, & delete repo-specific access tokens via API<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11504
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Submitting the repo avatar form without selecting a file shows a raw Go error: `Avatar.Open: open : no such file or directory.`. The existing `nil` check does not prevent this from happening.
The user avatar handler already guards against this same problem with [`form.Avatar != nil && form.Avatar.Filename != ""`](e1cecbd276/routers/web/user/setting/profile.go (L141)), I've done the same for the repo avatar handler.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11335
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Bram Hagens <bram@bramh.me>
Co-committed-by: Bram Hagens <bram@bramh.me>
Follow forgejo/forgejo!9110 and add a shortcut to the link action, via ctrl/command + K.
Close#11353
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11466
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: anon_ally <ANON_ALLY@noreply.codeberg.org>
Co-committed-by: anon_ally <ANON_ALLY@noreply.codeberg.org>
The provided instructions for how to add RPM package repo fail on Fedora 43:
```
Unknown argument "--add-repo" for command "config-manager". Add "--help" for more information about the arguments.
```
The [docs](https://forgejo.org/docs/latest/user/packages/rpm/#configuring-the-package-registry-using-dnf5) contain a different command, which does work.
This changes instructions to match docs.
Co-authored-by: sarge <ephemeralsarge@example.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11478
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: sarge <sarge@noreply.codeberg.org>
Co-committed-by: sarge <sarge@noreply.codeberg.org>
Forgejo's OCI container registry did not enable basic authentication for the top-level endpoint `/v2`. Furthermore, it did not include the `WWW-Authenticate` header when returning the status code 401 as mandated by [RFC 7235](https://datatracker.ietf.org/doc/html/rfc7235#section-3.1), "Hypertext Transfer Protocol (HTTP/1.1): Authentication", section 3.1. Those deficiencies made it impossible for Apple's [container](https://github.com/apple/container) to log into Forgejo OCI container registry. This has been rectified.
The problem did not occur with most other tools because they do not include credentials when sending the initial request to `/v2`. Forgejo's reply then included `WWW-Authenticate` as expected.
Enabling basic authentication for `/v2` has the side effect that Apple's container uses username and password for all successive requests and not the bearer token. If that is a problem, it's up to Apple to change container's behaviour.
If invalid credentials are passed to `container registry login`, then container enters an infinite loop. The same happens with quay.io, but not ghcr.io (returns 403) or docker.io (returns 401 but _without_ `WWW-Authenticate`). As this is invalid behaviour on container's side, it's up to Apple to change container. Docker and Podman handle it correctly.
Login and pushing have been tested manually with Docker 29.1.3, Podman 5.7.1, and Apple's container 0.9.0.
Resolves https://codeberg.org/forgejo/forgejo/issues/11297.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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...
- [ ] `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/11393
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
The [test disabling the issue unit][0] took care of [reseting the disabled units][1]. However, it overlooked that calling [`LoadUnitConfig`][2] also has a [side effect on `DefaultRepoUnits`][3]. It happens when [`validateDefaultRepoUnits` has a side effect][4] on the array backing the slice, when it is [not recreated][5]. As a result the issue unit is disabled for all tests that run after this one.
The subtle side effect is harmless because it only happens in tests, the `LoadUnitConfig` is otherwise only called once. For clarity `LoadUnitConfig` is modified to clone the unit array being validated so that the returned slice is never backed by the same array as the argument.
As the global variables used for repository units should be saved and restored as a whole, a dedicated test function (`SaveUnits`) is provided to be used by both integration tests and unit tests. The test of the unit model is refactored to be a blackbox test in order to avoid an import cycle.
[0]: cce5f868ce/tests/integration/repo_settings_test.go (L258)
[1]: cce5f868ce/tests/integration/repo_settings_test.go (L253)
[2]: cce5f868ce/models/unit/unit.go (L171)
[3]: cce5f868ce/models/unit/unit.go (L182)
[4]: cce5f868ce/models/unit/unit.go (L162)
[5]: cce5f868ce/models/unit/unit.go (L148)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11470
Reviewed-by: Ellen Εμιλία Άννα Zscheile <fogti@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: limiting-factor <limiting-factor@posteo.com>
Co-committed-by: limiting-factor <limiting-factor@posteo.com>
Remove recipients that are not active (e.g. done by moderation or
organizational reasons) and those that have the permi ssion to read
releases on that repository.
It was sufficiently checked for the repostiory case, but for user/org
project it was not checked and you could change the state of any
project by there mere knowledge of a ID.
The API already checked the permission sufficiently if auto merge could
be cancelled by the doer. The web route did not. Consolidate this check
in the function that lives in the services directory.
It was possible to hijack attachments during update and create functions
to another owner as permissions to check they weren't already attached
to another resource and wasn't checked if it belonged to the repository
that was being operated on.
There are two ways to use a OAuth2 token:
Via the Authorization header as a Bearer token.
Via the Authorization header as a Basic login.
For the former the scope was correctly passed through, for the latter it
was not and would mean no scope was checked if you used the token via
this way.
We do not know for sure, but it is quite likely someone assumed implicit
fallthrough. This meant that if someone used S256 for PKCE, it simply
did not verify the code challenge and always accepted it.
PKCE only started working recently as it was broken for a long time
already, forgejo/forgejo!8678
As discussed here: https://codeberg.org/forgejo/discussions/issues/444 the container v2 API logic does need some refactoring for better maintainability.
This is a proposition on how to achieve that. My goal was to be able to write unit tests for functions like processImageManifest() which are currently only tested indirectly by TestPackageContainer() in tests/integration/api_packages_container_test.go.
A first unit test was implemented that targets ProcessManifest(). I think that test also shows what steps are needed to successfully execute the ProcessManifest() function and hopefully helps understanding that code better.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11432
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: patdyn <patdyn@noreply.codeberg.org>
Co-committed-by: patdyn <patdyn@noreply.codeberg.org>
Just a small fix in a comment in the example config file.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11507
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: marijnjh <marijnjh@noreply.codeberg.org>
Co-committed-by: marijnjh <marijnjh@noreply.codeberg.org>
This PR is part of a series (#11311).
If the user authenticating to an API call is a Forgejo site administrator, or a Forgejo repo administrator, a wide variety of permission and ownership checks in the API are either bypassed, or are bypassable. If a user has created an access token with restricted resources, I understand the intent of the user is to create a token which has a layer of risk reduction in the event that the token is lost/leaked to an attacker. For this reason, it makes sense to me that restricted scope access tokens shouldn't inherit the owner's administrator access.
My intent is that repo-specific access tokens [will only be able to access specific authorization scopes](https://codeberg.org/forgejo/design/issues/50#issuecomment-11093951), probably: `repository:read`, `repository:write`, `issue:read`, `issue:write`, (`organization:read` / `user:read` maybe). This means that *most* admin access is not intended to be affected by this because repo-specific access tokens won't have, for example, `admin:write` scope. However, administrative access still grants elevated permissions in some areas that are relevant to these scopes, and need to be restricted:
- The `?sudo=otheruser` query parameter allows site administrators to impersonate other users in the API.
- Repository management rules are different for a site administrator, allowing them to create repos for another user, create repos in another organization, migrate a repository to an arbitrary owner, and transfer a repository to a prviate organization.
- Administrators have access to extra data through some APIs which would be in scope: the detailed configuration of branch protection rules, the some details of repository deploy keys (which repo, and which scope -- seems odd), (user:read -- user SSH keys, activity feeds of private users, user profiles of private users, user webhook configurations).
- Pull request reviews have additional perms for repo administrators, including the ability to dismiss PR reviews, delete PR reviews, and view draft PR reviews.
- Repo admins and site admins can comment on locked issues, and related to comments can edit or delete other user's comments and attachments.
- Repo admins can manage and view logged time on behalf of other users.
A handful of these permissions may make sense for repo-specific access tokens, but most of them clearly exceed the risk that would be expected from creating a limited scope access token. I'd generally prefer to take a restrictive approach, and we can relax it if real-world use-cases come in -- users will have a workaround of creating an access token without repo-specific restrictions if they are blocked from needed access.
**Breaking:** The administration restrictions introduced in this PR affect both repo-specific access tokens, and existing public-only access tokens.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
### 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.
- Although repo-specific access tokens are not yet exposed to end users, the breaking changes to public-only tokens will be visible to users and require release notes.
- [ ] 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/11468
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Go 1.16 added the signal.NotifyContext helper utility. `installSignals` could be further inlined in a future iteration, if needed.
When reading the [function documentation](https://pkg.go.dev/os/signal#NotifyContext), it becomes clear that this is doing the exact same thing as the old code.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10311
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: nachtjasmin <nachtjasmin@posteo.de>
Co-committed-by: nachtjasmin <nachtjasmin@posteo.de>
Closesforgejo/forgejo#11407
I looked at related Gitea discussions for when it was implemented and it looks like what to use exactly for `overflow` was not discussed, the intention was just to have overflowing content scroll, not to have irrelevant scrollbars appear at all times.
- https://github.com/go-gitea/gitea/pull/31683
- https://github.com/go-gitea/gitea/issues/31667
- https://github.com/go-gitea/gitea/pull/26561
But with `max-height` restrictions that are in place only horizontal scrollbars are ever needed on demand. Vertical ones are not needed. For this `auto` works much better than `scroll`.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11469
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
It is unfortunately all mixed up, because refreshing the data, means breaking the tests. And changing the code means needing fresh data.
- tests: ignore some more headers and sort the rest when dumping http responses
- code: fixed#10234 by requesting the latest issues first.
- tests: created a new repo to replace the disappeared repo, needed for the skip-numbers test
- refreshed the testdata.
- follow-up fixes to get the tests green.
- including a cherry-pick of https://github.com/go-gitea/gitea/pull/36295 and #11272
Co-authored-by: Joakim Olsson <joakim@unbound.se>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11282
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: patdyn <patdyn@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
This PR is part of a series (#11311).
Prevents the usage of three internal APIs in the web API code:
- `repo_model.SearchRepoOptions{}` without an `AuthorizationReducer`
- `organization.SearchTeamRepoOptions{}` without an `AuthorizationReducer`
- `access_model.GetUserRepoPermission()`, which doesn't take an `AuthorizationReducer` -- use `GetUserRepoPermissionWithReducer` instead.
A couple lingering usages are marked with `// nosemgrep: ...` as they have been inspected and considered correct as-is.
The `GetUserRepoPermission` is tested via the `.semgrep/tests` files; the other rules have been tested manually.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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/11476
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#11268
Fixes regression of #9614
Calling `initDisabledInputs` wasn't effective for template contents, so inputs in MDEs spawned by repo-legacy.js on comment editing were broken. Now repo-legacy.js also calls it when it spawns a new MDE.
Co-authored-by: Gusted <Gusted@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11341
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
This reverts commit d4951968f0, #10008.
When Forgejo cancels a job server-side, for example due to an additional push to an open PR, it immediately archives the logs from DBFS to disk due to the changes in #10008. Then, the runner recognizes that the job status is cancelled and it attempts to flush its pending logs to Forgejo, resulting in warnings being logged:
```
forgejo-runner.log:time="2026-02-23T01:32:11+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
forgejo-runner.log:time="2026-02-23T01:32:11+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
forgejo-runner.log:time="2026-02-23T01:32:11+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
forgejo-runner.log:time="2026-02-23T01:32:12+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
forgejo-runner.log:time="2026-02-23T01:32:13+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
forgejo-runner.log:time="2026-02-23T01:32:14+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
forgejo-runner.log:time="2026-02-23T01:32:16+01:00" level=info msg="runner: received shutdown signal"
forgejo-runner.log:time="2026-02-23T01:32:16+01:00" level=info msg="runner: shutdown initiated, waiting [runner].shutdown_timeout=0s for running jobs to complete before shutting down"
forgejo-runner.log:time="2026-02-23T01:32:16+01:00" level=info msg="[poller] shutdown begin, 1 tasks currently running"
forgejo-runner.log:time="2026-02-23T01:32:16+01:00" level=info msg="forcing the jobs to shutdown"
forgejo-runner.log:time="2026-02-23T01:32:18+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
forgejo-runner.log:time="2026-02-23T01:32:24+01:00" level=warning msg="uploading final logs failed, but will be retried: already_exists: log file has been archived" task_id=51
```
This appears to be the cause of the `push-cancel` end-to-end test failing since #10008 was merged. https://code.forgejo.org/forgejo/end-to-end/actions/runs/4985/jobs/8/attempt/1 The `push-cancel` test case itself seems to succeed, but then the test process aborts with `return 1`. Doesn't reproduce locally.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11462
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This legacy support was added in version 8. We now have version 14, so this deprecated feature can be confidently removed.
See dad16cd589 for a detailed explanation.
Docs PR: https://codeberg.org/forgejo/docs/pulls/1740
Co-authored-by: Jakob Linskeseder <jakob@linskeseder.com>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11098
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: jaylinski <jaylinski@noreply.codeberg.org>
Co-committed-by: jaylinski <jaylinski@noreply.codeberg.org>
This change is to enable some additional trace logging for oauth2.
Initial setups can be a real pain to debug, and getting JWT back for debug purpose helps a lot i.e. checking claims, roles, groups.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11175
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: AngryDove <angrydove@noreply.codeberg.org>
Co-committed-by: AngryDove <angrydove@noreply.codeberg.org>
**Breaking*: /teams/{id}/repos previously allowed read access to private
repositories even if a "public-only" access token was in-use. This has
been restricted to only return public repositories in this case.
**Breaking**: when using a public-only access tokens, private
repositories were not filtered out by the `/users/{username}/repos` or
`/orgs/{org}/repos` APIs. This access has been removed in this change.
**Breaking**: accessing the `/repositories/{id}` API with a public-only
access token did not restrict read access to only public repositories.
As part of a consolidation of permission logic with repo-specific access
tokens, this access has not been restricted.
As these APIs only work on forks, and it's not possible to change the
visibility of a fork from its parent, only testing the API access
pattern against the head is sufficient. Also it is not a breaking
change due to checkTokenPublicOnly middleware already enforcing this for
public-only scopes, and the lack of ability to change a fork's
visibility.
**Breaking**: Public-only tokens previously had the capability to make
issue dependencies and block issues w/ data from private repositories
through these APIs, which has been revoked by this change to support
fine-grained access tokens.
**Breaking**: Public-only tokens previously had the capability to view
private repositories through this API, which has been revoked by this
change to support fine-grained access tokens.
**Breaking**: Public-only tokens previously had the capability to view
private repositories through this API, which has been revoked by this
change to support fine-grained access tokens.
**Breaking*: /teams/{id}/repos/{org}/{repo} previously allowed read
access to private repositories even if a "public-only" access token was
in-use. This has been restricted to only return public repositories in
this case.
Repository-specific personal access tokens will allow a user's access tokens to be restricted to accessing zero-or-more specific repositories. Currently they can be configured as "All", or "Public only", and this project will add a third configuration option allowing specific repositories.
This PR is part of a series (#11311), and builds on the infrastructure work in #11434. In this PR, repository-specific access tokens are implemented on the universal permission checks performed by the API middleware, affecting ~182 API endpoints that perform permission checks based upon repositories referenced in their API path (eg. `/v1/api/repos/{owner}/{repo}/...`).
**Breaking change:** API access with a public-only access token would previously return a `403 Forbidden` error when attempting to access a private repository where the repository is on the API path. As part of incorporating the public-only logic into the centralized permission check, these APIs will now return `404 Not Found` instead, consistent with how repository-specific access tokens, and other permissions checks, are implemented in order to reduce the risk of data probing through error messages.
For larger context on the usage and future incoming work, the description of #11311 can be referenced.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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.
- As there is no end-user accessibility to create repo-specific access tokens, this functionality will not be accessible to end-users yet. But the breaking change in error APIs for public-only access tokens will be visible to end-users.
- [ ] 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-->
- Breaking features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11437): <!--number 11437 --><!--line 0 --><!--description aW1wbGVtZW50IHJlcG8tc3BlY2lmaWMgYWNjZXNzIHRva2VucyBicm9hZGx5IGZvciB1bml2ZXJzYWwgQVBJIHBlcm1pc3Npb24gY2hlY2tzLiAgKipCcmVha2luZzoqKiBBUEkgYWNjZXNzIHdpdGggYSBwdWJsaWMtb25seSBhY2Nlc3MgdG9rZW4gd291bGQgcHJldmlvdXNseSByZXR1cm4gYSBgNDAzIEZvcmJpZGRlbmAgZXJyb3Igd2hlbiBhdHRlbXB0aW5nIHRvIGFjY2VzcyBhIHByaXZhdGUgcmVwb3NpdG9yeSB3aGVyZSB0aGUgcmVwb3NpdG9yeSBpcyBvbiB0aGUgQVBJIHBhdGguICBBcyBwYXJ0IG9mIGluY29ycG9yYXRpbmcgdGhlIHB1YmxpYy1vbmx5IGxvZ2ljIGludG8gdGhlIGNlbnRyYWxpemVkIHBlcm1pc3Npb24gY2hlY2ssIHRoZXNlIEFQSXMgd2lsbCBub3cgcmV0dXJuIGA0MDQgTm90IEZvdW5kYCBpbnN0ZWFkLCBjb25zaXN0ZW50IHdpdGggaG93IG1vc3QgcGVybWlzc2lvbiBjaGVja3MgYXJlIGltcGxlbWVudGVkIGluIG9yZGVyIHRvIHJlZHVjZSB0aGUgcmlzayBvZiBkYXRhIHByb2JpbmcgdGhyb3VnaCBlcnJvciBtZXNzYWdlcy4=-->implement repo-specific access tokens broadly for universal API permission checks. **Breaking:** API access with a public-only access token would previously return a `403 Forbidden` error when attempting to access a private repository where the repository is on the API path. As part of incorporating the public-only logic into the centralized permission check, these APIs will now return `404 Not Found` instead, consistent with how most permission checks are implemented in order to reduce the risk of data probing through error messages.<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11437
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Repository-specific personal access tokens will allow a user's access tokens to be restricted to accessing zero-or-more specific repositories. Currently they can be configured as "All", or "Public only", and this project will add a third configuration option allowing specific repositories.
This PR is part of a series (#11311), and builds on the infrastructure work in #11434. In this PR, repository-specific access tokens are implemented in `CheckRepoScopedToken`, which is a specific codepath used by git operations to check the permissions of an access token.
For larger context on the usage and future incoming work, the description of #11311 can be referenced.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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...
- [ ] `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.
- As repo-specific access tokens are not exposed to end-users, this PR does not require release notes.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11452
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Project columns and cards use a sorting field for ordering, but nothing prevents duplicate values from being inserted. This causes unpredictable ordering and makes swap-based reordering unsafe. Additionally, the same issue can be added to a project multiple times, which shouldn't be possible.
This PR adds a migration to clean up existing data and enforce three unique constraints:
- (project_id, sorting) on project_board — one sorting value per column per project
- (project_id, issue_id) on project_issue — one card per issue per project
- (project_board_id, sorting) on project_issue — one sorting value per card per column
The migration deduplicates existing rows and reassigns sequential sorting values before adding the constraints.
Changes
- Migration: fix duplicate sorting values in project_board and project_issue, remove duplicate (project_id, issue_id) rows, add three unique constraints
- MoveColumnsOnProject: two-phase swap (negate then set) to avoid constraint collisions
- MoveIssuesOnProjectColumn: three-phase approach with duplicate validation and sorted lock ordering
- UpdateColumn: always persist sorting field (allows setting to 0)
- GetDefaultColumn: query max sorting before auto-creating
- createDefaultColumnsForProject: explicit sequential sorting
- changeProjectStatus: only set ClosedDateUnix when closing
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] 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/11334
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Myers Carpenter <myers@maski.org>
Co-committed-by: Myers Carpenter <myers@maski.org>
Followup to https://codeberg.org/forgejo/forgejo/pulls/9109
Fix issue reported by @mahlzahn that the string was confusing translators and they translated the part that wasn't meant to be translated.
Part of this fix was to replace custom IterWithTr with simple dict iteration to allow for placeholders in strings.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11381
Reviewed-by: Shiny Nematoda <snematoda@noreply.codeberg.org>
Reviewed-by: Ellen Εμιλία Άννα Zscheile <fogti@noreply.codeberg.org>
Probably fixes (or improves, at least) https://code.forgejo.org/forgejo/runner/issues/1391, paired with the runner implementation https://code.forgejo.org/forgejo/runner/pulls/1393.
When the FetchTask() API is invoked to create a task, unpreventable environmental errors may occur; for example, network disconnects and timeouts. It's possible that these errors occur after the server-side has assigned a task to the runner during the API call, in which case the error would cause that task to be lost between the two systems -- the server will think it's assigned to the runner, and the runner never received it. This can cause jobs to appear stuck at "Set up job".
The solution implemented here is idempotency in the FetchTask() API call, which means that the "same" FetchTask() API call is expected to return the same values. Specifically, the runner creates a unique identifier which is transmitted to the server as a header `x-runner-request-key` with each FetchTask() invocation which defines the sameness of the call, and the runner retains the value until the API call receives a successful response. The server implementation returns the same tasks back if a second (or Nth) call is received with the same `x-runner-request-key` header. In order to accomplish this is records the `x-runner-request-key` value that is used with each request that assigns tasks.
As a complication, the Forgejo server is unable to return the same `${{ secrets.forgejo_token }}` for the task because the server stores that value in a one-way hash in the database. To resolve this, the server regenerates the token when retrieving tasks for a second time.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
### 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/11401
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This reverts commit 9f3ab71647.
cascade-setup-end-to-end no longer works after this was merged: https://codeberg.org/forgejo/forgejo/actions/runs/140733/jobs/0/attempt/2
```
/var/run/act/actions/69/9e734ffd2a2ec8ed9c2f818ed272523f52007304147edf2d7efae8d6e0c3a5/cascading-pr.sh:26: repo_curl: forgejo-curl.sh api_json https://codeberg.org/api/v1/repos/forgejo/forgejo/pulls/11401
curl: option -H: error encountered when reading a file
curl: try 'curl --help' or 'curl --manual' for more information
/var/run/act/actions/69/9e734ffd2a2ec8ed9c2f818ed272523f52007304147edf2d7efae8d6e0c3a5/cascading-pr.sh:1: pr_get_origin: rm -fr /tmp/tmp.nZPEP759PH
fail /var/run/act/actions/69/9e734ffd2a2ec8ed9c2f818ed272523f52007304147edf2d7efae8d6e0c3a5/cascading-pr.sh
```
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11406
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Logs moving out of the database to the filesystem (actions_module.TransferLogsAndUpdateLogInStorage)
did not happen in the following cases:
- the runner does not send an UpdateLog message with NoMore == true
- StopTask is called (canceling from the web.UI, canceling a scheduled
task)
This is fixed by consistently calling actions_service.TransferLogsAndUpdateLogInStorage when
a task is completed by:
- UpdateTaskByState if it concludes with Status.IsDone
- StopTask
Test coverage exists at:
- TestActionsDownloadTaskLogs
will fail if UpdateTaskByState does not call TransferLogsAndUpdateLogInStorage when
when task.Status.IsDone()
stat .../tests/integration/gitea-integration-sqlite/data/actions_log/user2/actions-download-task-logs/48/72.log.zst: no such file or directory
- TestActionNowDoneNotification
will fail if StopTask returns on error when calling TransferLogsAndUpdateLogInStorage
Error Trace: .../tests/integration/actions_run_now_done_notification_test.go:142
Refs https://codeberg.org/forgejo/forgejo/issues/9999
---
Note on backporting: it cannot be easily backported to v11.0 because it would require a more involved backport to untangle circular dependencies. It is also not essential in the context of https://codeberg.org/forgejo/forgejo/issues/9999 for instances being polluted by logs that stay in the database. The new [cron job](https://codeberg.org/forgejo/forgejo/pulls/10009) that disposes of them will take care of those daily and they will not be growing the database indefinitely.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10008): <!--number 10008 --><!--line 0 --><!--description ZW5zdXJlIGFjdGlvbnMgbG9ncyBhcmUgdHJhbnNmZXJyZWQgd2hlbiBhIHRhc2sgaXMgZG9uZQ==-->ensure actions logs are transferred when a task is done<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10008
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
Fixes#11036.
This adds a link from a CI run to the file that its workflow was taken from.
| Before | After |
|---------|---------|
|  |  |
Before:
* the `test.yml` link points to the list of other runs (`/org123/repo2/actions?workflow=test.yml`)
After:
* the `test.yml` link points to the workflow definition (`/org123/repo2/src/commit/55b048363c8cfa7d9e8b5cade5c75681bd0c7328/.forgejo/workflows/test.yml`)
* the `all runs` link points to the list of other runs (`/org123/repo2/actions?workflow=test.yml`)
I have tried to retain the existing link to the list of workflow runs (moving it to a separate link), but I am not sure if this link should be retained at all and if so how.
## Checklist
### Tests
- 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 added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11216): <!--number 11216 --><!--line 0 --><!--description bGluayBDSSBqb2IgdG8gaXRzIGRlZmluaW5nIHdvcmtmbG93IGZpbGU=-->link CI job to its defining workflow file<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11216
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Remove the field `ephemeral` from the response to runner registration requests made using the HTTP API (POST to `/repos/{owner}/{repo}/actions/runners` and friends) that was introduced with https://codeberg.org/forgejo/forgejo/pulls/9962. The client already knows that it requested an ephemeral runner. Therefore, the information is redundant.
It can be included again should a compelling use case arise.
This part of the HTTP API hasn't been released yet. Therefore, it is safe to remove the field.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- [ ] 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/11350
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Our package registries types have many things in common, so they have many shared strings like
```json
"packages.installation": "Installation",
```
but not all and not consistently. For example, some packages duplicate these strings:
```json
"packages.*.install": "To install the package, run the following command:",
"packages.*.registry": "Setup this registry from the command line:",
"packages.*.repository": "Repository info",
"packages.*.dependencies": "Dependencies",
```
while other packages have them customized:
```json
"packages.cargo.install": "To install the package using Cargo, run the following command:",
"packages.composer.install": "To install the package using Composer, run the following command:",
"packages.conan.install": "To install the package using Conan, run the following command:",
"packages.conda.install": "To install the package using Conda, run the following command:",
```
While it's ok for them to have custom strings, I don't see need to duplicate the same generic strings. Even though Weblate provides tools to simplify maintenance of duplicated strings, our files still end up being bloated.
In this PR I deduplicated the strings listed above under a `common` key. There already was a generic shared string for Dependencies, that I just re-used.
Also fixed strings in Arch packages, which were saying Depends with meaning of Dependencies.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11345
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Followup to #10702 where two new strings were hardcoded in the template.
## Changes
- added as translatable strings
- made the template use a variable to avoid making it a long unreadable
- an unrelated change where tests related to this area of the template are moved to a separate file
- they were created in Forgejo: c92b4b12c8, 192177fc88
## Testing
Testing translations of all individual strings is considered not needed.
Added test for tmpl logic which was missing and that I've touched.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11333
Reviewed-by: Luis Adame <luisadame@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This is to have a simple and consistent make target for developers to locally run the checks which the CI will also run. The goal is to avoid wasting review cycles on CI failures.
To have a single source of truth, the CI is adjusted to call the same make target. Additional checks should no longer be added to the CI workflow, but rather to the makefile.
The pull request template is adjusted to remind of running this make target.
CI output is improved by using a simple bash script which uses sed to add `##[group]` tags to "make --debug=b" output and filter out messages which usually do not contribute to understanding. While this approach has limits and depends on the specific debug output format of GNU make, it avoids adjusting the makefile itself for additional CI beautification, contributing to maintainability.
- no tests needed (this is purely a build change)
- docs: hint added to PR template
- no release notes needed
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11053
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
The virtual session code creates an in-memory session, and only upon release does it copy it to the actual session store. This makes a lot of sense to avoid operations on session stores with potentially high cost for I/O.
This commit removes a weird hack used in this code: virtual sessions were always created with an _old_uid=0 key/value pair, which was taken into account when checking if the session needed to be persisted.
As I could not find _any_ use of _old_uid in the code base, this looks like something worth removing.
The first ever mention of _old_uid is b33f7f792b and even there it is part of a
newly added file with no additional information. So likely code copied over from another project?
- no tests to add, remove or change
- not relevant for documentation
- not relevant for release notes
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11277
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Potentially fixes one of the E2E failures that started to occur lately where the last tab (Starred repos) can overflow on user2's profile on CI.
Replaced the user by the one that has no counters on the tabs.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11337
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
As described in [this comment](https://gitea.com/gitea/act_runner/issues/19#issuecomment-739221) one-job runners are not secure when running in host mode. We implemented a routine preventing runner tokens from receiving a second job in order to render a potentially compromised token useless. Also we implemented a routine that removes finished runners as soon as possible.
Big thanks to [ChristopherHX](https://github.com/ChristopherHX) who did all the work for gitea!
Rel: #9407
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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.
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9962
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Manuel Ganter <manuel.ganter@think-ahead.tech>
Co-committed-by: Manuel Ganter <manuel.ganter@think-ahead.tech>
The example was not a valid map, which caused issues with some openapi yaml converters.
I gave the two options proper values and also added them to the other team structs so the examples are identical.
Also sorted them as they are enumerated in the [unit model definition](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/models/unit/unit.go), which is why the diff is a bit ugly.
Fixes#9881
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11093
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Florian Pallas <mail@fpallas.com>
Co-committed-by: Florian Pallas <mail@fpallas.com>
Previously, when a project id was passed into the new issue form as a
query parameter, it wouldn’t be selected if the project belonged to the
user or organization instead of directly to the repository.
Resolvesforgejo/forgejo#8489
Signed-off-by: Nils Philippsen <nils@redhat.com>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9906
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
Co-authored-by: Nils Philippsen <nilsph@noreply.codeberg.org>
Co-committed-by: Nils Philippsen <nilsph@noreply.codeberg.org>
Add `flex` or `inline-flex` to the direct parent element of the SVG icon in the navigation bar to make the overall alignment look better.
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11259
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: panc <pan0xc@foxmail.com>
Co-committed-by: panc <pan0xc@foxmail.com>
Increase the default `SQLITE_TIMEOUT` from 500ms to 60s.
In #11179 this was bumped up to 5s. But when that was backported to v14 in #11220, it failed consistently in CI through a couple increases, until it was bumped up further to 60s. This PR updates the `forgejo` branch to the same so that in the future when Forgejo 15 is released, it isn't regressed. `test-sqlite` has been failing on `forgejo` occasionally as well, so this increase is justified on this branch for this reason as well.
Putting aside the tests, I think a high value for the timeout (this 60s) is generally safer for production usage than a small timeout. The worst case with a high timeout is a slow request when there is high write contention on the DB.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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.
- **Will update** the documentation for the default value if approved.
- [ ] 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-->
- Other changes without a feature or bug label
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11292): <!--number 11292 --><!--line 0 --><!--description aW1wcm92ZSBTUUxpdGUgImRhdGFiYXNlIGlzIGxvY2tlZCIgZXJyb3JzIGJ5IGluY3JlYXNpbmcgZGVmYXVsdCBgU1FMSVRFX1RJTUVPVVRgICh0YWtlIDIp-->improve SQLite "database is locked" errors by increasing default `SQLITE_TIMEOUT` (take 2)<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11292
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Replaces https://codeberg.org/forgejo/forgejo/pulls/11271
This rule was problematic and didn't quite make sense:
* the intention is to have a navbar that is 48px+1px border
* we apply `min-height:49px` to: `#navbar` with intention of making it 49px tall total, with border
* but we also apply it to `#navbar .navbar-left/right`
* elements `#navbar .navbar-left/right` become 49px tall
* their parent `#navbar` becomes 49px+1px border = 50px, overriding what was done in step 2
This height missmatch had an incompatibility with this definition for open menu inside of navbar on mobile, causing jitter when the menu is opened/closed, because it was expecting navbar body to be 48px, but due to the rule that was removed it was actually 49px.
```css
#navbar.navbar-menu-open .navbar-left .navbar-mobile-right {
min-height: 48px;
}
```
The fix is to only apply `min-height` to `#navbar`'s children. At least `.navbar-left` is always expected to be present unconditionally on all pages. This does make the navbar 1px shorter. If we still want a 50px navbar but without the bug let me know and I'll adjust.
### Preview by @panc
From https://codeberg.org/forgejo/forgejo/pulls/11271, also applies to this PR.
| Before | After |
|----|----|
| <video src="/attachments/515fdfc1-cb97-46af-88ac-9bb0e216a996" title="Screencast From 2026-02-13 19-56-32" controls></video> | <video src="/attachments/133d1499-4660-402d-8082-f407b3644e5c" title="Screencast From 2026-02-13 19-57-29" controls></video> |
Reported-by: panc <panc@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11274
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
I noticed that the wrong content type in an `/upload` request can trigger a 500, and I'm guessing it is more appropriate to return 400 instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10954
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Roberto Vidal <roberto.vidal@ikumene.com>
Co-committed-by: Roberto Vidal <roberto.vidal@ikumene.com>
The navigation menu on mobile is divided into two sections, but there is no gap between them. I referred to the following code and set the gap to `gap: .35714286em`
```CSS
.ui.secondary.menu {
margin-left: 0;
margin-right: 0;
gap: .35714286em;
}
```
| Before | After |
|--------|-------|
|  |  |
| Before | After |
|--------|-------|
|  |  |
Another thing to note is that the dot of the stopwatch extends beyond the background.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11262
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: panc <pan0xc@foxmail.com>
Co-committed-by: panc <pan0xc@foxmail.com>
This change fixes an issue that makes Forgejo clean up too many versions of a container package even though it should keep them according to the rules set for the package.
The issue affects multi-platform container images.
Forgejo adds a package version for each platform (for example `linux/amd64`, `linux/arm64`) in addition to the actual tag (for example `0.6.0` or `latest`).
This results in rows in the table `package_version` similar to this (unimportant columns omitted for brevity):
| **lower_version** | **created_unix** |
|---|---|
| `latest` | `1768742887`|
| `0.6.0` | `1768742886` |
| `sha256:038e...` | `1768742886` |
| `sha256:fc38...` | `1768742886` |
| `0.5.0` | `1768742864` |
| `sha256:806d...` | `1768742864` |
| `sha256:0a19...` | `1768742864` |
| `0.4.0` | `1768742848` |
| `...` | `...` |
The code assumes that the first `<keep count>` entries can be ignored and considers every entry after `<keep count>` as eligible for cleanup.
That doesn't work for multi-platform container images because, for `<keep count>=5`, it considers version `0.4.0` as eligible.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11246): <!--number 11246 --><!--line 0 --><!--description Y2xlYW51cCBvZiBtdWx0aS1wbGF0Zm9ybSBjb250YWluZXIgaW1hZ2Vz-->cleanup of multi-platform container images<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11246
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: wandhydrant <wandhydrant@noreply.codeberg.org>
Co-committed-by: wandhydrant <wandhydrant@noreply.codeberg.org>
The general consensus I have gotten from past contributions is that `return nil, nil` is an
antipattern in Forgejo, especially because:
```go
val, err := Func()
if err != nil {
return
}
val.Func()
```
can easily lead to a nil pointer dereference.
This PR merely enables the lint and ignores all currently broken files. In addition to this PR,
a tracking issue to keep track of re-enabling nilnil linting on the ignored files could be
useful.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11235
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-committed-by: famfo <famfo@famfo.xyz>
Fixes: #11238
### Tests
- 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 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.
Co-authored-by: Diego Díez <diegodiez.ddr@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11240
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
Remove the documentation for the deprecated authentication methods Token and AccessToken. The functionality remains in place because it's still in use.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/11232
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Cyborus <cyborus@disroot.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Defines new css colours for theming:
```css
--color-selection-bg: var(--color-primary-light-1);
--color-selection-fg: var(--color-white);
```
which are then used both in the `base.css` and in the relative-time shadow object.
This, is how it looks for me when selecting before and after this patch (my Browser’s accent colour used for selection is orange):
| | Before | After |
|---|---|---|
| Forgejo Light |  |  |
| Forgejo Dark | |  |
| Gitea Light |  |  |
| Gitea Dark |  |  |
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11231
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
### Tests
- 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 added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] 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.
### Disclaimer
Generative AI (ChatGPT) was used to debug the e2e test, with copied code lines below threshold of originality.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11156
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
`Option[T]` currently exposes a method `Value()` which is permitted to be called on an option that has a value, and an option that doesn't have a value. This API is awkward because the behaviour if the option doesn't have a value isn't clear to the caller, and, because almost all accesses end up being `.Has()?` then `OK, use .Value()`.
`Get() (bool, T)` is added as a better replacement, which both returns whether the option has a value, and the value if present. Most call-sites are rewritten to this form.
`ValueOrZeroValue()` is a direct replacement that has the same behaviour that `Value()` had, but describes the behaviour if the value is missing.
In addition to the current API being awkward, the core reason for this change is that `Value()` conflicts with the `Value()` function from the `driver.Valuer` interface. If this interface was implemented, it would allow `Option[T]` to be used to represent a nullable field in an xorm bean struct (requires: https://code.forgejo.org/xorm/xorm/pulls/66).
_Note:_ changes are extensive in this PR, but are almost all changes are easy, mechanical transitions from `.Has()` to `.Get()`. All of this work was performed by hand.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] 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/11218
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Replaces #10789
Convert the layout from flex-list helpers to a CSS-native grid. This allows to having buttons in different rows aligned to each other while keeping the layout responsive, i.e. looking good on both desktop and mobile.
### Preview (desktop)
|Before|After|
|-|-|
|||
### Preview (mobile)
|Before|After|
|-|-|
|||
### Preview (Guest)
|Before|After|
|-|-|
|||
## Testing
Automated tests were added to make sure that actions in this list are still working, and for basic template logic. No tests were added for layout because layout being correct is an abstract concept that is difficult to explain to Playwright.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11127
Reviewed-by: Antonin Delpeuch <wetneb@noreply.codeberg.org>
As noted in https://codeberg.org/forgejo/forgejo/issues/10900#issuecomment-10339634, `TestAPICreateIssueParallel` is failing intermittently in Forgejo CI. Based upon this intermittent failure, I've made these changes:
- Increase the parallel run of the test from 10 instances to 100, which caused this test to fail consistently and reliably on my dev workstation. The test execution time at 100 parallel invocations is only ~4 seconds.
- Increase the default `SQLITE_TIMEOUT` from 500ms to 5s, which caused this test to succeed consistently on my dev workstation.
Is 5000ms the right setting? 🤷 On local testing, this specific test failed...
- 2500ms: failed 1/1 times
- 3000ms: failed 1/3 times
- 3500ms: failed 0/10 times
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. -- https://codeberg.org/forgejo/docs/pulls/1775
- [ ] 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/11179
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Forgejo's UI claims that whitespace is removed from the beginning and the end of the values of Forgejo Actions variables and secrets. However, that is not correct. The entered values are stored as-is. Only CRLF is replaced with LF, which is also the desired behaviour.
This PR changes the incorrect text which is also no longer displayed as placeholder but as a proper help text below the input fields. Furthermore, tests were added to verify the behaviour.
While adding tests, I discovered and fixed another inconsistency. Depending on whether secrets were managed using the UI or the HTTP API, they were treated differently. CRLF in secrets entered in the UI was correctly replaced with LF while secrets created using the HTTP API kept CRLF.
Fixes#11003.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11052
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Normalizes the issue/pr title case when searching if it contains any of the wip prefixes, which are also normalized, just in case.
Fixes#11189
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11190
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Luis <luis@adame.dev>
Co-committed-by: Luis <luis@adame.dev>
Display version without compat metadata for admins too, not just for regular users. It was confusing to some, though I don't remember who got confused.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11196
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Slightly related to https://codeberg.org/forgejo/forgejo/pulls/11196, but it has no tests related to the change in that PR.
Added tests because I wanted those config options be tested, but haven't found any existing tests.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11197
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Fixes#11083.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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.
Co-authored-by: f <f@sutty.nl>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11153
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: fauno <fauno@noreply.codeberg.org>
Co-committed-by: fauno <fauno@noreply.codeberg.org>
Adds a new button on the right side of the label's filter menu items to explicitly exclude labels.
The new button is reachable with the keyboard by using the vertical arrow keys to reach the label you want to exclude and then the horizontal arrow keys to select the exclusion button.
The new button will only be visible when hovering the menu item or reaching it with the keyboard.
Adjusted the alignment of labels when at least one label is selected so that users can clearly discern which labels are selected or not.
Resolves#3302
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10702
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Luis <luis@adame.dev>
Co-committed-by: Luis <luis@adame.dev>
Stores the entire list of AssigneeIDs for each issue in the indexer.
This fixes the bug where there were missing entries for issues with assignees while filtering.
Note: Will re-index all issues
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10552
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Adds a CI check which detects any usage of xorm's `Sync` method that doesn't include `IgnoreDropIndices: true`, and causes an error.
`semgrep` is a semantic grep tool that allows for the relatively easy authoring of linting tools that are customized to a project's specific needs, rather than generic like `golangci` and related tools. Although `semgrep` offers a suite of out-of-the-box rules (and a paid set of rules), neither of those are used here -- only one Forgejo-specific rule is added in `.semgrep/xorm.yaml`.
My intent with this change is to introduce the idea and infrastructure of `semgrep` with a single minimal rule. Once in-place, this will become a tool that we can use when we recognize bad coding patterns and wish to correct them permanently, rather than relying on human code review. While generic linting tools do this well for general patterns, this will allow Forgejo to apply domain-specific checks. For example, in #11112, an error indicates that it might be appropriate for us to always use `.StorageEngine("InnoDB")` when using an xorm engine -- if we made that determination, it could be cemented in-place with a `semgrep` rule relatively easily.
This specific rule looks for any access for xorm's `Sync` or `SyncWithOptions` methods on the `*xorm.Engine` or `*xorm.Session`. They are then considered errors if they don't include `IgnoreDropIndices: true`. This is *typically* correct and safe, but can also be ignored when specifically needed. In the `.semgrep/tests` folder, test code is added which validates that the `semgrep` rule matches the expected patterns; this self-test is run before `semgrep` runs on the PR in CI.
As a demonstration, when `IgnoreDropIndices` is removed from a migration, here's an error: https://codeberg.org/forgejo/forgejo/actions/runs/135750/jobs/12/attempt/1
```
models/forgejo_migrations/v14b_add-action_run-preexecutionerrorcode.go
❯❯❱ semgrep.xorm-sync-missing-ignore-drop-indices
xorm Sync operation may drop indices if used on an incomplete bean definition for an existing table.
Use SyncWithOptions with IgnoreDropIndices: true instead.
22┆ _, err := x.SyncWithOptions(xorm.SyncOptions{}, new(ActionRun))
```
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] 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/11142
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [https://data.forgejo.org/actions/setup-forgejo](https://code.forgejo.org/actions/setup-forgejo) | action | patch | `v3.1.3` → `v3.1.4` |
---
### Release Notes
<details>
<summary>actions/setup-forgejo (https://data.forgejo.org/actions/setup-forgejo)</summary>
### [`v3.1.4`](https://code.forgejo.org/actions/setup-forgejo/releases/tag/v3.1.4)
[Compare Source](https://code.forgejo.org/actions/setup-forgejo/compare/v3.1.3...v3.1.4)
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/actions/setup-forgejo-->
- other
- [PR](https://code.forgejo.org/actions/setup-forgejo/pulls/869): <!--number 869 --><!--line 0 --><!--description VXBkYXRlIGRlcGVuZGVuY3kgZm9yZ2Vqby9ydW5uZXIgdG8gdjEyLjYuMw==-->Update dependency forgejo/runner to v12.6.3<!--description-->
- [PR](https://code.forgejo.org/actions/setup-forgejo/pulls/863): <!--number 863 --><!--line 0 --><!--description VXBkYXRlIGRhdGEuZm9yZ2Vqby5vcmcvb2NpL2FscGluZSBEb2NrZXIgdGFnIHRvIHYzLjIz-->Update data.forgejo.org/oci/alpine Docker tag to v3.23<!--description-->
- [PR](https://code.forgejo.org/actions/setup-forgejo/pulls/849): <!--number 849 --><!--line 0 --><!--description UmVwbGFjZSBjb2RlLmZvcmdlam8ub3JnL29jaS9kZWJpYW4gRG9ja2VyIHRhZyB3aXRoIGRhdGEuZm9yZ2Vqby5vcmcvb2NpL2RlYmlhbg==-->Replace code.forgejo.org/oci/debian Docker tag with data.forgejo.org/oci/debian<!--description-->
- [PR](https://code.forgejo.org/actions/setup-forgejo/pulls/848): <!--number 848 --><!--line 0 --><!--description UmVwbGFjZSBjb2RlLmZvcmdlam8ub3JnL29jaS9hbHBpbmUgRG9ja2VyIHRhZyB3aXRoIGRhdGEuZm9yZ2Vqby5vcmcvb2NpL2FscGluZQ==-->Replace code.forgejo.org/oci/alpine Docker tag with data.forgejo.org/oci/alpine<!--description-->
<!--end release-notes-assistant-->
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi45My4xIiwidXBkYXRlZEluVmVyIjoiNDIuOTMuMSIsInRhcmdldEJyYW5jaCI6ImZvcmdlam8iLCJsYWJlbHMiOlsiZGVwZW5kZW5jeS11cGdyYWRlIiwidGVzdC9ub3QtbmVlZGVkIl19-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11104
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
Co-committed-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
## Changes
I've made releases list more usable on narrow viewports while trying keep the layout unchanged for desktop viewports.
To support these changes large amount of Tailwind classes were converted to regular CSS to be applied conditionally via `@media`. While it was possible to just adjust the Tailwind classes to achieve the same behavior, there's a positive effect which is that the repeating HTML of releases generated by template's range is much less verbose and contains fewer long duplicated lines of Tailwind classes.
## Preview
### Desktop
Not much changed, but the dot between tag and release name is no more.
|Before|After|
|-|-|
|||
### Mobile
|Before|After|
|-|-|
|||
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11080
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
The end-to-end tests are currently failing on v15: https://code.forgejo.org/forgejo/end-to-end/actions/runs/4900/jobs/8/attempt/1#jobstep-4-356 This is a regression from #11164.
The cause of this regression is:
- When the job emitter emits new jobs, it *now* sets their `Needs` field correctly, fixed in #11164.
- If a job has `needs` set to a non-empty array, it will start as status **blocked**: db037fca50/models/actions/run.go (L369-L370)
This got past manual testing and the end-to-end test run in #11164 because it is intermittent. If the runner invokes `UpdateTask` multiple times once the status of the job is settled, then the API will invoke the job emitter multiple times -- a second run would unblock the newly blocked jobs. Podman-based runners do this often due to a long cleanup time, and Docker-based runners (like the end-to-end test) can do it randomly depending on a race condition.
db037fca50/routers/api/actions/runner/runner.go (L241-L244)
The fix for this is to reinvoke the job emitter's logic whenever new jobs are created, so that their new blocked state can be reevaluated to see if it is correct or not. This is treated cautiously by examining if new jobs are present.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] 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.
- This will be a fix to an unreleased regression within the milestone, and so won't be user-facing.
*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/11184
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
fix(ui)!: Remove the instance configuration option `repository.pull-request.ADD_CO_COMMITTER_TRAILERS` (was enabled by default). It was responsible for addition of unexpected trailers to commit messages in squash merges. These trailers were `Co-authored-by: ` and `Co-committed-by: `. Both used the pull request author as value, who is also assigned as the author of the squash merge commit, which they were just repeating. Furthermore, `Co-committed-by: ` is an uncommon commit trailer, and there is only one committer for a commit. The trailers were being added by Forgejo while performing the merge, bypassing user input in the UI and weren't shown in it. See further description and more examples in [#11097](https://codeberg.org/forgejo/forgejo/issues/11097).
Closes: #11097Closes: Codeberg/Community#2030
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11096
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
This slightly simplifies calling code by centralizing the common 3-liner to create a JWT from claims, signed by a key.
But more importantly, it reduces the risk of `key.PreProcessToken()` being forgotten, which will become relevant in upcoming PRs:
`key.PreProcessToken()` adds the key id to the JWT header, which is important to efficiently validate tokens when multiple validation keys are supported (that is not the case yet)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11067
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
This fixes a flake that my previous PR #10933 introduced. Since no individual feed items were previously asserted in the test, the inconsistent sort order never caused an issue before. Thanks to @mfenniak for pointing me in the right direction.
## Checklist
### Tests
- 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 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
- [ ] 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/11176
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: xrstf <git@xrstf.de>
Co-committed-by: xrstf <git@xrstf.de>
- When working forgejo/forgejo!8714 I did not touch the UI to remove the
note and `disabled` attribute. This was not intentional, and was likely
caused by me straight going for testing (as the backend code would allow
the username change).
- Slightly refactor the context to a common function, don't hard error
if `CanUserRename` fails but does default to that you cannot rename in
that case (which is the standard behavior of OAuth2 users anyway).
I already was aware that it seems !8714 wasn't working on Codeberg but someone at FOSDEM pointed it out again, thus the reason for this bug fix.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11171
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- Resolvesforgejo/forgejo#11064
- Show a note similar to that of GPG keys, when a user has no SSH keys uploaded through Forgejo. The content is recognized as a comment in SSH authorized files format and ends with a newline.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11143
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Fixes#11163. When expanding a dynamic matrix (or any other dynamic job), the references to the original `needs` of the jobs are lost.
This is manually tested, and moderately covered by an automated test. Will follow-up with an end-to-end test after a regression run is complete.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/11164
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This patch only moves code around and splits out two functions from
loadOrCreateAsymmetricKey(). The diff is best viewed with -b to ignore
white space (indentation) changes.
This is done for two reasons:
- For future additions, we will need loadAsymmetricKey() only, without
the create
- The doubly nested immediately invoked closure construction was not
exactly helping clarity
golang-jwt/jwt already has a GetSigningMethod() function which we should
use to ensure that our signing methods are actually registered.
Yet we should also keep our own check against a set of allowed methods
such that we do not accidentally accept methods which we are not
prepared to support.
On an open PR that is waiting for job approval, if jobs haven't been approved by the time the abandon timeout occurs they get marked as cancelled. This doesn't match the expectations of abandoned jobs in my opinion, which is that they were never able to be dispatched to a runner (no matching labels), but these jobs never got a chance. They should remain valid and blocked until approved.
Discovered while testing #11125, but unrelated to the behaviour fixed there.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/11145
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
fixes#9028 - when searching issues via repo api, org labels are ignored
added integration test that reproduces the bug
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11109
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Ori Hoch <ori@uumpa.com>
Co-committed-by: Ori Hoch <ori@uumpa.com>
Fixes#11125. When a PR is closed, cancel any action runs associated with the pull request that are not approved so that they do not remain in the Actions list as a blocked action.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/11134
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR changes the URL format for `/compare/` links in the RSS/Atom feeds to include the full domain. This makes the links consistent with all other URLs in the feeds.
Fixes#10168.
I tested this on a local Forgejo build with a sample org and a dummy repository as per the original issue. I then fetched the feed to check:
```bash
$ curl http://localhost:3000/helloworld.atom | grep compare
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4194 0 4194 0 0 297k <id>10: ed4090ecc2...412413fd40</id>
0 -- <link href="ed4090ecc2...412413fd40" rel="alternate"></link>
```
## Checklist
### AI Disclosure
I used AI to
* ask it how to run a single integration test locally because I didn't know about `make test-sqlite#XXX`.
### Tests
- 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 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
- [ ] 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/10933
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: xrstf <git@xrstf.de>
Co-committed-by: xrstf <git@xrstf.de>
This modifies usernames of ActivityPub accounts to use the @example@example.tld
format with an additional optional port component (e.g. @user@example.tld:42).
This allows accounts from ActivityPub servers with more relaxed username
requirements than those of Forgejo's to interact with Forgejo. Forgejo would
also follow a "de facto" standard of ActivityPub implementations.
By separating different information using @'s, we also gain future
opportunities to store more information about ActivityPub accounts internally,
so that we won't have to rely on e.g. the amount of dashes in a username as
my migration currently does.
Continuation of Aravinth's work: https://codeberg.org/forgejo/forgejo/pulls/4778
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9254
Reviewed-by: jerger <jerger@noreply.codeberg.org>
Reviewed-by: Ellen Εμιλία Άννα Zscheile <fogti@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
Co-committed-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [https://data.forgejo.org/actions/cache](https://github.com/actions/cache) | action | patch | `v5.0.2` → `v5.0.3` |
---
### Release Notes
<details>
<summary>actions/cache (https://data.forgejo.org/actions/cache)</summary>
### [`v5.0.3`](https://github.com/actions/cache/releases/tag/v5.0.3)
[Compare Source](https://github.com/actions/cache/compare/v5.0.2...v5.0.3)
##### What's Changed
- Bump `@actions/cache` to v5.0.5 (Resolves: <https://github.com/actions/cache/security/dependabot/33>)
- Bump `@actions/core` to v2.0.3
**Full Changelog**: <https://github.com/actions/cache/compare/v5...v5.0.3>
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi45My4xIiwidXBkYXRlZEluVmVyIjoiNDIuOTMuMSIsInRhcmdldEJyYW5jaCI6ImZvcmdlam8iLCJsYWJlbHMiOlsiZGVwZW5kZW5jeS11cGdyYWRlIiwidGVzdC9ub3QtbmVlZGVkIl19-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11103
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
Co-committed-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
Resolves:
- #10497
- #10496
- #10499
Update the message Forgejo is showing when an user is not allowed to push to a repo:
```
remote: Forgejo: User 'username' is not allowed to push to 'branchname' in 'repo'.
remote: If you instead wanted to create a pull request to the branch 'branchname', please use:
remote: git push origin HEAD:refs/for/branchname/choose-a-descriptor
remote: You might want to replace 'origin' with the name of your Git remote if it is different from origin. You can freely choose the descriptor to set it to a topic.
remote: You can learn about creating pull requests with AGit in the docs: https://forgejo.org/docs/latest/user/agit-support/
```
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/10941): <!--number 10941 --><!--line 0 --><!--description ZGV0YWlsZWQgcGVybWlzc2lvbiBkZW5pZWQgbWVzc2FnZSBvbiBwdXNo-->detailed permission denied message on push<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10941
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Enrique Sanchez Cardoso <enriqueesanchz@gmail.com>
Co-committed-by: Enrique Sanchez Cardoso <enriqueesanchz@gmail.com>
Webhooks not enabled for push events cannot be tested using the
"Test delivery" button, because the built-in test payload corresponds
to a push event and is therefore filtered out at delivery time if the
webhook isn't configured to trigger for such events.
This fixes it by delivering the payload for a push event regardless
of the webhook's configuration. This has the downside of delivering
a payload which isn't necessarily representative of what the webhook
will deliver for real, but it would be a significant effort to implement
test payloads for all possible event types. We leave this as a follow-up
improvement.
Fixes#7934.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11073
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
The module calling `log.Fatal()` (which terminates the process) prevents the calling function to enrich the error message with vital information allowing the user to track down problematic configuration directives. Also this was impeding unit tests.
One such case is where the path to the specified key can not be created, as demonstrated in the test case. Here the error message is:
```
Error while loading or creating JWT key: Error generating private key ...: mkdir ...: permission denied
```
`log.Fatal()` is kept for `f.Close()` errors which indicate much more severe but very rare underlying issues. Handling these would require broader changes.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11066
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Fixes#11030.
When a `strategy.matrix` needs to be evaluated on the output of another job, it can become evaluated into an empty set of jobs. In this case, and assuming no other jobs in the run are active, the run should reach a settled state. The logic to check the other jobs in the run and determine if this state has been hit needs to be explicitly added to the job emitter.
To accomplish this change, this action run state logic was extracted out of `UpdateRunJobWithoutNotification` where it could be reused.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/11063
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
- In order to avoid a database locked message, you either need shared
cache or WAL. Shared cache was disabled in as its deprecrated and could
cause more good than trouble. Enable WAL by default, it's only
non-desirable in very narrow and select situations (NFS filesystem
situation) and is otherwise safe as default.
- Resolvesforgejo/forgejo#10900
Docs: forgejo/docs!1717
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11059
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Fixes#10881
Call the proper function for each repository the user watches, so adjusting the watch count can be done properly.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10882
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: christopher-besch <mail@chris-besch.com>
Co-committed-by: christopher-besch <mail@chris-besch.com>
This PR fixes a number of typos throughout the entire repository. Running https://github.com/crate-ci/typos and then changing all occurrences that I naively deemed "safe enough".
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10753
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Christoph Mewes <christoph@kubermatic.com>
Co-committed-by: Christoph Mewes <christoph@kubermatic.com>
This PR is in preparation of, but independent of, an upcoming suggestion for a feature addition:
* The first commit moves a tiny bit of logic into a separate function to prepare for extension of that logic, avoiding duplication
* The second commit moves checking for disabled registrations earlier, which, I think, has merits in terms of performance and resilience (hopefully not significant, but who knows?)
* The third commit adds simple unit tests for SignUp() and SignUpPost() to avoid the long-ish roundtrip over integration tests
* The forth commit introduces `ctx.Data["DisableRegistrationReason"]` for the signup template to use as the reason printed if `.DisableRegistration` to prepare for other reasons to be added
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10915
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Forgejo supports disabling features for users with the configuration
options `USER_DISABLED_FEATURES` and `EXTERNAL_USER_DISABLE_FEATURES`.
Add `manage_password` that prevents users from configuring passwords.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10541
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: hwipl <hwipl@noreply.codeberg.org>
Co-committed-by: hwipl <hwipl@noreply.codeberg.org>
Followup to https://codeberg.org/forgejo/forgejo/pulls/6154
en-US:
two days ago -> 2 days ago
two weeks ago -> 2 weeks ago
two months ago -> 2 months ago
two years ago -> 2 years ago
Other locales still require changes to ensure
that the relative time numbering is consistent.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10691
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: lily <lesson085@gmail.com>
Co-committed-by: lily <lesson085@gmail.com>
For the previous code with the Page attribute present in
ListCursorOptions for page 1, github would not return an "After" cursor,
such that the request for page 2 would request what effectively is the
content of page 1 a second time.
This would lead to an attempt to insert the same issues twice.
Note that this is not the only reason why this can happen with the
current code base.
We fix this particular issue by not using the Page attribute so github
does return an "After" cursor.
Fixes#10794
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10798
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
A template should not get (easy) access to a full signing key to prevent accidents.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10967
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
This is a successor to #10805, which simply did not work. It is also much simpler and basically a one line change to enable an existing feature in [go-github](https://github.com/google/go-github).
Fixes#10845
With this fix and #10798 in place, a migration of a repo with ~3K issues and ~1.3k pull requests finally completed successfully.
## Patch
We use SleepUntilPrimaryRateLimitResetWhenRateLimited to instruct the go-github code to wait until the retry time and retry the request when the primary rate limit gets hit.
## Test case
TestGitHubDownloadRepo() has been modified such that 403 rate limit errors are injected every 7 requests with a retry time of one second, resulting in the rate limit condition being hit twice with the current tests. The test case confirms that the migration code itself is in fact unaffected by the rate limit being hit.
## Scope
This change does not affect secondary rate limits.
If the server is restarted during the wait for the rate limit refresh, the migration likely still fails when retried, because inserts for already present database objects will be attempted.
This approach effectively puts the task's goroutine to sleep until the retry time, which implies that the respective resources stay allocated.
A better approach might be to add the necessary infrastructure to support restarts of migration tasks at a later time, but this is much more involved, because the migration state would need to be saved and/or re-created based on already pulled data. This would also require adding support for database upserts.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10846
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
It has always been largely used for showcasing UI elements but that name didn't work too well for it.
Testing:
Some of existing tests depend on these pages, making it redundant to create extra tests.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11019
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
I've been reading through the watch model code and found that the `isWrite` flag is dead code — it isn't used anywhere. To be honest I don't see why we should need that anyways. Therefore, I deleted it.
Also I've added some comments for the `WatchMode`. It took me quite some time to figure out why there are four options.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10880
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: christopher-besch <mail@chris-besch.com>
Co-committed-by: christopher-besch <mail@chris-besch.com>
The two commits in this PR fix test cases which did not work as intended, because `require.Errorf()` was used where `require.ErrorContains()` was intended.
The former formats the error output by the test itself when failing, while the latter is to expect the tested error to contain some expected string.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11035
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Related to #11035, this test case used `require.Errorf()` where it could use `require.Error()` to make it clear that this is not a case of confusion with `require.ErrorContains()`
The other cases in the same function already use `require.Error()`, so this clearly looks like a consistency glitch.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11037
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
Regression of forgejo/forgejo!9587
`git-diff` will always find renames because it is implied by the `diff.renames` configuration option. Specify `--find-renames` to detect renames again.
Resolvesforgejo/forgejo#11032
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11038
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
The indexer previously used a `camelcase` filter which could be problamatic for certain queries.
This commit removes the faulty filter for bleve, matching the behaviour of the database "indexer".
closes!10997
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11022
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Make it possible to filter action runs returned by `/api/v1/repos/andreas/test/actions/runs` by Git reference.
Resolves https://codeberg.org/forgejo/forgejo/issues/10874.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/11013
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Found while working on https://codeberg.org/forgejo/forgejo/pulls/10798#issuecomment-10083846: The symptom was that the go-github client never returned a `resp.After`, so I tracked down the root cause, which was that, with the mocked http server ...
Mocked headers never reached the calling client, because w.WriteHeader()
was called before the headers were set in the response.
Fix by moving w.WriteHeader() to the right place just before w.Write(),
which writes the body.
Test added which fails without the fix and succeeds with it.
### Tests
- 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.
### 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/11007
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
This PR makes two changes.
**First**, it removes the ability for Forgejo to rewrite ssh authorized_keys during startup. Forgejo previously checked if the application path or config file path had changed from that which is recorded in its database. If either has changed, it would rewrite the SSH `authorized_keys` file, as those paths are embedded into that file. The problem is that if a new installation runs the app and goes through a standard init procedure, it will clobber ~/.ssh/authorized_keys which is a disruptive mistake.
Instead, Forgejo will proceed to ssh initialization, and due to the change in #10010 the incorrect application path or config file path will result in a fatal server error that the administrator must resolve. Disabling SSH is added as a plausible option for how to resolve that fatal error.
**Second**, the interactive install UI has been modified to detect this error before the installation proceeds. If a user is attempting to install Forgejo with SSH, and they have an existing `~/.ssh/authorized_keys` file with keys present in it, the installation will fail with an error advising them to use a separate Forgejo user or to disable SSH. (More options are possible to fix this problem, but these are the obvious solutions.)
Fixes#10942.
Manually tested. Without the install process change, Forgejo behaves like this:
- Configure a typical end-user `~/.ssh/authorized_keys` file with normal keys
- Run through a Forgejo initialization process on a new database; run with SQLite, add a new administrator account during the init process.
- After initialization, Forgejo will restart and encounter a fatal error:
```
2026/01/20 10:11:24 routers/init.go:84:syncAppConfForGit() [I] AppPath changed from '' to '/home/mfenniak/Dev/forgejo/forgejo'
2026/01/20 10:11:24 routers/init.go:89:syncAppConfForGit() [I] CustomConf changed from '' to '/home/mfenniak/Dev/forgejo/custom/conf/app.ini'
2026/01/20 10:11:24 routers/init.go:95:syncAppConfForGit() [I] re-sync repository hooks ...
2026/01/20 10:11:24 ...er/issues/indexer.go:155:func2() [I] Issue Indexer Initialization took 9.858336ms
2026/01/20 10:11:24 modules/ssh/init.go:86:Init() [F] An unexpected ssh public key was discovered. Forgejo will shutdown to require this to be fixed. Fix by either:
Option 1: Delete the file /home/mfenniak/.ssh/authorized_keys, and Forgejo will recreate it with only expected ssh public keys.
Option 2: Permit unexpected keys by setting [server].SSH_ALLOW_UNEXPECTED_AUTHORIZED_KEYS=true in Forgejo's config file.
Option 3: If unused, disable SSH support by setting [server].DISABLE_SSH=true in Forgejo's config file.
Unexpected key on line 1 of /home/mfenniak/.ssh/authorized_keys
Unexpected key on line 2 of /home/mfenniak/.ssh/authorized_keys
Unexpected key on line 3 of /home/mfenniak/.ssh/authorized_keys
Unexpected key on line 4 of /home/mfenniak/.ssh/authorized_keys
```
With the install process change, the above error screenshot occurs instead.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10948): <!--number 10948 --><!--line 0 --><!--description ZG9uJ3QgY2xvYmJlciBhdXRob3JpemVkX2tleXMgZmlsZSBkdXJpbmcgaW5zdGFsbGF0aW9u-->don't clobber authorized_keys file during installation<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10948
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Forgejo organisations can have multiple owners. In issue or PR discussions, the tooltip for the "Owner" role should not imply that a repository has a single owner. Therefore, I am proposing that it says "an owner" instead of "the owner".
One choose to keep the tooltip with its current wording for repositories owned by an individual (instead of an organization), but the new tooltip remains correct even if there happens to be a single owner, and I don't think the wording difference warrants a runtime check.
#### Before (on Codeberg)
#### After (on local instance)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11004
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
The custom styles for tippy-enabled menus had too broad selectors, conflicting with styles of other .item elements in tippy boxes.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10969
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
While reviewing cpuprofiles of #10985, I noticed a bunch of slice-grows within this function.
Instead of `io.ReadAll` (which does not know the size in advance), use `fs.ReadFile`, which will perform correctly-sized allocations.
### Tests
This function is already covered by tests in `modules/assetfs/layered_test.go`
### 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/10987
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Polish a glitch from #10481
(kinda sad to let go of such a cute name)
### Checklist
* no tests to change
* no docs to change
* not relevant for release notes
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10966
Reviewed-by: Lucas <sclu1034@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
- `CodeSearchMode` should now be set when keyword is empty
- The default value for search mode should be exact, use fuzzy ONLY when fuzziness is enabled in settings
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10964
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
* Separate documentation about the workflow for better attention. I could imagine that it was not read by everyone, since it was after the trivial 'Please write in English' instructions.
* Improve explanations about the workflow, expectations and next steps.
* Explicitly mark the Enhancement template to be mostly for contributors.
* Disable blank issues. I could not really identify any recent usage of it that was legitimate.
* Improve instructions about which details to share about the own Forgejo usage.
* Explicitly state in the enhancement template that only issue references should go in there, not noise.
* Create a placeholder in problem template to add references to potential solutions later.
I hope this resolves some of the issues observed with the new workflow and improves the quality of submitted reports. Also addresses the feedback already received in https://codeberg.org/forgejo/user-research/issues/71
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10847
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Otto Richter <otto@codeberg.org>
Co-committed-by: Otto Richter <otto@codeberg.org>
## Summary
Currently, on `{INSTANCE_URL}/admin/config`, the "Disable router log" indicator is completely meaningless, as nothing is assigned to `ctx.Data["DisableRouterLog"]` in [`routers/web/admin/config.go`](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/routers/web/admin/config.go#L121).
This makes the indicator useful without changing any Go code by querying the `Loggers` item that has already been dumped to the context.
Some pictures :)
---
### Before (always)
### After (with default log config)
### After (with `LOGGER_ROUTER_MODE` set to empty)
---
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
As far as I can tell, there aren't tests for TMPL template rendering, if I have overlooked them I'll be happy to add.
- 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 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
(I don't really mind)
- [x] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10356
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: avery <avery@catpowered.net>
Co-committed-by: avery <avery@catpowered.net>
Followup to https://codeberg.org/forgejo/forgejo/pulls/7746
Replaces https://codeberg.org/forgejo/forgejo/pulls/10938
grid layout (desktop): give the Compare button a wrapper with same height as the first text line so it stays aligned to it (and to timeline badge)
inline layout (mobile): give the Compare button left margin so there's a gap between it and the text line
Initial fix for grid was proposed by luisadame.
Co-authored-by: Luis <luis@adame.dev>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10939
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] 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/10925
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: emilycares <emilydoescare@gmail.com>
Co-committed-by: emilycares <emilydoescare@gmail.com>
#10893 introduced a retry loop to manage concurrent updates when updating the state of `action_run` in the function `UpdateRunJobWithoutNotification`. However, when `UpdateRunJobWithoutNotification` is called from within a transaction, the retry loop continues to read the same data from the DB (due to repeatable read isolation) and loops infinitely.
As #10893 was later identified to not be required to fix the target problem (https://code.forgejo.org/forgejo/runner/issues/1302), this PR reverts the change. The only retained change is that the error `ErrActionRunOutOfDate` is a constant rather than `errors.New("run has changed")`.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] Reverted the test added for 10893 after confirming that it is the cause of the problem.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- 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
- [ ] 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/10945
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Ellen Εμιλία Άννα Zscheile <fogti@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Avatars storage handler ignores the size= url parameter, and we don't have any code for creating multiple sizes of the same avatar.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10932
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Replace newlines from the repo description with spaces to match in-app
rendering.
Related issue: #10823
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/10914
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Enrique Sanchez Cardoso <enriqueesanchz@gmail.com>
Co-committed-by: Enrique Sanchez Cardoso <enriqueesanchz@gmail.com>
This variable isn't needed because all themes are setting it to `--color-text`, but the relevant UI elements are already inheriting it from `body`.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10898
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Possible bug that could cause https://code.forgejo.org/forgejo/runner/issues/1302: by picking more tasks after the first `PickTask` didn't find anything, they'll be returned in `AdditionalTasks`. But the runner doesn't act upon additional tasks if there is no "first" task.
I can't see a practical way to cover this with an automated test other than mutating the production code to provide a synchronization point between the two operations.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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/10899
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
When concurrent updates occur to the `action_run` table, fetching a task via `FetchTask` can result in an error:
```
time="2026-01-16T16:02:30Z" level=error msg="failed to fetch task" error="internal: pick task: CreateTaskForRunner: update run 2358339: run has changed"
```
This is an error with no known harm. However, it is more efficient to recover from doing 90% of the work to fetch a task, and complete that work, rather than error out and rollback. Discovered while investigating https://code.forgejo.org/forgejo/runner/issues/1302#issuecomment-73859, although conclusions do not indicate that it is a source of this bug.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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.
- [ ] 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/10893
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
The existing implementation of `DropTableColumns()` came from before SQLite had the ability to `ALTER TABLE ... DROP COLUMN ...`. It works by parsing the table definition and rewriting it without the columns that are to be dropped, but it will fail to do this correctly if the table definition is not in the exact expected format. In #10887, a database that had probably come through some migration tool was not exactly formatted the way Forgejo expected, resulting in a migration failure.
This replaces `DropTableColumns()`'s hacky SQLite implementation with a more straightforward implementation. Affected indexes touching the target fields are dropped, then the field is dropped.
DROP COLUMN is supported on SQLite since [3.35.0, 2021-03-12](https://sqlite.org/releaselog/3_35_0.html).
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- Existing `test-sqlite-migration` coverage is relied upon for this change. During development it was proven to exercise the affected code -- in other words, multiple iterations of changes were required due to it failing as I worked on it.
- No coverage is added for "database with unexpected schema definition format" as the trigger issue for this change though, a point that can be raised if someone believes it is worthwhile.
- 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 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/10888
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
When an action's job fails, it marks the entire run as failed. Concurrency group cancellation was only looking for runs that are in a pending state, and therefore after a single job failed in the run, none of the other jobs in the run could be cancelled by a matching cancel-in-progress job.
Raised in https://codeberg.org/Codeberg/Community/issues/2315.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10863
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Discovered while trying to reproduce #10848 -- when using `forgejo doctor recreate-tables` against a PostgreSQL database with multiple Forgejo schemas in it, it fails. The reason is that when querying for index and sequence information, it begins to get information from the other schemas.
```
2026/01/15 15:19:15 ...3.6.1/command_run.go:288:run() [I] PING DATABASE postgresschema
2026/01/15 15:19:15 ...igrations/base/db.go:51:func2() [I] Creating temp table: tmp_recreate__external_login_user for Bean: ExternalLoginUser
2026/01/15 15:19:15 ...igrations/base/db.go:108:func2() [I] Copying table external_login_user to temp table tmp_recreate__external_login_user
2026/01/15 15:19:15 ...igrations/base/db.go:120:func2() [I] Dropping existing table external_login_user, and renaming temp table tmp_recreate__external_login_user in its place
2026/01/15 15:19:15 cmd/doctor.go:216:func1() [E] [Error SQL Query] ALTER INDEX "external_login_user_pkey" RENAME TO "external_login_user_pkey" [] - ERROR: relation "external_login_user_pkey" does not exist (SQLSTATE 42P01)
2026/01/15 15:19:15 ...igrations/base/db.go:404:renameTable() [E] Unable to rename external_login_user_pkey to external_login_user_pkey. Error: ERROR: relation "external_login_user_pkey" does not exist (SQLSTATE 42P01)
Command error: migrate: ERROR: relation "external_login_user_pkey" does not exist (SQLSTATE 42P01)
```
This is a very niche use-case that is likely to only affect a developer using PostgreSQL and popping back to older releases often enough to keep them around in different DB schemas. I don't think it's worth an automated test, which would require creating a secondary DB schema in a specific migration test. Manually tested on my dev environment.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10854
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
- Resolvesforgejo/forgejo#10849
- Yes, the referrer policy is causing cross-origin protection to fail.
Why? Because someone really cared about privacy, the referrer policy was
set to no-referrer. So no `Referrer` HTTP header and `Origin` is either
omited or set to `null`, because hey the browser isn't allowed to leak
it via that header either. The new cross-origin protection relies on
Sec-Fetch metadata to determine if the request is same-origin or not.
This metadata is only sent to trustworthy origins, and thus not when
you visit Forgejo on your intranet. But the new protection has a
fallback to compare the Origin to the Host header... but the Origin
header was conviently set to `null` to protect the user's privacy.
- We now set the referrer policy to strict-origin, which means only for
same-origin requests a Origin header is set. For cross-origin the
behavior is unchanged and the user's privacy is preserved.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10851
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Add support for OIDC workload identity federation.
Add ID_TOKEN_SIGNING_ALGORITHM, ID_TOKEN_SIGNING_PRIVATE_KEY_FILE, and
ID_TOKEN_EXPIRATION_TIME settings to settings.actions to allow for admin
configuration of this functionality.
Add OIDC endpoints (/.well-known/openid-configuration and /.well-known/keys)
underneath the "/api/actions" route.
Add a token generation endpoint (/_apis/pipelines/workflows/{run_id}/idtoken)
underneath the "/api/actions" route.
Depends on: https://code.forgejo.org/forgejo/runner/pulls/1232
Docs PR: https://codeberg.org/forgejo/docs/pulls/1667
Signed-off-by: Mario Minardi <mminardi@shaw.ca>
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [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.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10481
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Mario Minardi <mminardi@shaw.ca>
Co-committed-by: Mario Minardi <mminardi@shaw.ca>
Same as https://codeberg.org/forgejo/forgejo/pulls/10835 but for main branch since release-notes-assistant recently gained ability to search on both branches.
It was already announced in release notes of v13 and v11 point releases and shouldn't be in release notes of v14, which this file is causing.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10837
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
- Resolvesforgejo/forgejo#10819
- CSS from tippy is overriding the style specifically for active-stopwatch-popup because of strange/incorrect HTML structure, so override it via `!important`.
## Test
1. Start timer on any issue.
2. See that the styling is okay in the global time tracker popup in the navbar.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10827
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Resolves https://codeberg.org/forgejo/forgejo/issues/10584
Codeberg mostly uses about 30 connections with rare peaks, so I think it's safe to assume that this value is reasonable even for large Forgejo deployments, and only needs to be adjusted for very busy instances. In practice, the open connections likely remain lower due to the connection lifetime and maximum idle connections (which could maybe also be tuned later). A value of 30 would technically allow 3 full-loaded Forgejo instances to operate on one PostgreSQL instance (30 * 3 = 90 < 97) without conflicting.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10821
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Otto Richter <git@otto.splvs.net>
Co-committed-by: Otto Richter <git@otto.splvs.net>
The default braunch is configured in the repo settings. Only users with
administrator privileges for the repository can access the repo
settings. When the feature was implemented (72e956b79a),
the button in the branch list was only guarded with a check for repo
write permissions. This means the button is shown to too many users.
If no an user with write, but not admin permissions clicks on the button,
they see just a 404 page. Which is bad UX.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10814
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Fixed action variables and secrets according to [Docu](https://forgejo.org/docs/next/user/actions/basic-concepts/#name-constraints):
> Variable names must not start with the FORGEJO_, GITHUB_ or GITEA_ prefix.
This wasn't correctly enforced, so I changed the regex
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [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.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10682
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: zokki <zokki.softwareschmiede@gmail.com>
Co-committed-by: zokki <zokki.softwareschmiede@gmail.com>
- Regression of forgejo/forgejo!9830
- `reqSignIn` means it requires sign-in, but it does not require sign-in (can be hit by visiting large repository) so `ignSignIn` is the better option.
- Resulted in behavior of being redirected to `/user/login` when visiting a repository such as comaps or forgejo when not being logged in.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10815
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Fixes https://codeberg.org/forgejo/forgejo/issues/7514
When a token is used, provide a better error message when that token is not valid.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10727
Reviewed-by: Ellen Εμιλία Άννα Zscheile <fogti@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: zokki <zokki.softwareschmiede@gmail.com>
Co-committed-by: zokki <zokki.softwareschmiede@gmail.com>
Update the Forgejo driver for gof3 with modifications for non-backward compatible changes. The changes are isolated behind the f3.Enable flag and not yet functional. The purpose of this upgrade is to not drift from the gof3 implementation while the work continues.
The `fix: include remote users when counting users` commit is a functional change to Forgejo itself but does not change the behavior because the remote users are only created in fixtures or by F3.
59c721d26b/models/user/user.go (L65-L66)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10673
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: limiting-factor <limiting-factor@posteo.com>
Co-committed-by: limiting-factor <limiting-factor@posteo.com>
Using node head built from source, "make frontend" failed with this confusing message:
```
$ make node-check
/bin/sh: 1: printf: 0-pre: not completely converted
Forgejo requires Node.js 20.0.0 or greater and npm to build. You can get it at https://nodejs.org/en/download/
make: *** [Makefile:327: node-check] Error 1
```
The reason is that from this output
```
$ node -v
v26.0.0-pre
```
`0-pre` could not be converted to the printf `"%d"` format.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10790
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Nils Goroll <nils.goroll@uplex.de>
Co-committed-by: Nils Goroll <nils.goroll@uplex.de>
In support of adding foreign keys to the `action_runner_token` table, this PR also had to:
- Add detection and error if a table with "soft delete" is used with a foreign key, because it causes a tricky to track down foreign key violation
- Remove unused xorm "soft delete" capability on the `action_runner_token` table
- Change the `RepoID` and `OwnerID` fields to use the value `NULL` to indicate that this scope wasn't valid for the token, rather than the value `0`
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10756
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR contains the following updates:
| Update | Change |
|---|---|
| lockFileMaintenance | All locks refreshed |
🔧 This Pull Request updates lock files to use the latest dependency versions.
---
### Configuration
📅 **Schedule**: Branch creation - Between 12:00 AM and 03:59 AM, only on Monday ( * 0-3 * * 1 ) (UTC), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi43MS4wIiwidXBkYXRlZEluVmVyIjoiNDIuNzEuMCIsInRhcmdldEJyYW5jaCI6ImZvcmdlam8iLCJsYWJlbHMiOlsiZGVwZW5kZW5jeS11cGdyYWRlIiwidGVzdC9ub3QtbmVlZGVkIl19-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10785
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
Co-committed-by: Renovate Bot <forgejo-renovate-action@forgejo.org>
We need to take all matching required status into account to get the desired status because there can be some pending.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10747
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
Implements auto-linking container images from the package registry to a repository (closes#2823). This might ease implementing #2699 in the future.
Specifically, auto-linking happens on package creation and NOT when publishing updates to the same package. This should prevent "relinking" a manually unlinked package when publishing an update. Linking is performed either via the the Docker label `` (as described here: https://codeberg.org/forgejo/forgejo/issues/2823#issuecomment-8163866) or by naming the image like the repository (supports nested image names).
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- I added test coverage for Go changes...
- ~~[ ] in their respective `*_test.go` for unit tests.~~ _(Not required, since only already tested functions were used)_
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- ~~I added test coverage for JavaScript changes...~~ _(No changes to JavaScript code)_
### 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: https://codeberg.org/forgejo/docs/pulls/1666
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [X] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10617
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Leon Schmidt <mail@leon.wtf>
Co-committed-by: Leon Schmidt <mail@leon.wtf>
Fixes a typo that prevents the forgejo docs builds from being updated.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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.
- [ ] 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/10780
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Add special parsing to handle the keys found in the `Reason` field of `ObjectVerification` structs.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10755
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Έλλεν Εμίλια Άννα Zscheile <fogti+devel@ytrizja.de>
Co-committed-by: Έλλεν Εμίλια Άννα Zscheile <fogti+devel@ytrizja.de>
```
NAME:
forgejo doctor cleanup-commit-status - Cleanup extra records in commit_status table
USAGE:
forgejo doctor cleanup-commit-status
DESCRIPTION:
Forgejo suffered from a bug which caused the creation of more entries in the
"commit_status" table than necessary. This operation removes the redundant
data caused by the bug. Removing this data is almost always safe.
These reundant records can be accessed by users through the API, making it
possible, but unlikely, that removing it could have an impact to
integrating services (API: /repos/{owner}/{repo}/commits/{ref}/statuses).
It is safe to run while Forgejo is online.
On very large Forgejo instances, the performance of operation will improve
if the buffer-size option is used with large values. Approximately 130 MB of
memory is required for every 100,000 records in the buffer.
Bug reference: https://codeberg.org/forgejo/forgejo/issues/10671
OPTIONS:
--help, -h show help
--custom-path string, -C string Set custom path (defaults to '{WorkPath}/custom')
--config string, -c string Set custom config file (defaults to '{WorkPath}/custom/conf/app.ini')
--work-path string, -w string Set Forgejo's working path (defaults to the directory of the Forgejo binary)
--verbose, -V Show process details
--dry-run Report statistics from the operation but do not modify the database
--buffer-size int Record count per query while iterating records; larger values are typically faster but use more memory (default: 100000)
--delete-chunk-size int Number of records to delete per DELETE query (default: 1000)
```
The cleanup effectively performs `SELECT * FROM commit_status ORDER BY repo_id, sha, context, index, id`, and iterates through the records. Whenever `index, id` changes without the other fields changing, then it's a useless record that can be deleted. The major complication is doing that at scale without bringing the entire database table into memory, which is performed through a new iteration method `IterateByKeyset`.
Manually tested against a 455,303 record table in PostgreSQL, MySQL, and SQLite, which was reduced to 10,781 records, dropping 97.5% of the records.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10686
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Some HTTP API endpoints related to Actions, like `/api/v1/repos/{owner}/{repository}/actions/runners`, were not disabled if Actions had been disabled on a repository. With this change, all endpoints related to Actions will be disabled if Actions are disabled.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10726
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Fix#10714 (introduced in #8438) by silently ignoring large .gitmodules files.
Additionally:
- the limit was bumped from 10KB to 64KB (https://github.com/boostorg/boost/blob/master/.gitmodules has 20KB)
- a warning is shown on the .gitmodules view page if this limit is exceeded
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10744
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Adds @0xllx0 as a maintainer + point-of-contact in the `CODEOWNERS` file for federation-related code.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10716
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: elle <0xllx0@noreply.codeberg.org>
Co-committed-by: elle <0xllx0@noreply.codeberg.org>
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10752
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR does three things:
- First it moves the inline web app manifest into its own route `/manifest.json`
- Secondly, it add a setting `pwa.STANDALONE` that can be set to `true` if one wants users to be allowed to "install" forgejo as an pwa into their browser. This usually means an "install app" button, which essentially just creates an shortcut to use a single-tab window for browsing the app / forgejo.
- Thirdly since we have now an extra route, it checks if someone placed a `public/manifest.json` in forgejo's custom path; if yes, it's content is served instead. This allows more customization without the need on our side to completly implement every nuance of web app manifests.
This closes issue #2638
### Tests
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
### Documentation
- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs/pulls/1669) to explain to Forgejo users how to use this change.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [x] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/5384): <!--number 5384 --><!--line 0 --><!--description W2FsbG93IGZvcmdlam8gdG8gcnVuIGFzIGEgcHdhIHN0YW5kYWxvbmUgYXBwbGljYXRpb24gJiBvdmVycmlkZSBvZiB0aGUgd2ViYXBwIG1hbmlmZXN0Lmpzb24gdmlhIHRoZSBhIGN1c3RvbSBmaWxlIGluIGBwdWJsaWMvbWFuaWZlc3QuanNvbmBdKGh0dHBzOi8vY29kZWJlcmcub3JnL2Zvcmdlam8vZm9yZ2Vqby9wdWxscy81Mzg0KQ==-->[allow forgejo to run as a pwa standalone application & override of the webapp manifest.json via the a custom file in `public/manifest.json`](https://codeberg.org/forgejo/forgejo/pulls/5384)<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/5384
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Lucas <sclu1034@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Fixes the layout of the actions list specifically when an action name is too long to be displayed within the column's constrained width.
I took the opportunity to add some ancillary improvements:
- Center elements vertically
- Space elements consistently: the error badge didn't have the same margin on the left like the disabled badge.
Fixes#4580
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10648
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Luis <luis@adame.dev>
Co-committed-by: Luis <luis@adame.dev>
This was implicitly loaded during the mail notifications notifier. If
you disable mail notifications on Forgejo then this will result in the
reviewer not being loaded and NPE.
`GPGKeyToEntity` incorrectly assumed that within a keyring with multiple
keys that the first key is verified and should be exported. Look at all
keys and find the one that matches the verified key ID.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Co-authored-by: Onur Cakmak <occ@occ.me>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10715
Reviewed-by: Cyborus <cyborus@disroot.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Onur Cakmak <occ@noreply.codeberg.org>
Co-committed-by: Onur Cakmak <occ@noreply.codeberg.org>
Attempt to fix intermittent test failure noted in #10633, detailed technical notes in https://codeberg.org/forgejo/forgejo/issues/10633#issuecomment-9571199.
- Failure to cancel the previous processes is now a test error that aborts immediately, preventing 2hr long test runs that won't succeed.
- When the process cancellation fails, the stack trace of all goroutines is printed to help diagnose the cause of any failure to cancel tasks.
- `context.Background()` referenced in the actions notifier is corrected when opening git repos, which seems to be a cause of failure to cancel the tasks -- git subprocesses are spawned from the repo context, which is the background context, and that prevents the context registered in the process manager from cancelling them.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10713
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#10155
When participants are displayed, don't include those that only have made a pending review. Those should not yet be revealed as participants.
Apart from adding automated tests, this is the manual verification process I've followed:
1. Set up three users
2. User 1 creates a repository, then creates a pull request adding a new file
3. User 2 creates a new code comment but doesn't not publish the review, shows as pending.
4. User 3 creates a new code comment and publishes the review.
5. From everyone's perspective the number of participants is: 2. And, the participants displayed in the list are 1 and 3. User 2, which hasn't yet published the review is not displayed.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10528
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: luisadame <luisadame@noreply.codeberg.org>
Co-committed-by: luisadame <luisadame@noreply.codeberg.org>
This will help api packages like https://codeberg.org/Cyborus/forgejo-api to generate clients that expose the header information as well. Currently `forgejo-api` has to edit the swagger json to generate a client crate that knows about headers.
- Create separate response types for different endpoint behaviors
- CommitList: Base type with only X-Total-Count header
- CommitListWithPagination: For GetPullRequestCommits (pagination headers + X-Total-Count)
- CommitListWithLegacyPagination: For GetAllCommits (pagination headers + X-Total-Count + deprecated X-Total)
- ChangedFileList: Base type with only X-Total-Count header
- ChangedFileListWithPagination: For GetPullRequestFiles (pagination headers + X-Total-Count)
This ensures swagger documentation accurately reflects which headers each endpoint returns.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9380
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Cyborus <cyborus@disroot.org>
Co-authored-by: Myers Carpenter <myers@maski.org>
Co-committed-by: Myers Carpenter <myers@maski.org>
I'd like to add myself to the CODEOWNERS for federation code, partly out of personal interest and partly because ActivityPub is easy to hold the wrong way and I unfortunately know a thing or two about this mess by now.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10706
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-committed-by: famfo <famfo@famfo.xyz>
In #10678, I fixed an incorrect codepath that was intended to prevent duplicate redundant entries in `commit_status`. However, the codepath that was repaired didn't take into account changes in the `description` field -- eg. going from `Waiting to run` to `Has started running` both have the `pending` commit status state but are distinct and should be retained. This PR fixes the fix so that changes in description do still cause new entries into the `commit_status` table.
This issue was raised due to an end-to-end test failure in the `push-cancel` actions test. I've manually tested that this fixes the end-to-end test.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10696
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Add an HTTP API endpoint for runner registration. It enables managing the entire runner lifecycle using Forgejo's HTTP API. See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/78 for background, design considerations, and usage.
Example usage:
```
$ curl -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Authorization: token 3fc3ef39805b0f811a5d7789cb7b448348d6bfbb" --data '{"name":"api-runner","description":"Lorem ipsum"}' http://localhost:3000/api/v1/user/actions/runners
```
```json
{"id":30,"uuid":"a5e33697-9f58-437d-83c3-551b6c6a6334","token":"cac45fa6726fe4e28f42598773671af28a3be121"}
```
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10677
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
- Replace the [Monaco Editor](https://microsoft.github.io/monaco-editor/)
with [CodeMirror 6](https://codemirror.net/). This editor is used to
facilitate the 'Add file' and 'Edit file' functionality.
- Rationale:
- Monaco editor is a great and powerful editor, however for Forgejo's
purpose it acts more like a small IDE than a code editor and is doing
too much. In my limited user research the usage of editing files via
the web UI is largely for small changes that does not need the
features that Monaco editor provides.
- Monaco editor has no mobile support, Codemirror is very usable on mobile.
- Monaco editor pulls in large dependencies (for language support) and
by replacing it with Codemirror the amount of time that webpack needs
to build the frontend is reduced by 50% (~30s -> ~15s).
- The binary of Forgejo (build with `bindata` tag) is reduced by 2MiB.
- Codemirror is much more lightweight and should be more usable on
less powerful hardware, most notably the lazy loading is much faster
as codemirror uses less javascript.
- Because Codemirror is modular it is much easier to change the
behavior of the code editor if we wish to.
- Drawbacks:
- Codemirror is quite modular and as seen in `package.json` and in
`codeeditor.ts` we have to supply a lot more of its features to have
feature parity with Monaco editor.
- Monaco editor has great integrated language support (features that
an lsp would provide), Codemirror only has such language support to an
extend.
- Monaco editor has its famous command palette (known by many as its
also available in VSCode), this is not available in code mirror.
- Good to note:
- All features that was added on top of the monaco editor (such as
dynamically changing language support depending on the filename)
still works and the theme is based on the VSCode colors which largely
resembles the monaco editor.
- The code editor is still lazy-loaded (this is painfully clear by
reading how imports are passed around in `codeeditor.ts`).
- This change was privately tested by a few people, a few bugs were
found (and fixed) but no major drawbacks were noted for their usage of
the web editor.
- There's a "search" button in the top bar, so that search can be used
on mobile. It is otherwise only accessible via
<kbd>Ctrl</kbd>+<kbd>f</kbd>.
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10559
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: Beowulf <beowulf@beocode.eu>
- No need to use http when https is available.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10692
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Fixes the auto merge tip not being properly displayed due to an `overflow: hidden` set at the `.item` level. The fix resets that overflow rule if the auto merge button is being hovered and goes back to `hidden` when no longer being hovered.
Fixed also a small misalignment between the tip and the button.
Resolves#4822
### Test
1. Go to a pull request that merges into a protected branch that requires status checks to pass.
2. Go to the merge area of that pull request.
3. Click on the "Create merge commit" button.
4. Hover over the clock icon.
5. Observe that some text appears to the right of that clock icon.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10652
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Luis <luis@adame.dev>
Co-committed-by: Luis <luis@adame.dev>
Fixes#10671.
Cleanup for the inflated number of records in this table will come in a near future change.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10678
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
In a workflow such as:
```yaml
jobs:
define-matrix:
runs-on: docker
outputs:
array-value: ${{ steps.define.outputs.array }}
steps:
- id: define
run: |
echo 'array=["value 1", "value 2"]' >> "$FORGEJO_OUTPUT"
array-job:
runs-on: docker
needs: define-matrix
strategy:
matrix:
array: ${{ fromJSON(needs.define-matrix.outputs.array-value-oops-i-made-an-error-here) }}
steps: # ...
other-job:
runs-on: docker
needs: define-matrix
steps: # .... ${{ needs.define-matrix.outputs.array-value }}
```
After the job `define-matrix` is done, an error will be triggered because `array-value-oops-i-made-an-error-here` is not a valid output, and so `array-job` can't be figured out. When the job emitter triggers that error and stores it in the database, it will mark all the jobs in the workflow as failed (`FailRunPreExecutionError()`) in order to ensure that no blocked jobs remain and appear stuck forever.
However, `other-job` is also unblocked by `job_emitter.go` because it's dependency of `define-matrix` is now complete. After the error occurs, job emitter will attempt to unblock `other-job` and the conditional `UpdateRunJob` will fail because the condition `"status": StatusBlocked` is no longer true:
0af52cdca2/services/actions/job_emitter.go (L88-L92)
This causes an error, and that error rolls back the transaction in `checkJobsOfRun`, and that causes job emitter's queue to constantly retry the same work which has the same outcome each time.
This fix tells `checkJobsOfRun` that an error occurred that prevents all jobs in the run from progressing, and therefore no updates need to proceed.
Discovered while authoring https://code.forgejo.org/forgejo/end-to-end/pulls/1367 and causing an error unintentionally. 🤣
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10665
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Placeholder tasks, which are used to store the outputs of a reusable workflow, were hard coded to always have attempt 1. If you executed "Re-run all jobs" with a reusable workflow, a second placeholder task would be created with the same attempt, which caused: (a) Forgejo to not know which attempt, and therefore which outputs, were valid, and (b) the UI to be stuck in "You are viewing an out-of-date run of this job..." when viewing the job.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10666
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
- Create `modules/testimport/import.go` to centralize blank import needed for tests (in order to run the `init` function) to simplify maintenance.
- Remove the imports that are not needed.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10662
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: limiting-factor <limiting-factor@posteo.com>
Co-committed-by: limiting-factor <limiting-factor@posteo.com>
In-progress jobs don't have a rotating status icon on `/org/repo/actions`. Likely a regression from #9444 as the rotation style was in `RepoActionView` which won't be loaded on the action list page.
Manually tested and confirmed that the styling is effective on both `/org/repo/actions` and in the action log page (`.../runs/#/jobs/#/attempt/#`).
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reported-by: limiting-factor
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10656
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
#10647 introduced a regression which was detected by the [matrix-dynamic end-to-end test](0e0b1429e6/actions/example-matrix-dynamic/.forgejo/workflows/test.yml), resulting in [test failures](https://code.forgejo.org/forgejo/end-to-end/actions/runs/4608/jobs/2/attempt/1).
The cause of this regression was an added code path which is invoked when a job is being reparsed due to being incomplete, in which the original `needs` value of the job is preserved. To describe it in detail, here's an incomplete job...
```
on: [push]
jobs:
# ...
matrix-job:
runs-on: docker
needs: define-matrix
strategy:
matrix: ${{ fromJSON(needs.define-matrix.outputs.matrix-value) }}
steps: # ...
```
This job is "incomplete" when it is parsed initially because the `define-matrix` job needs to be completed before its matrix can be evaluated into the correct jobs to run. It `needs: define-matrix`. When it is first parsed by Forgejo, `needs: define-matrix` is pulled out of the job definition and stored in the database, in the `action_run_job` table's `needs` column, because Forgejo will be the one managing when it is run by detecting the completion of the `define-matrix` job.
During #10647, a change was made which caused new jobs' which have their own `needs` (from reusable workflows) to have their `needs` be merged with the `needs` that were stored in the database. The regression is that when a job is expanded, it will still be considered a blocked job because it has a `needs` list (even though we know that those jobs are complete):
03e2ecfbc4/models/actions/run.go (L369-L370)
As for why it was originally added in #10647? Unfortunately the comment that I left in the code doesn't explain the functional problem it was attempting to solve, and just describes it as-if the original needs are still needed for *something*. 🙄 It makes perfect sense to me, right now, that we would **not** keep `needs` values that are already known to be complete.
I've run through my new reusable workflow end-to-end test (https://code.forgejo.org/forgejo/end-to-end/pulls/1362) with this codepath removed and it works perfectly fine.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10658
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This change allows the `with:` field of a reusable workflow to reference a previous job, such as `with: { some-input: "${{ needs.other-job.outputs.other-output }}" }`. `strategy.matrix` can also reference `${{ needs... }}`.
When a job is parsed and encounters this situation, the outer job of the workflow is marked with a field `incomplete_with` (or `incomplete_matrix`), indicating to Forgejo that it can't be executed as-is and the other jobs in its `needs` list need to be completed first. And then in `job_emitter.go` when one job is completed, it checks if other jobs had a `needs` reference to it and unblocks those jobs -- but if they're marked with `incomplete_with` then they can be sent back through the job parser, with the now-available job outputs, to be expanded into the correct definition of the job.
The core functionality for this already exists to allow `runs-on` and `strategy.matrix` to reference the outputs of other jobs, but it is expanded upon here to include `with` for reusable workflows.
There is one known defect in this implementation, but it has a limited scope -- if this code path is used to expand a nested reusable workflow, then the `${{ input.... }}` context will be incorrect. This will require an update to the jobparser in runner version 12.4.0, and so it is out-of-scope of this PR.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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)).
- **end-to-end test:** will require the noted "known defect" to be resolved, but tests are authored at https://code.forgejo.org/forgejo/end-to-end/compare/main...mfenniak:expand-reusable-workflows-needs
### 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10647
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#10580
Remove obsolete styles so that people do not trip over them.
I went through the codebase with `rg` and made sure that the only elements which had potential to use such mix of classes were doing so accidentally, and removed all the unused code.
### A small fix for Forgejo themes
Ref https://codeberg.org/forgejo/forgejo/pulls/10581#issuecomment-9245399. The missing variable was used in one place outside of devtest.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10581
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Currently, there's no way for actions runners to know what version of
Forgejo is running on the server side. This makes it
difficult/impossible to know which features are available and can make
maintaining compatibility tricky.
Let's add the Forgejo server version to the context.
See associated PR in the runner repo: https://code.forgejo.org/forgejo/runner/pulls/1249
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10642
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: John Moon <john.moon@vts-i.com>
Co-committed-by: John Moon <john.moon@vts-i.com>
This pull request escapes the dash before the author when a Discord webhook is triggered by a push event and formats the commit hash as code.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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)).
No tests were added, but the existing test for Discord webhooks passed.
### 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10626
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Valentine Briese <valentinegb@icloud.com>
Co-committed-by: Valentine Briese <valentinegb@icloud.com>
Follow-up to #10525; adds support for `jobs.<job_id>.secrets` to expanded reusable workflows (when no `runs-on` is specified in a job that `uses: ...` another workflow).
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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)).
- **end-to-end testing**: [prepared, PR n](https://code.forgejo.org/forgejo/end-to-end/pulls/1351)
### 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.
- [ ] Doc to be created
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10627
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
`build-release.yml` attempts to run an end-to-end check with a cascading PR, but it doesn't target the currently building branch. When two releases build simultaneously (eg. `forgejo/v14.0` and `forgejo`), whichever one starts the end-to-end test first is then "cancelled" by the second one as it pushes an update to the same branch.
This will be a bit of an experimental change due to the difficulty in setting up a test environment. After merge, I intend to watch a v14 and forgejo build and verify that they are independent, and, that both are actually tested with the correct target build.
This introduces a need to backport any changes to `.forgejo/cascading-release-end-to-end` in the future to maintain cascading functionality in all active releases.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10632
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
When new content is added via JS and htmx is not used for this change,
htmx need to be informed that DOM changes happened and that it needs to
reprocess the DOM (or at least the changed parts).
When a diff is really large, it is hidden by default. The user can press
a button to load the diff, which then will be added via JS.
The diff contains buttons to expand it, which are using htmx behind the
scenes. Therefore a reprocessing via htmx needs to be triggered after
adding the large diff.
Fixes#10570
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10572
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
This is a followup to !10524.
In addition I changed that the tooltip triggers for the whole height, instead for only the bar height, because otherwise it is esp for small bars nearly impossible to get the tooltip to open.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10556
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
Follow-up to #10525; adds support for `on.workflow_call.inputs` to expanded reusable workflows (when no `runs-on` is specified in a job that `uses: ...` another workflow).
The majority of the work for this is done by the `jobparser` library which evaluates inputs automatically when the job is being parsed and stores those inputs on the expanded jobs as the "default" value in `on.workflow_call.inputs`. Forgejo's role here is just to to ensure that `forgejo.event_name` is set to `"workflow_call"` when a job is dispatched, which causes the runner to use the inputs that are stored -- 34c20aa50f/act/runner/expression.go (L452-L467).
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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)).
- **end-to-end testing**: https://code.forgejo.org/forgejo/end-to-end/pulls/1323
### 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.
- https://codeberg.org/forgejo/docs/pulls/1664
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10614): <!--number 10614 --><!--line 0 --><!--description c3VwcG9ydCB3b3JrZmxvdyBpbnB1dHMgb24gZXhwYW5kZWQgcmV1c2FibGUgd29ya2Zsb3dz-->support workflow inputs on expanded reusable workflows<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10614
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#2705.
Fixes#7635.
This PR fixes the commit graph showing false connections for orphan/root commits. Connection lines are now shown only when a parent/child relationship exists. Visible relationships are determined using `git log`'s `%P` output by the new `ComputeGlyphConnectivity` function. The SVG template is adapted to render vertical lines conditionally.
Unit tests for `ComputeGlyphConnectivity` cover regular linear commit history, orphan commits, merge commits, and non-commit glyphs (`|`, `/`, `\`). Unit tests also cover the changes to the `git log` parsing. The SVG template was verified manually.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10484
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Bram Hagens <bram@bramh.me>
Co-committed-by: Bram Hagens <bram@bramh.me>
Changes foreign key database inconsistency handling so that inconsistent records are automatically deleted with an administrator warning during migration. As noted in discussion: https://codeberg.org/forgejo/discussions/issues/385#issuecomment-9175566
Intended for backport to v14 to eliminate pain during upgrades.
Because these migrations are now deleting data, rather than allowing the administrator to do it, all migrations have been covered with an integration test that verifies expected data is deleted. This is particularly interesting with nullable fields.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10568
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Permits the Forgejo to return multiple tasks to the Runner in one API call, if requested. Fixes#8917.
Related runner PR: https://code.forgejo.org/forgejo/runner/pulls/1245
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10602
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Follow-up to #10525; adds support for `on.workflow_call.outputs` to expanded reusable workflows (when no `runs-on` is specified on a job that `uses: ...` another workflow). When all the inner jobs of a workflow call complete, `on.workflow_call.outputs` is evaluated and the related outputs are stored on the outer job's `ActionTask`.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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)).
- **end-to-end testing**: https://code.forgejo.org/forgejo/end-to-end/pulls/1322
### 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.
- https://codeberg.org/forgejo/docs/pulls/1661
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10578): <!--number 10578 --><!--line 0 --><!--description c3VwcG9ydCB3b3JrZmxvdyBvdXRwdXRzIG9uIGV4cGFuZGVkIHJldXNhYmxlIHdvcmtmbG93cw==-->support workflow outputs on expanded reusable workflows<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10578
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This commit changes the commit link rendering (link to a single commit,
a diff, a PR, etc):
1. If it is a link to something on the local instance:
1.1. If it is to the same org and repo, the link is just e.g. the
commit hash
1.2. If it is to another repo, the link is the org/repo/commit hash
2. If the link is to another instance:
The link is the domain/optional sub path/org/repo/commit hash
This change is made to keep the link as short as possible, while not
hiding that the link may go to an external instance.
Followup to !9146Closes#10241
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10530
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Cleans up diagnostic output added in #10586.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10591
Reviewed-by: floss4good <floss4good@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Fixes#10589.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10594
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
API call `GET /repos/{owner}/{repo}/issues/{index}/times` has no defined ordering implemented in it, causing PostgreSQL to have intermittent test failures on `TestAPIGetTrackedTimes` which expected records to be returned in ID order. ID order is reasonable enough, so this PR adds that ordering.
Fixes#10577.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10588
Reviewed-by: Cyborus <cyborus@disroot.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Intermittent test failure ([example](https://codeberg.org/forgejo/forgejo/actions/runs/125874/jobs/9/attempt/1)):
```
=== TestAdminViewRepos (tests/test_utils.go:327)
--- FAIL: TestAdminViewRepos (0.39s)
testlogger.go:411: 2025/12/26 15:21:27 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /workspace/forgejo/forgejo/tests/gitea-lfs-meta
testlogger.go:411: 2025/12/26 15:21:27 ...eb/routing/logger.go:102:func1() [I] router: completed POST /user/login for test-mock:12345, 303 See Other in 4.7ms @ auth/auth.go:178(auth.SignInPost)
testlogger.go:411: 2025/12/26 15:21:27 ...eb/routing/logger.go:102:func1() [I] router: completed GET /admin/repos for test-mock:12345, 200 OK in 75.1ms @ admin/repos.go:29(admin.Repos)
admin_repo_test.go:29:
Error Trace: /workspace/forgejo/forgejo/tests/integration/admin_repo_test.go:29
Error: Not equal:
expected: 1
actual : 0
Test: TestAdminViewRepos
admin_repo_test.go:30:
Error Trace: /workspace/forgejo/forgejo/tests/integration/admin_repo_test.go:30
Error: Not equal:
expected: "repo49"
actual : ""
Diff:
--- Expected
+++ Actual
@@ -1 +1 @@
-repo49
+
Test: TestAdminViewRepos
```
Cause: the page is displaying 50 out of 65 repos in the fixture with a default sort of "recently updated"; on PostgreSQL that is occasionally causing the target link not to appear on the first page. As a fix, I've switched the test to load with reverse alphabetical order which should cause it to consistently appear on the first page.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10587
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Second pass at fixing the issue documented in #10583, as it contains to fail: https://codeberg.org/forgejo-integration/forgejo/actions/runs/14694/jobs/0/attempt/1#jobstep-13-7. Hoping that it is failing because RUNNER_TEMP is different than expected in the LXC environment, but additional `git` output commands should clarify the issue if this doesn't work.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10586
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Align the URLs of admin API endpoints for runner management with other levels like organizations. It enables using the same URL schema (`/actions/runners`) for managing all kinds of runners. The old API endpoints that use `/admin/runners` have been deprecated but are retained for compatibility reasons for the foreseeable future.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Other changes without a feature or bug label
- [PR](https://codeberg.org/forgejo/forgejo/pulls/10573): <!--number 10573 --><!--line 0 --><!--description cmVmYWN0b3I6IHVwZGF0ZSBBY3Rpb25zIFJ1bm5lciBhZG1pbiBBUEkgZW5kcG9pbnQgVVJMcyB0byBiZSBjb25zaXN0ZW50IHcvIG90aGVyIGxldmVscw==-->refactor: update Actions Runner admin API endpoint URLs to be consistent w/ other levels<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10573
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Previously, Forgejo's behaviour for an Actions reusable workflow was to send the entire job to one specific Forgejo Runner based upon its required `runs-on` label, and that single Runner would then read the workflow file and perform all the jobs inside simultaneously, merging their log output into one output (#9768).
This PR begins an implementation of expanding reusable workflows into their internal jobs.
In this PR, the most basic support is implemented for expanding reusable workflows:
- If a `runs-on` field is provided on the workflow, then the legacy behaviour of sending the reusable workflow to a runner is maintained.
- If the `runs-on` field is omitted, then the job may be expanded, if:
- If the `uses:` is a local path within the repo -- expanded
- If the `uses:` is a path to another repo that is on the same Forgejo server -- expanded
- If the `uses:` is a fully-qualified URL -- not expanded
Because this is an "opt-in" implementation by omitting `runs-on`, and all existing capability is retained, I've **omitted some features** from this PR to make the scope small and manageable for review and testing. These features will be implemented after the initial support is landed:
- Workflow input variables
- Workflow secrets
- Workflow output variables
- "Incomplete" workflows which require multiple passes to evaluate -- any job within a reusable workflow where the `with`, `runs-on`, or `strategy.matrix` fields contain an output from another job with `${{ needs... }}`
Although this implementation has restrictions with missing features, it is intended to fix#9768.
Replaces PR #10448.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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)).
- end-to-end testing: https://code.forgejo.org/forgejo/end-to-end/pulls/1316
### 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.
- https://codeberg.org/forgejo/docs/pulls/1648
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10525
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Raise the default value for LimitDispatchInputs from 10 to 100.
100 should be plenty while offering some protection against excessively large inputs. Note that the limit only applies to the number of submitted inputs, not the total number of inputs defined in a workflow.
See https://codeberg.org/forgejo/forgejo/pulls/10368 for background and motivation.
The change also prevents the dispatch menu in the UI from becoming too large.
Before:
Afterwards (scrollbars are invisible, unfortunately):
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10563
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Closes#10534
The primary code change is that `TestMissingTranslationHandling` was converted to a unit test.
However translation unit tests were a mix of mostly unrelated old (INI) and new (JSON) code with unclear licensing. It was cleaned up with help of Git history.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10539
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Minor code cleanup for code/issue search.
Mostly breaking up the common functionality into separate functions :)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10549
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
- Follow up of forgejo/forgejo!5041, forgejo/forgejo!6074, forgejo/forgejo!8692, forgejo/forgejo!9923
- The `webhook` table contains a encrypted header authorization.
- Use `keying` to safely store this secret and bound them to the table, column and row id
- The migration isn't spectacular but does closely follow what we learned in the previous three migrations: use a transaction and delete records when you can't decrypt them.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10059
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
The aria-label now changes dynamically depending on whether
the monospace font is enabled or disabled.
Greetings from GPN :)
Fixes#7669.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8244
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: JohnnyJayJay <johnny@leftfold.tech>
Co-committed-by: JohnnyJayJay <johnny@leftfold.tech>
Previously searching for posters would use full name or username depending on the `[ui].DEFAULT_SHOW_FULL_NAME` setting, now it searches for both of them regardless of the setting.
This also a fixes a bug when `[ui].DEFAULT_SHOW_FULL_NAME=true` that users without a full name where not able to searched for.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10394
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: BtbN <btbn@btbn.de>
Co-committed-by: BtbN <btbn@btbn.de>
The timeline event for a dismissed review didn't used the `AvatarUtils` until now. The `AvatarUtils` also adds classes to the img tag, which makes sure the avatar is correctly styled and not stretched.
This PR replaces the img tag with the expected call to the `AvatarUtils`.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10524
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Continuing refactor work to split functionality out of `RepoActionView` and into more testable, more manageable sub-components. #9768 will eventually result in some updates to this view for new functionality, and before more complexity is added I'd like to clean it up to a more maintainable state.
Previous refactor step: #10366
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10537
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Recognize commit hashes if they have leading or trailing punctuation, `ccc33dd2dfcd8e9d81c7e91f74acf92114a61ea0...` will not be recognized properly. The restriction of two punctuation characters on either side has been lifted.
Resolves#8602
Co-Authored-By: Beowulf <beowulf@beocode.eu>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8643
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: James Anderson <james@jamesa.me>
Co-committed-by: James Anderson <james@jamesa.me>
In https://codeberg.org/forgejo/forgejo/pulls/9409, REST API endpoints were added to manage runners. The REST API endpoints were modelled after GitHub's REST API. That comes at the cost of introducing methods and fields that Forgejo does not and is unlikely to support in the future, like label IDs or label types. But Forgejo would have to maintain them for a very long time.
The introduced endpoints have been revised and aligned with existing Forgejo REST API endpoints:
* POST for `/registration-token` has been removed because it was only an alias of GET.
* `/runners` returns a list of `ActionRunner` instead of a wrapper object. `total_count` was replaced with the header `x-total-count` that is used throughout Forgejo.
* `status` in `ActionRunner` was converted to an enum that is documented.
* `busy` in `ActionRunner` was combined with `status`. A single enum is easier to extend and consume.
* `labels` in `ActionRunner` was converted to a list of strings to match existing Forgejo REST API endpoints.
* `ephemeral` has been removed from `ActionRunner` because ephemeral runners have not been merged, yet.
* `ActionRunner` received a number of new fields: `uuid`, `version`, `description`, `owner_id`, and `repo_id`.
In addition to those structural changes, the test coverage was enhanced and the API documentation polished.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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
- 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 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
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10450
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Change that the Cancel button is shown until all jobs are finished and do not hide it, when the first job failed.
Additionally the wrapping of the header was changed.
| Before | After |
| :--: | :----: |
|  |  |
Fixes#8922
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9261
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
This is for preventing that a markdown button is recognized as button for submission in a html form.
Buttons can't be stripped from the markdown due to: https://codeberg.org/forgejo/forgejo/pulls/7670#issuecomment-4086608
There is no issue with buttons if they always have `type="button"`, so this should be fine.
This is a "follow-up" to !7670.
Fixes#7656
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10520
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
Fixes#4712Fixes#7783
When filtering issues or PRs by "Recently updated" or "Least recently updated", the last updated time is shown.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10488
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Bram Hagens <bram@bramh.me>
Co-committed-by: Bram Hagens <bram@bramh.me>
Ensures that admins, users, etc. see the runners they are allowed to see.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10490
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
The forgejo admin command line allows to deal with all the propose auth mecanism but pam, this PR adds full support for adding and updating pam auth mecanism via the command line without limitation.
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10388
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Baptiste Daroussin <bapt@FreeBSD.org>
Co-committed-by: Baptiste Daroussin <bapt@FreeBSD.org>
- Please speak English, as this is the language all maintainers can speak and write.
- Be civil, and follow the [Forgejo Code of Conduct](https://codeberg.org/forgejo/code-of-conduct).
- Take a moment to [check if a similar problem has already been discussed in the past.](https://codeberg.org/forgejo/forgejo/issues?q=&type=all&labels=78137). Feel free to add your own experience there, if applicable.
- We are currently experimenting with a new workflow to understand your problems and requests. Please try to focus on explaining the problem you are facing, which could be a bug in the code, a moment of confusion, or a missing feature. We'll think about solutions to the problem at a later step. If you want to learn more about the background of our workflow, feel invited to read and participate in [the discussion that led to the current approach](https://codeberg.org/forgejo/discussions/issues/415). We are looking forward to your feedback.
- type:markdown
attributes:
value:|
### New workflow
We are currently experimenting with a new workflow to manage issues and better understand your problems and needs. This is step 1 of the workflow:Please try to focus on explaining the problem you are facing, which could be a bug in the code, a moment of confusion, or a need that you have.
We do not expect anything from Forgejo users after creating a problem report, but we appreciate if you stay responsive to further questions. If you want, you can also participate in a discussion for solutions.
Forgejo contributors will review your report, try to understand how important it is to you and other Forgejo users, and suggest potential solutions. In a next step, solutions can be documented and implemented.
If you want to learn more about the background of our workflow, feel invited to read and participate in [the discussion that led to the current approach](https://codeberg.org/forgejo/discussions/issues/415). We are looking forward to your feedback.
- type:dropdown
id:can-reproduce
attributes:
@ -30,15 +41,18 @@ body:
- type:textarea
id:environment
attributes:
label:Your usage of Forgejo
label:About your usage of Forgejo
description:|
Please provide a description of your usage of Forgejo. To better understand your problem, it will be relevant to know in which environment you use Forgejo and if you have performed specific configuration.
Please provide a brief description of your usage of Forgejo. There is no clear guideline on how much you need to share here. You can be brief, but we value the insights you provide us to better understand your use case. Thank you very much!
<details><summary>Further instructions</summary>
*If you report a bug with a certain functionality, it will be relevant to learn about related configuration ("This is how I configured my identity provider", "This is how my Forgejo Actions runner is set up").
*Please elaborate on your personal relation to Forgejo and user role ("I'm new to Forgejo, but used a comparable product called …", "In my role as a designer, …").
*If you feel that Forgejo needs a change in functionality, please describe in which environment you want to use it, so that we can understand for which audience the complexity needs to appeal to ("We're a group of friends with no technical / professional background and use a personal Forgejo instance to prepare our first libre game").
*If you already explained your usage of Forgejo elsewhere (e.g. in another issue or in a user research repository), you can put a link here.
*When reporting problems with certain functionality, you should include related information. Examples:
*When reporting an issue with setting up an identity provider, it is useful to know if you use Forgejo in a 10-users non-profit / start up, or if you are talking about a school / university with several thousands of users.
*When describing confusion, it will be relevant to know your skill level and background ("New, but used a similar product", "In my role as a project manager ..."), so we know for which target audience we need to design the functionality.
*When reporting workflow issues or needs, it will be useful to know how large your project is, how many team members you have, which skill level we are talking about etc. For example, we might choose a different design depending on whether a feature is only for professional developers or for hobby coders.
*If you want, we always appreciate generic information about your Forgejo usage to help us understand your usage and make better decisions. For example:
*Your personal relation to Forgejo and user role ("I'm new to Forgejo, but used a comparable product called …", "In my role as a designer, …").
*If you already explained your usage of Forgejo elsewhere (e.g. in another issue or in a user research repository), feel free to just drop a link.
</details>
validations:
@ -48,7 +62,7 @@ body:
attributes:
label:Problem description
description:|
Please describe your problem as a first-hand experience. Try to focus on the problem. Finding a solution will happen in a next step.
Please describe your problem as a first-hand experience. Try to focus on the problem. You do not have to find a solution, you can leave this to us.
<details><summary>Further instructions</summary>
*Start by explaining what you want to achieve ("I wanted to find an issue to work on").
@ -75,7 +89,7 @@ body:
id:forgejo-ver
attributes:
label:Forgejo Version
description:Forgejo version (or commit reference) your instance is running
description:Forgejo version (or commit reference) your instance is running or that you used to reproduce the bug on Forgejo Next.
- type:textarea
id:versions
attributes:
@ -84,3 +98,10 @@ body:
Please include details to help us understand your problem:browser engine and version (for UI issues), operating system and version running Forgejo, database engine and version, deployment methods and relevant third-party packages (e.g. renderers, identity providers)
validations:
required:true
- type:markdown
attributes:
value:|
### Solutions
*Acceptedsolutions to address this problem will go here*
description:Suggest a solution to one or multiple problems that have already been reported (see step 1).
description:"[Advanced users only] Suggest a solution to one or multiple problems that have already been reported (see step 1)."
title:"enh: "
labels:["enhancement/feature"]
body:
@ -8,19 +8,28 @@ body:
value:|
- Please speak English, as this is the language all maintainers can speak and write.
- Be civil, and follow the [Forgejo Code of Conduct](https://codeberg.org/forgejo/code-of-conduct).
- We are currently experimenting with a new workflow to understand your problems and requests. This is step 2 of a two-step-process. The goal is to discuss potential solutions to already-reported problems. If you want to learn more about the background of our workflow, feel invited to read and participate in [the discussion that led to the current approach](https://codeberg.org/forgejo/discussions/issues/415). We are looking forward to your feedback.
- type:markdown
attributes:
value:|
### New workflow
We are currently experimenting with a new workflow to manage issues and better understand your problems and needs. This is step 2 of the workflow, which is intended for Forgejo contributors:If you just want to raise a problem or need you have, please refer to step 1.
This step allows to document a solution to one or multiple problems. It allows developers to focus on actionable implementation tasks without the clutter of previous discussions or triaging work.
If you want to learn more about the background of our workflow, feel invited to read and participate in [the discussion that led to the current approach](https://codeberg.org/forgejo/discussions/issues/415). We are looking forward to your feedback.
- type:textarea
id:problems
attributes:
label:Existing problems this enhancement addresses
description:List the issue numbers of the reported problems that this enhancement addresses. If you haven't previously described a problem, please [complete step one of the workflow](https://codeberg.org/forgejo/forgejo/issues/new?template=.forgejo%2fissue_template%2fproblem.yaml) and describe the problem you'd like to solve first.
description:Only list the issue numbers of the **existing** problems that your proposal addresses. **Do not add new descriptions.** If you haven't previously described a problem, please [complete step one of the workflow](https://codeberg.org/forgejo/forgejo/issues/new?template=.forgejo%2fissue_template%2fproblem.yaml) and describe the problem you'd like to solve first.
validations:
required:true
- type:textarea
id:description
attributes:
label:Enhancement description
description:As concisely as possible, describe the changes you suggest for Forgejo and explain how they address the problems.
description:Describe the changes you suggest for Forgejo and explain how they address the problems.
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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).
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
### 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...
- [ ] `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)).
@ -28,6 +37,9 @@ The [contributor guide](https://forgejo.org/docs/next/contributor/) contains inf
### Release notes
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
- [ ] 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.
"dependencyDashboardHeader":"This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.\n- [ ] <!-- manual job -->Check this box to trigger a request for Renovate to run again on this repository\n",
xorm Sync operation may drop indices if used on an incomplete bean definition for an existing table. Use SyncWithOptions with IgnoreDropIndices:trueinstead.
;; LFS authentication secret, change this yourself
;LFS_JWT_SECRET =
;;
@ -417,8 +420,8 @@ DB_TYPE = sqlite3
;; Database connection max idle time, 0 prevents closing due to idle time.
;CONN_MAX_IDLETIME = 0
;;
;; Database maximum number of open connections, default is 100 which is the lowest default from Postgres (MariaDB + MySQL default to 151). Ensure you only increase the value if you configured your database server accordingly.
;MAX_OPEN_CONNS = 100
;; Database maximum number of open connections. Ensure you only increase the value if your database server is configured to handle the amount of open connections accordingly.
;; Private key file path used to sign OAuth2 tokens. The path is relative to APP_DATA_PATH.
;; This setting is only needed if JWT_SIGNING_ALGORITHM is set to RS256, RS384, RS512, ES256, ES384 or ES512.
;; The file must contain a RSA or ECDSA private key in the PKCS8 format. If no key exists a 4096 bit key will be created for you.
;; XXX jwt/ is a misnomer, it should rather be oauth2/, because we use many JWTs
;JWT_SIGNING_PRIVATE_KEY_FILE = jwt/private.pem
;;
;; OAuth2 authentication secret for access and refresh tokens, change this yourself to a unique string. CLI generate option is helpful in this case. https://forgejo.org/docs/latest/admin/command-line/#generate-secret
;; Add co-authored-by and co-committed-by trailers if committer does not match author
;ADD_CO_COMMITTER_TRAILERS = true
;;
;; Retarget child pull requests to the parent pull request branch target on merge of parent pull request. It only works on merged PRs where the head and base branch target the same repo.
;RETARGET_CHILDREN_ON_MERGE = true
@ -1561,15 +1562,17 @@ LEVEL = Info
;DEFAULT_EMAIL_NOTIFICATIONS = enabled
;; Send an email to all admins when a new user signs up to inform the admins about this act. Options: true, false
;SEND_NOTIFICATION_EMAIL_ON_NEW_USER = false
;; Disabled features for users, could be "deletion", "manage_ssh_keys","manage_gpg_keys" more features can be disabled in future
;; Disabled features for users, could be "deletion", "manage_ssh_keys","manage_gpg_keys", "manage_password" more features can be disabled in future
;; - deletion: a user cannot delete their own account
;; - manage_ssh_keys: a user cannot configure ssh keys
;; - manage_gpg_keys: a user cannot configure gpg keys
;; - manage_password: a user cannot configure their password
;USER_DISABLED_FEATURES =
;; Comma separated list of disabled features ONLY if the user has an external login type (eg. LDAP, Oauth, etc.), could be `deletion`, `manage_ssh_keys`, `manage_gpg_keys`. This setting is independent from `USER_DISABLED_FEATURES` and supplements its behavior.
;; Comma separated list of disabled features ONLY if the user has an external login type (eg. LDAP, Oauth, etc.), could be `deletion`, `manage_ssh_keys`, `manage_gpg_keys`, `manage_password`. This setting is independent from `USER_DISABLED_FEATURES` and supplements its behavior.
;; - deletion: a user cannot delete their own account
;; - manage_ssh_keys: a user cannot configure ssh keys
;; - manage_gpg_keys: a user cannot configure gpg keys
;; - manage_password: a user cannot configure their password
constaggregatedArtifactSelect="min(id) as id, run_id, artifact_name, sum(file_size) as file_size, max(status) as status, min(created_unix) as created_unix, max(updated_unix) as updated_unix, max(expired_unix) as expired_unix"
assert.Equal(t,1,subtle.ConstantTimeCompare([]byte(runner.TokenHash),[]byte(auth_model.HashToken(token,runner.TokenSalt))),"the token cannot be verified with the same method as routers/api/actions/runner/interceptor.go as of 8228751c55d6a4263f0fec2932ca16181c09c97d")
// performance relies on indexes on repo_id and status
iferr:=db.GetEngine(ctx).Where("repo_id=? AND pull_request_poster_id=?",repoID,pullRequestPosterID).And(builder.In("status",[]Status{StatusUnknown,StatusWaiting,StatusRunning,StatusBlocked})).Find(&runs);err!=nil{
iferr:=db.GetEngine(ctx).Where("repo_id=? AND pull_request_poster_id=?",repoID,pullRequestPosterID).And(builder.In("status",PendingStatuses())).Find(&runs);err!=nil{
returnnil,err
}
returnruns,nil
@ -280,7 +356,7 @@ func GetRunsNotDoneByRepoIDAndPullRequestPosterID(ctx context.Context, repoID, p
// performance relies on indexes on repo_id and status
iferr:=db.GetEngine(ctx).Where("repo_id=? AND pull_request_id=?",repoID,pullRequestID).And(builder.In("status",[]Status{StatusUnknown,StatusWaiting,StatusRunning,StatusBlocked})).Find(&runs);err!=nil{
iferr:=db.GetEngine(ctx).Where("repo_id=? AND pull_request_id=?",repoID,pullRequestID).And(builder.In("status",PendingStatuses())).Find(&runs);err!=nil{
