Renovate: Feature Request: Add tag after bumpVersion and automerge

[ScottRudiger]

What would you like Renovate to be able to do?

When using bumpVersion I'd like Renovate to also be able to tag a commit as latest in the same way as if a human was running the command npm version patch (or major/minor).

In my case, specifically, I'd like Renovate to add the following commits to a single PR (assume starting version is 1.0.0):

• chore(deps): update dependency [dependencyName] to [version]
• 1.0.1

Once all required status checks are green, auto merge (Renovate already does this).

Then, to get the tag on the master branch, run git push upstream master --tags (this triggers my ci to publish v1.0.1 to the npm registry).

Describe the solution you'd like

For my use case, I'd like this to work with "automergeType": "pr"; however, it's up to the maintainers whether or not to include a solution for branches as well. Additionally, tagging latest in the same way as npm version is fine for me; however, a more versatile way of adding arbitrary tags may be desired by others.

Describe alternatives you've considered

An alternative solution that works for me now is to manually run npm version patch, create/merge a PR, and npm push upstream master --tags after Renvoate has automerged dependency updates. It would be great if this could be automated.

Additional context

My current Renovate config

[rarkins]

Right now Renovate combines all updates into a single commit. i.e. you won't see this:

• chore(deps): update dependency [dependencyName1] to [version]
• chore(deps): update dependency [dependencyName2] to [version]

Making it all into a single commit - including lock files if necessary - makes things very clean. Is changing that a pre-requisite the second part?

[ScottRudiger]

Sorry, since I just started using Renovate I've only seen one dependency get updated so far so I haven't seen multiple updates in one commit yet. I'll edit above to reflect that behavior.

That's fine if the updated dependencies are in one commit (I agree it's clean). The main thing I'm concerned with is adding the tagged commit in the second part.

[rarkins]

OK so the next points are:

• Do you need an extra commit for 1.0.1, or do you only care about the tag?
• Do you really want the tag in the branch, or in master after you automerge?

I'm pretty sure you won't want us tagging branches, because the commits in branches can change (e.g. rebased upon conflict). I think what you want is for us to only tag after an automerge to master.

If we were to tag, it would probably not be via git though - it would be via the API.

[ScottRudiger]

• Do you need an extra commit for 1.0.1, or do you only care about the tag?

I _think_ I only need the tag.

I just know that npm version patch adds a separate commit with a message like 1.0.1, which is tagged as latest. However, as long as the version gets bumped and the tag is on the single update commit, that might be sufficient.

For me, personally, I'd have to double-check with how CircleCI picks up tags to be sure. Thinking back, I believe it's based on a regex of the commit msg (maybe it needs to be separate).

• Do you really want the tag in the branch, or in master after you automerge?

I'm pretty sure you won't want us tagging branches, because the commits in branches can change (e.g. rebased upon conflict). I think what you want is for us to only tag after an automerge to master.

Right you are; I'd like the tag to be on master after an automerge.

If we were to tag, it would probably not be via git though - it would be via the API.

As long as CircleCI can detect that the tag was added to master, that works for me. 👍

I'll try to look into CircleCI's requirements and get back to you.

[rarkins]

Please let me know what the process/logic is for CircleCI to detect tags and decide what to do. I think the builds are typically not triggered merely by a label addition so we may need to include it right away with Renovate's master commit.

[ScottRudiger]

FYI, @rarkins I posed the question to CircleCI 4 days ago without response yet (thread).

If you have time, let me know if it covers what you need to know and I'll edit the question; or, feel free to respond if there's anything you'd like to add.

[ScottRudiger]

@rarkins I went ahead and tested creating a tag via GitHub's API and it actually triggered CircleCI's tag filter! So I think this will be a fairly simple matter. 👍

We can just do the following:

• Update deps & commit as normal (w/ "bumpVersion": "patch" in my case).
• Wait until after merge.
• Create the tag with input, e.g.:
  json { "tag": "v1.0.1", "message": "1.0.1", "object": "c3d0be41ecbe669545ee3e94d31ed9a4bc91ee3c", "type": "commit", "tagger": { "name": "Scott Rudiger", "email": "[email protected]", "date": "2011-06-17T14:53:35-07:00" } }
• Then create the reference with the SHA from the response; e.g.:
  json { "ref": "refs/tags/v1.0.1", "sha": "3b3d829be78c2bb3438fd70d45b4b4e0175d3b36" }
• At this point, the tag should show up on GitHub and CircleCI's workflow will be triggered (with the right config).

This worked for me when I simply added the tag to a previous commit via the API (CircleCI triggered with this test config and the tag showed up).

[rarkins]

@ScottRudiger thanks for checking that out. I guess the logic is like this?

1. Only do this if both bumpVersion and automerge are enabled
2. Only do it for the root package.json
3. After automerging, create tag and then create the reference

[ScottRudiger]

1. Only do this if both bumpVersion and automerge are enabled

That would work for me, but maybe some users would be surprised since tagging isn't really explicit in the names. It's up to you, but I was picturing something like bumpVersionAndTag. Or, just tag which defaults to the new version when bumpVersion is set. That way, others could add arbitrary tags for whatever reason.

Agreed on the last 2 points.

[DiegoRBaquero]

@ScottRudiger thanks for checking that out. I guess the logic is like this?

1. Only do this if both bumpVersion and automerge are enabled
2. Only do it for the root package.json
3. After automerging, create tag and then create the reference

I would love to see this. Any progress? Trying to get this for Pager :)

[rarkins]

Given the current list of higher priority features I want to implement, I don't expect this to be completed unless it's by an outside contribution. If anyone is interested in implementing it, let's make sure we lock down requirements here first and bump needs-requirements -> ready so that there's no misunderstandings about what to implement.