This padding causes visual bug, because it only applies to the first line and not to the rest in case the line is broken into multiple.
I don't think it's actually needed here for good look, so I decided to remove it. In case decreased padding looks worse, the padding can be grown back via other element so it wouldn't cause this bug.
Preview: https://codeberg.org/attachments/56fd2ee8-4955-409d-998f-1feba987b9af
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4318
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
A test must not fail depending on the performance of the machine it
runs on. It creates false negative and serves no purpose. These are
not benchmark tests for the hardware running them.
When a new go version is published, it takes about 24h for
https://github.com/actions/go-versions to be updated (see
https://github.com/actions/go-versions/pull/102 for example).
In the meantime the setup-go action that depends on it will install a
version of go that fails golang.org/x/vuln/cmd/govulncheck.
Move the security check to be the last step of the test job instead of
the first. It will still block the PRs from being merged but it will
allow the PR authors to keep working and look at the test results in
the meantime.
Fixes: https://codeberg.org/forgejo/forgejo/issues/4294
If a repository has
git config --add push.pushOption submit=".sourcehut/*.yml"
it failed when pushed because of the unknown submit push
option. It will be ignored instead.
Filtering out the push options is done in an earlier stage, when the
hook command runs, before it submits the options map to the private
endpoint.
* move all the push options logic to modules/git/pushoptions
* add 100% test coverage for modules/git/pushoptions
Test coverage for the code paths from which code was moved to the
modules/git/pushoptions package:
* cmd/hook.go:runHookPreReceive
* routers/private/hook_pre_receive.go:validatePushOptions
tests/integration/git_push_test.go:TestOptionsGitPush runs through
both. The test verifying the option is rejected was removed and, if
added again, will fail because the option is now ignored instead of
being rejected.
* cmd/hook.go:runHookProcReceive
* services/agit/agit.go:ProcReceive
tests/integration/git_test.go: doCreateAgitFlowPull runs through
both. It uses variations of AGit related push options.
* cmd/hook.go:runHookPostReceive
* routers/private/hook_post_receive.go:HookPostReceive
tests/integration/git_test.go:doPushCreate called by TestGit/HTTP/sha1/PushCreate
runs through both.
Note that although it provides coverage for this code path it does not use push options.
Fixes: https://codeberg.org/forgejo/forgejo/issues/3651
It is entirely possible that the difference between the specified
sleep time and the actual sleep time is greater than 15 seconds.
https://developer.mozilla.org/en-US/docs/Web/API/setTimeout#Notes
> Note that in either case, the actual delay may be longer than
> intended; see Reasons for delays longer than specified below.
It is however an error for the delay to be shorter.
⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
FAIL web_src/js/utils.test.js > sleep
AssertionError: expected false to be truthy
❯ testSleep web_src/js/utils.test.js:192:48
190| const endTime = Date.now(); // Record the end time
191| const actualSleepTime = endTime - startTime;
192| expect(Math.abs(actualSleepTime - ms) <= 15).toBeTruthy();
| ^
193| }
194|
❯ web_src/js/utils.test.js:184:3
We haven't decided much (to my knowledge), and I've been using the main branch in production (as one does) and found out even I myself rely on Tab sometimes working to move focus and have been caught off guard by it indenting lines instead.
So this removes Tab handling and instead adds two new buttons to the toolbar. The indentation logic is unchanged (other than now focusing the textarea during button handling, to ensure execCommand works, and thus undo history is preserved).
I'm not sure which terminology to use in tooltips. Could also add keyboard shortcuts for the whole toolbar eventually, but as is this is hopefully an better solution to the problems I previously created than un-merging the whole thing :)
<img width="414" alt="Screenshot with two new buttons" src="/attachments/b7af3aa4-a195-48d1-be0a-1559f25dce8e">
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4263
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Danko Aleksejevs <danko@very.lv>
Co-committed-by: Danko Aleksejevs <danko@very.lv>
#3654 introduced support for searching non-default branches and tags.
However, the results page lacked any indicator (aside from the url) on which branch/tag the searcg was performed. A branch dropdown was introduced to the code search page when git-grep is used both as an indicator and as a intrusive way to switch between branches/tags.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4262
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Support legacy _links LFS batch response.
Fixes#31512.
This is backwards-compatible change to the LFS client so that, upon
mirroring from an upstream which has a batch api, it can download
objects whether the responses contain the `_links` field or its
successor the `actions` field. When Gitea must fallback to the legacy
`_links` field a logline is emitted at INFO level which looks like this:
```
...s/lfs/http_client.go:188:performOperation() [I] <LFSPointer ee95d0a27ccdfc7c12516d4f80dcf144a5eaf10d0461d282a7206390635cdbee:160> is using a deprecated batch schema response!
```
I've only run `test-backend` with this code, but added a new test to
cover this case. Additionally I have a fork with this change deployed
which I've confirmed syncs LFS from Gitea<-Artifactory (which has legacy
`_links`) as well as from Gitea<-Gitea (which has the modern `actions`).
Signed-off-by: Royce Remer <royceremer@gmail.com>
(cherry picked from commit df805d6ed0458dbec258d115238fde794ed4d0ce)
