Can you use orb@latest (or just omit version # to accept the latest version of an orb)?
Or does the calling config have to explicitly include the version you want to use?
Also, is it possible to allow fuzzy versioning? I think that would be the most flexible approach (i.e., give me any 0.0.x version, but not 0.1.x).
@wyardley a full list of version semantics supported by Circle CI is described in the Semantic Versioning of Orbs section of their documentation.
Circle CI supports simple range semantics. So you can use orb@0.0 for all 0.0.x versions.
Thanks! I figured there must be some kind of reference like that, but couldn’t find it earlier.
@wyardley See our documentation here:
https://circleci.com/docs/2.0/creating-orbs/#semantic-versioning-in-orbs
You may also use the special string
volatileto pull in whatever the highest version number is at time your build runs.
Hope that helps!
Yup, thanks to both of you for your reply
One thing I noticed was that there is some delay after publishing when using a fuzzy spec, where you seem to get an old version of an orb.
I mentioned this to support, but that was somewhat confusing at first; it would be really nice if there was some output when using an orb that says
Using foo/bar@1.0.2
When using a fuzzy spec like foo/bar@1 or foo/bar@volatile
Just following up to my own question, support did point out that if you go to the “configuration” tab, you’ll see that:
# Orb 'foo/bar@1' resolved to 'foo/bar@1.0.1'
tho it would be nice if it showed up in the build output too.
@wyardley might I suggest, if you are interested in the information being displayed in the build logs, that you file a Feature request through the Ideas portal - https://circleci.com/ideas/
That way it’s in the request queue, and other members of the community can up vote the request if they too would benefit.