Trigger downstream CI ?

[baentsch]

open-quantum-safe/liboqs-python@f52b265 removed CCI support in that subproject. #1498 fixes the consequent CCI failure in liboqs.

This triggered the question for me whether we still want to trigger downstream CI (and/or for which subprojects) -- and (if/where) to consequently add/change the CI trigger logic (e.g., trigger downstream github actions instead of CCI)?

From the perspective of testing integrations it would be goodness, but it puts responsibilities/can trigger work in downstream projects.

Somewhat related: open-quantum-safe/oqs-provider#182 adds a CCI trigger from oqs-provider to oqs-demos as (various) oqs-demos integrate oqs-provider. A similar trigger exists from oqs-openssl111 to oqs-demos. This leads to an inefficient repeated execution of oqs-demos CCI if liboqs changes trigger downstream CCI to both oqs-openssl111 and oqs-provider. Can this be improved/are both necessary?

[baentsch]

#1498 (comment)

[SWilson4]

@baentsch I'm taking a look at triggering the liboqs-python CI via the GitHub API, which involves a bit of tinkering with the CI for both that repo and liboqs. Are there any jobs (e.g., release/deploy/etc) that I should be careful not to trigger by mistake?

[baentsch]

My approach was to develop this in separate repos before deploying it: See https://github.com/baentsch/ghtestsuper/blob/main/.github/workflows/test.yml for trigger and https://github.com/baentsch/ghtestsub/blob/main/.github/workflows/test.yml for receiver. That way no-one got annoyed. My proposal would be to add the receiver code first and when that's merged, start to trigger, first by command line, then by CI.

[baentsch]

Oh, and welcome on board, @SWilson4 !

[baentsch]

that I should be careful not to trigger by mistake

Just checked again all subprojects: In github there's no CI task yet that triggers persistent changes -- apart from what's coming online when open-quantum-safe/oqs-demos#214 gets merged: That'll be the first github CI that is both "triggerable" and creating persistent artifacts. But I don't see a reason why you shouldn't be "trigger happy" even with that one :-)

[SWilson4]

I have a PR open for the liboqs-python side here: open-quantum-safe/liboqs-python#65

Quick note: it seems that "success" in the liboqs pipeline doesn't mean that the liboqs-python pipeline completed with no errors but rather that it was started successfully. To confirm that the downstream pipeline completed successfully, you have to check manually. This seems to be compatible with the current behaviour of the other downstream projects, so I assume it's OK?

[baentsch]

I have a PR open for the liboqs-python side here: open-quantum-safe/liboqs-python#65

Thanks! Approved.

so I assume it's OK?

Yes: If any of the triggered downstream fails, they tell us by email and status report at https://openquantumsafe.org/dashboard.html