Switch off CircleCI

[baentsch]

The project already started to move to GH CI. This issue is to suggest completing the move off CCI.

[ajbozarth]

As I've mentioned in previous oqs calls, after wrapping up #298 I plan to start work moving the CI to GitHub. This seems to be the primary issue for tracking that work, but #213 and #284 seem to duplicate the general move to GitHub Actions work. In addition #300 #301 and #308 might be straight forward to include spending how the process goes.

In preparation for this work I just wanted to note down the relevant issues for tracking

[baentsch]

but #213 and #284 seem to duplicate the general move to GitHub Actions work

Not totally right: #213 calls for creating cross-platform docker images: I did this in #214 only for oqs-provider/ossl3 and just for two platforms as a proof-of-concept that the move to GH and dockerx works. This may be simple to extend to all demos but I wouldn't be surprised if more problems occur than you may feel comfortable doing in one PR. Let's see how it turns out (whether the same adaptations in all images are required). The reference in the first line item indeed predates this issue and also #284 became an issue in its own right instead of staying bundled up as the forth line item. The goal of creating #294 and #284 was to motivate others to contribute smaller, more focused PRs instead of solving everything in one go tackling #213.

[ajbozarth]

This may be simple to extend to all demos but I wouldn't be surprised if more problems occur than you may feel comfortable doing in one PR

Given I built and tested all my work in #298 on both macOS and a RHEL VM, I believe this should just be a config, but as you said well see what happened when I get into it

The goal of creating #294 and #284 was to motivate others to contribute smaller, more focused PRs instead of solving everything in one go tackling #213.

That makes sense, once I get into it I'll see how creating the different parts of the CI flow and maybe decide to separate the work as the issues are separated.

The my initial primary goal is to move the automated testing CI off on circleCI and onto GitHub Actions, cross platform support and deployment will either come after or hand-in-hand depending on how it goes (I've never wrote GH Actions from scratch, only edited existing configs, so hopefully I'll be learning new tricks along the way)

[ajbozarth]

A bit of an update on my progress here, I've been playing with GitHub actions on my fork in my free moments the past few weeks and as of yesterday I have a working build and test example (using openssl3 demo). I'll share some implementation notes below:

Based on my research the best way to handle projects like ours, with many "subproject", is for each subproject (ie demo) to have it's own workflow yaml that is only triggered when there are edits to it's own dir.

I'm initially focused on getting build and test CI working, without including the push CI. My focus on the build and test is to move the current build and test steps from CircleCI and make sure they run on both linux/amd64 and linux/arm64 and on both pinned releases and latest liboqs/oqsprovider code.

You can take a peek at some of my work at https://github.com/ajbozarth/oqs-demos/actions and https://github.com/ajbozarth/oqs-demos/tree/testci but it's pretty messy since I had to push every time I edit for the actions to trigger to test them. Since then I've found how to trigger workflows via VSCode with pushing, so I may clean up my work and open a draft PR today since I may no longer need to push to run workflows.

[ajbozarth]

I may clean up my work and open a draft PR today since I may no longer need to push to run workflows.

After confirming I can trigger local workflow files against branches on my fork without pushing I decided to open #321 as a draft with my current progress

[baentsch]

FWIW, https://github.com/open-quantum-safe/oqs-demos/actions/runs/11952048136/job/33316958573?pr=322 shows warnings in the GH-CI driven build --> worthwhile fixing at the same time as moving the other integrations over to GH?

[Hawazyn]

Tracking multiple CI pipeline issues and understanding the current state can be overwhelming. I propose opening a single issue to consolidate the requirements and streamline collaboration. What are your thoughts?

[ajbozarth]

consolidate the requirements and streamline collaboration

@Hayyaaf That was my intention with my comment above, to make this issue the tracking issue for my CI updates work and have my PR close this and the other issues it handles. I don't believe we should close the other issues before the specific feature they request is complete though. In general now that my PR is open it would be the best place to hold discussion on the CI work. (This is based on my personal open-source history, I'll defer to @baentsch if he wants to follow a different process for this project)

[baentsch]

I propose opening a single issue to consolidate the requirements and streamline collaboration. What are your thoughts?

Agreed with @ajbozarth on tracking all issues related to the CCI -> GH CI move (here --added). My link re: warnings above seemed simple enough to do at the same time (update an actions version) but feel free to keep/solve it separately (but be aware that one of you may need to rebase, depending on what's done when). I step aside and let you handle as you see fit.