IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Closes#2797
I'm aware of https://github.com/go-gitea/gitea/pull/28163 exists, but since I had it laying around on my drive and collecting dust, I might as well open a PR for it if anyone wants the feature a bit sooner than waiting for upstream to release it or to be a forgejo "native" implementation.
This PR Contains:
- Support for the `workflow_dispatch` trigger
- Inputs: boolean, string, number, choice
Things still to be done:
- [x] API Endpoint `/api/v1/<org>/<repo>/actions/workflows/<workflow id>/dispatches`
- ~~Fixing some UI bugs I had no time figuring out, like why dropdown/choice inputs's menu's behave weirdly~~ Unrelated visual bug with dropdowns inside dropdowns
- [x] Fix bug where opening the branch selection submits the form
- [x] Limit on inputs to render/process
Things not in this PR:
- Inputs: environment (First need support for environments in forgejo)
Things needed to test this:
- A patch for https://code.forgejo.org/forgejo/runner to actually consider the inputs inside the workflow.
~~One possible patch can be seen here: https://code.forgejo.org/Mai-Lapyst/runner/src/branch/support-workflow-inputs~~
[PR](https://code.forgejo.org/forgejo/runner/pulls/199)
![image](/attachments/2db50c9e-898f-41cb-b698-43edeefd2573)
## Testing
- Checkout PR
- Setup new development runner with [this PR](https://code.forgejo.org/forgejo/runner/pulls/199)
- Create a repo with a workflow (see below)
- Go to the actions tab, select the workflow and see the notice as in the screenshot above
- Use the button + dropdown to run the workflow
- Try also running it via the api using the `` endpoint
- ...
- Profit!
<details>
<summary>Example workflow</summary>
```yaml
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log Level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
tags:
description: 'Test scenario tags'
required: false
type: boolean
boolean_default_true:
description: 'Test scenario tags'
required: true
type: boolean
default: true
boolean_default_false:
description: 'Test scenario tags'
required: false
type: boolean
default: false
number1_default:
description: 'Number w. default'
default: '100'
type: number
number2:
description: 'Number w/o. default'
type: number
string1_default:
description: 'String w. default'
default: 'Hello world'
type: string
string2:
description: 'String w/o. default'
required: true
type: string
jobs:
test:
runs-on: docker
steps:
- uses: actions/checkout@v3
- run: whoami
- run: cat /etc/issue
- run: uname -a
- run: date
- run: echo ${{ inputs.logLevel }}
- run: echo ${{ inputs.tags }}
- env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
- run: echo "abc"
```
</details>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3334
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Vulnerability #1: GO-2024-2947
Leak of sensitive information to log files in
github.com/hashicorp/go-retryablehttp
More info: https://pkg.go.dev/vuln/GO-2024-2947
Module: github.com/hashicorp/go-retryablehttp
Found in: github.com/hashicorp/go-retryablehttp@v0.7.5
Fixed in: github.com/hashicorp/go-retryablehttp@v0.7.7
Example traces found:
#1: services/migrations/gitlab.go:500:74: migrations.GitlabDownloader.GetComments calls gitlab.DiscussionsService.ListMergeRequestDiscussions, which eventually calls retryablehttp.Client.Do
There are a few changes of template logic which defines when which elements should be shown on profile page. The motivation is to have the elements when needed and don't when they're not relevant.
## Changes
### RSS button
Now displayed if:
* feeds are enabled
AND one or more of:
* the current user is an admin
* the current user is viewing their profile
* the activity is publicly available
So, basically in cases when the .rss feed actually contains any events. Before this change this button was constantly shown and was giving an empty feed if it was unavailable.
### Public activity tab
The tab is displayed if:
* the current user is an admin
* the current user is viewing their profile
* the activity is publicly available
* the current tab is this exact tab, for example, in case it was accessed by adding `?tab=activity` to the URL, so that the UI is not broken w/o a highlighted tab
So, this tab is not displayed when it's not going to contain any information, but still can be accessed.
### Banner "This user has disabled the public visibility of the activity."
For admins:
* always show the big blue banner to warn that sharing a screenshot of this publicly is bad idea
For self:
* always display a little note about the current visibility status with a "Change" link
For others:
* only display a little note to explain why the activity is not shown
### Heatmap and activity feed
Elements are only displayed when relevant, instead of keeping empty leftovers, for easier testing. This template change is also covered by test. **Everything in this Changes section is covered by test unless I forgot something.**
## Preview
There's obviously too many states to screenshot, here are highlights:
![](https://codeberg.org/attachments/47559531-9bcd-46c0-90d4-8b51512da752)
_Warning admin for why they're seeing the information_
![](https://codeberg.org/attachments/3107bf62-955b-4fe5-bce3-6305a928afe1)
_Viewing self - private_
![](https://codeberg.org/attachments/afb63ead-fb0b-4fc7-9d8b-c6c09e9ae62b)
_Viewing self - public_
![](https://codeberg.org/attachments/df3c090a-7490-4827-b33b-771fd4fa0a9f)
_Don't have access to the information_
![](https://codeberg.org/attachments/2dd2b0ac-2fe0-4453-aa4b-e91fd08f4411)
_The tab is not shown when the activity can't be accessed_
![](https://codeberg.org/attachments/ed4c61de-b3b7-4523-b92b-bc76e1d8b7c5)
_Can't access the RSS feed_
![](https://codeberg.org/attachments/5a27f2be-d79c-4fb4-85a5-758348398f1b)
_Can access the RSS feed_
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4189
Reviewed-by: Otto <otto@codeberg.org>
See
https://docs.docker.com/reference/build-checks/legacy-key-value-format/.
Fixes these warnings seen during the docker build:
```
4 warnings found (use --debug to expand):
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 5)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 9)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 75)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 76)
```
Introduced in: https://github.com/moby/buildkit/pull/4923
(cherry picked from commit 996037fb6a61b1a7f9a0a837fd87bbeab9cad154)
Conflicts:
Dockerfile.rootless
trivial context conflict
This PR modifies the structs for editing and creating org teams to allow
team names to be up to 255 characters. The previous maximum length was
30 characters.
(cherry picked from commit 1c26127b520858671ce257c7c9ab978ed1e95252)
Now that the backlog has been resoloved, it is not uncommon for a few
upgrade to wait for a few days before a ruling is made on wether they
should be upgraded or not.
That may leave one or two slots for other upgrades although there may
be more that could be decided immediately.
Raising the concurrency to 10 leaves room for such bursts and avoid
creating a backlog that is not justified by delays related to the
availability of contributors.