Fix the error message when the token is incorrect (#25701) (#25834)
Backport #25701 by @CaiCandong
we refactored `userIDFromToken` for the token parsing part into a new
function `parseToken`. `parseToken` returns the string `token` from
request, and a boolean `ok` representing whether the token exists or
not. So we can distinguish between token non-existence and token
inconsistency in the `verfity` function, thus solving the problem of no
proper error message when the token is inconsistent.
close #24439
related #22119
Co-authored-by: caicandong <50507092+CaiCandong@users.noreply.github.com> Co-authored-by: Jason Song <i@wolfogre.com>
Fix activity type match in `matchPullRequestEvent` (#25746) (#25797)
Backport #25746
Fix #25736
Caused by #24048
Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
pull_request:
branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.
Correct permissions for `.ssh` and `authorized_keys` (#25721) (#25731)
Backport #25721 by @wolfogre
Set the correct permissions on the .ssh directory and authorized_keys
file, or sshd will refuse to use them and lead to clone/push/pull
failures.
It could happen when users have copied their data to a new volume and
changed the file permission by accident, and it would be very hard to
troubleshoot unless users know how to check the logs of sshd which is
started by s6.
`data-source-position` of checkboxes in a task list was incorrect
whenever there was YAML front matter. This would result in issue content
or PR descriptions getting corrupted with random `x` or space characters
when a user checked or unchecked a task.
Giteabot [Sun, 11 Jun 2023 09:29:25 +0000 (05:29 -0400)]
Add `WithPullRequest` for `actionsNotifier` (#25144) (#25196)
Backport #25144 by @Zettat123
Fix #25093
If
[`WithPullRequest`](https://github.com/go-gitea/gitea/blob/679b1f7949aa40d4f962ef27f91b0b384b9c56a5/services/actions/notifier_helper.go#L90-L96)
is not called, the `Ref` in
[`notifyInput`](https://github.com/go-gitea/gitea/blob/679b1f7949aa40d4f962ef27f91b0b384b9c56a5/services/actions/notifier_helper.go#L55-L65)
will be empty, so the workflows in the head branch will not be found and
triggered.
If redirect_to parameter has set value starting with \\example.com
redirect will be created with header Location: /\\example.com that will
redirect to example.com domain.
Giteabot [Mon, 5 Jun 2023 15:05:52 +0000 (11:05 -0400)]
Fix parallelly generating index failure with Mysql (#24567) (#25081)
Backport #24567 by @lunny
- Fix possible parallel creating commit status index problem and
creating issues/pull request index problem work with Mysql5/Mysql8
- Add parallel tests
- Reenable TestRepoCommitsStatusParallel on CI
HesterG [Tue, 30 May 2023 10:08:32 +0000 (18:08 +0800)]
Unify doc links to use paths relative to doc folder (#24979) (#25000)
Backport #24979
Changes:
1. Use uniform links types relative to doc folder (start with `doc/`)
2. According to [docusaurus
links](https://docusaurus.io/docs/markdown-features/links), if `<a>` is
used, the `href` is resolved as URL location, but not file location. So
need to use `[text]({{< relref "path" >}})` instead.
sillyguodong [Tue, 30 May 2023 05:12:21 +0000 (13:12 +0800)]
Fix missing reference prefix of commits when sync mirror repository (#24994)
replace #24868
just a patch to fix #24824 in v1.19.4
The reference name of commits when synchronizing should also has prefix
like refs/heads/<branch-name>.
Giteabot [Fri, 19 May 2023 13:17:48 +0000 (09:17 -0400)]
Fix Actions being enabled accidentally (#24802) (#24810)
Backport #24802 by @wolfogre
Regression of #24536. If the user doesn't explicitly disable Actions, it
will be enabled.
1. Gitea will call `loadRepositoryFrom` before `loadActionsFrom`.
https://github.com/go-gitea/gitea/blob/25d4f95df25dae5226e96e813dde87b071d9155e/modules/setting/setting.go#L234-L237
2. In `loadRepositoryFrom`,
`rootCfg.Section("actions").Key("ENABLED").MustBool(true)` will set
`actions.ENABLED` with `true`.
https://github.com/go-gitea/gitea/blob/25d4f95df25dae5226e96e813dde87b071d9155e/modules/setting/repository.go#L313-L315
3. In `loadActionsFrom`, `rootCfg.Section("actions")` will get a section
with Actions enabled.
Although the cause of the problem was using `true` by copy-paste
mistake, it also surprised me that
**`rootCfg.Section("actions").Key("ENABLED").MustBool(true)` doesn't
only read, but also write.**
oliverpool [Fri, 12 May 2023 18:14:41 +0000 (20:14 +0200)]
fix: release page for empty or non-existing target (#24659)
Backport #24470
Fixes #24145
---
To solve the bug, I added a "computed" `TargetBehind` field to the
`Release` model, which indicates the target branch of a release. This is
particularly useful if the target branch was deleted in the meantime (or
is empty).
I also did a micro-optimization in `calReleaseNumCommitsBehind`. Instead
of checking that a branch exists and then call `GetBranchCommit`, I
immediately call `GetBranchCommit` and handle the `git.ErrNotExist`
error.
This optimization is covered by the added unit test.
Giteabot [Mon, 8 May 2023 10:48:06 +0000 (06:48 -0400)]
Refresh the refernce of the closed PR when reopening (#24231) (#24587)
Backport #24231 by @sillyguodong
Close #24213
Replace #23830
#### Cause
- Before, in order to making PR can get latest commit after reopening,
the `ref`(${REPO_PATH}/refs/pull/${PR_INDEX}/head) of evrey closed PR
will be updated when pushing commits to the `head branch` of the closed
PR.
#### Changes
- For closed PR , won't perform these behavior: insert`comment`, push
`notification` (UI and email), exectue
[pushToBaseRepo](https://github.com/go-gitea/gitea/blob/74225033413dc0f2b308bbe069f6d185b551e364/services/pull/pull.go#L409)
function and trigger `action` any more when pushing to the `head branch`
of the closed PR.
- Refresh the reference of the PR when reopening the closed PR (**even
if the head branch has been deleted before**). Make the reference of PR
consistent with the `head branch`.
There are many users reporting similar problem: if the SECRET_KEY
mismatches, some operations (like 2FA login) only reports unclear 500
error and unclear "base64 decode error" log （some maintainers ever spent
a lot of time on debugging such problem)
The SECRET_KEY was not well-designed and it is also a kind of technical
debt. Since it couldn't be fixed easily, it's good to add clearer error
messages, then at least users could know what the real problem is.
Giteabot [Fri, 5 May 2023 13:07:02 +0000 (09:07 -0400)]
Fix the permission of team's `Actions` unit issue (#24536) (#24545)
Backport #24536 by @sillyguodong
close #24449
The unit of `Actions` should be contorlled not only by
`repository.DISABLED_REPO_UNITS` but also by `actions.ENABLED`
in the `app.ini`.
Previously, the permission of the team's `Actions` unit was not
controlled by `actions.Enabled`. So, even if the user sets
`actions.Enabled` to false, he can still select the permission of the
`Actions` unit for the team.
This PR makes the permissions of the team's `Actions` unit also
controlled by `actions.Enabled`. Just append`TypeActions` into
`DisabledRepoUnits` slice when initializing if `actions.Enabled` is
false.
### Changes:
If `Actions` is set disbaled in `app.ini`, like below:
```yaml
[actions]
ENABLED = false
```
1. If user try to create/edit a team, will prompt user that `Actions` is
disbaled.
Giteabot [Wed, 3 May 2023 12:15:56 +0000 (08:15 -0400)]
Fix api error message if fork exists (#24487) (#24493)
Backport #24487 by @fnetX
On the @Forgejo instance of Codeberg, we discovered that forking a repo
which is already forked now returns a 500 Internal Server Error, which
is unexpected. This is an attempt at fixing this.
The error message in the log:
~~~
2023/05/02 08:36:30 .../api/v1/repo/fork.go:147:CreateFork() [E]
[6450cb8e-113] ForkRepository: repository is already forked by user
[uname: ...., repo path: .../..., fork path: .../...]
~~~
The service that is used for forking returns a custom error message
which is not checked against.
About the order of options:
The case that the fork already exists should be more common, followed by
the case that a repo with the same name already exists for other
reasons. The case that the global repo limit is hit is probably not the
likeliest.
---------
Co-authored-by: Otto Richter (fnetX) <git@fralix.ovh>
Giteabot [Tue, 2 May 2023 20:58:11 +0000 (16:58 -0400)]
Enable whitespace rendering on selection in Monaco (#24444) (#24485)
Backport #24444 by @silverwind
Remove the
[renderWhitespace](https://microsoft.github.io/monaco-editor/docs.html#interfaces/editor.IEditorOptions.html#renderWhitespace)
override, so the default value of `selection` takes over and makes
whitespace visible on selection.
<img width="128" alt="Screenshot 2023-04-30 at 19 09 41"
src="https://user-images.githubusercontent.com/115237/235366707-d598268d-03cc-4839-a195-c460bddae99b.png">
`getAuthenticatedMeta` has checked them, these code are duplicated one.
And the first invokation has a wrong permission check. `DownloadHandle`
should require read permission but not write.
Add tags list for repos whose release setting is disabled (#23465) (#24369)
Backport #23465
Close #23427
Co-Author: @wxiaoguang
If a repo's release setting is enabled, the logic has't changed.
Clicking the "Tags" button will jump to `/{user}/{repo}/tags` and
`templates/repo/release/list.tmpl` template will be used.
If the release setting is disabled, clicking the "Tags" button will
still jump to `/{user}/{repo}/tags` but a new template
`templates/repo/tag/list.tmpl` will be used.
Require repo scope for PATs for private repos and basic authentication (#24362) (#24364)
Backport #24362 by @jolheiser
> The scoped token PR just checked all API routes but in fact, some web
routes like `LFS`, git `HTTP`, container, and attachments supports basic
auth. This PR added scoped token check for them.
Fix https://github.com/go-gitea/gitea/issues/16188. Turns out the
element was completely misaligned by fomantic styles. Add most of the
original styles in `!important` form to fix.
Tapping the button doesn't do anything useful in Simulator.app, but I
guess it's still better to not outright hide it in case it has a
possiblity to work.
Don't set meta `theme-color` by default (#24340) (#24346)
Backport #24340 by @silverwind
Fixes https://github.com/go-gitea/gitea/issues/24321. By not setting
this meta tag, Safari will use body color for chrome and out-of-viewport
areas, which looks much better then static mismatching green.
As per
[MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name/theme-color)
it's really only Apple browsers who still support this tag, most others
have dropped support.
Before:
<img width="347" alt="Screenshot 2023-04-25 at 19 59 13"
src="https://user-images.githubusercontent.com/115237/234363180-0fe667ef-5469-4f5f-b31a-c9d73aff10ac.png">
After:
<img width="361" alt="Screenshot 2023-04-25 at 20 00 00"
src="https://user-images.githubusercontent.com/115237/234363185-e2d2b62f-0133-4316-944d-b614ffb84eb0.png">
- Support `configuration variables`
([#43](https://gitea.com/gitea/act/pulls/43))
- Support specifying command for `services` containers
([#50](https://gitea.com/gitea/act/pulls/50))
projects / gitea.git / log