- Remove a unused dependency. This dependency was added to handle YAML
'frontmatter' meta, parsing them and converting them to a table or
details in the resulting HTML. As can be read in the issue that reported
the behavior of YAML frontmatter being rendered literally,
https://github.com/go-gitea/gitea/issues/5377.
- It's an unused dependency as the codebase since then moved on to do this YAML
parsing and rendering on their own, this was implemented in
812cfd0ad9.
- Adds unit tests that was related to this functionality, to proof the
codebase already handles this and to prevent regressions.
- It was noticed [in the Forgejo matrix channel](https://matrix.to/#/!qjPHwFPdxhpLkXMkyP:matrix.org/$vk78UR0eFCwQMDMTZ7-DWjMVB_LIAwHW6SkjhEcGkQQ?via=matrix.org) that the generation of the Forgejo project contributor stats was taking quite a while on codeberg.org. This was continued with the fact that a few moments later it was once again generating them again; it seemed like they weren't being cached while they were.
- The problem was that the cache TTL is hardcoded to ten minutes and not to the configured TTL. This patch changes that by using the configured TLL for the contributor cache, as this is a computationally heavy operation and should be cached for as long as possible for a good user experience. This doesn't impact the accuracy of this feature because the commit ID of the default branch is used as a cache key.
- Also changed in this patch, is that errors aren't cached and are instead being logged, this is more helpful to the administrator. For the user essentially nothing changed on this side, the contributor stats just looks like it's loading indefinitely.
- Realistically, testing this isn't possible, as the cache library Forgejo currently uses doesn't expose the TTL or expiration time of a key. Manually testing this behavior is quite lengthy, as one of the steps would need to be "wait for ten minutes" and describe how you can notice the data was cached or was just generated, and because you could use different types of cache, it will be quite hard to write down how you could check the TTL of a key for a particular cache (I'm not even sure it's even possible for some).
- Update the `github.com/buildkite/terminal-to-html/v3` dependency from
version v3.10.1 to v3.13.0.
- Version v3.12.0 introduced an incompatible change, the return type of
`AsHTML` changed from `[]byte` to `string`. That same version also
introduced streaming mode
https://github.com/buildkite/terminal-to-html/pull/126, which allows us
to avoid reading the whole input into memory.
- Closes#4313
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
