This commit adds a new flag, `--keep-labels`, to the runner registration CLI command. If this flag is present and the runner being registered already exists, it will prevent the runners' labels from being reset.
In order to accomplish this, the signature of the `RegisterRunner` function from the `models/actions` package has been modified so that the labels argument can be nil. If it is, the part of the function that updates the record will not change the runner.
Various tests have been added for this function, for the following cases: new runner with labels, new runner without label, existing runner with labels, existing runner without labels.
The flag has been added to the CLI command, the action function has been updated to read the labels parameters through a separate function (`getLabels`), and test cases for this function have been added.
<!--
Before submitting a PR, please read the contributing guidelines:
https://codeberg.org/forgejo/forgejo/src/branch/forgejo/CONTRIBUTING.md
-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4610
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Emmanuel BENOÎT <tseeker@nocternity.net>
Co-committed-by: Emmanuel BENOÎT <tseeker@nocternity.net>
- Fixes a panic where the file history router would panic if the page
number was set to a page where no commits would be returned. It now
returns a 404 in such case.
- Regresion of a5b1c1b0b3
- Panic log provided by @algernon.
- Minimal integration test added.
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- On a empty blockquote the callout feature would panic, as it expects
to always have at least one child.
- This panic cannot result in a DoS, because any panic that happens
while rendering any markdown input will be recovered gracefully.
- Adds a simple condition to avoid this panic.
- Add an early-return to `LoadSchedules` and `LoadRepos` of the
`SpecList` type, @Beowulf noticed that useless queries were being run
every 30 seconds. These stemmed from these two functions being run even
if there were no scheduled actions.
- No tests were added, because there is zero testing infrastructure or
fixtures for the actions specifications models. I feel these are trivial
enough to not require any tests.
- The usage of the `vue-bar-graph` is complicated, because of the `GSAP`
dependency they pull in, the dependency uses a non-free license.
- The code is rewritten to use the `chart.js` library, which is already
used to draw other charts in the activity tab. Due to the limitation of
`chart.js`, we have to create a plugin in order to have images as labels
and do click handling for those images.
- The chart isn't the same as the previous one, once again simply due to
how `chart.js` works, the amount of commits isn't drawn anymore in the
bar, you instead have to hover over it or look at the y-axis.
- Resolves #4569
- The current way of detecting javascript licenses relies on
`license-checker-webpack-plugin`, which gets it information from
Webpack. However this isn't quite acurate as libraries might bundle
their dependencies into a output file, at which point Webpack no longer
sees that such dependency is used. For example, `vue-bar-graph` did
this which bundled `GSAP`.
- The new approach uses `license-checker-rseidelsohn`, which simply
scans all non-development (determined by `package.json`) packages and
read their LICENSE information, this might result in extra dependencies
being included into `license.txt` which aren't used in the final output
file (for example they would've been tree-shaken out by webpack), but
this takes a better safe than sorry approach as currently licenses are
missing from dependencies that are being bundled into Forgejo's
javascript code.
This aligns the popup width of the label selector during issue creation
to the width of the label selector in an already created issue.
(The inherited width from "ui form" is reset to prevent width: 100% on the
input element in the search box.)
- Currently if you want to update the milestone of an issue or pull
request, your whole page will be reloaded to reflect the newly set
milestone. This is quite unecessary, as only the milestone text is
updated and a new timeline event is added.
- This patch converts the milestone section in the issue/pull request
sidebar to use HTMX, so it becomes a progressive element and avoids
reloading the whole page to update the milestone.
- The update of the milestone section itself is quite straightforward
and nothing special is happening. To support adding new timeline events,
a new element `#insert-timeline` is conviently placed after the last
timeline event, which can be used with
[`hx-swap-oob`](https://htmx.org/attributes/hx-swap-oob/) to position
new timeline events before that element.
- Adds E2E test.
