Fixes#12660, reported by @mahlzahn.
### 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...
- [ ] <s>`make pr-go` before pushing</s> because the OOM killer kills it before it does anything useful
### 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/12734
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Fixes#2325.
This introduces a way to download downsized versions of the user and repository avatars:
* `/avatars/123abcd` still serves the full-size avatar
* `/avatars/123abcd?size=64` serves it at size 64x64 px
Those downsized versions are computed on demand when requested for the first time and cached. The caching is done in a storage location configurable in the instance settings, just like the storage locations for the full-sized avatars are. The sizes of the downsized images are restricted to a fixed set of sizes, so that the cache doesn't grow too big. The caching and resizing logic is exposed in a way that could potentially be reused for other types of images (such as user uploads in issue discussions).
Luckily, the Go templates already specify in many places which size those avatars should be rendered, even if this information was only used for external avatar providers (such as Gravatar) until now.
The range of sizes requested by the HTML templates is rather wide: the table below lists all the sizes I could find, and the corresponding size served by the backend with the logic I implemented. The scaling factor of 2 was already used for requesting resized external avatars, and likely exists to make sure that users with display scaling enabled get a sharper picture.
| Size requested in the template | After scaling (x2) | Size of the image served |
|---------|---------|---------|
| 256 px | 512 px | original (512 px) |
| 140 px | 280 px | original (512 px) |
| 48 px | 96 px | 128 px |
| 40 px | 80 px | 128 px |
| 32 px | 64 px | 64 px |
| 28 px | 56 px | 64 px |
| 24 px | 48 px | 64 px |
| 20 px | 40 px | 64 px |
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11242
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
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#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>
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>
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>
Fixes#6185.
## 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 also tested the changes manually.
### 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/9045
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Fixes#9332.
I decided to leave the "Editable" badge next to the PR branch name, because I think it doesn't hurt to have it there, especially if some users have already learned to look for it there.
For those more familiar with the Github UI and not knowing to look for the "Editable" badge, this patch will also put the information in a more familiar place.
Unfortunately the changes to the existing test had to be more involved because the existing test used a PR which was made with the same head repo as the base repo (whereas the editable setting is only offered for PRs from forks).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9392
Reviewed-by: Lucas <sclu1034@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>
Fixes#8639.
For your convenience this PR is made via AGit for you to see the issue directly in Codeberg ^^
### 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 am not sure how to best write a unit test for this. It looks like there isn't any AGit PR in the default test database. The integration test in `test/integration/pull_review_test.go` creates one by manually running Git commands. I could just copy all that code to do the same in another test, but I feel bad about duplicating this. Can they be sensibly migrated to some helpers module that can be reused across tests? Or can we add an AGit PR to the test database? Or can we modify the `Flow` attribute of a PR in a test just for the sake of simulating that it's an AGit one?
### 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/8642
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
## Checklist
### Tests
I don't think this deserves a test.
### 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.
### What does it fix
In the dashboard, when someone deletes a branch, the message
that is displayed doesn't distinguish the branch name from the rest
of the message visually. Because that's user-provided content, I find
it odd, as it blends in with the system-generated message.
For consistency with other messages (such as the one obtained when
renaming a repository), I propose to show the branch name in monospaced
font via the `<code></code>` markup.
I didn't update the other languages by fear of interfering with Weblate but
I would be happy to update the other languages accordingly if you wish so.
I didn't add any tests because I don't think it's necessary for such a small change.
#### Before
#### After
#### Renaming a repository (unchanged, just for reference)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8418
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
This is a port of a gitea PR: https://github.com/go-gitea/gitea/pull/34512.
I have added some copy-editing commits on top for cleanliness.
I haven't tested the changes manually and only relied on the existing automated test.
## 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.
### 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.
Co-authored-by: Jim Lin <jim@andestech.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8041
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Hello all, I am finally taking the time to follow-up on #6277 to get this implemented :)
## Checklist
### 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.
### 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/7930): <!--number 7930 --><!--line 0 --><!--description QWRkIGVycm9yIHJlcG9ydGluZyB0byBQUnMgd2l0aCBpbnZhbGlkIHdvcmtmbG93cw==-->Add error reporting to PRs with invalid workflows<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7930
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Without this change, I get the error:
> Error creating test engine: sqlite3 requires: import _ "github.com/mattn/go-sqlite3" or -tags sqlite,sqlite_unlock_notify
(cherry picked from commit 15fa4cf98e6f72203e4e1e8906ae32ce5cc6b753)
(cherry picked from commit 29932030932e74410857fcdb97ccca9374c8232a)
(cherry picked from commit f5054e48832d056ab72bf6c46369bc64098dc06b)
(cherry picked from commit e14c5f934c65441e5b2a75e084f17fc4812f6e52)
(cherry picked from commit ed53157084bfac78c76ad924a9473caee4897829)
(cherry picked from commit dc8346508bef1436d2486d7ba887f76d247081a3)
(cherry picked from commit e6d8e1a973eb8ddcd1efa444dfa768c79de88c1e)
(cherry picked from commit f3b9ca02f3134b79b48b88191f25e5a517bdebf2)
(cherry picked from commit 3799c133b419bdc0133a7732bc1155795c5cef74)
Closes#1789.
The bug was due to the fact that GitLab does not guarantee that issue numbers are created sequentially: some identifiers can be skipped. Therefore, the new pull requests numbers should not be offset by the number of issues, but by the maximum issue number.
See for instance https://gitlab.com/troyengel/archbuild/-/issues/?sort=created_date&state=all&first_page_size=20, where there is only a singe issue with number "2".
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/1790
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
(cherry picked from commit 2c185c39fe600041701d5f59cb1076a788815cb4)
(cherry picked from commit 8f68dc4c9c2f0acab55d59a496b0f141befad969)
(cherry picked from commit 7e932b7fca1b119e7cc646183c383ba51a5f1d14)
(cherry picked from commit 6bbe75ecf8ac502bd42ff5765e6e7733f290a54e)
(cherry picked from commit b18c2e8d658c3311e0a299696bd1b6612c52ef13)
Conflicts:
services/migrations/gitlab.go
https://codeberg.org/forgejo/forgejo/pulls/2075
(cherry picked from commit abc129c762b3c1a992ad5c67adf62d8336eadbbe)
(cherry picked from commit 28884fac10c455a9f40bebd961fca40afd4a749e)
(cherry picked from commit 5f528dd85fa6705c60d15bce616a46f00df1b85b)
(cherry picked from commit cb9b8a31b25b27fa5e386b20f02e532bbf3462a2)
(cherry picked from commit 97f02df163e2b4e23b82e23e5ef57a586b17f021)
(cherry picked from commit 4611e10e6acef9185e1f8c84e63d1fe95fcf6436)
Fix gitlab migration unit test
Closes#1837.
The differences in dates can be explained by commit e19b9653ea, which
changed the order in which "created_date" and "updated_date" are
considered.
(cherry picked from commit b0bba20aa44e30ef0296b89f336d426224d73a16)
Mock HTTP requests in GitLab migration test
This introduces a new utility which can be added to other tests
making HTTP calls to a live service, to cache the responses of this
service in the repository.
(cherry picked from commit 52053b138948bd74c7eb88c0796c2e18f4247f3c)
Enable mocked HTTP responses for GitLab migration test
(cherry picked from commit 19cefc4de24b935a6a5c92be8360301f196f3aa5)
Simplify HTTP mocking utility in unit tests
Follow-up to https://codeberg.org/forgejo/forgejo/pulls/1841
(cherry picked from commit ca517c8bb4bf97f061b8b19fd3303d734f46660c)
(cherry picked from commit b227e0dd6bdf2dc3e8679443fc538fbce4b3bcf5)
(cherry picked from commit 6cc9d06556cda6c952a0542284fbe504114971ce)
(cherry picked from commit f0746e648dc30510d655b8a3b821199b2638800f)
(cherry picked from commit 414193341b8493723c16694789cbc08dc80b9ce5)
(cherry picked from commit 6e93df3bbb6c589502afc9dc74a7ae1a7c0f7da8)
(cherry picked from commit db0dbab5527c9f1783fd0eddb057c2d91cbb67e4)
(cherry picked from commit 8f9c9c63fbd3f266bb29d38791e83dc369cc1350)
(cherry picked from commit e74e26203095b675ccedbc2e166faed59369d467)
(cherry picked from commit 2e0933edcfa102b578fb3c2500f9e6af9e5ba1c7)
(cherry picked from commit 65060c69616631221d3dd9ef8b48fbcb007ad0c6)
