Include collaboration repositories on dashboard source/forks/mirrors list (#31946) (#32122)
Backport #31946 by @lunny
Fix #13489
In the original implementation, only `All` will display your owned and
collaborated repositories. For other filters like `Source`, `Mirrors`
and etc. will only display your owned repositories.
This PR removed the limitations. Now except `collbrations`, other
filters will always display your owned and collaborated repositories.
This PR addresses the missing `bin` field in Composer metadata, which
currently causes vendor-provided binaries to not be symlinked to
`vendor/bin` during installation.
In the current implementation, running `composer install` does not
publish the binaries, leading to issues where expected binaries are not
available.
By properly declaring the `bin` field, this PR ensures that binaries are
correctly symlinked upon installation, as described in the [Composer
documentation](https://getcomposer.org/doc/articles/vendor-binaries.md).
Handle invalid target when creating releases using API (#31841) (#32043)
Backport #31841 by @kemzeb
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.
Discovered while working on #31840.
Co-authored-by: Kemal Zebari <60799661+kemzeb@users.noreply.github.com>
Fix `/repos/{owner}/{repo}/pulls/{index}/files` endpoint not populating `previous_filename` (#32017) (#32028)
Backport #32017 by @charles-plutohealth
---
`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.
Support allowed hosts for migrations to work with proxy (#32025) (#32026)
Backport #32025 by @wolfogre
Fix #32024. Follow #27655.
After this PR, all usage of "new dial context" needs to provide a proxy,
so I dropped the old `NewDialContext` and renamed
`NewDialContextWithProxy` to `NewDialContext`.
Increase `cacheContextLifetime` to reduce false reports (#32011) (#32023)
Backport #32011 by @wolfogre
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.
Prevent update pull refs manually and will not affect other refs update (#31931) (#31955)
Backport #31931 by @lunny
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.
Giteabot [Tue, 20 Aug 2024 17:55:14 +0000 (01:55 +0800)]
Refactor the usage of batch catfile (#31754) (#31889)
Backport #31754 by @lunny
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.
Giteabot [Sun, 18 Aug 2024 00:34:05 +0000 (08:34 +0800)]
Fix overflowing content in action run log (#31842) (#31853)
Backport #31842 by @Adrian-Hirt
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 (see
first screenshot):
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 (see second screenshot in which
the line wraps nicely):
Giteabot [Sat, 17 Aug 2024 03:19:26 +0000 (11:19 +0800)]
Fix raw wiki links (#31825) (#31845)
Backport #31825 by @Zettat123
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.
Giteabot [Fri, 16 Aug 2024 17:50:12 +0000 (01:50 +0800)]
Avoid returning without written ctx when posting PR (#31843) (#31848)
Backport #31843 by @wolfogre
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.
Giteabot [Fri, 16 Aug 2024 12:41:45 +0000 (20:41 +0800)]
Add missing repository type filter parameters to pager (#31832) (#31837)
Backport #31832 by @yp05327
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?
Giteabot [Wed, 14 Aug 2024 01:57:23 +0000 (09:57 +0800)]
Fixes for unreachable project issues when transfer repository from organization (#31770) (#31828)
Backport #31770 by @emrebdr
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.
Fix for #31538
Co-authored-by: Edip Emre Bodur <emrebdr29@gmail.com> Co-authored-by: Jason Song <i@wolfogre.com>
Giteabot [Tue, 13 Aug 2024 02:43:48 +0000 (10:43 +0800)]
Scroll images in project issues separately from the remaining issue (#31683) (#31823)
Backport #31683 by @SimonPistache
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.
Co-authored-by: Simon Priet <105607989+SimonPistache@users.noreply.github.com>
Giteabot [Mon, 12 Aug 2024 04:41:13 +0000 (12:41 +0800)]
Add `:focus-visible` style to buttons (#31799) (#31819)
Backport #31799 by @silverwind
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.
Giteabot [Fri, 9 Aug 2024 07:43:23 +0000 (15:43 +0800)]
Fix `IsObjectExist` with gogit (#31790) (#31806)
Backport #31790 by @wolfogre
Fix #31271.
When gogit is enabled, `IsObjectExist` calls
`repo.gogitRepo.ResolveRevision`, which is not correct. It's for
checking references not objects, it could work with commit hash since
it's both a valid reference and a commit object, but it doesn't work
with blob objects.
So it causes #31271 because it reports that all blob objects do not
exist.
Giteabot [Thu, 8 Aug 2024 03:08:30 +0000 (11:08 +0800)]
Fix protected branch files detection on pre_receive hook (#31778) (#31796)
Backport #31778 by @lunny
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.
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.
Distinguish LFS object errors to ignore missing objects during migration (#31702) (#31745)
Backport #31702 by @wolfogre
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.
Remove unneccessary uses of `word-break: break-all` (#31637) (#31652)
Backport #31637 by @silverwind
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.
Fix: Allow org team names of length 255 in create team form (#31564) (#31603)
Backport #31564 by @tobiasbp
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
Jimmy Praet [Fri, 5 Jul 2024 12:40:45 +0000 (14:40 +0200)]
Return an empty string when a repo has no avatar in the repo API (#31187) (#31567)
Backport #31187
Resolves #31167.
https://github.com/go-gitea/gitea/pull/30885 changed the behavior of
`repo.AvatarLink()` where it can now take the empty string and append it
to the app data URL. This does not point to a valid avatar image URL,
and, as the issue mentions, previous Gitea versions returned the empty
string.
Co-authored-by: Kemal Zebari <60799661+kemzeb@users.noreply.github.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix slow patch checking with commits that add or remove many files (#31548) (#31560)
Backport #31548 by @brechtvl
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.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
projects / gitea.git / log