Closed steinwelberg closed 1 year ago
Just to be sure, is the goal to test the orb in other existing repositories? In Orb tools 12 we are aiming to do away with the need for publishing development orbs at all, to make testing easier for open-source contributions. Publishing to a tag would still be possible but removing publishing means we do not need an API token for the building portion of the orb, meaning we could run forked PRs and allow the tests to fully run as they are no longer blocked by this access.
Multi-tag support confirmed added to #181
Thanks a bunch! 🙏
Describe Request
In the old orb tools version (10.x), it was possible to create a development release of an orb with a custom version tag, e.g.
dev:<branch-name>
. This allowed for easy testing of changes in an orb without having to bump the orb version after every commit to an orb, AND to have a master branch which always published thedev:alpha
version.With the current Orb version, this is a bit more troublesome. There are now 2 tags created:
dev:alpha
dev:<SHA1>
We could use the
dev:alpha
tag when working on a branch, however it might be overridden by a pipeline run by another branch. And we would also loose the possibility to use thedev:alpha
tag to always get the latest (not released) orb version from master.I see 2 possible solutions to achieve what I would like:
dev:<SHA-1>
, for other branches, usedev:<branch_name>
(taken from theCIRCLE_BRANCH
env var. This is however a bit opinionated, and potentially not backwards compatible.pub-dev-tag
By default, thedev:<SHA-1>
tag could be used, which preserves backwards compatibility. With the new property, a custom tag can then be specified for versions published from a branch.Supporting Documentation Links
The documentation still refers to branch versions for a development orb: https://circleci.com/docs/orb-concepts/#development-orbs