Remove unused CSRF options, decouple "new csrf protector" and "prepare"
logic, do not redirect to home page if CSRF validation falis (it
shouldn't happen in daily usage, if it happens, redirecting to home
doesn't help either but just makes the problem more complex for "fetch")
Simon Pistache [Mon, 16 Sep 2024 20:41:46 +0000 (22:41 +0200)]
feat(#31666): Set the columns height to hug all its contents (#31726)
In Projects, columns heights are defined by the sum of all contents
height of the biggest column, rather than a fraction of the viewport
height. It default to 60vh when there is no cards to display.
Kemal Zebari [Thu, 12 Sep 2024 07:47:31 +0000 (00:47 -0700)]
Handle invalid target when creating releases using API (#31841)
A 500 status code was thrown when passing a non-existent target to the
create release API. This snapshot handles this error and instead throws
a 404 status code.
**Note** that implementation was made intentionally to work same as in
issue list so that URL can be bookmarked for quick access with
predefined filters in URL
Fix `/repos/{owner}/{repo}/pulls/{index}/files` endpoint not populating `previous_filename` (#32017)
---
`status == "rename"` should have read `status == "renamed"`. The typo
means that file.PreviousFilename would never be populated, which e.g.
breaks usage of the Github Action at
https://github.com/dorny/paths-filter.
This PR adds support for migrating repos from [AWS
CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html).
The access key ID and secret access key are required to get repository
information and pull requests. And [HTTPS Git
credentials](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html)
are required to clone the repository.
Jason Song [Mon, 9 Sep 2024 21:34:42 +0000 (05:34 +0800)]
Enable compression for Actions logs by default (#32013)
Close #31801. Follow #31761.
Since there are so many benefits of compression and there are no reports
of related issues after weeks, it should be fine to enable compression
by default.
Save initial signup information for users to aid in spam prevention (#31852)
This will allow instance admins to view signup pattern patterns for
public instances. It is modelled after discourse, mastodon, and
MediaWiki's approaches.
Note: This has privacy implications, but as the above-stated open-source
projects take this approach, especially MediaWiki, which I have no doubt
looked into this thoroughly, it is likely okay for us, too. However, I
would be appreciative of any feedback on how this could be improved.
Jason Song [Mon, 9 Sep 2024 04:51:25 +0000 (12:51 +0800)]
Increase `cacheContextLifetime` to reduce false reports (#32011)
Replace #32001.
To prevent the context cache from being misused for long-term work
(which would result in using invalid cache without awareness), the
context cache is designed to exist for a maximum of 10 seconds. This
leads to many false reports, especially in the case of slow SQL.
This PR increases it to 5 minutes to reduce false reports.
5 minutes is not a very safe value, as a lot of changes may have
occurred within that time frame. However, as far as I know, there has
not been a case of misuse of context cache discovered so far, so I think
5 minutes should be OK.
Please note that after this PR, if warning logs are found again, it
should get attention, at that time it can be almost 100% certain that it
is a misuse.
Remove SHA1 for support for ssh rsa signing (#31857)
https://github.com/go-fed/httpsig seems to be unmaintained.
Switch to github.com/42wim/httpsig which has removed deprecated crypto
and default sha256 signing for ssh rsa.
No impact for those that use ed25519 ssh certificates.
This is a breaking change for:
- gitea.com/gitea/tea (go-sdk) - I'll be sending a PR there too
- activitypub using deprecated crypto (is this actually used?)
Add automatic light/dark option for the colorblind theme (#31997)
The normal themes already have a variant which automatically chooses
light/dark mode based on the browser.
This PR adds the same variant, but for the colorblind themes.
Distinguish official vs non-official reviews, add tool tips, and upgr… (#31924)
This Pull Request is a follow up to
https://github.com/go-gitea/gitea/pull/31886:
1. Adds a UI indicator between official (green) and unofficial (grey)
approved pull requests on the Pull Request page (as suggested by
@kdumontnu )
2. Adds tooltips adding clarity to the type and status of a review on
the Pull Request page (as suggested by @kdumontnu)
3. Updates text adding more clarity to required approvals (as suggested
by @kdumontnu)
4. Updates text on the branch settings page explaining what branch
approval limitations (as suggested by @yp05327)
Official approval:
<img width="376" alt="Screenshot 2024-08-26 at 1 03 52 PM"
src="https://github.com/user-attachments/assets/500f083d-bfc0-45c5-82b7-b98e20495696">
Updated text for approvals:
<img width="991" alt="Screenshot 2024-08-26 at 12 54 00 PM"
src="https://github.com/user-attachments/assets/ab3ff012-9742-4c1b-933d-21addcb89f2c">
Updated text for allowlisted/whitelisted approvals:
<img width="990" alt="Screenshot 2024-08-26 at 1 01 40 PM"
src="https://github.com/user-attachments/assets/1a5bae61-d9e0-4d96-b86f-92610b0940d1">
Removes all URLs from translation strings to easy up changing them in
the future and to exclude people injecting malicious URLs through
translations. First measure as long as #24402 is out of scope.
Prevent update pull refs manually and will not affect other refs update (#31931)
All refs under `refs/pull` should only be changed from Gitea inside but
not by pushing from outside of Gitea.
This PR will prevent the pull refs update but allow other refs to be
updated on the same pushing with `--mirror` operations.
The main changes are to add checks on `update` hook but not
`pre-receive` because `update` will be invoked by every ref but
`pre-receive` will revert all changes once one ref update fails.
Fix sort order for organization home and user profile page (#31921)
Fix #31916
In #30876, `sortOrder` has been changed into a map, but it is only
implemented in explore.
~~But it seems that size sort order has no effect from long long ago,~~
not directly caused by the PR above.
I think it is still caused by #29231.
In #29231, it merged the sort orders from
`templates/explore/repo_search.tmpl` and
`templates/admin/repo/search.tmpl`.
In `templates/admin/repo/search.tmpl`, it contains size sort orders, but
not in `templates/explore/repo_search.tmpl`, which is used in non-admin
pages.
So `order by size` is added from #29231, but the handler was not added.
- When pasting a URL over another URL, replace the URL instead of
creating a useless `[url](url)`. This is the 1-line change
[here](https://github.com/go-gitea/gitea/pull/31948/files#diff-be8e94d7e3da33b187381f53d28095107bd0cf29ae9a9e997e4f422f4a54479cR122).
- Always run `initTextareaEvents`, previously it was not run when
`dropzoneEl` was not present like when attachements are disabled on the
server. Refactored the function to gracefully handle absent `dropzoneEl`
and rename the function to a better name.
silverwind [Thu, 29 Aug 2024 14:51:51 +0000 (16:51 +0200)]
Update JS and PY dependencies (#31940)
- `stylelint` is excluded because of deprecation warnings added in
16.8.2, depending on
https://github.com/AndyOGo/stylelint-declaration-strict-value/issues/379
- `eslint-plugin-sonarjs@2` adds a lot of new rules, but I have not
gotten around to reviewing them yet, so rule config is unchanged.
- Fixes https://github.com/go-gitea/gitea/security/dependabot/70
- Tested code editor and contributor graph
Jason Song [Thu, 29 Aug 2024 03:48:21 +0000 (11:48 +0800)]
Refactor globallock (#31933)
Follow #31908. The main refactor is that it has removed the returned
context of `Lock`.
The returned context of `Lock` in old code is to provide a way to let
callers know that they have lost the lock. But in most cases, callers
shouldn't cancel what they are doing even it has lost the lock. And the
design would confuse developers and make them use it incorrectly.
See the discussion history:
https://github.com/go-gitea/gitea/pull/31813#discussion_r1732041513 and
https://github.com/go-gitea/gitea/pull/31813#discussion_r1734078998
It's a breaking change, but since the new module hasn't been used yet, I
think it's OK to not add the `pr/breaking` label.
## Design principles
It's almost copied from #31908, but with some changes.
### Use spinlock even in memory implementation (unchanged)
In actual use cases, users may cancel requests. `sync.Mutex` will block
the goroutine until the lock is acquired even if the request is
canceled. And the spinlock is more suitable for this scenario since it's
possible to give up the lock acquisition.
Although the spinlock consumes more CPU resources, I think it's
acceptable in most cases.
### Do not expose the mutex to callers (unchanged)
If we expose the mutex to callers, it's possible for callers to reuse
the mutex, which causes more complexity.
For example:
```go
lock := GetLocker(key)
lock.Lock()
// ...
// even if the lock is unlocked, we cannot GC the lock,
// since the caller may still use it again.
lock.Unlock()
lock.Lock()
// ...
lock.Unlock()
// callers have to GC the lock manually.
RemoveLocker(key)
```
In this PR, we only expose `ReleaseFunc` to callers. So callers just
need to call `ReleaseFunc` to release the lock, and do not need to care
about the lock's lifecycle.
```go
release, err := locker.Lock(ctx, key)
if err != nil {
return err
}
// ...
release()
// if callers want to lock again, they have to re-acquire the lock.
release, err := locker.Lock(ctx, key)
// ...
```
In this way, it's also much easier for redis implementation to extend
the mutex automatically, so that callers do not need to care about the
lock's lifecycle. See also
https://github.com/go-gitea/gitea/pull/31813#discussion_r1722659743
### Use "release" instead of "unlock" (unchanged)
For "unlock", it has the meaning of "unlock an acquired lock". So it's
not acceptable to call "unlock" when failed to acquire the lock, or call
"unlock" multiple times. It causes more complexity for callers to decide
whether to call "unlock" or not.
So we use "release" instead of "unlock" to make it clear. Whether the
lock is acquired or not, callers can always call "release", and it's
also safe to call "release" multiple times.
But the code DO NOT expect callers to not call "release" after acquiring
the lock. If callers forget to call "release", it will cause resource
leak. That's why it's always safe to call "release" without extra
checks: to avoid callers to forget to call it.
### Acquired locks could be lost, but the callers shouldn't stop
Unlike `sync.Mutex` which will be locked forever once acquired until
calling `Unlock`, for distributed lock, the acquired lock could be lost.
For example, the caller has acquired the lock, and it holds the lock for
a long time since auto-extending is working for redis. However, it lost
the connection to the redis server, and it's impossible to extend the
lock anymore.
In #31908, it will cancel the context to make the operation stop, but
it's not safe. Many operations are not revert-able. If they have been
interrupted, then the instance goes corrupted. So `Lock` won't return
`ctx` anymore in this PR.
Jason Song [Mon, 26 Aug 2024 14:27:57 +0000 (22:27 +0800)]
Introduce globallock as distributed locks (#31908)
To help #31813, but do not replace it, since this PR just introduces the
new module but misses some work:
- New option in settings. `#31813` has done it.
- Use the locks in business logic. `#31813` has done it.
So I think the most efficient way is to merge this PR first (if it's
acceptable) and then finish #31813.
## Design principles
### Use spinlock even in memory implementation
In actual use cases, users may cancel requests. `sync.Mutex` will block
the goroutine until the lock is acquired even if the request is
canceled. And the spinlock is more suitable for this scenario since it's
possible to give up the lock acquisition.
Although the spinlock consumes more CPU resources, I think it's
acceptable in most cases.
### Do not expose the mutex to callers
If we expose the mutex to callers, it's possible for callers to reuse
the mutex, which causes more complexity.
For example:
```go
lock := GetLocker(key)
lock.Lock()
// ...
// even if the lock is unlocked, we cannot GC the lock,
// since the caller may still use it again.
lock.Unlock()
lock.Lock()
// ...
lock.Unlock()
// callers have to GC the lock manually.
RemoveLocker(key)
```
In this PR, we only expose `ReleaseFunc` to callers. So callers just
need to call `ReleaseFunc` to release the lock, and do not need to care
about the lock's lifecycle.
```go
_, release, err := locker.Lock(ctx, key)
if err != nil {
return err
}
// ...
release()
// if callers want to lock again, they have to re-acquire the lock.
_, release, err := locker.Lock(ctx, key)
// ...
```
In this way, it's also much easier for redis implementation to extend
the mutex automatically, so that callers do not need to care about the
lock's lifecycle. See also
https://github.com/go-gitea/gitea/pull/31813#discussion_r1722659743
### Use "release" instead of "unlock"
For "unlock", it has the meaning of "unlock an acquired lock". So it's
not acceptable to call "unlock" when failed to acquire the lock, or call
"unlock" multiple times. It causes more complexity for callers to decide
whether to call "unlock" or not.
So we use "release" instead of "unlock" to make it clear. Whether the
lock is acquired or not, callers can always call "release", and it's
also safe to call "release" multiple times.
But the code DO NOT expect callers to not call "release" after acquiring
the lock. If callers forget to call "release", it will cause resource
leak. That's why it's always safe to call "release" without extra
checks: to avoid callers to forget to call it.
### Acquired locks could be lost
Unlike `sync.Mutex` which will be locked forever once acquired until
calling `Unlock`, in the new module, the acquired lock could be lost.
For example, the caller has acquired the lock, and it holds the lock for
a long time since auto-extending is working for redis. However, it lost
the connection to the redis server, and it's impossible to extend the
lock anymore.
If the caller don't stop what it's doing, another instance which can
connect to the redis server could acquire the lock, and do the same
thing, which could cause data inconsistency.
So the caller should know what happened, the solution is to return a new
context which will be canceled if the lock is lost or released:
silverwind [Sun, 25 Aug 2024 17:23:13 +0000 (19:23 +0200)]
Update mermaid to v11 (#31913)
Update mermaid to
[v11](https://github.com/mermaid-js/mermaid/releases/tag/v11.0.0) and
enable the new [`suppressErrorRendering`
option](https://github.com/mermaid-js/mermaid/pull/4359) to ensure
mermaid never renders error elements into the DOM (we have per-chart
error rendering, so don't need it). Tested various chart types.
BTW, I was unable to reproduce that error rendering from mermaid with
`suppressErrorRendering: false` and I thought we had some CSS to hide
the error element, but I could not find it, not even in git history.
william-allspice [Wed, 21 Aug 2024 05:40:18 +0000 (00:40 -0500)]
Move lock icon position and add additional tooltips to branch list page (#31839)
This Pull Request adds missing tool tips for the protected, copy, and rss icons on the branch list page. It also moved protected icon position after the branch name.
Lunny Xiao [Tue, 20 Aug 2024 17:04:57 +0000 (01:04 +0800)]
Refactor the usage of batch catfile (#31754)
When opening a repository, it will call `ensureValidRepository` and also
`CatFileBatch`. But sometimes these will not be used until repository
closed. So it's a waste of CPU to invoke 3 times git command for every
open repository.
This PR removed all of these from `OpenRepository` but only kept
checking whether the folder exists. When a batch is necessary, the
necessary functions will be invoked.
胖梁 [Mon, 19 Aug 2024 02:38:40 +0000 (10:38 +0800)]
Actions support workflow dispatch event (#28163)
fix #23668
My plan:
* In the `actions.list` method, if workflow is selected and IsAdmin,
check whether the on event contains `workflow_dispatch`. If so, display
a `Run workflow` button to allow the user to manually trigger the run.
* Providing a form that allows users to select target brach or tag, and
these parameters can be configured in yaml
* Simple form validation, `required` input cannot be empty
* Add a route `/actions/run`, and an `actions.Run` method to handle
* Add `WorkflowDispatchPayload` struct to pass the Webhook event payload
to the runner when triggered, this payload carries the `inputs` values
and other fields, doc: [workflow_dispatch
payload](https://docs.github.com/en/webhooks/webhook-events-and-payloads#workflow_dispatch)
Other PRs
* the `Workflow.WorkflowDispatchConfig()` method still return non-nil
when workflow_dispatch is not defined. I submitted a PR
https://gitea.com/gitea/act/pulls/85 to fix it. Still waiting for them
to process.
Behavior should be same with github, but may cause confusion. Here's a
quick reminder.
*
[Doc](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)
Said: This event will `only` trigger a workflow run if the workflow file
is `on the default branch`.
* If the workflow yaml file only exists in a non-default branch, it
cannot be triggered. (It will not even show up in the workflow list)
* If the same workflow yaml file exists in each branch at the same time,
the version of the default branch is used. Even if `Use workflow from`
selects another branch
```yaml
name: Docker Image CI
Adrian Hirt [Sat, 17 Aug 2024 03:34:27 +0000 (05:34 +0200)]
Fix overflowing content in action run log (#31842)
When a long line with characters such as dots is returned by a step in
an action (e.g. by the output of the Ruby on Rails test runner), it
overflows the log container, causing the page to scroll sideways.
This PR adds the CSS `overflow-wrap: anywhere;` to the
`.job-step-section .job-step-logs .job-log-line .log-msg` selector,
which causes such lines to wrap as well
Jason Song [Fri, 16 Aug 2024 17:04:54 +0000 (01:04 +0800)]
Avoid returning without written ctx when posting PR (#31843)
Fix #31625.
If `pull_service.NewPullRequest` return an error which misses each `if`
check, `CompareAndPullRequestPost` will return immediately, since it
doesn't write the HTTP response, a 200 response with empty body will be
sent to clients.
Not sure what kind of error can cause it to happen, so this PR just
expose it. And we can fix it when users report that creating PRs failed
with error responses.
It's all my guess since I cannot reproduce the problem, but even if it's
not related, the code here needs to be improved.
Zettat123 [Fri, 16 Aug 2024 12:40:51 +0000 (20:40 +0800)]
Fix raw wiki links (#31825)
Fix #31395
This regression is introduced by #30273. To find out how GitHub handles
this case, I did [some
tests](https://github.com/go-gitea/gitea/issues/31395#issuecomment-2278929115).
I use redirect in this PR instead of checking if the corresponding `.md`
file exists when rendering the link because GitHub also uses redirect.
With this PR, there is no need to resolve the raw wiki link when
rendering a wiki page. If a wiki link points to a raw file, access will
be redirected to the raw link.
yp05327 [Thu, 15 Aug 2024 16:34:24 +0000 (01:34 +0900)]
Add missing repository type filter parameters to pager (#31832)
Fix #31807
ps: the newly added params's value will be changed.
When the first time you selected the filter, the values of params will
be `0` or `1`
But in pager it will be `true` or `false`.
So do we have `boolToInt` function?
Rowan Bohde [Wed, 14 Aug 2024 21:50:09 +0000 (16:50 -0500)]
render plain text file if the LFS object doesn't exist (#31812)
We had an issue where a repo was using LFS to store a file, but the user
did not push the file. When trying to view the file, Gitea returned a
500 HTTP status code referencing `ErrLFSObjectNotExist`. It appears the
intent was the render this file as plain text, but the conditional was
flipped. I've also added a test to verify that the file is rendered as
plain text.
Edip Emre Bodur [Tue, 13 Aug 2024 02:53:43 +0000 (05:53 +0300)]
Fixes for unreachable project issues when transfer repository from organization (#31770)
When transferring repositories that have issues linked to a project
board to another organization, the issues remain associated with the
original project board. This causes the columns in the project board to
become bugged, making it difficult to move other issues in or out of the
affected columns. As a solution, I removed the issue relations since the
other organization does not have this project table.
Simon Priet [Mon, 12 Aug 2024 23:36:28 +0000 (01:36 +0200)]
Scroll images in project issues separately from the remaining issue (#31683)
As discussed in #31667 & #26561, when a card on a Project contains
images, they can overflow the card on its containing column. This aims
to fix this issue via snapping scrollbars.
---
Issue #31667 is open to discussion as there should be room for
improvement.
silverwind [Mon, 12 Aug 2024 00:40:18 +0000 (02:40 +0200)]
Add `:focus-visible` style to buttons (#31799)
Buttons now show a focus style via
[`:focus-visible`](https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible)
when the browser deems the focus to be important, like for example when
the button is focused via keyboard navigation.
Fábio Barkoski [Sun, 11 Aug 2024 04:50:54 +0000 (01:50 -0300)]
Move repository visibility to danger zone in the settings area (#31126)
Moved repository visibility to the danger zone in the settings area. To
change the visibility, it is necessary to go to the danger zone, click
on the private/public button, and accept the change in the modal.
projects / gitea.git / log