About two weeks ago I created, and then published, an Orb called hutson/semantic-delivery
. It exports a single job called delivery
.
Here’s a minimal usage example:
version: 2.1
orbs:
semantic-delivery: hutson/semantic-delivery@1.0.2
workflows:
default:
jobs:
- semantic-delivery/delivery:
context: github-interaction
Under jobs
you can see that I invoke the delivery
job contained in the hutson/semantic-delivery
Orb. Based on my experience, I feel my example demonstrates how the approach of one-job per Orb may not be a good choice.
Circle CI Orbs have no default export for an Orb. So I will always end up with the extra /delivery
in the job name, even though it’s the only job contained in the Orb.
What I feel might be a better approach for my Orbs is to bundle common tasks for a given workflow, or language, into a single Orb.
Circle CI does this well with their circleci/node
Orb.
So I’ve begun exploring this path by renaming my hutson/semantic-delivery
Orb to hutson/library-release-workflows
.
My intention is to export jobs, commands, and executors, that automate a library’s delivery, deploy, and release, workflows on Circle CI.
My Orb still has a deliver
job which tags a library based on the commit conventions used in the library’s repository.
My next task is to explore publishing the tagged library to a public package registry, such as Npm and PyPI. So now I have new questions, such as:
- Should I have a single
deploy
job that can be used by any language, and do the language detection (to know what publication method to use) based on the contents of the repository? - Or do I use a parameterized job that allows the user to tell me which package registry to use?
- Or do I just create a
python-deploy
job, and anpm-deploy
job, etc?
Also:
- Should I expect library maintainers to use
hutson/library-release-workflows
directly, or should it’s functionality be exposed through a language-specific Orb, such as a Node or Python Orb likecircleci/node
?