CI Optimization Tactics

[vthomas13]

What is this about?

• [ ] Any documentation updates (changelog, READMEs, etc.) need not run against the pipeline.
• [ ] Draft PRs don't need to trigger all the CI jobs. => We can't do that, we need to run CI on draft PRs
• [ ] CI should run only on develop, master, and valid PRs. (Right now it runs on any branches created)
• [ ] Opt-in/out to run the CircleCI running by passing in the commit message
• [ ] Button in CircleCI called "Trigger Pipeline" that will allow you to start the workflow on any arbitrary branch.
• [ ] Starting PRs as Draft, to reduce CI jobs ran & declutter PR queues

Scenario

No response

Design

No response

Technical Details

No response

Threat Modeling Framework

No response

Acceptance Criteria

No response

Stakeholder review needed before the work gets merged

• [ ] Engineering (needed in most cases)
• [ ] Design
• [ ] Product
• [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
• [ ] Security
• [ ] Legal
• [ ] Marketing
• [ ] Management (please specify)
• [ ] Other (please specify)

References

https://consensys.slack.com/archives/CTQAGKY5V/p1717679382264779

[Gudahtt]

I would recommend refocusing this issue around a single task. The clearest benefit listed here is to stop running CI workflows for non-PR branches.

We can't easily do this from the CircleCI dashboard because we need CI to run on the develop and master branches even when there is no corresponding PR. But we can bail early on branches other than those, if we detect that there is no corresponding PR.

For the "skip CI for certain types of content updates/commit messages" related ideas, that can get quite complex and deserves a separate issue.