Allow to release a development version of an orb with a custom tag

[steinwelberg]

Describe Request:

In the old orb tools version, 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 the dev: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 pipeline run by another branch. And we would also loose the possibility to use the dev:alpha tag to always get the latest (not released) orb version.

I see 2 possible solutions to achieve what I would like:

1. Depending on the branch that the publish job is run from, create a different tag. For master, use dev:<SHA-1>, for other branches, use dev:<branch_name (taken from the CIRCLE_BRANCH env var. This is however a bit opinionated, and potentially not backwards compatible.
2. Allow to specify the additional tag. through a new property e.g. pub-dev-tag By default, the dev:<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

[steinwelberg]

Btw, I am willing to provide a PR if it will have a chance to get accepted.

[rodrigo-fagundes]

Hi @steinwelberg , There's a discussion on custom tags on https://github.com/CircleCI-Public/orb-tools-orb/issues/162.

[rodrigo-fagundes]

Imho, to keep the segregation of concerns, orb-tools-orb could just get out of the way and receive the orb version you're intending to push. It could still validate if the parameter being passed is in X.Y.Z format to avoid an error, but how you get to that number doesn't seem a orb-tools-orb responsibility.

Orb-tools-orb dictating how you branch or tag seems overreaching to me. As suggested in #162, I think the best approach is just receive the version as a parameter.

[steinwelberg]

I agree and that would work for me as well 😉. I was more continuing on how the previous orb worked, but completely letting it up to the publisher seems like a better idea.

My request is however not completely the same as yours as that only touches the production version and I'd like to also be able to modify the dev version. Hence, the feature request is still valid.

[KyleTryon]

Closing this to merge the conversation into #162 . Thanks all.

[steinwelberg]

IMO, my request was different then the one in #162 as that one was about the GIT tag (production version) and my request is about the development version. I can ask the same question in #162, but I think that will clutter the discussion..

[KyleTryon]

Apologies @steinwelberg, this is different enough to be its own issue, I agree.

Can you help me understand the use-case for publishing to a specific tag based on branch? For each commit, on any branch currently, a specific SHA based tag will be generated. What would you want the custom tag/reference for?

One benefit I can think of, is if you plan on updating that tag frequently, it might be useful.

Could you share how you might expect this to look in your config? I could see something like this:

- orb-tools/publish:
      orb-name: <namespace>/<orb-name>
      dev-tag: '$CIRCLE_BRANCH'
      vcs-type: << pipeline.project.type >>
       requires:
        [orb-tools/lint, orb-tools/review, orb-tools/pack, shellcheck/check]
      # Use a context to hold your publishing token.
      context: <publishing-context>
      filters: *filters

[KyleTryon]

Just opened this, let me know what you think. I may need to add some additional testing. https://github.com/CircleCI-Public/orb-tools-orb/pull/180

[steinwelberg]

Hi @KyleTryon, first of all sorry for the late reply :(..

With regards to the use-case. We regularly have multiple branches open in the orb that we are developing. Testing these orbs with the current way of tagging is a bit cumbersome as you either have to use the dev:<SHA1 > or dev:alpha versions in the project that wants to test the latest changes in an orb. As orb development often requires a few iterations to get things right, the dev:<SHA1> version is very cumbersome as after every commit to the orb, you also have to create a commit to the project that wants to test the orb changes. The dev:alpha version is also not ideal as multiple branches will override the dev:alpha version when changes are made to the orb and the pipeline runs. Hence, having a way to separate dev versions per branch, like it was possible in the previous major version of the orb, really helps.

The example code snippet that you have shown would work for us indeed. As long as it gives us a branch specific version, something like dev:<branch_name>.

Btw, I don't see how https://github.com/CircleCI-Public/orb-tools-orb/pull/180 resolves this ticket as this is about the production version and not a development version.

[steinwelberg]

@KyleTryon Can you please look at my last comment? As I mentioned above, I think this issue should be reopened.