Skip to content
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

CPP-2313 Add proper support for custom jobs in CircleCI #753

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

ivomurrell
Copy link
Contributor

Description

Our initial 4.0 release of Tool Kit only contained minimal support for defining custom jobs in CircleCI. They didn't define the executor the job would run in, resulting in CircleCI validation errors unless they were added explicitly in a custom block, so even calling it 'minimal support' might be a stretch. This PR adds proper support for the execution property, as well as adding a splitIntoMatrix option to jobs which works the same as it does for workflow jobs. Efforts have also been made to refactor the code so that it's easier to follow.

This now allows us to generate a CircleCI config for next-preflight using Tool Kit config exclusively without manual intervention.

Closes #740, as this PR carries on from the changes made in that PR.

Checklist:

  • My commit messages are conventional commits, for example: feat(circleci): add support for nightly workflows, fix: set Heroku app name for staging apps too

Our previous logic for guessing whether to prepend our Tool Kit orb
namespace to a workflow job didn't account for approval jobs, which
don't need to be declared in a `jobs` stanza ahead of time.

Also add some comments justifying why we're inferring whether to prepend
the Tool Kit namespace as the logic is getting increasingly complicated.
All jobs specified in a CircleCI config need to have an execution
environment assigned to it. Let's use the default node executor for our
generated jobs, including a matrix of the node executors if appropriate.
This increases the complexity of the workflow job logic even further so
I've refactored the code significantly as part of this in an effort to
make it more readable.
This means we can reuse the aggregate error formatting instead of
rewriting another version. It also means that the details field of
ToolKitErrors can be preserved.
@ivomurrell ivomurrell requested a review from a team as a code owner January 9, 2025 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant