CI Cleanup Initiative

[PoisonPhang]

Our CI now has over 170 jobs per push to PR. It's time to start cleaning this up.

As a starting point we need to:

• Prune jobs that should not be getting built for QA via CI
• Break up our jobs into phases, at least a build and test/check phase
• Make the jq style filter less of a hassle to maintain

Pruning Jobs

There was mention of jobs that should not be part of our standard Build workflow. If we could begin by listing known jobs from this list in this discussion, that would be helpful. Otherwise, I'll start investigating which jobs belong in this list.

Breaking Jobs into Phases

Build Phase Jobs

Build phase jobs should only contain jobs that build things required for our checks/tests to complete.

Test Phase Jobs

Check Phase Jobs should only be tests/checks preformed to ensure the correctness of our code. Note these are separate from our current Check workflow that includes things like linters. Instead, this should encompass jobs that belong to checks (as opposed to packages).

[benluelo]

Something we can consider for the rust jobs is moving checks like clippy into a derivation's checkPhase, this would reduce the jobs by quite a bit. We could also move tests into the check phase, although I'm more hesitant to do so since there's no guarantee they run quickly.

[PoisonPhang]

Something we can consider for the rust jobs is moving checks like clippy into a derivation's checkPhase, this would reduce the jobs by quite a bit.

For sure, this seems like a solid improvement.

[benluelo]

related: #13

[benluelo]

Jobs that can be filtered out:

• download-circuit (shell script)
• docgen (shell script)
• githook (dev shell)
• evm (dev shell)
• round-trip (this can be removed entirely)
• evm-*-deploy (shell scripts)
• rust-sol-bindings (this can be removed entirely)

Not sure what these ones are:

• tera (looks like this is only used by docgen, likely doesn't need to be a package as it's only used internally)

Jobs that likely only need one system:

• treefmt
• nil
• spellcheck

We can also consider only building "top-level" packages, and removing packages from CI that are used in other packages:

• devnet-validator-node-ids
• devnet-validator-keys
• devnet-validator-gentxs

[PoisonPhang]

Thanks, this is a very helpful list.

Jobs that likely only need one system:

Could you elaborate on what you mean by "one system"?

[benluelo]

formatting, spelling, linting etc don't need to be run on multiple architectures (imo) since we don't gain anything from checking these things twice other than two failing jobs in CI

[benluelo]

Something else we should review is whether or not certain packages need to be exposed or not. Packages like tera, devnet-validator-*, etc are only used internally, and (most likely) don't need to be exported as a package.

[PoisonPhang]

Created #545, #546, and #547 to break up the work for this large task.

[hussein-aitlahcen]

As all the PR have been merged, should we close this conversation?