This thread is for sharing your orbs in progress to get early testers or seek input on the design of your orb.
Sneak peak: build-tools orb
What handy commands or jobs would you like to see that might be useful in almost any build?
About two weeks ago I created, and then published, an Orb called
hutson/semantic-delivery. It exports a single job called
Here’s a minimal usage example:
version: 2.1 orbs: semantic-delivery: email@example.com workflows: default: jobs: - semantic-delivery/delivery: context: github-interaction
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
So I’ve begun exploring this path by renaming my
hutson/semantic-delivery Orb to
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
deployjob 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-deployjob, and a
- Should I expect library maintainers to use
hutson/library-release-workflowsdirectly, or should it’s functionality be exposed through a language-specific Orb, such as a Node or Python Orb like
Just my two cents, but:
I’d say options 1) or 2) sound best. 1) sounds like a harder implementation task for you as the orb developer, as compared to 2). 3) would be a lot of work, as well, if you wanted to cover all the possible languages.
For this one, I’d say it’s up to you! I don’t think a particular dominant pattern or best practice in this regard has yet emerged.
Relatedly, we recently made it possible to compose orbs from other orb elements: https://circleci.com/changelog/#orbs-inside-orbs
It’s still early days for orbs, so the various techniques will evolve, but my sense is that the scope of an orb is best calibrated to the intended audience’s context for what the orb does. For an orb aimed largely at internal audiences I suspect you can get away with a fair amount of esoteric complexity (meaning things like powerful but somewhat obscure or opinionated parameters or jobs that aggregate a lot of different kinds of tasks that tend to go together in your particular workflows). For orbs intended for a broader audience it’s probably better to have a fairly narrow focus to ease discovery and how well someone can reason about a brand new orb.