Orbs sneak peaks - share your orbs in progress

Ecosystem Orbs
1

This thread is for sharing your orbs in progress to get early testers or seek input on the design of your orb.

2

Sneak peak: build-tools orb

What handy commands or jobs would you like to see that might be useful in almost any build?

3

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 a npm-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 like circleci/node?
1 Like
4

Hi @hutson!

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.

1 Like
5

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.

1 Like