release triggering for supported and ready downstreams and fix CI on forks

[jplomas]

Proof-in-doing of the concept discussed in the liboqs status meeting Tue 14 Jul 2026: the uses liboqs-go as an example.

A release of liboqs triggers release(s) of [tested and ready] downstream language wrappers.

This PR is in parallel with the PR on liboqs-go, which contains the release job triggered: open-quantum-safe/liboqs-go#55

A release job is only dispatched on liboqs release, so there are no release-blocking failures if the downstream repo is not ready or is breaking. However, if any necessary changes are in situ, it will allow the language wrapper release to be made at the same time as the main liboqs release.

The downstream-release workflow is renamed downstream-release-tests to better reflect the “readiness” functionality, while downstream-release now handles the actual downstream release, as its name implies.

Also fixes a longstanding issue preventing all CI passing on forks: there is now a repository check to skip downstream dispatches where repository secrets are absent.

Claude assistance with greps and hash pins; code review by corerabbit.ai

Motivation:

liboqs-go wrapper releases stalled between 0.10 and 0.15, though only the latter release contained any breaking changes. Similar CI changes could rapidly speed up the deployment of other language wrappers.

[baentsch]

The job name renaming makes perfect sense: One to test readiness (1), one to do release(s) (2). I wonder though, whether it wouldn't be sensible to first have automated readiness tests for all downstreams before having automated releases -- or do I misunderstand the logic of this PR to be (1) for oqsprovider (as before) and (2) for liboqs-go (new) only, i.e., no (1) for liboqs-go?

[jplomas]

The status quo of downstream readiness is relatively maintained: (1) is for PR authors to see if their changes will break downstream, (2) is for release managers to automatically release downstream which are ready or those which do not break. The errors for both (1) and (2) surface in the affected downstream repository.

This PR is minimal -- (1) for liboqs-go and all the language wrappers would be very useful imo -- as the overall approach has yet to be green-lit.

From the status meeting, a summary (which might be my misinterpretation) is that downstream readiness cannot slow down a liboqs release.

The work regarding #2474 and #2489 aligns more with the:

automated readiness tests for all downstreams before having automated releases
design, but this is contrary to what I understand to be desirable.

From a "fresh look" perspective, I think I would favour defining critical (supported) downstreams, and building their main as a gating CI job on all liboqs PRs and pushes, but I appreciate there does not appear to be the appetite for this approach.

[baentsch]

From a "fresh look" perspective, I think I would favour defining critical (supported) downstreams, and building their main as a gating CI job on all liboqs PRs and pushes, but I appreciate there does not appear to be the appetite for this approach.

I'd personally also favour that from the perspective of being able to more easily/quickly do releases. But this would mean very (re)active downstream maintenance (which doesn't exist) and substantially higher CI costs (contradicting https://github.com/open-quantum-safe/tsc/blob/main/guidelines/ci_usage.md).

So what about this compromise: Run downstream release readiness tests on all "critical" downstreams not at push but only at a merge highlighting problems thus possibly unearthed (and not discovered in PR review) in a (newly, automatically generated) issue (instead of blocking/failing the PR)?

[jplomas]

That would seem a reasonable compromise.

Notably, the "pull from downstream and test in liboqs CI" is different from the approach in #2474