Jason Song [Wed, 7 Aug 2024 15:29:08 +0000 (23:29 +0800)]
Add `TAGS` to `TEST_TAGS` and fix bugs found with gogit (#31791)
Found at
https://github.com/go-gitea/gitea/pull/31790#issuecomment-2272898915
`unit-tests-gogit` never work since the workflow set `TAGS` with
`gogit`, but the Makefile use `TEST_TAGS`.
This PR adds the values of `TAGS` to `TEST_TAGS`, ensuring that setting
`TAGS` is always acceptable and avoiding confusion about which one
should be set.
Lunny Xiao [Tue, 6 Aug 2024 13:32:49 +0000 (21:32 +0800)]
Fix protected branch files detection on pre_receive hook (#31778)
Fix #31738
When pushing a new branch, the old commit is zero. Most git commands
cannot recognize the zero commit id. To get the changed files in the
push, we need to get the first diverge commit of this branch. In most
situations, we could check commits one by one until one commit is
contained by another branch. Then we will think that commit is the
diverge point.
And in a pre-receive hook, this will be more difficult because all
commits haven't been merged and they actually stored in a temporary
place by git. So we need to bring some envs to let git know the commit
exist.
Edip Emre Bodur [Mon, 5 Aug 2024 10:59:53 +0000 (13:59 +0300)]
Fix null requested_reviewer from API (#31773)
If the assign the pull request review to a team, it did not show the
members of the team in the "requested_reviewers" field, so the field was
null. As a solution, I added the team members to the array.
Jason Song [Thu, 1 Aug 2024 10:02:46 +0000 (18:02 +0800)]
Use UTC as default timezone when schedule Actions cron tasks (#31742)
Fix #31657.
According to the
[doc](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onschedule)
of GitHub Actions, The timezone for cron should be UTC, not the local
timezone. And Gitea Actions doesn't have any reasons to change this, so
I think it's a bug.
However, Gitea Actions has extended the syntax, as it supports
descriptors like `@weekly` and `@every 5m`, and supports specifying the
timezone like `TZ=UTC 0 10 * * *`. So we can make it use UTC only when
the timezone is not specified, to be compatible with GitHub Actions, and
also respect the user's specified.
It does break the feature because the times to run tasks would be
changed, and it may confuse users. So I don't think we should backport
this.
## ⚠️ BREAKING ⚠️
If the server's local time zone is not UTC, a scheduled task would run
at a different time after upgrading Gitea to this version.
Jason Song [Thu, 1 Aug 2024 09:04:04 +0000 (17:04 +0800)]
Clarify Actions resources ownership (#31724)
Fix #31707.
Also related to #31715.
Some Actions resources could has different types of ownership. It could
be:
- global: all repos and orgs/users can use it.
- org/user level: only the org/user can use it.
- repo level: only the repo can use it.
There are two ways to distinguish org/user level from repo level:
1. `{owner_id: 1, repo_id: 2}` for repo level, and `{owner_id: 1,
repo_id: 0}` for org level.
2. `{owner_id: 0, repo_id: 2}` for repo level, and `{owner_id: 1,
repo_id: 0}` for org level.
The first way seems more reasonable, but it may not be true. The point
is that although a resource, like a runner, belongs to a repo (it can be
used by the repo), the runner doesn't belong to the repo's org (other
repos in the same org cannot use the runner). So, the second method
makes more sense.
And the first way is not user-friendly to query, we must set the repo id
to zero to avoid wrong results.
So, #31715 should be right. And the most simple way to fix #31707 is
just:
However, it is quite intuitive to set both owner id and repo id since
the repo belongs to the owner. So I prefer to be compatible with it. If
we get both owner id and repo id not zero when creating or finding, it's
very clear that the caller want one with repo level, but set owner id
accidentally. So it's OK to accept it but fix the owner id to zero.
Jason Song [Wed, 31 Jul 2024 10:29:48 +0000 (18:29 +0800)]
Distinguish LFS object errors to ignore missing objects during migration (#31702)
Fix #31137.
Replace #31623 #31697.
When migrating LFS objects, if there's any object that failed (like some
objects are losted, which is not really critical), Gitea will stop
migrating LFS immediately but treat the migration as successful.
This PR checks the error according to the [LFS api
doc](https://github.com/git-lfs/git-lfs/blob/main/docs/api/batch.md#successful-responses).
> LFS object error codes should match HTTP status codes where possible:
>
> - 404 - The object does not exist on the server.
> - 409 - The specified hash algorithm disagrees with the server's
acceptable options.
> - 410 - The object was removed by the owner.
> - 422 - Validation error.
If the error is `404`, it's safe to ignore it and continue migration.
Otherwise, stop the migration and mark it as failed to ensure data
integrity of LFS objects.
And maybe we should also ignore others errors (maybe `410`? I'm not sure
what's the difference between "does not exist" and "removed by the
owner".), we can add it later when some users report that they have
failed to migrate LFS because of an error which should be ignored.
Hide the "Details" link of commit status when the user cannot access actions (#30156)
Fix #26685
If a commit status comes from Gitea Actions and the user cannot access
the repo's actions unit (the user does not have the permission or the
actions unit is disabled), a 404 page will occur after clicking the
"Details" link. We should hide the "Details" link in this case.
OIDC: case-insensitive comparison for auth scheme `Basic` (#31706)
@kylef pointed out on https://github.com/go-gitea/gitea/pull/31632 that
[RFC7617](https://www.rfc-editor.org/rfc/rfc7617.html#section-2)
mandates case-insensitive comparison of the scheme field `Basic`. #31632
copied a case-sensitive comparison from
https://github.com/go-gitea/gitea/pull/6293. This PR fixes both
comparisons.
The issue only affects OIDC, since the implementation for normal Gitea
endpoints is already correct:
We don't need to have polyfills down to Node v4. Some of our deps have
polyfills, and don't utilize the built-in implementation if available.
While this does decrease our package graph, I haven't been able to
notice any decrease/increase in page load times, although that could
likely be just because it's already pretty fast.
Nolyfill is https://github.com/SukkaW/nolyfill
updates to files generated with:
```shell
npx nolyfill install
npm update
```
Before this is/isn't merged, I'd be appreciative/thankful for other's
insights.
Edit: This isn't due to a specific individual. I am generally supportive
of them and their dedication to backward compatibility. This PR is due
to not needing those imports for our minimum requirements. Please don't
take this PR as commentary on anyone's character.
The introspect endpoint was using the OIDC token itself for
authentication. This fixes it to use basic authentication with the
client ID and secret instead:
* Applications with a valid client ID and secret should be able to
successfully introspect an invalid token, receiving a 200 response
with JSON data that indicates the token is invalid
* Requests with an invalid client ID and secret should not be able
to introspect, even if the token itself is valid
Unlike #31561 (which just future-proofed the current behavior against
future changes to `DISABLE_QUERY_AUTH_TOKEN`), this is a potential
compatibility break (some introspection requests without valid client
IDs that would previously succeed will now fail). Affected deployments
must begin sending a valid HTTP basic authentication header with their
introspection requests, with the username set to a valid client ID and
the password set to the corresponding client secret.
Remove unneccessary uses of `word-break: break-all` (#31637)
Fixes: https://github.com/go-gitea/gitea/issues/31636
1. Issue sidebar topic is disussed in
https://github.com/go-gitea/gitea/issues/31636
2. Org description already has `overflow-wrap: anywhere` to ensure no
overflow.
Carsten Klein [Tue, 16 Jul 2024 22:49:05 +0000 (00:49 +0200)]
Allow searching issues by ID (#31479)
When you are entering a number in the issue search, you likely want the
issue with the given ID (code internal concept: issue index).
As such, when a number is detected, the issue with the corresponding ID
will now be added to the results.
allow synchronizing user status from OAuth2 login providers (#31572)
This leverages the existing `sync_external_users` cron job to
synchronize the `IsActive` flag on users who use an OAuth2 provider set
to synchronize. This synchronization is done by checking for expired
access tokens, and using the stored refresh token to request a new
access token. If the response back from the OAuth2 provider is the
`invalid_grant` error code, the user is marked as inactive. However, the
user is able to reactivate their account by logging in the web browser
through their OAuth2 flow.
Also changed to support this is that a linked `ExternalLoginUser` is
always created upon a login or signup via OAuth2.
### Notes on updating permissions
Ideally, we would also refresh permissions from the configured OAuth
provider (e.g., admin, restricted and group mappings) to match the
implementation of LDAP. However, the OAuth library used for this `goth`,
doesn't seem to support issuing a session via refresh tokens. The
interface provides a [`RefreshToken`
method](https://github.com/markbates/goth/blob/master/provider.go#L20),
but the returned `oauth.Token` doesn't implement the `goth.Session` we
would need to call `FetchUser`. Due to specific implementations, we
would need to build a compatibility function for every provider, since
they cast to concrete types (e.g.
[Azure](https://github.com/markbates/goth/blob/master/providers/azureadv2/azureadv2.go#L132))
1. Fixed border-radius
2. Monaco ignores the alpha channel on the shadow color, introduce
`color-shadow-opaque`
3. Remove scrollbar color which follows
https://github.com/go-gitea/gitea/pull/29800
Before:
<img width="34" alt="Screenshot 2024-07-13 at 15 38 18"
src="https://github.com/user-attachments/assets/042d9bde-6db9-4467-a2a4-8f61ecc773eb">
<img width="35" alt="Screenshot 2024-07-13 at 15 38 31"
src="https://github.com/user-attachments/assets/04146ee0-551c-4ff2-9636-bd119b33595a">
After:
<img width="45" alt="Screenshot 2024-07-13 at 15 38 06"
src="https://github.com/user-attachments/assets/1f58fa5a-1289-4e45-83c9-18ca82a5e266">
<img width="39" alt="Screenshot 2024-07-13 at 21 16 56"
src="https://github.com/user-attachments/assets/e12ebe22-b29b-4798-9f0d-4c100f311562">
Sunny Wan [Thu, 11 Jul 2024 23:23:31 +0000 (19:23 -0400)]
Display app name in the registration email title (#31562)
I changed the title of the registation email from "Welcome to Gitea" to
"Welcome to (appname)". I did this by substituting 'Gitea' in
register_notify to %s and formating the registration title in mail.go. I
changed this for all the languages I could, but I struggled to changed
the translation file for Farsi. I have attached the screenshots of
before and after and the related issue below.
Related issue:
https://github.com/go-gitea/gitea/issues/31108
Before change:
![Screenshot from 2024-07-04
22-32-17](https://github.com/go-gitea/gitea/assets/94445569/4178b51c-1acc-45f4-9750-dff41564a709)
After:
![Screenshot from 2024-07-04
22-32-01](https://github.com/go-gitea/gitea/assets/94445569/9cd7a58d-c0f5-4a3c-a66c-805c55411eaa)
---------
Signed-off-by: Sunny Wan <Sunnywan2020@gmail.com> Co-authored-by: 6543 <6543@obermui.de>
Fix: Allow org team names of length 255 in create team form (#31564)
Gitea 1.22.1 was supposed to allow for team names of length 255 (up from
30) after the following PR was merged in:
https://github.com/go-gitea/gitea/pull/31410. However, the length of
team names was still limited to 30 as described in this issue:
https://github.com/go-gitea/gitea/issues/31554.
One more change to _gitea_ needs to be made to allow for the longer team
names, as there is a 30 character limit here:
https://github.com/go-gitea/gitea/blob/2c92c7c5226e29636a1d47a277130f477fa2037b/services/forms/org.go#L65
Allow disabling authentication related user features (#31535)
We have some instances that only allow using an external authentication
source for authentication. In this case, users changing their email,
password, or linked OpenID connections will not have any effect, and
we'd like to prevent showing that to them to prevent confusion.
Included in this are several changes to support this:
* A new setting to disable user managed authentication credentials
(email, password & OpenID connections)
* A new setting to disable user managed MFA (2FA codes & WebAuthn)
* Fix an issue where some templates had separate logic for determining
if a feature was disabled since it didn't check the globally disabled
features
* Hide more user setting pages in the navbar when their settings aren't
enabled
The build currently seems to work fine without this, but in theory it
should fail because Fomantic is JavaScript. I feel more comfortable
having this loader declared.
Note: I did try using the [combined loader
config](https://github.com/privatenumber/esbuild-loader#-quick-setup)
but when I did that, vue files could not load, so I think this is the
best option.
None of the frontend js/ts files was touched besides these two commands
(edit: no longer true, I touched one file in
https://github.com/go-gitea/gitea/pull/31559/commits/61105d0618e285d97e95044bfb64415f364a4526
because of a deprecation that was not showing before the rename).
`tsc` currently reports 778 errors, so I have disabled it in CI as
planned.
Henry Goodman [Fri, 5 Jul 2024 18:21:56 +0000 (04:21 +1000)]
Allow force push to protected branches (#28086)
Fixes #22722
### Problem
Currently, it is not possible to force push to a branch with branch
protection rules in place. There are often times where this is necessary
(CI workflows/administrative tasks etc).
The current workaround is to rename/remove the branch protection,
perform the force push, and then reinstate the protections.
### Solution
Provide an additional section in the branch protection rules to allow
users to specify which users with push access can also force push to the
branch. The default value of the rule will be set to `Disabled`, and the
UI is intuitive and very similar to the `Push` section.
It is worth noting in this implementation that allowing force push does
not override regular push access, and both will need to be enabled for a
user to force push.
This applies to manual force push to a remote, and also in Gitea UI
updating a PR by rebase (which requires force push)
This modifies the `BranchProtection` API structs to add:
- `enable_force_push bool`
- `enable_force_push_whitelist bool`
- `force_push_whitelist_usernames string[]`
- `force_push_whitelist_teams string[]`
- `force_push_whitelist_deploy_keys bool`
As requested in
https://github.com/go-gitea/gitea/pull/31504#issuecomment-2196196646.
This PR refactor the login page:
![Screenshot from 2024-07-04
19-23-10](https://github.com/go-gitea/gitea/assets/6918444/c45700f4-6747-473c-bdee-2156718a7953)
![Screenshot from 2024-07-04
19-23-21](https://github.com/go-gitea/gitea/assets/6918444/b1bf71cf-85f9-4517-a409-cc6d72e6af8f)
![Screenshot from 2024-06-30
09-35-20](https://github.com/go-gitea/gitea/assets/6918444/728cc37e-0cca-4883-afec-a43663d2c666)
# Changes
- [x] use separate box for passkey login and go to registration
- [x] move forgot passoword next to password label
- [x] fix password required label `*` and padding
- [x] remove tabs from login page
Fix slow patch checking with commits that add or remove many files (#31548)
Running git update-index for every individual file is slow, so add and
remove everything with a single git command.
When such a big commit lands in the default branch, it could cause PR
creation and patch checking for all open PRs to be slow, or time out
entirely. For example, a commit that removes 1383 files was measured to
take more than 60 seconds and timed out. With this change checking took
about a second.
This is related to #27967, though this will not help with commits that
change many lines in few files.
Add typescript guideline and typescript-specific eslint plugins and fix issues (#31521)
1. Add some general guidelines how to write our typescript code
2. Add `@typescript-eslint/eslint-plugin`, general typescript rules
3. Add `eslint-plugin-deprecation` to detect deprecated code
4. Fix all new lint issues that came up