feat(ci): add support for user-defined jobs

[mistydemeo]

This adds support for user-defined jobs in CI. Currently, we support publish jobs specifically, and these run parallel with other publish jobs. These are specified in TOML via the user_publish_jobs hash:

user_publish_jobs = { github = ["./.github/workflows/something.yml"] }

Fixes #379.

[Gankra]

For discussion, writing out the slug-driven approach I had pictured:

publish-jobs = ["itch"]

Would tell us that:

• When building github CI, we expect to find a file called .github/workflows/publish-itch.yml
• We generate a step called publish-itch in .github/workflows/release.yml containing that fragment

With a hypothetical buildkite workflow (i have no idea what buildkite looks like, let's pretend it's vaguely github-shaped):

• When building buildkite CI, we expect to find a file called .buildkite/pipelines/publish-itch.yml
• We generate a step called publish-itch in .buildkite/pipelines/release.yml containing the fragment

---

I also figured it would be more ergonomic to have builtins and user-defined jobs sharing the publish-jobs / upload-jobs array, but I respect wanting to make them separate arrays.

[mistydemeo]

Hm, that slug approach seems reasonable. While it commits us to a specific directory structure in the target repo, that's not really a bad thing.

I do still want to keep it separated out by CI system. I can see a scenario where someone has more than one configured in the same repo and doesn't have 1:1 job parity between systems. Even if it requires more work from the user, I think it's better to specify extra jobs per CI system.

[Gankra]

Can you envision an approach where the per-ci-system stuff can be sugarred away for people who don't need it?

[mistydemeo]

Do you think that's necessary? Specifying a hash isn't enough extra work for the user that supporting a sugar syntax in addition to the other one feels like it's a bit more complex than we want to commit to.

[Gankra]

tbh I'll be surprised if any user ever needs that level of generality, so I respect the desire to have it available but it seems like an ergonomics pain to force everyone to refer to the possibility but never use it.

[mistydemeo]

I got talked into the simpler list syntax in place of the more complex hash syntax; pushed a version with that. Think this is ready now, save docs.

[mistydemeo]

The most recent version places both types of publish jobs in a single array. We distinguish between types via prefixing user jobs with a @. For example:

publish-jobs = ["homebrew", "@greeter"]

homebrew is a cargo-dist builtin, and @greeter is mapped to .github/workflows/publish-greeter.yml.

[Gankra]

General impl seems right, just some gunk from how many iterations this went through to clean up

[Gankra]

the ./ is stripped by this point in the code, so no need to map

[mistydemeo]

Not true, the publish_jobs vec we're fetching from has the original prefixed names.

[Gankra]

both versions of this code were stripping it, how are we ending up with multiple copies of the strip being needed?

[mistydemeo]

Good question! I'm... not really sure? I checked and it's absolutely true that the FromStr is constructing the PublishStyle with no ./ prefix, while the type in the task does have it until I strip it here.