This adds a new `doctor` check: `fix-push-mirrors-without-git-remote`. The new check looks for push mirrors that do not have their remotes configured in git. If automatic fixing is enabled, it will remove these push mirrors from the database.
The check is not run by default, and thus, must be invoked manually. It should be usable in a half-migrated state, too, and as such, fixes#1800.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/1853
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-committed-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 9038e07ef35978336612588d68c1315179a45c73)
(cherry picked from commit b15bafcbc7d9033b0cc7b0fd888915b117e08d42)
(cherry picked from commit 93ba05a2dd9fdec46f337542cd5f22c8960ac55f)
(cherry picked from commit e418ea80822361e387b460c583592bbd83d4a39e)
(cherry picked from commit 321790a91ec8553d1b3668f606ebec762865dd17)
(cherry picked from commit f4e19d332392cb455b3b4e32e271f3e42302bbc8)
(cherry picked from commit 4d9923dee851a4046050761d3dd352f2f343f4fc)
(cherry picked from commit 049df69eda1ceb47f6e74c9a67e9ce5041e65c3b)
Conflicts:
services/doctor/push_mirror_consistency.go
https://codeberg.org/forgejo/forgejo/pulls/2214
(cherry picked from commit c79cba8d556320be0da7ca8324b39cd8930465bf)
(cherry picked from commit f3a3969c02cade7261a5f25c9e342800ccdf9111)
(cherry picked from commit 69741e4e66932a9ac092089e7ba27399c55dcd1a)
(cherry picked from commit 2a3c7b09cbdfd62cca2619aaf37b6913a373d142)
(cherry picked from commit a1554c1168d897e8db4024d716a837c012bf74e9)
(cherry picked from commit edae2c6d2dda7f44e40ae88fba60a15f61b72232)
(cherry picked from commit 49737cf009a6a0fc119cf8a1a1593493c77c841a)
(cherry picked from commit ec53704c34a3e9491b4f210250d5e053f4b221e5)
(cherry picked from commit 7a1c5c0f323cb5e9235d8fa6e59a0a1b172d3abb)
(cherry picked from commit e658c20c0f21b42f741c0149e0e79ea0bb3b949c)
(cherry picked from commit baf575468f39c5dd0c2ff3498ef9f706d12d114e)
(cherry picked from commit 40cb14eff427c801243e374f7c60fef994bcb792)
(cherry picked from commit 25ab4d07136d023236de00e9143957c856b4d196)
(cherry picked from commit 5a29005215a5e9419ed3096c1bc0aae172f45089)
(cherry picked from commit fef1260e990719af49644970aaa2a7219438b681)
(cherry picked from commit eadbbb1afe6f36cfaf4cc3fc346b510893f21011)
(cherry picked from commit db22d61eb47b56cc7cf0f44934f8f550df029e76)
(cherry picked from commit 9d3b0be39a008e2e1a4f474b0ab74627e003430d)
(cherry picked from commit b3fa3c1292228ef4833b6ea1f120102471478256)
(cherry picked from commit c8300d4fe24fccaefc18e95ec8c6d689f1cb4d7a)
(cherry picked from commit 8ba6a4c9dbd9cbb2758b02016f1858d1e85633ce)
(cherry picked from commit 8b8df652c1eb7806e590751942b4689e374e1128)
(cherry picked from commit fc8fa050c688451c9c2079b1f0f71ed11a6d7e4d)
(cherry picked from commit bcf3faf69843421517bf3ddf032fe92cbf0a766d)
(cherry picked from commit 514a631aa650987ef3400ad31eb32af676a97164)
(cherry picked from commit 529c7a09f73bdb27ac14e0cdb6312eac2bc1109c)
(cherry picked from commit 0d093d76e2d27523f42606d78c1302057c328913)
- Implements https://codeberg.org/forgejo/discussions/issues/32#issuecomment-918737
- Allows to add Forgejo-specific migrations that don't interfere with Gitea's migration logic. Please do note that we cannot liberally add migrations for Gitea tables, as they might do their own migrations in a future version on that table, and that could undo our migrations. Luckily, we don't have a scenario where that's needed and thus not taken into account.
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/795
(cherry picked from commit 8ee32978c0af1f8f71679c87f695df2b90b617c8)
(cherry picked from commit c240b34f595a7a9763f7b748052ac98f9f18954d)
(cherry picked from commit 03936c649243a0a29701393d58e63e33064c7461)
(cherry picked from commit a20ed852f8b6d28872c05d688bffe5c6976bfa03)
(cherry picked from commit 1dfa82676f1feb745633618fde2d362bf19c4f28)
(cherry picked from commit c39ae0bf8abced8fd5dc32589e68515ac308b69b)
(cherry picked from commit cfaff08996c9f42592c95a63fe907b45b8a9317a)
(cherry picked from commit 94a458835a2b0336b26c1c9df64fdfe2de47f496)
(cherry picked from commit 61a3cf77dfe3f612ff110eb19f94dcb08051daf1)
(cherry picked from commit abb350fde879cc495761dc4616b7aa0fc5d94d54)
(cherry picked from commit 5194829d6b4ed702cf50ff875da57d04d77c8a18)
(cherry picked from commit 89239a60f23cad7dad03add744e23a4f3b10d6a4)
(cherry picked from commit 683cfd86efc5fa8cc04973ce3115351515a20917)
(cherry picked from commit f4546cfed92844e3666b80130eadabb9348b88ae)
(cherry picked from commit 86614d5826392b3fbe68355baeab9a0a761883a5)
(cherry picked from commit e4b9c32187a039a83686a82856a9a192919c6e82)
(cherry picked from commit 8c253719afa9b82f169757df007587d38560c06d)
(cherry picked from commit 857365d6c15b5471d63662b1d89d1523151c4f79)
(cherry picked from commit a488b3952f58bbf28bfa101a24e52dad7c9662eb)
(cherry picked from commit 98313c49109c941426beecc1a3e7887f28b99970)
(cherry picked from commit 430d95e8240971e266705d2e7202a5c785379cb2)
(cherry picked from commit 08bf9d918fbb67f5ac06c0cfdc24229aa14ff83f)
(cherry picked from commit f8a170e2d042fcb8f314e123de6918317ac1e909)
(cherry picked from commit d20e325378e67087279496d35b575e566836aaa1)
(cherry picked from commit 6c0aa7dd4fd8c234984d455933f69f51abcb2d32)
(cherry picked from commit 46c08c26c7bd3260b3ac7678f24566b467f4a2fb)
(cherry picked from commit 9ee22153c4ec62392693c9151d5395221d097f70)
[DB] Ensure forgejo migration up to date (squash)
- Hook Forgejo's `EnsureUpToDate` to Gitea's `EnsureUpToDate`, such that
the Forgejo migrations are also being checked to be up to date.
- I'm not sure how I missed this and if this has caused any problems,
but due to the lack of any open issue about it it seems to not be a big
problem.
(cherry picked from commit 6c65b6dcf6ab0d58e5c2d03a866e4e38294f72ad)
(cherry picked from commit 6d45c37d843147e69b0a27ebe35c617d7f574b76)
[DB] Add test for TestEnsureUpToDate (squash)
- Add a test for the behavior of `EnsureUpToDate`, to ensure it will
error when needed and succeed when the forgejo version is up to date.
- Add forgejo_migrations package to GO_TEST_PACKAGES, to avoid running
it with `test-unit` and instead test it with `test-*-migration`.
(cherry picked from commit b172a506914fee40a50daa51f0c8e547427fd2f8)
(cherry picked from commit d8af3088205b592340fd836135ffe97da9cec5a6)
(cherry picked from commit e69e64a32c5e38247e94ab880536e3cfeab67cc6)
(cherry picked from commit 4e8363fad4e08845960912a3ea3fe7265ee60602)
(cherry picked from commit fc9ecd6c533eca864503423cf4a21710984a6b75)
(cherry picked from commit e5c446e3dc9bc6e9549862f7b764a634f4fbaaae)
(cherry picked from commit 7066a15655a33f57ccfb68cf2cb994ea57ad3666)
(cherry picked from commit 9183cdc8354d529a1c2b570551bc1578fb10d58b)
(cherry picked from commit 5f93039e0d7c8a7eb79df16ce0d8603f948b1bd2)
Conflicts:
Makefile
https://codeberg.org/forgejo/forgejo/pulls/2245
(cherry picked from commit a039b3b0c9a7016de9e7e71ea0cc7a1185adb8d9)
- This also means that if one of the test fails, it will actually
propagate to make and subsequently fail the test.
- Remove the 'delete duplicates issue users' code, I checked this
against my local development database (which contains quite bizarre
cases, even some that Forgejo does not like), my local instance database
and against Codeberg production and they all yielded no results to this
query, so I'm removing it thus resolving the error that the delete code
was not compatible with Mysql.
- Sync all tables that are requires by the migration in the test.
- Resolves#2206
(cherry picked from commit 8e02be7e89a76ccbc3f8a58577be0fcc34e1469e)
(cherry picked from commit 006f06441645d864fc27ca30352367b3afafc5bb)
Fixes#27114.
* In Gitea 1.12 (#9532), a "dismiss stale approvals" branch protection
setting was introduced, for ignoring stale reviews when verifying the
approval count of a pull request.
* In Gitea 1.14 (#12674), the "dismiss review" feature was added.
* This caused confusion with users (#25858), as "dismiss" now means 2
different things.
* In Gitea 1.20 (#25882), the behavior of the "dismiss stale approvals"
branch protection was modified to actually dismiss the stale review.
For some users this new behavior of dismissing the stale reviews is not
desirable.
So this PR reintroduces the old behavior as a new "ignore stale
approvals" branch protection setting.
---------
Co-authored-by: delvh <dev.lh@web.de>
This resolves a problem I encountered while updating gitea from 1.20.4
to 1.21. For some reason (correct or otherwise) there are some values in
`repository.size` that are NULL in my gitea database which cause this
migration to fail due to the NOT NULL constraints.
Log snippet (excuse the escape characters)
```
ESC[36mgitea |ESC[0m 2023-12-04T03:52:28.573122395Z 2023/12/04 03:52:28 ...ations/migrations.go:641:Migrate() [I] Migration[263]: Add git_size and lfs_size columns to repository table
ESC[36mgitea |ESC[0m 2023-12-04T03:52:28.608705544Z 2023/12/04 03:52:28 routers/common/db.go:36:InitDBEngine() [E] ORM engine initialization attempt #3/10 failed. Error: migrate: migration[263]: Add git_size and lfs_size columns to repository table failed: NOT NULL constraint failed: repository.git_size
```
I assume this should be reasonably safe since `repository.git_size` has
a default value of 0 but I don't know if that value being 0 in the odd
situation where `repository.size == NULL` has any problematic
consequences.
Closes#27455
> The mechanism responsible for long-term authentication (the 'remember
me' cookie) uses a weak construction technique. It will hash the user's
hashed password and the rands value; it will then call the secure cookie
code, which will encrypt the user's name with the computed hash. If one
were able to dump the database, they could extract those two values to
rebuild that cookie and impersonate a user. That vulnerability exists
from the date the dump was obtained until a user changed their password.
>
> To fix this security issue, the cookie could be created and verified
using a different technique such as the one explained at
https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#secure-remember-me-cookies.
The PR removes the now obsolete setting `COOKIE_USERNAME`.
Part of https://github.com/go-gitea/gitea/issues/27097:
- `gitea` theme is renamed to `gitea-light`
- `arc-green` theme is renamed to `gitea-dark`
- `auto` theme is renamed to `gitea-auto`
I put both themes in separate CSS files, removing all colors from the
base CSS. Existing users will be migrated to the new theme names. The
dark theme recolor will follow in a separate PR.
## ⚠️ BREAKING ⚠️
1. If there are existing custom themes with the names `gitea-light` or
`gitea-dark`, rename them before this upgrade and update the `theme`
column in the `user` table for each affected user.
2. The theme in `<html>` has moved from `class="theme-name"` to
`data-theme="name"`, existing customizations that depend on should be
updated.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
This PR reduces the complexity of the system setting system.
It only needs one line to introduce a new option, and the option can be
used anywhere out-of-box.
It is still high-performant (and more performant) because the config
values are cached in the config system.
This fixes a performance bottleneck. It was discovered by Codeberg.
Every where query on that table (which has grown big over time) uses
this column, but there is no index on it.
See this part of the log which was posted on Matrix:
```
2023/09/10 00:52:01 ...rs/web/repo/issue.go:1446:ViewIssue() [W] [Slow SQL Query] UPDATE `issue_user` SET is_read=? WHERE uid=? AND issue_id=? [true x y] - 51.395434887s
2023/09/10 00:52:01 ...rs/web/repo/issue.go:1447:ViewIssue() [E] ReadBy: Error 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
2023/09/10 00:52:01 ...eb/routing/logger.go:102:func1() [I] router: completed GET /Codeberg/Community/issues/1201 for [::ffff:xxx]:0, 500 Internal Server Error in 52384.2ms @ repo/issue.go:1256(repo.ViewIssue)
```
Fix the bug on try.gitea.io
```log
2023/09/18 01:48:41 ...ations/migrations.go:635:Migrate() [I] Migration[276]: Add RemoteAddress to mirrors
2023/09/18 01:48:41 routers/common/db.go:34:InitDBEngine() [E] ORM engine initialization attempt #7/10 failed. Error: migrate: migration[276]: Add RemoteAddress to mirrors failed: exit status 128 - fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
- fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
```
Caused by #26952
---------
Co-authored-by: Jason Song <i@wolfogre.com>
This PR adds a new field `RemoteAddress` to both mirror types which
contains the sanitized remote address for easier (database) access to
that information. Will be used in the audit PR if merged.
Currently, Artifact does not have an expiration and automatic cleanup
mechanism, and this feature needs to be added. It contains the following
key points:
- [x] add global artifact retention days option in config file. Default
value is 90 days.
- [x] add cron task to clean up expired artifacts. It should run once a
day.
- [x] support custom retention period from `retention-days: 5` in
`upload-artifact@v3`.
- [x] artifacts link in actions view should be non-clickable text when
expired.
In PR #26786, the Go version for golangci-lint is bumped to 1.21. This
causes the following error:
```
models/migrations/v1_16/v210.go:132:23: SA1019: elliptic.Marshal has been deprecated since Go 1.21: for ECDH, use the crypto/ecdh package. This function returns an encoding equivalent to that of PublicKey.Bytes in crypto/ecdh. (staticcheck)
PublicKey: elliptic.Marshal(elliptic.P256(), parsed.PubKey.X, parsed.PubKey.Y),
```
The change now uses [func (*PublicKey)
ECDH](https://pkg.go.dev/crypto/ecdsa#PublicKey.ECDH), which is added in
Go 1.20.
Replace #22751
1. only support the default branch in the repository setting.
2. autoload schedule data from the schedule table after starting the
service.
3. support specific syntax like `@yearly`, `@monthly`, `@weekly`,
`@daily`, `@hourly`
## How to use
See the [GitHub Actions
document](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)
for getting more detailed information.
```yaml
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
```
Signed-off-by: Bo-Yi.Wu <appleboy.tw@gmail.com>
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
## Archived labels
This adds the structure to allow for archived labels.
Archived labels are, just like closed milestones or projects, a medium to hide information without deleting it.
It is especially useful if there are outdated labels that should no longer be used without deleting the label entirely.
## Changes
1. UI and API have been equipped with the support to mark a label as archived
2. The time when a label has been archived will be stored in the DB
## Outsourced for the future
There's no special handling for archived labels at the moment.
This will be done in the future.
## Screenshots
Part of https://github.com/go-gitea/gitea/issues/25237
---------
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
The xorm `Sync2` has already been deprecated in favor of `Sync`,
so let's do the same inside the Gitea codebase.
Command used to replace everything:
```sh
for i in $(ag Sync2 --files-with-matches); do vim $i -c ':%sno/Sync2/Sync/g' -c ':wq'; done
```
Fixes#25918
The migration fails on MSSQL because xorm tries to update the primary
key column. xorm prevents this if the column is marked as auto
increment:
c622cdaf89/internal/statements/update.go (L38-L40)
I think it would be better if xorm would check for primary key columns
here because updating such columns is bad practice. It looks like if
that auto increment check should do the same.
fyi @lunny
- cancel running jobs if the event is push
- Add a new function `CancelRunningJobs` to cancel all running jobs of a
run
- Update `FindRunOptions` struct to include `Ref` field and update its
condition in `toConds` function
- Implement auto cancellation of running jobs in the same workflow in
`notify` function
related task: https://github.com/go-gitea/gitea/pull/22751/
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Signed-off-by: appleboy <appleboy.tw@gmail.com>
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: delvh <dev.lh@web.de>
Close#24544
Changes:
- Create `action_tasks_version` table to store the latest version of
each scope (global, org and repo).
- When a job with the status of `waiting` is created, the tasks version
of the scopes it belongs to will increase.
- When the status of a job already in the database is updated to
`waiting`, the tasks version of the scopes it belongs to will increase.
- On Gitea side, in `FeatchTask()`, will try to query the
`action_tasks_version` record of the scope of the runner that call
`FetchTask()`. If the record does not exist, will insert a row. Then,
Gitea will compare the version passed from runner to Gitea with the
version in database, if inconsistent, try pick task. Gitea always
returns the latest version from database to the runner.
Related:
- Protocol: https://gitea.com/gitea/actions-proto-def/pulls/10
- Runner: https://gitea.com/gitea/act_runner/pulls/219
Fix#25776. Close#25826.
In the discussion of #25776, @wolfogre's suggestion was to remove the
commit status of `running` and `warning` to keep it consistent with
github.
references:
-
https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#about-commit-statuses
## ⚠️ BREAKING ⚠️
So the commit status of Gitea will be consistent with GitHub, only
`pending`, `success`, `error` and `failure`, while `warning` and
`running` are not supported anymore.
---------
Co-authored-by: Jason Song <i@wolfogre.com>
current actions artifacts implementation only support single file
artifact. To support multiple files uploading, it needs:
- save each file to each db record with same run-id, same artifact-name
and proper artifact-path
- need change artifact uploading url without artifact-id, multiple files
creates multiple artifact-ids
- support `path` in download-artifact action. artifact should download
to `{path}/{artifact-path}`.
- in repo action view, it provides zip download link in artifacts list
in summary page, no matter this artifact contains single or multiple
files.
Related #14180
Related #25233
Related #22639Close#19786
Related #12763
This PR will change all the branches retrieve method from reading git
data to read database to reduce git read operations.
- [x] Sync git branches information into database when push git data
- [x] Create a new table `Branch`, merge some columns of `DeletedBranch`
into `Branch` table and drop the table `DeletedBranch`.
- [x] Read `Branch` table when visit `code` -> `branch` page
- [x] Read `Branch` table when list branch names in `code` page dropdown
- [x] Read `Branch` table when list git ref compare page
- [x] Provide a button in admin page to manually sync all branches.
- [x] Sync branches if repository is not empty but database branches are
empty when visiting pages with branches list
- [x] Use `commit_time desc` as the default FindBranch order by to keep
consistent as before and deleted branches will be always at the end.
---------
Co-authored-by: Jason Song <i@wolfogre.com>
releated to #21820
- Split `Size` in repository table as two new colunms, one is `GitSize`
for git size, the other is `LFSSize` for lfs data. still store full size
in `Size` colunm.
- Show full size on ui, but show each of them by a `title`; example:
- Return full size in api response.
---------
Signed-off-by: a1012112796 <1012112796@qq.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: DmitryFrolovTri <23313323+DmitryFrolovTri@users.noreply.github.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Fix#25088
This PR adds the support for
[`pull_request_target`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)
workflow trigger. `pull_request_target` is similar to `pull_request`,
but the workflow triggered by the `pull_request_target` event runs in
the context of the base branch of the pull request rather than the head
branch. Since the workflow from the base is considered trusted, it can
access the secrets and doesn't need approvals to run.
# The problem
There were many "path tricks":
* By default, Gitea uses its program directory as its work path
* Gitea tries to use the "work path" to guess its "custom path" and
"custom conf (app.ini)"
* Users might want to use other directories as work path
* The non-default work path should be passed to Gitea by GITEA_WORK_DIR
or "--work-path"
* But some Gitea processes are started without these values
* The "serv" process started by OpenSSH server
* The CLI sub-commands started by site admin
* The paths are guessed by SetCustomPathAndConf again and again
* The default values of "work path / custom path / custom conf" can be
changed when compiling
# The solution
* Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use
test code to cover its behaviors.
* When Gitea's web server runs, write the WORK_PATH to "app.ini", this
value must be the most correct one, because if this value is not right,
users would find that the web UI doesn't work and then they should be
able to fix it.
* Then all other sub-commands can use the WORK_PATH in app.ini to
initialize their paths.
* By the way, when Gitea starts for git protocol, it shouldn't output
any log, otherwise the git protocol gets broken and client blocks
forever.
The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path
> env var GITEA_WORK_DIR > builtin default
The "app.ini" searching order is: cmd arg --config > cmd arg "work path
/ custom path" > env var "work path / custom path" > builtin default
## ⚠️ BREAKING
If your instance's "work path / custom path / custom conf" doesn't meet
the requirements (eg: work path must be absolute), Gitea will report a
fatal error and exit. You need to set these values according to the
error log.
----
Close#24818Close#24222Close#21606Close#21498Close#25107Close#24981
Maybe close#24503
Replace #23301
Replace #22754
And maybe more
Follow up #22405Fix#20703
This PR rewrites storage configuration read sequences with some breaks
and tests. It becomes more strict than before and also fixed some
inherit problems.
- Move storage's MinioConfig struct into setting, so after the
configuration loading, the values will be stored into the struct but not
still on some section.
- All storages configurations should be stored on one section,
configuration items cannot be overrided by multiple sections. The
prioioty of configuration is `[attachment]` > `[storage.attachments]` |
`[storage.customized]` > `[storage]` > `default`
- For extra override configuration items, currently are `SERVE_DIRECT`,
`MINIO_BASE_PATH`, `MINIO_BUCKET`, which could be configured in another
section. The prioioty of the override configuration is `[attachment]` >
`[storage.attachments]` > `default`.
- Add more tests for storages configurations.
- Update the storage documentations.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Earl Warren
