mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2026-05-13 06:20:24 +00:00
3f77d37d44
Some checks are pending
/ release (push) Waiting to run
testing-integration / test-unit (push) Waiting to run
testing-integration / test-sqlite (push) Waiting to run
testing-integration / test-mariadb (v10.6) (push) Waiting to run
testing-integration / test-mariadb (v11.8) (push) Waiting to run
testing / backend-checks (push) Waiting to run
testing / frontend-checks (push) Waiting to run
testing / test-unit (push) Blocked by required conditions
testing / test-e2e (push) Blocked by required conditions
testing / test-remote-cacher (redis) (push) Blocked by required conditions
testing / test-remote-cacher (valkey) (push) Blocked by required conditions
testing / test-remote-cacher (garnet) (push) Blocked by required conditions
testing / test-remote-cacher (redict) (push) Blocked by required conditions
testing / test-mysql (push) Blocked by required conditions
testing / test-pgsql (push) Blocked by required conditions
testing / test-sqlite (push) Blocked by required conditions
testing / security-check (push) Blocked by required conditions
testing / semgrep/ci (push) Waiting to run
Forgejo Actions keeps one set of artifacts per workflow run -- those of the latest workflow run. If a particular workflow run is rerun, Forgejo is supposed to remove outdated artifacts. However, it does not do that. As a result, the user is presented a mix of outdated and new artifacts, even within the same archive.
This is remedied by wiping the artifacts before each rerun. The same happens when only one or more jobs are rerun, which also matches the behaviour of GitHub Actions. In the example below, when only rerunning `artifacts-two`, `many-artifacts-one` would disappear and a new version of `many-artifacts-two` would be made available.
Reproducer:
```yaml
on:
push:
jobs:
artifacts-one:
runs-on: ubuntu-latest
steps:
- run: mkdir -p artifacts-one
- run: |
if [[ "${{ github.run_attempt}}" == 1 ]] ; then echo "${{ github.run_attempt}}" > artifacts-one/ONE; fi
echo "${{ github.run_attempt}}" > artifacts-one/TWO
- uses: forgejo/upload-artifact@v4
with:
name: many-artifacts-one
path: artifacts-one/
artifacts-two:
runs-on: ubuntu-latest
steps:
- run: mkdir -p artifacts-two
- run: |
if [[ "${{ github.run_attempt}}" == 1 ]] ; then echo "${{ github.run_attempt}}" > artifacts-two/ONE; fi
echo "${{ github.run_attempt}}" > artifacts-two/TWO
- uses: forgejo/upload-artifact@v4
with:
name: many-artifacts-two
path: artifacts-two/
```
Resolves https://codeberg.org/forgejo/forgejo/issues/12163.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org).
### Tests for Go changes
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12523
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| actions | ||
| activities | ||
| admin | ||
| asymkey | ||
| auth | ||
| avatars | ||
| db | ||
| dbfs | ||
| fixtures | ||
| forgefed | ||
| forgejo/semver | ||
| forgejo_migrations | ||
| forgejo_migrations_legacy | ||
| git | ||
| gitea_migrations | ||
| issues | ||
| moderation | ||
| organization | ||
| packages | ||
| perm | ||
| project | ||
| pull | ||
| quota | ||
| repo | ||
| secret | ||
| shared/types | ||
| system | ||
| unit | ||
| unittest | ||
| user | ||
| webhook | ||
| error.go | ||
| main_test.go | ||
| org.go | ||
| org_team.go | ||
| org_team_test.go | ||
| org_test.go | ||
| repo.go | ||
| repo_test.go | ||
| repo_transfer.go | ||
| repo_transfer_test.go | ||