Because the `git` module did not recognize SSH signed tags, those
signatures ended up in the `notes` column of the `release` table. While
future signatures will not end up there, Forgejo should clean up the old
ones.
This migration does just that: finds all releases that have an SSH
signature, and removes those signatures, preserving the rest of the
note (if any).
While this may seem like an expensive operation, it's only done once,
and even on the largest known Forgejo instance as of this
writing (Codeberg), the number of affected rows are just over a hundred,
a tiny amount all things considered.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Refactor the webhook logic, to have the type-dependent processing happen
only in one place.
---
1. An event happens
2. It is pre-processed (depending on the webhook type) and its body is
added to a task queue
3. When the task is processed, some more logic (depending on the webhook
type as well) is applied to make an HTTP request
This means that webhook-type dependant logic is needed in step 2 and 3.
This is cumbersome and brittle to maintain.
Updated webhook flow with this PR:
1. An event happens
2. It is stored as-is and added to a task queue
3. When the task is processed, the event is processed (depending on the
webhook type) to make an HTTP request
So the only webhook-type dependent logic happens in one place (step 3)
which should be much more robust.
- the raw event must be stored in the hooktask (until now, the
pre-processed body was stored)
- to ensure that previous hooktasks are correctly sent, a
`payload_version` is added (version 1: the body has already been
pre-process / version 2: the body is the raw event)
So future webhook additions will only have to deal with creating an
http.Request based on the raw event (no need to adjust the code in
multiple places, like currently).
Moreover since this processing happens when fetching from the task
queue, it ensures that the queuing of new events (upon a `git push` for
instance) does not get slowed down by a slow webhook.
As a concrete example, the PR #19307 for custom webhooks, should be
substantially smaller:
- no need to change `services/webhook/deliver.go`
- minimal change in `services/webhook/webhook.go` (add the new webhook
to the map)
- no need to change all the individual webhook files (since with this
refactor the `*webhook_model.Webhook` is provided as argument)
(cherry picked from commit 26653b196bd1d15c532af41f60351596dd4330bd)
Conflicts:
services/webhook/deliver_test.go
trivial context conflict
Fix#29000Fix#28685Fix#18568
Related: #27497
And by the way fix#24036, add a Cancel button there (one line)
(cherry picked from commit 5cddab4f74bbb307ddf13e458c7ac22f93b9283a)
The tests on migration tests failed but CI reports successfully
https://github.com/go-gitea/gitea/actions/runs/7364373807/job/20044685969#step:8:141
This PR will fix the bug on migration v283 and also the CI hidden
behaviour.
The reason is on the Makefile
`GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags='$(TEST_TAGS)' $(MIGRATE_TEST_PACKAGES)` will
return the error exit code.
But
`for pkg in $(shell $(GO) list
code.gitea.io/gitea/models/migrations/...); do \
GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags '$(TEST_TAGS)' $$pkg; \
done`
will not work.
This also fix#29602
(cherry picked from commit 45277486c2c6213b7766b1da708a991cdb1f3565)
Conflicts:
.github/workflows/pull-db-tests.yml
Makefile
models/migrations/v1_22/v283.go
models/migrations/v1_22/v286_test.go
models/migrations/v1_22/v287_test.go
already in Forgejo for the Makefile & CI logic but Gitea changes
otherwise rule
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)
- Use `forgejo` binary name for migration suggestions.
- Resolves https://codeberg.org/forgejo/forgejo/issues/869#issuecomment-944501
(cherry picked from commit 418a0bed8f831b72b206ca415d99c99824bec839)
(cherry picked from commit 734579ce9b0f66b61b4a08f605695af9db1d4f4e)
(cherry picked from commit 34bce5be193505cfc58a115dcd42a5d5912cb250)
(cherry picked from commit 9c788a6ec03ab413fc346386a6db846d1ca3b3e2)
(cherry picked from commit 6cabe323115d3e56f0eab1fe1d9eb384e32486d5)
(cherry picked from commit eba83a24408d40a922aee168ab7518fda0d488bb)
(cherry picked from commit 271c4586b2f2d88c8abcb3a514e02d579ee0fdb6)
(cherry picked from commit 60883a4d68e0d15faec91df3a88644f5a4761ac5)
(cherry picked from commit ec1f866ccb22fba03ebdabb2a09fb149c9efcd4a)
(cherry picked from commit 3689fbe53c426e7bd728ba35c0c744b952c93298)
(cherry picked from commit 8019b115b640d744233b9652efc8895294ad4103)
(cherry picked from commit 0d565d655b282382f910e6a6b74808852ebc6c0f)
(cherry picked from commit b3f72a1e118da558bfc72cc2ba42adb38f7b2e4b)
(cherry picked from commit 1bd8eab96db30c4690d7f39c9585d9edcbb80032)
(cherry picked from commit 1b0e01e40713f0e5e41318857c96e18d8156ae96)
(cherry picked from commit d2551dc9b75b002c35ffcd2d9d49a53e79f29341)
(cherry picked from commit cbaead8c387f8d9f25f3e914d26fe80ced5a5e17)
(cherry picked from commit cdab2d7a542ccea3e7d983f8993a14549e8f215e)
(cherry picked from commit 7de165e11bd878b80908b3957e3435bae87b6834)
(cherry picked from commit a3af896878c818bf57affa2286d5e26c1e840e66)
(cherry picked from commit 886a9019c6ccbe2165b2c1aba8f0ad457b9176e8)
(cherry picked from commit 6990c95c991f4081e5bd047a1b010ad016f16054)
(cherry picked from commit 7a9fc379399eb42e0d34bb9ee9d937a0f4bbdbf0)
(cherry picked from commit 9fd194fdcf8ce1755e2cd069fbd02f125f9f21e9)
(cherry picked from commit df976e858bd80f2207fbb0fde91f975633a0b0f6)
(cherry picked from commit db8dd753edbd9bb972eb8d56ce96fb8caee14f63)
(cherry picked from commit 216648a1041a6fd9603bcadaeadd6706b516df62)
(cherry picked from commit 80fa4d46bd40dc041e35733ee7d1bcaa81d497e6)
(cherry picked from commit 7a2998a46a8fbc1953285c189e0504caedc509c0)
(cherry picked from commit 40fa85df8e9eca51e4ea85dfdbc1088bda6ec3b2)
(cherry picked from commit e671021168e38ea249f1b169374b4c4a7318250d)
(cherry picked from commit cb4b7e2b5c3840a07cf2e890ede976c021774735)
(cherry picked from commit 241a2b5242f7dbfdf1963164c8b2b279fcd5ae51)
(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>
Earl Warren
