Adds dynamic matrix evaluation to Gitea Actions: a job's
`strategy.matrix` can be built from the outputs of the jobs it needs.
```yaml
jobs:
generate:
runs-on: ubuntu-latest
outputs:
matrix: ${{ steps.set.outputs.result }}
steps:
- id: set
run: echo "result=[1,2,3]" >> $GITHUB_OUTPUT
build:
needs: [generate]
runs-on: ubuntu-latest
strategy:
matrix:
version: ${{ fromJson(needs.generate.outputs.matrix) }}
steps:
- run: echo "building ${{ matrix.version }}"
```
Such a matrix cannot be expanded at planning time, so the job is planned
as a single placeholder and expanded by the job emitter once its needs
finish. Each combination is then gated by `if:` and concurrency as
usual.
- A matrix that resolves to no combination fails the job, as on GitHub.
- Expansion is capped at `MaxJobNumPerRun`.
- Workflows without a needs-dependent matrix are unaffected.
Fixes https://github.com/go-gitea/gitea/issues/25179
---------
Signed-off-by: Pascal Zimmermann <pascal.zimmermann@theiotstudio.com>
Signed-off-by: ZPascal <pascal.zimmermann@theiotstudio.com>
Co-authored-by: Claude <claude-sonnet-4-5@anthropic.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
Co-authored-by: bircni <bircni@icloud.com>
Co-authored-by: Zettat123 <zettat123@gmail.com>
Add support for `strategy.max-parallel` on Gitea Actions matrix jobs.
**How it works**
Jobs over the limit are inserted as `Blocked` instead of `Waiting`, so
runners never see them. When a job finishes, the job-status resolver
promotes one `Blocked` job per freed slot, in job order. Slots are
counted per `JobID` and scoped by reusable-workflow caller. A
`Cancelling` job still owns its runner, so it keeps its slot.
The cap is applied wherever a job can become `Waiting`: initial insert,
rerun, approval, and resolver promotion.
Best effort, not a hard invariant: two concurrent emitter passes can
each promote into the last slot, overshooting by one. It does not
compound, since every later pass recounts.
**Parsing**
Any YAML number, cast to an int as GitHub does (`1.5` → 1). `0` or
negative means unlimited. Expressions (`${{ ... }}`) are not evaluated
yet and fall back to unlimited.
**Migration**
Adds the `max_parallel` column on `action_run_job`. No index or
constraint changes.
**Compatibility**
Existing rows default to `0`, so behaviour is unchanged. No runner
changes needed: the runner protocol is untouched, and since the server
splits the matrix each runner still receives a single job.
Closes https://github.com/go-gitea/gitea/issues/35561
Signed-off-by: Pascal Zimmermann <pascal.zimmermann@theiotstudio.com>
Signed-off-by: ZPascal <pascal.zimmermann@theiotstudio.com>
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Zettat123 <zettat123@gmail.com>
### Description
Replaces all remaining direct `gopkg.in/yaml.v3` imports with
`go.yaml.in/yaml/v4` across models, modules, routers, services, and
integration tests. `gopkg.in/yaml.v3` moves from a direct to an indirect
dependency in `go.mod`.
#### API compatibility
The yaml.Node type, node.Kind/node.Content traversal style
(modules/markup/markdown/convertyaml.go), and the
UnmarshalYAML(*yaml.Node) interface signature
(modules/optional/serialization.go) are all preserved in v4 — no
call-site changes were required beyond the import path.
**Related:**
- https://github.com/go-gitea/gitea/pull/36564#issuecomment-4526536805
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
## Overview
This PR updates the Go toolchain version from `1.25.5` to `1.25.6` for
the Gitea project.
## Changes
### Toolchain Update
- **Go Toolchain**: Updated from `go1.25.5` to `go1.25.6`
This is a minor toolchain version bump that ensures the project uses the
latest patch release of Go 1.25.
## Security Improvements
While this PR primarily addresses the toolchain update, the project
maintains a strong security posture through:
### Current Security Measures
```log
Vulnerability #1: GO-2026-4342
Excessive CPU consumption when building archive index in archive/zip
More info: https://pkg.go.dev/vuln/GO-2026-4342
Standard library
Found in: archive/zip@go1.25.5
Fixed in: archive/zip@go1.25.6
Example traces found:
#1: modules/packages/nuget/metadata.go:217:25: nuget.ParseNuspecMetaData calls zip.Reader.Open
Vulnerability #2: GO-2026-4341
Memory exhaustion in query parameter parsing in net/url
More info: https://pkg.go.dev/vuln/GO-2026-4341
Standard library
Found in: net/url@go1.25.5
Fixed in: net/url@go1.25.6
Example traces found:
#1: modules/storage/minio.go:284:34: storage.MinioStorage.URL calls url.ParseQuery
#2: routers/api/v1/repo/action.go:1640:29: repo.DownloadArtifactRaw calls url.URL.Query
Vulnerability #3: GO-2026-4340
Handshake messages may be processed at the incorrect encryption level in
crypto/tls
More info: https://pkg.go.dev/vuln/GO-2026-4340
Standard library
Found in: crypto/tls@go1.25.5
Fixed in: crypto/tls@go1.25.6
Example traces found:
#1: services/auth/source/ldap/source_search.go:129:25: ldap.dial calls ldap.Conn.StartTLS, which calls tls.Conn.Handshake
#2: modules/graceful/server.go:156:14: graceful.Server.Serve calls http.Server.Serve, which eventually calls tls.Conn.HandshakeContext
#3: modules/lfs/content_store.go:132:27: lfs.hashingReader.Read calls tls.Conn.Read
#4: modules/proxyprotocol/conn.go:91:21: proxyprotocol.Conn.Write calls tls.Conn.Write
#5: modules/session/virtual.go:168:39: session.VirtualStore.Release calls couchbase.CouchbaseProvider.Exist, which eventually calls tls.Dial
#6: services/auth/source/ldap/source_search.go:120:22: ldap.dial calls ldap.DialTLS, which calls tls.DialWithDialer
#7: services/migrations/gogs.go:114:34: migrations.client calls http.Transport.RoundTrip, which eventually calls tls.Dialer.DialContext
```
## Breaking Changes
None expected. This is a minor toolchain patch update.
