Skip to content

Conversation

@mhucka
Copy link
Collaborator

@mhucka mhucka commented Nov 5, 2025

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.yaml puts 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.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.

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.
@github-actions github-actions bot added the size: XL lines changed >1000 label Nov 5, 2025
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.
@mhucka mhucka force-pushed the mh-new-ci branch 2 times, most recently from 99157aa to ba0a3af Compare November 6, 2025 06:27
@mhucka mhucka added the area/devops Involves build systems, Make files, Bazel files, continuous integration, and/or other DevOps topics label Nov 6, 2025
Using the Docker version of hadolint allows the job to use `ubuntu-slim`.
Copy link
Collaborator

@pavoljuhas pavoljuhas left a 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.

mhucka and others added 3 commits November 6, 2025 22:49
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.
mhucka and others added 7 commits November 8, 2025 05:40
…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.
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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants