-
Notifications
You must be signed in to change notification settings - Fork 187
Rework CI workflow #944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mhucka
wants to merge
66
commits into
quantumlib:main
Choose a base branch
from
mhucka:mh-new-ci
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Rework CI workflow #944
+688
−1,094
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The revised CI workflow adds linting of workflows via actionlint. This config file tells actionlint that one of the runner names it doesn't recognize by default is actually valid.
The new `ubuntu-slim` runner name is not yet known to `actionlint`.
This defines a reusable action for installing and configuring Bazel. It's called from steps in the new `ci.yaml` file.
Add settings to allow prerelease python versions, so we can use 3.14.
Splitting up the previous workflows into separate files did work, but on balance, I find the disadvantages outweigh the advantages. The modularity of the separate files approach was good for reducing cognitive load and making maintenance a little bit easier, but it also decreased overall execution efficiency because the organization I used required more jobs. This new single file `ci.yaml` puts all the CI checks into one place, and adds some additional lint jobs compared to the previous set of workflow files. Note: this `ci.yaml` file does not have the wheel-building steps that the previous setup had. The wheel builds and PyPI uploads will be reintroduced in an upcoming separate workflow.
Remove option that is not relevant for this workflow.
There are too many lines with hashes that go over 80 chars, and some of the key values are troublesome to try to split across multiple lines.
It seems that `yamllint` is not installed on ubuntu-slim runners, unlike the case with ubunt-24.04 runners.
There are some library compatibility issues I don't understand. We'll have to try to do this architecture in the future.
99157aa to
ba0a3af
Compare
Fix more problems Fix more syntax problems Fix typo Fix typo
No longer necessary.
sergeisakov
approved these changes
Nov 6, 2025
Using the Docker version of hadolint allows the job to use `ubuntu-slim`.
pavoljuhas
requested changes
Nov 7, 2025
Collaborator
pavoljuhas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see inline comments. Otherwise LGTM.
Co-authored-by: Pavol Juhas <pavol.juhas@gmail.com>
Per review comments by @pavoljuhas, for simplicity and because this code base is fairly small, using an action to find changed files is not worth the added complexity.
…ist (quantumlib#931) Add a guide for Gemini Code Assist to teach it about the conventions used in this project. [Gemini Code Assist](https://codeassist.google/) is a coding assistant based on Google Gemini. Among other things, it has an [integration with GitHub](https://developers.google.com/gemini-code-assist/docs/set-up-code-assist-github). Google has enabled it in our organization. It acts as a [code reviewer for pull requests](https://developers.google.com/gemini-code-assist/docs/review-github-code). Its behavior can be [customized](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github) to some extent, and it can be informed about the practices and conventions used in a project through the use of a [styleguide.md file](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github#styleguide.md). The `styleguide.md` file in this PR is essentially a draft contributors' guide for the qsim project. The contents can serve as a starting point for adding a section to the qsim documentation. --------- Co-authored-by: Pavol Juhas <pavol.juhas@gmail.com>
Some scripts in check/ don't exist yet.
Now that we are not testing file changes, the parameter is not needed.
Add a debug option for making linting jobs not fail if there are errors. Temporarily set it to `true` until some other PRs are merged.
The previous approach ended up with hadolint not printing file names. The new code works better and is simpler.
This is courtesy of Google Search's AI Mode.
It takes almost a minute to pip install the requirements. In reality, we only need 3 packages.
The previous version did not work after all.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/devops
Involves build systems, Make files, Bazel files, continuous integration, and/or other DevOps topics
size: XL
lines changed >1000
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Splitting up the previous workflows into separate files worked, but on balance, I find the disadvantages outweigh the advantages. The modularity of using separate files was somewhat good for reducing cognitive load and making maintenance a little bit easier, but it also decreased overall execution efficiency because it required more jobs overall and required more overhead.
This new single file
ci.yamlputs all the CI checks into one place, and adds some additional lint jobs compared to the previous set of workflow files. It also introduces a separate action for setting up Bazel that lets us control more aspects of the configuration.Note: this
ci.yamlfile does not have the wheel-building steps that the previous setup had. The wheel builds and PyPI uploads will be reintroduced in an upcoming separate workflow.