1
0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-11-25 08:59:31 -05:00
Commit graph

12 commits

Author SHA1 Message Date
Earl Warren
998a431747
Do not update PRs based on events that happened before they existed
* Split TestPullRequest out of AddTestPullRequestTask
* A Created field is added to the Issue table
* The Created field is set to the time (with nano resolution) on creation
* Record the nano time repo_module.PushUpdateOptions is created by the hook
* The decision to update a pull request created before a commit was
  pushed is based on the time (with nano resolution) the git hook
  was run and the Created field

It ensures the following happens:

* commit C is pushed
* the git hook queues AddTestPullRequestTask for processing and returns with success
* TestPullRequest is not called yet
* a pull request P with commit C as the head is created
* TestPullRequest runs and ignores P because it was created after the commit was received

When the "created" column is NULL, no verification is done, pull
requests that were created before the column was created in the
database cannot be newer than the latest call to a git hook.

Fixes: https://codeberg.org/forgejo/forgejo/issues/2009
2024-04-11 11:16:23 +02:00
Earl Warren
f1c1a1e877
models: reserve v11 for backporting release blocker 2024-04-11 11:13:28 +02:00
JakobDev
94d4b241b3 Resolve conflicts 2024-04-08 12:55:05 +02:00
hazycora
8cbacf850a
Add back ID field to pronouns migration
looks unnecessary, but not doing this seems to cause failed tests. Other previous migrations follow this pattern as well.
2024-04-03 15:16:38 -05:00
hazycora
204dd9e300
Add migration for pronouns 2024-04-03 15:15:53 -05:00
Gusted
79b7089360
[FEAT] Configure if protected branch rule should apply to admins
- Currently protected branch rules do not apply to admins, however in
some cases (like in the case of Forgejo project) you might also want to
apply these rules to admins to avoid accidental merges.
- Add new option to configure this on a per-rule basis.
- Adds integration tests.
- Resolves #65
2024-03-29 00:21:49 +01:00
Earl Warren
d6eab2b586
models/forgejo_migrations: Gitea tables migration ID
Sync() will act on the given struct and the ID field should be exactly
as it is in the Gitea migration when a Gitea table is modified.
2024-03-27 09:27:32 +01:00
Gergely Nagy
8fdffc94ca Add a migration to remove SSH signatures from release notes
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>
2024-03-26 08:09:36 +00:00
Gergely Nagy
36147f580c
Allow users to hide all "Add more units..." hints
Repositories displaying an "Add more..." tab on the header is a neat way
to let people discover they can enable more units. However, displaying
it all the time for repository owners, even when they deliberately do
not want to enable more units gets noisy very fast.

As such, this patch introduces a new setting which lets people disable
this hint under the appearance settings.

Fixes #2378.

Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
2024-03-21 08:15:51 +01:00
Gergely Nagy
2ca4862f8b
[GITEA] Allow changing the repo Wiki branch to main
Previously, the repo wiki was hardcoded to use `master` as its branch,
this change makes it possible to use `main` (or something else, governed
by `[repository].DEFAULT_BRANCH`, a setting that already exists and
defaults to `main`).

The way it is done is that a new column is added to the `repository`
table: `wiki_branch`. The migration will make existing repositories
default to `master`, for compatibility's sake, even if they don't have a
Wiki (because it's easier to do that). Newly created repositories will
default to `[repository].DEFAULT_BRANCH` instead.

The Wiki service was updated to use the branch name stored in the
database, and fall back to the default if it is empty.

Old repositories with Wikis using the older `master` branch will have
the option to do a one-time transition to `main`, available via the
repository settings in the "Danger Zone". This option will only be
available for repositories that have the internal wiki enabled, it is
not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`.

When migrating a repository with a Wiki, Forgejo will use the same
branch name for the wiki as the source repository did. If that's not the
same as the default, the option to normalize it will be available after
the migration's done.

Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will
now include the wiki branch name in `GET` requests, and allow changing
the wiki branch via `PATCH`.

Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d87c526d2a)
2024-02-05 16:57:47 +01:00
Gergely Nagy
36f7c162e2
[FEAT] Repository flags
This implements "repository flags", a way for instance administrators to
assign custom flags to repositories. The idea is that custom templates
can look at these flags, and display banners based on them, Forgejo does
not provide anything built on top of it, just the foundation. The
feature is optional, and disabled by default. To enable it, set
`[repository].ENABLE_FLAGS = true`.

On the UI side, instance administrators will see a new "Manage flags"
tab on repositories, and a list of enabled tags (if any) on the
repository home page. The "Manage flags" page allows them to remove
existing flags, or add any new ones that are listed in
`[repository].SETTABLE_FLAGS`.

The model does not enforce that only the `SETTABLE_FLAGS` are present.
If the setting is changed, old flags may remain present in the database,
and anything that uses them, will still work. The repository flag
management page will allow an instance administrator to remove them, but
not set them, once removed.

Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit ba735ce222)
(cherry picked from commit f09f6e029b)
(cherry picked from commit 2f8b041489)
(cherry picked from commit d3186ee5f4)
2024-02-05 16:09:42 +01:00
Gergely Nagy
5eeccecafc
[GITEA] Optionally allow anyone to edit Wikis
This is largely based on gitea#6312 by @ashimokawa, with updates and
fixes by myself, and incorporates the review feedback given in that pull
request, and more.

What this patch does is add a new "default_permissions" column to the
`repo_units` table (defaulting to read permission), adjusts the
permission checking code to take this into consideration, and then
exposes a setting that lets a repo administrator enable any user on a
Forgejo instance to edit the repo's wiki (effectively giving the wiki
unit of the repo "write" permissions by default).

By default, wikis will remain restricted to collaborators, but with the
new setting exposed, they can be turned into globally editable wikis.

Fixes Codeberg/Community#28.

Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b74439922)
(cherry picked from commit 337cf62c10)
(cherry picked from commit b6786fdb32)
(cherry picked from commit a5d2829a10)

[GITEA] Optionally allow anyone to edit Wikis (squash) AddTokenAuth

(cherry picked from commit fed50cf72e)
(cherry picked from commit 42c55e494e)
(cherry picked from commit e3463bda47)
2024-02-05 16:09:42 +01:00