Orb-to-orb dependency resolution

Ecosystem Orbs
1

Hey,

Context:

I am leading the development of suite of orbs that will, if all goes well, power Dialogue’s next generation ci/cd. We’ve written close to ten orbs at this point, some of which depend on others. The dependency graph currently goes up to three levels deep. All our orbs are currently being published to dialogue/sandbox@dev:<orb-name>. This is because heavy refactoring and learnings are ongoing so the structure has been very unstable until recently. As the exact orbs we want become clear, and their naming patterns, we’ll start to publish each orb proper.

Question:

We’ve noticed that at the time an orb is published its dependencies will be resolved, downloaded, and shipped with that published version of the orb. In practice, given a graph like:

project a
|
orb a
|
orb b
|
orb c

When we update orb c we’ve had to re-publish orb b and orb a in order for project a to see the effect.

  • Is my description above accurate to the reality of how orbs work?
  • Is there clear documentation about this somewhere?
  • Is there a way to make a project whose transitive dependency is e.g. patch-updated and which is only pinned up to e.g. minor by the intermediate orb(s) automatically observe the release upon next build?

Thanks to anyone who can help shed some light on the precise nature of the system here.

Cheers!
Jason

2 Likes
2

Hi @jasonkuhrt! Great questions! And sounds like your team is on the bleeding edge of orb adoption, which is awesome.

  • Is my description above accurate to the reality of how orbs work?

I think so? But I’m not 100% sure. Dropping a simple syntax example might help.

  • Is there clear documentation about this somewhere?
  • Is there a way to make a project whose transitive dependency is e.g. patch-updated and which is only pinned up to e.g. minor by the intermediate orb(s) automatically observe the release upon next build?

Did you see this section of our orbs documentation?

https://circleci.com/docs/2.0/creating-orbs/#semantic-versioning-in-orbs

I think it may answer your questions. In short—orbs are designed to be immutable, so when you import one orb in another orb, you import that orb at a specific version, which will never change unless you manually change it.

That said, because of how our semantic versioning works, as explained in the documentation, you can important, say, orb/foo@1.2, and that will automatically resolve to the latest published 1.2.x version of the orb. Which I think is the exact minor pinning you are asking about here—correct?

Thanks!