And add more comments
(cherry picked from commit 4f386e2c5e39b860424faf4cbc02c16f641f956e)
Conflicts:
cmd/main_test.go
tests/integration/integration_test.go
trivial context conflicts
unset XDG_CONFIG_HOME early to enable gitea to manage git configuration.
simple error checking to satisfy the linting. Closes#33039
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 233b7959e0518c47ef83c6a80c617546983433eb)
Fix#32992
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 20c7fba60157067252af49da41b6f8929a5ae31a)
Conflicts:
routers/web/repo/issue_new.go
the function is at routers/web/repo/issue.go in Forgejo
- For every process that is spawned (every new non-trivial goroutine
such as http requests, queues or tasks) start a [execution
tracer](https://pkg.go.dev/runtime/trace). This allows very precise
diagnosis of how each individual process over a time period.
- It's safe and [fast](https://go.dev/blog/execution-traces-2024#low-overhead-tracing) to
be run in production, hence no setting to disable this. There's only
noticable overhead when tracing is actually performed and not continuous.
- Proper tracing support would mean the codebase would be full of
`trace.WithRegion` and `trace.Log`, which feels premature for this patch
as there's no real-world usage yet to indicate which places would need
this the most. So far only Git commands and SQL queries receive somewhat
proper tracing support given that these are used throughout the codebase.
- Make git commands a new process type.
- Add tracing to diagnosis zip file.
The following message is displayed when upgrading to Forgejo:
[W] Table system_setting Column version db default is , struct default is 1
The same message also shows when upgrading from Gitea 1.21 to Gitea 1.22.
It is fine for the version field to default to zero or NULL instead of one.
Some database fields were added in the database to facilitate
migration from Gitea and do not serve any purpose. Drop them since
v1.22 is the last version of the database to allow a transparent
migration to Forgejo.
This commit allows chaning default branch update style through global
and repository settings. The setting affects "Update branch" button
in PR view (button shows when some commits are ahead of master branch).
When default update style is set to "rebase", dropdown button updates branch
by rebase by default. When update style is set to other value, dropdown button
updates branch by merge. Any of these actions may be selected using dropdown
in any case.
Signed-off-by: George Bartolomey <george@bh4.ru>
Make the result the same as GitHub:
* all skipped, then result is skipped
* any cancelled, then result cancelled
(cherry picked from commit 22c4599542ee3e10bcab4c9136467bbac8e90ba0)
fix#32857
(cherry picked from commit d28a4843b8de5d5e01ef3d7b2ad25f22853247ad)
Conflicts:
web_src/js/components/ActionRunStatus.vue
remove the refactoring, keep the additional cancelled status
Fix#32795
If a job uses a matrix, multiple `ActionRunJobs` may have the same
`JobID`. We need to merge the outputs of these jobs to make them
available to the jobs that need them.
(cherry picked from commit 7269130d2878d51dcdf11f7081a591f85bd493e8)
Conflicts:
models/fixtures/action_run.yml
models/fixtures/action_run_job.yml
trivial context conflicts
use errors.New to replace fmt.Errorf with no parameters
Signed-off-by: RiceChuan <lc582041246@gmail.com>
(cherry picked from commit dfd75944992fc6508ec891b4c29715c23e59e4ed)
Signed-off-by: Awiteb <a@4rs.nl>
Fixes: #6239
## 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.
- 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/6240
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Awiteb <a@4rs.nl>
Co-committed-by: Awiteb <a@4rs.nl>
This commit has a fundamental flaw, in order to syncronize if external
users are still active the commit checks if the refresh token is
accepted by the OAuth provider, if that is not the case it sees that as
the user is disabled and sets the is active field to `false` to signal
that. Because it might be possible (this commit makes this a highly
likelyhood) that the OAuth provider still recognizes this user the
commit introduces code to allow users to re-active themselves via the
oauth flow if they were disabled because of this. However this code
makes no distinction in why the user was disabled and always re-actives
the user.
Thus the reactivation via the OAuth flow allows users to bypass the
manually activation setting (`[service].REGISTER_MANUAL_CONFIRM`) or if
the admin for other reasons disabled the user.
This reverts commit 21fdd28f08.
(cherry picked from commit e45ffc530f482a46de25d28f18b039f296750414)
Conflicts:
models/fixture_test.go
trivial context conflict and remove one line in deadcode
- If a organisation is set to be limited visible, then it will still be
visible for signed-in users. However `UnitPermission` didn't take this
into account, it does now.
- Add unit test.
- Resolves#6141
## 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>
