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

  {
    "tag": "v1.0.1",
    "message": "1.0.1",
    "object": "c3d0be41ecbe669545ee3e94d31ed9a4bc91ee3c",
    "type": "commit",
    "tagger": {
      "name": "Scott Rudiger",
      "email": "scottrudiger@gmail.com",
      "date": "2011-06-17T14:53:35-07:00"
    }
  }

• Then create the reference with the SHA from the response; e.g.:

  {
    "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.

[DanySK]

A pity this proposal has found no implementors, I'd really enjoy it right now :)

[rarkins]

One concrete step would be to get the requirements fully agreed and described so that we can move it to status:ready. Generally people don't pick up an issue when it's still in requirements stage

[DanySK]

@rarkins I think that we should have them summarized in the first comment, it is hard to rebuild them through the comment. Also, I'd propose to make the function more generic than proposed here, so that it can work with any project relying on tagging for versioning. This proposal would require a changes to bumpVersion, as follows:

bumpVersion becomes an object with the following fields (options):

• versionFrom (string, possible values: package.json, git_tags; defaults to package.json, could be expanded). Rationale: the last stable project version could be specified in a file, or get deduced by looking at the git history (git describe --abbrev=0).
• generateTag (boolean, default: false). Rationale: when set to true, renovate also generates a git annotated tag with the same version of the package, then pushes the tag to the repository.
• tagPrefix (string, default: "v"). Rationale: prefixes the tag with an arbitrary string. Many use vX.Y.Z as tags, but many others prefer just plain versions. Only considered when generate_tag is true.
• tagPostfix (string, default: ""). Rationale: postfixes the tag with an arbitrary string. Some could use a postfix to identify versions generated automatically, e.g. X.Y.Z-autobumped-dep${{packageName}}Tov${{version}}. Allows templating.
• tag_message (string, default: "<bumped_version>\nVersion generated by Renovate"). Rationale: allows customization of the tag message. Only considered when generate_tag is set to true. Similar to commitMessage, allows templating.
• defaultBumpedValue (string, possible values: patch, minor, major; defaults to minor). Rationale: the same of the current bumpVersion
• bumpWhen (object, default: {"excludePackagePatterns" : [".*"]}). Rationale: allows fine-grained configuration of the updates triggering a new release event. Controlled similarly to packageRules with:
  • bumpWhen.excludePackageNames
  • bumpWhen.excludePackagePatterns
  • bumpWhen.excludePackagePrefixes
  • bumpWhen.matchPackageNames
  • bumpWhen.matchPackagePatterns
  • bumpWhen.matchPackagePrefixes
• if bumpVersion is set to a string, then it reproduces the previous behavior, so that backwards compatibility is not broken.

---

I think that packageRules can exclude some packages, but one might want to receive the updates for a package, but not trigger a tagging procedure for that specific update.

Use case 3:

Software library Foo depends on libraries Bar and Baz (depending on modules Baz-Core and Baz-Bazzy). The project is not written in Javascript, so it can't use package.json, rather, it computes its versions using git tags (e.g, by using git describe). Bar is considered a re-exposed part of the API, while Baz is used internally. Foo uses renovate for receiving, testing and automerging updates to both its dependencies. Since updates to Bar are exposed to clients of Foo, whenever a new version of Bar is merged in, a new minor release of the library should be created. Authors do not prefix v to their version tags.

This would be supported by the following configuration (exclusion is not required, but it is here for illustrative purposes):

"bumpVersion": {
  "versionFrom": "git_tags",
  "generateTag": true,
  "tagPrefix": "",
  "bumpWhen": {
      "matchPackageName": ["Bar"],
      "excludePackagePatterns": ["^Baz.*"]
  }
} 

defaultBumpedValue inherits value minor

By the way, we might also need: tag_postfix (to create beta releases), excludePackagePatterns, excludePackagePrefixes, and the corresponding match versions.

[rarkins]

@DanySK this is really great. To help my and others' understanding, could you also summarize the various use cases which drive this implementation proposal?

E.g. I can start with the original one:

• When a repo is updated with new dependencies, that repo itself should be "bumped" to a new version

I think originally in this feature request we were also adding:

• "..and when bumping a repo to a new version there should be the option to apply a matching tag, which is what triggers downstream activity for some cases"

What are the other ones - or subsets of those - which you're now adding?

For example you're adding package names, but I'm not sure that's necessary because bumpVersion can be controlled by packageRules which themselves can have already limited the package names.

[DanySK]

I think that packageRules can exclude some packages, but one might want to receive the updates for a package, but not trigger a tagging procedure for that specific update.

Use case 3:

Software library Foo depends on libraries Bar and Baz (depending on modules Baz-Core and Baz-Bazzy). The project is not written in Javascript, so it can't use package.json, rather, it computes its versions using git tags (e.g, by using git describe). Bar is considered a re-exposed part of the API, while Baz is used internally. Foo uses renovate for receiving, testing and automerging updates to both its dependencies. Since updates to Bar are exposed to clients of Foo, whenever a new version of Bar is merged in, a new minor release of the library should be created. Authors do not prefix v to their version tags.

This would be supported by the following configuration (exclusion is not required, but it is here for illustrative purposes):

"bumpVersion": {
  "version_from": "git_tags",
  "generate_tag": true,
  "tag_prefix": "",
  "bump_when": [
    {
      "matchPackageName": ["Bar"],
      "excludePackagePatterns": ["^Baz.*"]
    }
  ]

} 

default_bumped_value inherits value minor

By the way, we might also need: tag_postfix (to create beta releases), excludePackagePatterns, excludePackagePrefixes, and the corresponding match versions.

Note: I'm updating my previous comment too.