a0be0f22fc34a20e90797dada527c19cd2e1eaf1
46
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
a0be0f22fc | chore: rename 'migrations' to 'gitea_migrations' | ||
|
|
82ad5189fe |
feat: add foreign keys to the access table (#9557)
Adds two foreign keys:
- `access.user_id` -> `user`
- `access.repo_id` -> `repository`
Testing:
- Existing automated test suite
- Minor adjustments required to `reverseproxy_test.go`
- Test failures caused a reorganization of delete operations in `DeleteRepositoryDirectly`
- Manually tested
- On "user" and "repo" Collaborator page, added, removed, and changed the access-level of collaborators
## 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.
- [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/9557): <!--number 9557 --><!--line 0 --><!--description YWRkIGZvcmVpZ24ga2V5cyB0byB0aGUgYGFjY2Vzc2AgdGFibGU=-->add foreign keys to the `access` table<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9557
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
|
||
|
|
906e2e7c4a |
fix: false error logging "Render JSON failed" from workflow dispatch via API (#9675)
When making a `POST` to start a workflow dispatch, and not specifying the option `"return_run_info": true`, the API handler attempts to render a `nil` as a JSON body to a `204 No Content` response. This results in an error being logged to the console, as this status code does not permit a body. ``` Render JSON failed: http: request method or response status code does not allow body ``` There is no functional impact except for a false error log, as `ctx.JSON` just logs a `Render JSON failed` error if it fails. I could not find any existing code which allows integration tests to intercept or inspect log output, which would be required for an automated test verifying this is fixed. If anyone could advise an existing test that performs log interception, or any hints on how such a mechanism would be created, I don't mind adding it... but it may not be warranted for such a tiny bug either. ## 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. - [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/9675 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
78d92aafd7 |
feat: strip EXIF information from uploaded avatars (#9638)
Strips EXIF information from uploaded avatars (excluding the orientation tag), affecting both user & repo avatars. Adds a new subcommand `forgejo admin avatar-strip-exif` to perform a retroactive update of avatar files. Fixes #9608. ## 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. - [ ] 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/9638): <!--number 9638 --><!--line 0 --><!--description VXBsb2FkZWQgYXZhdGFyIGltYWdlcyBjYW4gc29tZXRpbWVzIGNvbnRhaW4gdW5leHBlY3RlZCBtZXRhZGF0YSBzdWNoIGFzIHRoZSBsb2NhdGlvbiB3aGVyZSB0aGUgaW1hZ2Ugd2FzIGNyZWF0ZWQsIG9yIHRoZSBkZXZpY2UgdGhlIGltYWdlIHdhcyBjcmVhdGVkIHdpdGgsIHN0b3JlZCBpbiBhIGZvcm1hdCBjYWxsZWQgRVhJRi4gRm9yZ2VqbyBub3cgcmVtb3ZlcyBFWElGIGRhdGEgd2hlbiBjdXN0b20gdXNlciBhbmQgcmVwb3NpdG9yeSBpbWFnZXMgYXJlIHVwbG9hZGVkIGluIG9yZGVyIHRvIHJlZHVjZSB0aGUgcmlzayBvZiBwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBpbmZvcm1hdGlvbiBiZWluZyBsZWFrZWQgdW5leHBlY3RlZGx5LiBBIG5ldyBDTEkgc3ViY29tbWFuZCBgZm9yZ2VqbyBkb2N0b3IgYXZhdGFyLXN0cmlwLWV4aWZgIGNhbiBiZSB1c2VkIHRvIHN0cmlwIEVYSUYgaW5mb3JtYXRpb24gZnJvbSBhbGwgZXhpc3RpbmcgYXZhdGFyczsgd2UgcmVjb21tZW5kIHRoYXQgYWRtaW5pc3RyYXRvcnMgcnVuIHRoaXMgY29tbWFuZCBvbmNlIGFmdGVyIHVwZ3JhZGUgaW4gb3JkZXIgdG8gbWluaW1pemUgdGhpcyByaXNrIGZvciBleGlzdGluZyBzdG9yZWQgZmlsZXMu-->Uploaded avatar images can sometimes contain unexpected metadata such as the location where the image was created, or the device the image was created with, stored in a format called EXIF. Forgejo now removes EXIF data when custom user and repository images are uploaded in order to reduce the risk of personally identifiable information being leaked unexpectedly. A new CLI subcommand `forgejo doctor avatar-strip-exif` can be used to strip EXIF information from all existing avatars; we recommend that administrators run this command once after upgrade in order to minimize this risk for existing stored files.<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9638 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
92684b6208 |
chore(e2e): test flakiness in issue-comment-dropzone.test.e2e.ts (#9660)
Flaky e2e test failure:
```
1) [Mobile Chrome] › tests/e2e/issue-comment-dropzone.test.e2e.ts:74:1 › Re-add images to dropzone on edit
Error: expect(locator).toHaveCount(expected) failed
Locator: locator('.dropzone').locator('.dz-preview')
Expected: 1
Received: 0
Timeout: 3000ms
Call log:
- Expect "toHaveCount" with timeout 3000ms
- waiting for locator('.dropzone').locator('.dz-preview')
7 × locator resolved to 0 elements
- unexpected value "0"
87 | await expect(dropzone.locator('.files').first()).toHaveCount(1);
88 | const preview = dropzone.locator('.dz-preview');
> 89 | await expect(preview).toHaveCount(1);
| ^
90 | await expect(preview.locator('.dz-filename')).toHaveText('foo.png');
91 | await expect(preview.locator('.octicon-copy')).toBeVisible();
92 | await assertCopy(page, workerInfo, ';
at /workspace/forgejo/forgejo/tests/e2e/issue-comment-dropzone.test.e2e.ts:89:25
```
Observed on chromium and Mobile Chrome.
I haven't been able to reproduce this test failure in local testing, but in examining the playwright test artifacts I noted that the browser is getting a `404 Not Found` error attempting to load a URL `(test server url)/uploading...` (where `...` is literally present in the URL). My theory is that the test is firing the paste event in `pasteImage` and not waiting for the XMLHttpRequest to complete the upload, and then saving the issue comment with the placeholder URL `uploading...` in the Markdown, causing a later failure. This patch adds two `waitForResponse` calls -- one when pasting the image to wait for the upload to complete, and one which is probably redundant which waits for the `/attachments` GET while editing the comment.
If this test continues to be flaky, it may at least have a different error revealing more about its cause.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9660
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
|
||
|
|
a80f8f9d01 |
chore(e2e): test flakiness in webauthn.test.e2e.ts (#9662)
Test failure:
```
1) [chromium] › tests/e2e/webauthn.test.e2e.ts:14:1 › WebAuthn register & login flow ─────────────
Error: page.goto: Navigation to "http://localhost:3003/user/login" is interrupted by another navigation to "http://localhost:3003/"
Call log:
- navigating to "http://localhost:3003/user/login", waiting until "load"
46 |
47 | // Login.
> 48 | response = await page.goto('/user/login');
| ^
49 | expect(response?.status()).toBe(200);
50 |
51 | await page.getByLabel('Username or email address').fill(username);
at /workspace/forgejo/forgejo/tests/e2e/webauthn.test.e2e.ts:48:25
```
I have not been able to reproduce this locally.
What seems to be happening is that the current code is clicking the "Sign out" menu option, and then while the browser is busy (navigating to `/logout`, redirecting to `/`), the test attempts to navigate directly to `/user/login`. The two navigations are racey, depending on how fast they work they may result in this error. The proposed fix is to wait for the sign-out operation to complete by waiting for the URL to land on `/`, before then proceeding with the rest of the test with the second login.
Normally this would be *just* a `waitForURL` call. But because of the redirect on logout, I've encountered the below error if the code is just invoking `waitForURL`. So I put the `waitForURL` invocation into an `expect(...).toPass()`. This isn't technically the correct usage of `toPass` which is intended for *assertions* which will eventually become successful, whereas this is attempting to retry a wait... but... a wait shouldn't need a retry. (I'd argue this is a Playwright bug.)
```
Error: page.waitForURL: net::ERR_ABORTED; maybe frame was detached?
```
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9662
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
|
||
|
|
79f6f8e508 |
fix: db.Iterate can miss records, can return records twice (#9657)
Fixes #9644. Rewrites `db.Iterate` so that it performs DB queries in this format: - First: `SELECT ...columns... FROM table ORDER BY id LIMIT ...buffer-size...` - Subsequent buffer fills: adding a `WHERE id > ...last-id-from-previous...` This approach: - Prevents records from being missed or returned twice - Returns records in a predictable order - Should be faster, by virtue of using database indexes on the primary key to perform the query - Doesn't rely on any unpredictable database behaviour when using `LIMIT` and `OFFSET` without an `ORDER BY` - (Downside: does require reflection to read field values off Go structures for the primary key value) Expands the automated tests to include the predicted failure case identified in #9644, which verified the previous broken behaviour, as well as verifying that the `cond` parameter is applied which was previously not covered by test automation. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9657 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
68bf916acd |
fix!: detect extra cmdline args and emit errors (#9458)
Fixes #9433. ``` $ ./gitea admin user create --username blah --must-change-password false Hint: boolean false must be specified as a single arg, eg. '--restricted=false', not '--restricted false' Command error: unexpected arguments: false ``` **Breaking**: CLI sub-commands that only have flags would previously ignore anything that might be considered an "extra" argument, and would proceed without any errors. I've manually tested this change on the single `admin user create` command with positive (ensuring cmd still works) and negative (ensuring errors are reported) test cases. I've attempted to ensure the change is applied only to commands which don't use the CLI `Args()` and avoided touching them, including: - `admin user must-change-password` takes a list of users - `doctor recreate-tables` takes a list of tables - `embedded [list/view/extract]` use a pattern of resources to operate upon - git repo hook subcommands, and the ssh serv command, use arguments and have been omitted from the 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... - [ ] 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. - [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. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9458 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
0a02ffd355 |
feat(email): reference the commit closing the issue (#9522)
Preview-on: https://codeberg.org/attachments/0016d106-0353-43d2-953e-4f2ae1a0d166 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9522 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Reviewed-by: 0ko <0ko@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
02ea77c6a0 | display pre-execution errors in action view UI | ||
|
|
25ba696b6a | don't execute workflows when event parsing fails; create a pre-execution error instead | ||
|
|
152b98da90 | save pre-execution errors to the DB when workflow execution is prevented by user data | ||
|
|
c434b963b4 |
feat: implement "concurrency" block in Forgejo Actions at the workflow level (#9434)
Currently references a pre-release version of `code.forgejo.org/forgejo/runner/v11`, pending release of https://code.forgejo.org/forgejo/runner/pulls/1026. Fixes #5914. This PR is quite large, but it can be reviewed commit-by-commit in relatively small, logical chunks. Adds support for workflows with a `concurrency` block, and submembers `group` and `cancel-in-progress`. For example: ``` on: workflow_dispatch: jobs: rust-checks: runs-on: debian-latest steps: - run: sleep 300 concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: false ``` The concurrency block effectively ends up with four supported behaviors that users will want to choose from: - Backwards compatibility / default -- if omitted completely, the existing Forgejo behavior will be implemented. That behavior is that push and pull request synchronize events will cancel all previous runs on the same repository, branch, and workflow. - Unlimited concurrency -- if the `cancel-in-progress` value is set to `false` and no `group` is provided, then the previously described Forgejo behavior will be disabled and an unlimited number of workflows can be executed simultaneously (to the maximum supported by the Forgejo Runner capacity). - Queue-behind -- if a `group` is provided and `cancel-in-progress: false` is set, then every new action run with in the same repository with the same group value will be queued behind previous workflow runs, allowing only one workflow to execute at a time in the group, but allowing all workflows to finish naturally. - Cancel-in-progress -- if a `group` is provided and `cancel-in-progress: true` is set, then every new action run with in the same repository with the same group value will cause previously queued or running runs to be cancelled, allowing only one workflow to execute at a time in the group, but preferring execution of the most recent workflow. Both the `group` and `cancel-in-progress` values can access values from the `github`, `inputs` and `vars` context for dynamic behavior. ## 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. - https://codeberg.org/forgejo/docs/pulls/1513 - [ ] 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/9434): <!--number 9434 --><!--line 0 --><!--description aW1wbGVtZW50ICJjb25jdXJyZW5jeSIgYmxvY2sgaW4gRm9yZ2VqbyBBY3Rpb25zIGF0IHRoZSB3b3JrZmxvdyBsZXZlbA==-->implement "concurrency" block in Forgejo Actions at the workflow level<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9434 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
dcd431b0d4 |
fix: ensure deleted Debian package does not remain referenced in the apt repository files (#9386)
Introduces a new `Notifier` which listens for `PackageDelete` events and triggers a rebuild of the `Packages` & `Release` files which are stored in the debian package repository. Fixes #9369. ## 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/9386 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
187ad99f3c |
feat: add foreign keys to stopwatch & tracked_time tables (#9373)
Adds four foreign keys: - stopwatch -- issue_id -> issue, user_id -> user - tracked_time -- issue_id -> issue, user_id -> user The majority of work encompassed in this PR is updating testing and support infrastructure to support foreign keys: - `models/db/foreign_keys.go` adds new capabilities to sort registered tables into the right insertion order to avoid violating foreign keys - `RecreateTables`, used by migration testing and the `doctor recreate-table` CLI, has been updated to support tables with foreign keys; new restrictions require that FK-related tables be rebuilt at the same time - test fixture data is inserted in foreign-key order, and deleted in the reverse An upgrade to xorm v1.3.9-forgejo.2 is incorporated in this PR, as two unexpected behaviors in the foreign key schema management were discovered during development of the updated `RecreateTables` routine. Work in this PR is laid out to be reviewed easier commit-by-commit. ## 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. - [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. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9373 Reviewed-by: Earl Warren <earl-warren@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> |
||
|
|
0b923a03b4 |
test: fix 'Missing required prop' warning during RepoActionView frontend tests (#9454)
Fixes warnings in the `RepoActionView.test.js`, introduced in #9444 but caused by the frontend tests not providing all required properties to the component. ``` stderr | web_src/js/components/RepoActionView.test.js > processes ##[group] and ##[endgroup] [Vue warn]: Missing required prop: "runIndex" at <RepoActionView jobIndex="1" attemptNumber="1" initialJobData= { state: { run: { status: 'success', commit: [Object] }, currentJob: { steps: [Array] } }, logs: { stepsLog: [] } } ... > at <VTUROOT> ``` ## 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/9454 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
2dd333f8fb |
docs: update example config docs for MAX_CREATION_LIMIT (#9376)
Follow-up to include information from https://codeberg.org/forgejo/docs/pulls/1501 into the app.example.ini file. ## 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 - [ ] 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/9376 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
ff84ab2014 |
chore: replace xorm v1.3.9 with v1.3.9-forgejo.1, preparation for foreign key additions (#9326)
Prepares for the addition of foreign keys to Forgejo tables by bringing xorm over to https://code.forgejo.org/xorm/xorm/releases/tag/v1.3.9-forgejo.1. ## 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/9326 Reviewed-by: Earl Warren <earl-warren@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> |
||
|
|
89e0323351 |
fix: respect UI DEFAULT_SHOW_FULL_NAME setting in email From: headers (#9307)
Changes email's `From` field to respect the server's `DEFAULT_SHOW_FULL_NAME` setting, bringing consistency between seeing an email from a user, opening the related issue, and seeing a different name in Forgejo's web UI. Manually tested by varying the `DEFAULT_SHOW_FULL_NAME` server property, enabling and disabling it:  Fixes #9149. ## 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)). - Performed manual testing with ### 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. - [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/9307 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
eb21dd17b8 |
fix: loading action logs on a task that isn't fetched yet, fails when the job is fetched (#9293)
Discovered a regression caused by #9017. Steps to reproduce: - Disable the forgejo-runner that will pick up a workflow - Trigger any workflow to run - Through the Actions list, click on the new workflow that is pending a runner to fetch it - You'll be redirected to /user/repo/actions/runs/73/jobs/0/attempt/0 (attempt = 0) - The UI will appear normal with the job "Waiting"... - Startup the forgejo-runner to pick up the workflow - The UI will begin to have errors: - JavaScript promise rejection: JSON.parse: unexpected keyword at line 1 column 1 of the JSON data. Open browser console to see more details. (5) The cause is that the redirect to `/attempt/0` occurs for a job that hasn't been started, but once the job is started attempt 0 is not a valid attempt and errors will occur when polling for data. This fix corrects the problem by redirecting to the attempt that will be present (attempt 1) when the job is fetched. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9293 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
512b3fad5b |
feat: support Markdown editor bold & italic keyboard shortcuts (#9110)
Ctrl/Cmd-B & Ctrl/Cmd-I are implemented in the markdown editor to allow bolding & italicizing of text. The shortcut defers to the toolbar for implementation, and so should have the exact same behavior as clicking B or I. Fixes #7549 (Partially addresses #3604) Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9110 Reviewed-by: 0ko <0ko@noreply.codeberg.org> Reviewed-by: Lucas <sclu1034@noreply.codeberg.org> Reviewed-by: Beowulf <beowulf@beocode.eu> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
e311aa7cae |
fix: action view 'Re-run all jobs' leaves UI on the last attempt, not the new attempt (#9172)
In #9017, the ability to view older logs of an action run was added. However, the 'Re-run all jobs' button was not updated in any way. When viewing the logs for attempt 1 and clicking 'Re-run all jobs', the UI would continue to show the logs for attempt 1. Before #9017 the behavior would have begun to view the logs from the re-run operation. There are two commits in this PR: - Update the `Rerun` view handler so that it redirects the user to the next attempt number for the job. - The next attempt number isn't actually persisted to the DB until the rerun is picked up from a worker. By pure coincidence, viewing an out-of-range attempt number was fully functional because it also happened to be viewing a job that wasn't picked up by a worker, and fell into those code paths. However, as there were no automated tests around this codepath and it felt fragile, new tests have been added around the template render, backend data fetch, and frontend UI component, to ensure it continues to work in this corner-case 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 - 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... - [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. (_Note_: This is a fix for an unreleased regression, no need for 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/9172 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
a082555c04 |
fix: prevent initial 'blank' display of action logs view, remove unnecessary API calls (#9099)
When you access Actions logs, there is a momentary render of a partially blank screen such as this:  This is caused by the `RepoActionView` Vue component having no data. It then performs a fetch to two APIs in parallel (shown here as `/0` and `/artifacts`) to retrieve the steps and artifacts for the action run, and then it renders the page. And then, even if the job is complete and the user hasn't yet interacted to expand any logs, it performs the same API calls a second time.  This PR fixes both problems by: - Injecting the initial data for the Action's steps & Artifacts into the initial page render, and using that data into the `RepoActionView` to serve as its initial data load. - No longer unconditionally starting a second invocation of `loadJob` 1 second later, as the initial data can be used to determine whether the job is still running and requires an interval refresh. ## 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 **WIP** - 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... - [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 - [ ] 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--> - User Interface bug fixes - [PR](https://codeberg.org/forgejo/forgejo/pulls/9099): <!--number 9099 --><!--line 0 --><!--description cHJldmVudCBpbml0aWFsICdibGFuaycgZGlzcGxheSBvZiBhY3Rpb24gbG9ncyB2aWV3LCByZW1vdmUgdW5uZWNlc3NhcnkgQVBJIGNhbGxz-->prevent initial 'blank' display of action logs view, remove unnecessary API calls<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9099 Reviewed-by: Earl Warren <earl-warren@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> |
||
|
|
8e813902c5 |
feat: ability to view previous logs for Actions runs that have been retried (#9017)
Adds a new dropdown to the job logs, visible only when a job has been retried at least once:  When an older run attempt from the dropdown is selected, displays the older run's logs:  Context on implementation & design decisions: - It is important that when a URL from an Action's log is shared, the person on the other side sees the exact same logs that were being viewed. For this reason, all log views are automatically redirected to a fully-qualified URL (including the *run*, *job*, and *attempt*), so that when they are shared there is a guarantee of stability in the viewed logs. - Individual jobs can be rerun any number of times independent of other jobs in the same workflow. This means there isn't a "set" of related jobs that were executed at the same time, and this led me to remove the display of current status of jobs on the left-hand side of the view. There isn't a logical set of job statuses to display here. Fixes #1043. Based upon @gmem's original work in #1416. ## 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... - [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 - [ ] 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--> - User Interface features - [PR](https://codeberg.org/forgejo/forgejo/pulls/9017): <!--number 9017 --><!--line 0 --><!--description YWJpbGl0eSB0byB2aWV3IHByZXZpb3VzIGxvZ3MgZm9yIEFjdGlvbnMgcnVucyB0aGF0IGhhdmUgYmVlbiByZXRyaWVk-->ability to view previous logs for Actions runs that have been retried<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9017 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
49a28ba554 | add TestActionsViewViewPost to unit test Done change | ||
|
|
cb17e7542c | Convert anonymous structs in ViewResponse into named structs for unit testing | ||
|
|
13142acf60 | fix: refresh Action Log view until entire workflow run is completed | ||
|
|
5596cd8d7a |
fix: very long commit messages cause pushed commits to fail to display on the action feed on MySQL (#9098)
When adding "user pushed to ..." and "user synced commits to ..." messages to the activity feed, the `actionNotifier` currently records the entire commit message into the `action.content` field, but when displaying the commit in the activity feed only the first line of the message is displayed. This change tweaks the JSON `Message` field to be abbreviated using the `abbreviatedComment` function, which will include only the first 200 characters of the first line of the commit message. This will reduce wasted storage in the `action` table to persist duplicated messages that aren't fully displayed in the UI anyway. Fixes #8447, which is an error that occurs in this method due to the 64K character limit in `TEXT` fields in MySQL and the possibility of syncing FEED_MAX_COMMIT_NUM (default 5) long commit messages and exceeding this limit. Automated testing is bolted onto existing tests. I've cloned the entire structures before mutating them to ensure the mutations don't affect the webhook notifier. ## 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/9098 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
86ce1477c1 |
test(e2e): improve reliability of workflow list dynamic refresh test (#9059)
The "refresh does not break interacting with open drop-downs" is flaky. It attempts to verify that a refresh of the "Actions" list page does not occur when the user is currently navigating the dropdowns on the page, as htmx would replace their dropdowns mid-action. It does this by clicking on the dropdowns, verifying the dropdown text is visible, simulating a refresh, and verifying that the dropdown text is still visible.
Example failure log:
```
1) [chromium] › tests/e2e/actions.test.e2e.ts:173:3 › workflow list dynamic refresh › refresh does not break interacting with open drop-downs
Error: Timed out 3000ms waiting for expect(locator).toBeVisible()
Locator: getByText('Waiting')
Expected: visible
Received: hidden
Call log:
- Expect "toBeVisible" with timeout 3000ms
- waiting for getByText('Waiting')
7 × locator resolved to <a class="item" href="?workflow=test-dispatch.yml&actor=0&status=5">↵⇆⇆⇆⇆⇆⇆⇆Waiting↵⇆⇆⇆⇆⇆⇆</a>
- unexpected value "hidden"
194 | await expect(page.getByText('Failure')).toBeVisible();
195 | await simulatePollingInterval(page);
> 196 | await expect(page.getByText('Waiting')).toBeVisible();
| ^
197 | await expect(page.getByText('Failure')).toBeVisible();
198 |
199 | // Actor dropdown
at /workspace/forgejo/forgejo/tests/e2e/actions.test.e2e.ts:196:45
```
The dropdown list stops refreshes if there are any `[aria-expanded=true]` elements on the page:
https://codeberg.org/forgejo/forgejo/src/commit/ab6ea6a743e0dc9aa2e4c19201fb42533858a843/templates/repo/actions/list.tmpl#L31-L33
But fomantic doesn't set the `aria-expanded` attribute immediately on mouseup; it delays for up to 100ms:
https://codeberg.org/forgejo/forgejo/src/commit/f8a332c2e66de08a1fc0c8db8f3b570c51ec7da5/web_src/js/modules/fomantic/dropdown.js#L241-L246
The easiest fix is to align the test's expectations with the underlying code, which is to verify that the `aria-expanded=true` element is present in the test before proceeding with the simulated refresh.
Before this change, this test would fail as frequently as 10-out-of-10 in local runs, but usually more around 70% (albeit closer to 0% in a playwright ui). After this change, I've executed the test with zero failures in 100 back-to-back runs with `npx playwright test ./tests/e2e/actions.test.e2e.ts --project chromium --repeat-each 100`.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9059
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
|
||
|
|
11218ac43c |
fix(ui): don't allow comment boxes to stretch outside diff boundries on small device UI (#9052)
The context menu of the comment box was not always available on a mobile-sized device, because it would escape its container, overlap other elements, and be unable to be clicked. To address this, I've made the comment box constrained to the width of the diff box. This allows Playwright to interact with the element without ambiguity of the click targets, avoiding any "intercepts pointer events". Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9052 Reviewed-by: 0ko <0ko@noreply.codeberg.org> Reviewed-by: Beowulf <beowulf@beocode.eu> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
6ac0ab3549 |
test(e2e): improve resiliency of accessibilityCheck (#9051)
In the helper method `accessibilityCheck`, accessibility checks are performed on the page including measurements of contrast between elements, and the theme is transitioned from the `light` to `dark` theme and back between two checks (with a hard-coded 100ms wait). Experimentally this is proven to result in false-positive failures of the accessibilityCheck.
I believe the cause of these failures are CSS transitions that are occurring either between the theme transition, or from operations that have occurred before the `accessibilityCheck` method is called. For example, one test `Markdown insert link` pops open the `Add a link` dialog box which has a CSS transition applied as the background is greyed out.
To fix this, I've wrapped both accessibility scans within `accessibilityCheck` in a `expect(...).toPass({ timeout: 1000 })` to allow Playwright to retry the assertions over the next second. 1 second exceeds the time that I've observed of any CSS transition in the project (max found was 0.3 seconds).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9051
Reviewed-by: Antonin Delpeuch <wetneb@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
|
||
|
|
f9a6657248 |
fix: minio initialization can freeze indefinitely if misconfigured (#8897)
Fixes #8893 by using a 30 second initialization timeout on the minio storage. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8897 Reviewed-by: Earl Warren <earl-warren@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> |
||
|
|
b0c453902b |
fix: comment starting with a mermaid block displays error in activity feed (#8896)
In the event a comment starts with a fenced code block, don't display a blank block (or a mermaid error) in the activity feed. Instead, do not display an abbreviated comment text at all, and just display the issue/PR title.  Handles one more case identified in #8781, posted by @skedastically in https://codeberg.org/forgejo/forgejo/issues/8781#issuecomment-6274957. ## 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/8896 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
da9bedc967 |
test: fix failure in relative-time tests in US/Canada DST-aware timezones (#8858)
When running relative-time tests on my local system, the tests fail. I've verified this failure does occur when the local system time is configured to use these timezones: - America/Edmonton - America/Boise - America/Goose Bay But the tests pass if the local system time is in these timezones: - America/Phoenix (has no DST) - Europe/Berlin (different DST rules) "7 months ago" (the existing test case output) is accurate considering the offsets used in the test, but internally dayjs calculates it to be 7.99 months when the system TZ is in the "success" TZs, and 8.0001 months in the "failure" TZs. I believe the source of the difference is that... - dayjs takes timestamps with offsets, applies the offset, and then treats them as local times... - Summer Time ended on Oct 27 (the "now" date under test) in Europe, but did not end until November 3rd in the US/Canada... - In Europe there would have been one hour less between those local timestamps than there would be in US/Canada. My proposed fix is to perform the diff calculations after converting the timestamps to UTC values. This provides consistent successful output regardless of the local system TZ. As the tests are sensitive to system timezone, I've modified the CI build to run the frontend tests twice with two different TZ environment variables. This is a pretty coarse way to exercise the problem and I'm open to improvements. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8858 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
9524b8c370 |
fix: PR review dismissals were not appearing in activity feed (#8853)
Discovered that `NotifyPullRevieweDismiss` was dead code while working on another issue; it should have been `PullReviewDismiss` when originally implemented. Related fixes to the activity feed view which were incomplete as well. Dismissing a PR review now appears on the activity feed:  ## 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/8853 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
a1451655eb |
fix: standardize truncation of user-entered comment text in activity feed (#8854)
Currently long-form comments in the activity feed are truncated in three different ways...
- Comment on issue/PR: to 200 characters, with an ellipsis, potentially splitting the middle of multi-line markdown blocks
- PR review: first line of text in the review comment
- PR review dismissed: no truncation on comment text...
- Although this feed entry doesn't work currently (#8853) and the UI doesn't really lend itself to long comments anyway.
For the sake of consistency, and to fix #8781, this PR fixes the implementation so that all truncation occurs by grabbing the first line of text and then truncating it to 200 characters if necessary.
This fixes #8781 by not ever truncating in the middle of a markdown *block*; it's still possible to trigger some unexpected behavior such as:
- Truncate in the middle of markdown structures like a link, causing raw markdown to render in the feed
- Provide an image embed on the first line of a comment, causing an image to appear in the feed; if it's a large image it could disrupt browsing a nice brief activity feed
But these behaviors seem acceptable edge cases until they're identified to cause any significant user impact.
## 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/8854): <!--number 8854 --><!--line 0 --><!--description c3RhbmRhcmRpemUgdHJ1bmNhdGlvbiBvZiB1c2VyLWVudGVyZWQgY29tbWVudCB0ZXh0IGluIGFjdGl2aXR5IGZlZWQ=-->standardize truncation of user-entered comment text in activity feed<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8854
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
|
||
|
|
1f2bbbd4aa |
fix: prevent user-entered text with | characters from being truncated in activity feed (#8844)
Prevents a variety of user-entered texts that can contain `|` characters from being truncated in the activity feed, affecting: issue & PR titles, comment content, review comments, and review dismissal comments. Where `action.content` was containing a pipe-separated list of UI data fields before, it now uses a JSON-encoded string array. The old format is still supported for reading from the feed. In some places where `action.content` was not using this format, or where user-generated text was not inserted, the old format is retained. Fixes part of the cause behind #8781, allowing small mermaid graphs to be rendered in the feed (for now...) --  ## 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. - [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/8844 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
7f6b9a8867 |
fix: expanding exactly 20 lines between diff sections leaves visual artifact (#8519)
Fixes #8488. The issue was caused by having exactly 20 lines of text between two diff sections, which is `BlobExcerptChunkSize`. The previous diff section ends at 530, the next diff section starts at 551, leaving 20 hidden lines. This triggered an off-by-one error in determining whether a synthetic section should be added to the render to include a new expander; it was falsely being triggered when it shouldn't have been. Mostly correct logic was already present in `GetExpandDirection`, so I changed the `ExcerptBlob` web rendering to use `GetExpandDirection` on whether to include the synthetic section. Then I covered `GetExpandDirection` with unit tests covering all boundary conditions, which discovered one other minor bug -- the case where exactly `BlobExcerptChunkSize` is hidden between two diff sections should never have displayed an "Up" and "Down" expansion, but just a single expander (as below).  Note that *technically* the `ExcerptBlob` change is not covered by any new tests... but the relevant logic has been moved to somewhere more easily testable and fully covered. If this isn't covered enough for tests, let me know. ## 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/8519 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
e47fa23729 |
fix: PR not blocked by review request for a whitelisted team (#8511)
Fixes #8491. Previous behavior always updated the newly created review to set the `official` flag to false. This logic is now removed. The most likely reason that this logic existed was that team reviews were being marked as official based upon `doer`, rather than the target team, which seems undesirable. The expected behavior was retained by removing the check for `IsOfficialReviewer(..., doer)`, ensuring that when making a review request for a team, it doesn't matter *who* makes the request. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8511 Reviewed-by: Earl Warren <earl-warren@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> |
||
|
|
b6c6981c30 |
feat(ui): add repository description to og:image:alt (#8325)
Followup to https://codeberg.org/forgejo/forgejo/pulls/6053 Adds the repository description to the "alt" tag of the OpenGraph summary card, improving accessibility when these images are displayed. Fixes #8192. Other summary cards, for issues and releases, are not modified as they already contain the issue title or release title, which seems reasonable. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8325 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Reviewed-by: 0ko <0ko@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
6ad706aa88 |
feat(ui): Automatically refresh workflows in the "Actions" list (#7361)
- Make the "Actions" list (for example, https://codeberg.org/forgejo/forgejo/actions) dynamically refresh using htmx and partial page reloading. This addresses a pet peeve of mine, I find it common to end up on this page and have workflows in-progress, but not be able to monitor the workflows to success or failure from the page as it currently doesn't do any data refreshing. - There are a few major risks involves with this change. - Increased server-side load & network utilization. In order to mitigate this risk, I have configured the refresh to occur every 30 seconds **only** when the Page Visibility API indicates that the web page is currently visible to the end-user. It is still reasonable to assume this change will increase server-side load though. - UI interactions on the page, such as the "Actor" and "Status" dropdown and the workflow dispatch form, would be replaced from the server with non-expanded UI during the refresh. This problem is prevented by stopping the refresh while these UIs are in their expanded states. - E2E tests added. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7361 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
d9252f53a3 |
Fix bug where Action UI may occasionally not load logs (#6122)
In the combination of events where the user is viewing an action that is completed (and therefore no interval-based loading of logs is occurring), and `loadJob` is called while `loadJob` is already running (commonly from expanding two log sections back-to-back), the second request for loading would be discarded and never occur. To fix this, the invocation of `loadJob` keeps track of the log cursors it is attempting to load, and an aborted invocation stores its attempted load. If `loadJob` succeeds in loading and finds that an attempt was aborted while it was busy, it will reload the data. Steps to reproduce: - Open an Action UI that is already "Done". - Click on two steps in rapid succession to expand their logs. - (Race condition) As long as the second click is registered while the first log chunk is being loaded, its data won't load. ## 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... (**not applicable**) - [ ] 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 - [ ] 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/6122 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> 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> |
||
|
|
2faa7ce749 |
Rework GetLatestCommitStatusForPairs query using a subquery for PG compatibility (#6113)
## Scope Intended to fix #6099; and moves related tests to integration tests (per. request https://codeberg.org/forgejo/forgejo/pulls/6105#issuecomment-2486228) ## 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 applicable** - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... **not applicable** - [ ] 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. - Rationale: bug-fix for a change that hasn't been released yet. - [ ] 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/6113 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
|
bb8c712ffa | add tests for GetLatestCommitStatusForRepoCommitIDs | ||
|
|
73583fdea1 | Fix unconditional DB queries in commit status fetches | ||
|
|
77fafbe578 |
Add a "summary card" to issues & PRs for consumption by OpenGraph clients (#6053)
## Overview Hi all, I'm a first-time contributor to Forgejo. I was looking for something interesting to contribute and the first thing that caught my attention was https://codeberg.org/forgejo/forgejo/issues/6043, a request for an enhancement to include "issue previews" when publishing links to social media platforms. As a bit of background, the way these platforms work is that they search for meta tags in the posted link's content, and if they find a meta `og:image` (along with other meta tags) they'll pull the image to include in the social media post. Forgejo currently provides an `og:image` tag but it just renders the repository or repository-owner's avatar. This PR will render `og:image` for an issue or PR into a link to `{...}/summary-card`, which is a dynamically generated image that contains a summary of the issue. ## Design Notes ### Rendering / Rasterization The tricky part of solving this problem is rendering an image that combines some text, some images, and some layout elements. To address this, I've created a `card` module which allows for a handful of operations: - Create a new rendered image (a "Card") - Add a margin to a card - Split the card, horizontally or vertically, into two pieces with a proportional layout (eg. 70%/30%, as desired), each of which are "Cards" that render into the same root image - Render text into a card, with line-wrapping and text-alignment capabilities - Render an image onto a card - Fetches an external image as safely as possible (for server-side fetch of Gravatar, etc.) The card module can be reused to create `og:image` summary cards for any object in the future, although obviously it's capabilities are limited. The current implementation is on issues/PRs. I considered a few alternative approaches before taking this approach, and here's why I rejected those options: - Provide the summary card as an SVG object which could be rendered much more easily with a template file -- however, support for SVG isn't defined as positive for OpenGraph, and a quick look through some existing implementations suggest that it is not widely supported, if at all - Rendering as HTML/CSS, or SVG, and then using an external tool to convert into a PNG (or other static) image -- this would be much nicer and easier to implement, but would require tying in some very heavy-weight dependencies - Rendering using a more sophisticated graphics library, eg. cairo -- also would be nicer and easier to implement, but again a heavy dependency for a small functionality As a result of the limited capabilities of the new card module, summary cards don't have icons on them (which would require SVG rasterization) or pretty status badges with colors and rounded rects. In the future if better drawing capabilities were added, the graphics could be improved, but it doesn't seem too important. ### External Avatars In order to rasterize a user's avatar onto the summary card, it might have to be retrieved by the server from the external source (eg. Gravatar). A `fetchExternalImage` routine attempts to do this in the safest way possible to protect the server from any possible security exposure from this; (a) verifying that the content-types are acceptable, (b) ensuring that the file-size and image-size are within the safe bounds that are used for custom avatars, (c) using a very-short timeout to avoid stalling the server if an external dependency is offline. ### Caching Summary cards are cached after rendered. This has the downside of causing updates to statuses, avatars, titles, etc. being stale on the summary card for the cache TTL. However, during testing I found that some social media engines like Mastodon will cause the summary card to be accessed a significant number of times after being referenced by a post, causing a mini-tornado of requests. The cache compensates for this to avoid server load in this situation. ### Scope I'm considering out-of-scope: - Summary cards on other objects (eg. repos, users) can be left for future implementation ## 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...~~ n/a, no JS changes - [x] ~~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)).~~ - Manual testing - [x] Access & attach screenshots of both an issue and a pull-request's summary card; see below - [x] Ensure reasonable (non-crash) behavior of rendering text with glyphs outside the font -- correctly rendered as replacement unicode chars - [x] Using a public test instance, verify that og:image behavior looks good on platforms like Mastodon and BlueSky - [x] Bluesky: ✅ - [x] Mastodon: ✅ (Note that the summary card will be requested many times as the post is federated; either each server, or each client, will fetch it itself) - [x] OpenGraph test site (https://www.opengraph.xyz/): ✅ - [x] Discord: Looks OK ✅; needs "twitter:card" to be set to "summary_large_image" to display the large-scale image, but (a) that's probably annoying to use, (b) probably wrong because it doesn't match Twitter Card's spec for a "photographic image", and (c) don't want to encourage/continue use of vendor-specific tag - [x] Verify cases with user avatar missing (or autogen), and repo avatar missing (falls back to repo owner avatar) Pull request summary card:  Issue summary card:  (images to the right are the custom repo avatar, w/ fallback to the repo owner avatar) ### 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. - OpenGraph capabilities are expected to work in the background without user awareness, and so there is no need for documentation to explain the capabilities for users. ### 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/6053 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |