Giteabot [Wed, 20 Mar 2024 01:38:30 +0000 (09:38 +0800)]
Fix PR creation via api between branches of same repo with head field namespaced (#26986) (#29857)
Backport #26986 by @norohind
Fix #20175
Current implementation of API does not allow creating pull requests
between branches of the same
repo when you specify *namespace* (owner of the repo) in `head` field in
http request body.
Giteabot [Mon, 18 Mar 2024 06:45:43 +0000 (14:45 +0800)]
Editor error message misleading due to re-used key. (#29859) (#29876)
Backport #29859 by @buckybytes
The error message:
`editor.file_changed_while_editing = The file contents have changed
since you started editing. <a target="_blank" rel="noopener noreferrer"
href="%s">Click here</a> to see them or <strong>Commit Changes
again</strong> to overwrite them.`
Is re-used in inappropriate contexts. The link in the key goes to a 404
when the key is used in a situation where the file contents have not
changed.
Added two new keys to differentiate commit id mismatch and push out of
date conditions.
Lunny Xiao [Sun, 17 Mar 2024 01:40:06 +0000 (09:40 +0800)]
Fix codeowner detected diff base branch to mergebase (#29783) (#29807)
Fix #29763
Backport #29783
This PR fixes 2 problems with CodeOwner in the pull request.
- Don't use the pull request base branch but merge-base as a diff base
to detect the code owner.
- CodeOwner detection in fork repositories will be disabled because
almost all the fork repositories will not change CODEOWNERS files but it
should not be used on fork repositories' pull requests.
Use the upcoming
[Temporal.PlainDate](https://tc39.es/proposal-temporal/docs/plaindate.html)
via polyfill. If there is any remaining bugs in `<absolute-date>` this
will iron them out. I opted for the lightweight polyfill because both
seem to achieve our goal of localizeable absolute dates.
- With
[`@js-temporal/polyfill`](https://www.npmjs.com/package/@js-temporal/polyfill)
chunk size goes from 81.4 KiB to 274 KiB
- With
[`temporal-polyfill`](https://www.npmjs.com/package/temporal-polyfill)
chunk size goes from 81.4 KiB to 142 KiB
Also see [this
table](https://github.com/fullcalendar/temporal-polyfill?tab=readme-ov-file#comparison-with-js-temporalpolyfill)
for more comparisons of these polyfills. Soon there will be
[treeshakable
API](https://github.com/fullcalendar/temporal-polyfill?tab=readme-ov-file#tree-shakable-api)
as well which will further reduce size.
Giteabot [Thu, 14 Mar 2024 22:08:59 +0000 (06:08 +0800)]
Fix Safari spinner rendering (#29801) (#29802)
Backport #29801 by @silverwind
Fixes: https://github.com/go-gitea/gitea/issues/29041 Fixes: https://github.com/go-gitea/gitea/pull/29713
Any of the `width: *-content` properties seem to workaround this Webkit
bug, this one seemed most suitable.
Before:
<img width="184" alt="Screenshot 2024-03-14 at 22 29 58"
src="https://github.com/go-gitea/gitea/assets/115237/6effc5f0-bc64-4752-be74-9c43b3974407">
After:
<img width="177" alt="Screenshot 2024-03-14 at 22 30 30"
src="https://github.com/go-gitea/gitea/assets/115237/5de244d7-6b46-428e-957c-4b10f53e2441">
Giteabot [Thu, 14 Mar 2024 10:02:37 +0000 (18:02 +0800)]
Support GITEA_I_AM_BEING_UNSAFE_RUNNING_AS_ROOT env (#29788) (#29791)
Backport #29788 by @wolfogre
I was trying to run unit tests for Gitea on act runner, by using `make
test`.
It failed with log:
```
2024/03/14 03:09:26 ...s/setting/setting.go:180:loadRunModeFrom() [F] Gitea is not supposed to be run as root. Sorry. If you need to use privileged TCP ports please instead use setcap and the `cap_net_bind_service` permission
```
So it will be convenient to skip by setting environment, since it's OK
to use root user in job containers.
It's not a bug, but I want to backport it to v1.21 since it doesn't
break anything.
---------
Co-authored-by: Jason Song <i@wolfogre.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Giteabot [Wed, 13 Mar 2024 08:02:00 +0000 (16:02 +0800)]
Suppress error from monaco-editor (#29684) (#29758)
Backport #29684 by @silverwind
Fixes: https://github.com/go-gitea/gitea/issues/29414
I see no way for us to catch this error, so downgrade it until
https://github.com/microsoft/monaco-editor/issues/4325 is fixed, which
will likely take a few weeks to propagate up from vscode.
The entries in `updates.config.js` will make
[`updates`](https://github.com/silverwind/updates) not upgrade these
anymore and I think it's good documentation as well to have the reasons
why we don't upgrade these dependencies.
Giteabot [Wed, 13 Mar 2024 00:04:58 +0000 (08:04 +0800)]
Fix date rendering by adding `<gitea-absolute-date>` (#29725) (#29747)
Backport #29725 by @silverwind
Alternative to: https://github.com/go-gitea/gitea/pull/29698 Fixes: https://github.com/go-gitea/gitea/issues/29034
<img width="278" alt="image"
src="https://github.com/go-gitea/gitea/assets/115237/12ecd967-2723-410d-8a28-a1b0f41b7bba">
It also fixes a secondary issue that we were showing timestamp tooltips
over date, which makes no sense, so these are now gone as well:
Giteabot [Sun, 10 Mar 2024 17:29:17 +0000 (01:29 +0800)]
fix: rendering internal file links in org (#29669) (#29705)
Backport #29669 by @ankitrgadiya
The internal links to other files in the repository were not rendering
with the Src Prefix (/src/branch-name/file-path). This commit fixes that
by using the `SrcLink` as base if available.
This PR will fix the bug on migrations 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`
When logging out of Gitea, a error toast can be seen for a split second.
I don't know why or how it happens but I found it it's an `AbortError`
(related to
[AbortController#abort](https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort)),
so let's hide it.
Giteabot [Sat, 9 Mar 2024 00:40:05 +0000 (08:40 +0800)]
Use more specific selector for `name` links (#29679) (#29681)
Backport #29679 by @silverwind
Followup https://github.com/go-gitea/gitea/pull/29305. As per discussion
in https://github.com/go-gitea/gitea/pull/29666#discussion_r1517506422,
make this selector only search in the current `.markup` document, as
there can be multiples displayed at the same time.
This seeks to fix the bug reported on issue #29196.
Cause:
ID's with custom characters (- , _ , etc.), were not linking correctly
in the Markdown file when rendered in the browser because the ID in the
respective destinies would be different than the one in anchor, while
for IDs with only letters, the ID would be the same.
Fix:
It was suggested that to fix this bug, it should more or less like
GitHub does it. While in gitea the anchors would be put in HTML like
this:
```
<p dir="auto"><a href="#user-content-_toc152597800" rel="nofollow">Review</a></p>
<p dir="auto"><a href="#user-content-_toc152597802" rel="nofollow">Staging</a></p>
<p dir="auto"><a href="#user-content-_toc152597803" rel="nofollow">Development</a></p>
<p dir="auto"><a href="#user-content-_toc152597828" rel="nofollow">Testing</a></p>
<p dir="auto"><a href="#user-content-_toc152597829" rel="nofollow">Unit-tests</a></p>
```
In GitHub, the same anchor's href properties would be the same without
"user-content-" trailing behind.
So my code made sure to change those anchors, so it would not include
"user-content-" and then add respective Event Listeners so it would
scroll into the supposed places.
Fixes: #29196 Co-authored-by: DC <106393991+DanielMatiasCarvalho@users.noreply.github.com> Co-authored-by: silverwind <me@silverwind.io>
wxiaoguang [Sun, 3 Mar 2024 02:28:45 +0000 (10:28 +0800)]
Only use supported sort order for "explore/users" page (#29430) (#29443)
Backport #29430
Thanks to inferenceus : some sort orders on the "explore/users" page
could list users by their lastlogintime/updatetime.
It leaks user's activity unintentionally. This PR makes that page only
use "supported" sort orders.
Removing the "sort orders" could also be a good solution, while IMO at
the moment keeping the "create time" and "name" orders is also fine, in
case some users would like to find a target user in the search result,
the "sort order" might help.
Giteabot [Sat, 2 Mar 2024 19:40:06 +0000 (03:40 +0800)]
Fix queue worker incorrectly stopped when there are still more items in the queue (#29532) (#29546)
Backport #29532
Without `case <-t.C`, the workers would stop incorrectly, the test won't
pass. For the worse case, there might be only one running worker
processing the queue items for long time because other workers are
stopped. The root cause is related to the logic of doDispatchBatchToWorker.
It isn't a serious problem at the moment, so keep it as-is.
Giteabot [Sat, 2 Mar 2024 12:26:54 +0000 (20:26 +0800)]
Fix incorrect subpath in links (#29535) (#29541)
Backport #29535 by wxiaoguang
* `$referenceUrl`: it is constructed by "Issue.Link", which already has
the "AppSubURL"
* `window.location.href`: AppSubURL could be empty string, so it needs
the trailing slash
Giteabot [Sat, 2 Mar 2024 00:45:48 +0000 (08:45 +0800)]
Fix issue & comment history bugs (#29525) (#29527)
Backport #29525 by @wxiaoguang
* Follow #17746: `HasIssueContentHistory` should use expr builder to
make sure zero value (0) be respected.
* Add "doer" check to make sure `canSoftDeleteContentHistory` only be
called by sign-in users.
Giteabot [Fri, 1 Mar 2024 13:51:54 +0000 (21:51 +0800)]
Set pre-step status to `skipped` if job is skipped (#29489) (#29523)
Backport #29489 by @sillyguodong
close #27496
1. Set pre-step (Set up job) status to `skipped` if job is skipped.
2. Apart from pre-step, the other steps should also be set to `skipped`.
The status of other steps are reported from the runner side. This will
be completed by this PR: https://gitea.com/gitea/act_runner/pulls/500
- `e.error` can be undefined in some cases which would raise an error
inside this error handler, fixed that.
- The displayed message mentions looking into the console, but in my
case of error from `ResizeObserver` there was nothing there, so add this
logging. I think this logging was once there but got lost during
refactoring.
Giteabot [Wed, 28 Feb 2024 22:13:49 +0000 (06:13 +0800)]
Fix counter display number incorrectly displayed on the page (#29448) (#29478)
Backport #29448 by @charles7668
issue : #28239
The counter number script uses the 'checkbox' attribute to determine
whether an item is selected or not.
However, the input event only increments the counter value, and when
more items are displayed, it does not update all previously loaded
items.
As a result, the display becomes incorrect because it triggers the
update counter script, but checkboxes that are selected without the
'checked' attribute are not counted
Co-authored-by: charles <30816317+charles7668@users.noreply.github.com>
Giteabot [Wed, 28 Feb 2024 20:24:51 +0000 (04:24 +0800)]
Fix workflow trigger event bugs (#29467) (#29475)
Backport #29467 by @Zettat123
1. Fix incorrect `HookEventType` for issue-related events in
`IssueChangeAssignee`
2. Add `case "types"` in the `switch` block in `matchPullRequestEvent`
to avoid warning logs
Giteabot [Wed, 28 Feb 2024 11:22:31 +0000 (19:22 +0800)]
The job should always run when `if` is `always()` (#29464) (#29469)
Backport #29464 by @Zettat123
Fix #27906
According to GitHub's
[documentation](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds),
a job should always run when its `if` is `always()`
> If you would like a job to run even if a job it is dependent on did
not succeed, use the `always()` conditional expression in
`jobs.<job_id>.if`.
Giteabot [Tue, 27 Feb 2024 08:18:49 +0000 (16:18 +0800)]
Not trigger all jobs any more, when re-running the first job (#29439) (#29441)
Backport #29439 by @sillyguodong
Previously, it will be treated as "re-run all jobs" when `jobIndex ==
0`. So when you click re-run button on the first job, it triggers all
the jobs actually.
Giteabot [Mon, 26 Feb 2024 09:26:23 +0000 (17:26 +0800)]
Fix incorrect tree path value for patch editor (#29377) (#29421)
Backport #29377 by wxiaoguang
Regression of #18718. When submitting the form,
EditRepoFileForm.TreePath is marked as "Required", so the value can't be
empty. The value is not used by backend, so use a meaningful dummy value
for it.
Lunny Xiao [Fri, 23 Feb 2024 07:46:56 +0000 (15:46 +0800)]
Adjust changelog for v1.21.6 to move prs to correct labels (#29339)
When releasing, the releaser should read all the pull requests carefully
and do some adjustments because some of pull requests' labels are not
right when it's merged.
And the changelog tool needs to be adjusted. If one pull request has
both `bug` and `API`, it should mark it as `bug` but not `API`.
Giteabot [Thu, 22 Feb 2024 21:49:07 +0000 (05:49 +0800)]
Don't show third-party JS errors in production builds (#29303) (#29333)
Backport #29303 by @silverwind
So we don't get issues like
https://github.com/go-gitea/gitea/issues/29080 and
https://github.com/go-gitea/gitea/issues/29273 any more. Only active in
[production
builds](https://webpack.js.org/guides/production/#specify-the-mode), in
non-production the errors will still show.
6543 [Thu, 22 Feb 2024 20:45:31 +0000 (21:45 +0100)]
Remove SSH workaround (#27893) (#29332)
Backport #27893
- Update github.com/gliderlabs/ssh to include
https://github.com/gliderlabs/ssh/commit/02f9d573009f8c13755b6b90fa14a4f549b17b22.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1230
Giteabot [Thu, 22 Feb 2024 16:19:48 +0000 (00:19 +0800)]
Improve the `issue_comment` workflow trigger event (#29277) (#29322)
Backport #29277 by @Zettat123
Fix #29175
Replace #29207
This PR makes some improvements to the `issue_comment` workflow trigger
event.
1. Fix the bug that pull requests cannot trigger `issue_comment`
workflows
2. Previously the `issue_comment` event only supported the `created`
activity type. This PR adds support for the missing `edited` and
`deleted` activity types.
3. Some events (including `issue_comment`, `issues`, etc. ) only trigger
workflows that belong to the workflow file on the default branch. This
PR introduces the `IsDefaultBranchWorkflow` function to check for these
events.
yp05327 [Thu, 22 Feb 2024 03:55:03 +0000 (12:55 +0900)]
Implement some action notifier functions (#29173) (#29308)
Backport #29173
Fix #29166
Add support for the following activity types of `pull_request`
- assigned
- unassigned
- review_requested
- review_request_removed
- milestoned
- demilestoned
KN4CK3R [Thu, 22 Feb 2024 03:20:20 +0000 (04:20 +0100)]
Prevent double use of `git cat-file` session. (#29298) (#29301)
Backport #29298
Fixes the reason why #29101 is hard to replicate.
Related #29297
Create a repo with a file with minimum size 4097 bytes (I use 10000) and
execute the following code:
```go
gitRepo, err := gitrepo.OpenRepository(db.DefaultContext, <repo>)
assert.NoError(t, err)
// Create a second reader
r2, err := b.DataAsync()
assert.NoError(t, err) // Should be no error but is ErrNotExist
defer r2.Close()
```
The problem is the check in `CatFileBatch`:
https://github.com/go-gitea/gitea/blob/79217ea63c1f77de7ca79813ae45950724e63d02/modules/git/repo_base_nogogit.go#L81-L87
`Buffered() > 0` is used to check if there is a "operation" in progress
at the moment. This is a problem because we can't control the internal
buffer in the `bufio.Reader`. The code above demonstrates a sequence
which initiates an operation for which the code thinks there is no
active processing. The second call to `DataAsync()` therefore reuses the
existing instances instead of creating a new batch reader.
projects / gitea.git / log