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.
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.
minorby 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.