mirror of
https://github.com/go-gitea/gitea.git
synced 2026-06-13 15:14:00 +00:00
bc2fbe77b1
[actions-proto-go v0.6.0](https://gitea.com/gitea/actions-proto-go) adds a `capabilities` field to `RegisterRequest` and `DeclareRequest`. This lets a runner advertise the transitional `cancelling` capability directly in the proto message instead of through the out-of-band mechanism we used while the proto bump was pending. This PR: - Bumps `gitea.dev/actions-proto-go` to `v0.6.0`. - Drops the forward-compat `capabilityGetter` type-assertion shim and the `runnerRequestHasCancellingCapability` helper, reading `GetCapabilities()` directly (now part of the `declareRequest` interface). - Removes the "capability state unknown → preserve existing value" branch. ## Why the behaviour change is correct The shim and the `(hasSupport, known)` two-value return only existed because the old proto had no `capabilities` field, so we couldn't tell "runner doesn't support it" from "we can't see the field." With v0.6.0 the field is always present. Since proto3 repeated fields have no presence, "no capabilities sent" now unambiguously means the runner does not advertise the capability, so a runner that omits `cancelling` is correctly recorded as `HasCancellingSupport = false`. There is no regression: prior to this bump Gitea was on `v0.5.0`, where the type assertion always failed and `HasCancellingSupport` was therefore never set from requests — so no runner relied on the preserved-unknown path. ## Compatibility The change is wire-compatible in both directions of version skew, because the new field uses a previously unused field number (8 on `RegisterRequest`, 3 on `DeclareRequest`) and the transport uses the binary protobuf codec: - **Old runner → new Gitea:** the runner omits the field; it decodes to an empty capability list. Registration/declaration succeed; the runner simply doesn't get the cancelling feature. - **New runner → old Gitea:** the runner sends the field; the old server's generated code doesn't know the field number and silently ignores it. Registration/declaration succeed. The feature only activates once both server and runner are on `v0.6.0`.