auto version to return the next version number

[sherifkayad]

Is your feature request related to a problem? Please describe.

I guess the answer to that is yes. We are trying to use auto to generate releases from our Jenkins and eventually we want to know what the exact published release is (e.g. v1.1.1). The reason behind that is that we developed some custom tool that based on a release tag / branch can generate some information about the release and link that to our internal documentation platform.

Describe the solution you'd like

Would be great to keep utilizing the command:
auto version

But instead of only getting patch, minor or major, maybe this time with a special flag we can get the real version number to be released e.g.:
auto version --next-release-version

Describe alternatives you've considered

The only alternative for us in the meantime is to do a grep on the outcome of the auto release -d command and do some ugly string concatenation e.g.:
auto release -d | grep -Po ' Would have created a release on GitHub for version: \K[^ ]+'

[hipstersmoothie]

you can actually get that information by doing auto shipit --dry-run --quiet. This will not do a release and will print just the version that will be published. this should work in 95% of cases. If your project is an independent lerna project it won't be accurate though.

The reason behind that is that we developed some custom tool that based on a release tag / branch can generate some information about the release and link that to our internal documentation platform.

To me this seems like a place where you could write a plugin for auto that does this for you and is integrated better. Can you describe this more?

[hipstersmoothie]

@sherifkayad does this work for you?

[sherifkayad]

@hipstersmoothie The command auto shipit --dry-run --quiet didn't work for some odd reason in our Jenkins environment and we had to fall back to the original command I posted auto release -d | grep -Po ' Would have created a release on GitHub for version: \K[^ ]+'

We are currently checking if probably a plugin would make sense and how we can contribute it back if we did it.

[msonnleitner]

@hipstersmoothie Should auto shipit --dry-run also work for pre-release branches? I tried this approach but it returns

✔ success Would have created prerelease version: 0.0.2-next.0

although in my case 0.0.2-next.1 is already existing

On master it seems to work though:

⚠ warning Published version would be: 0.0.2

[hipstersmoothie]

The dry-run output is admittedly a little stupid and doesn't actually call to plugin code so the results might not be 100% accurate. What is your use case that you're trying to accomplish?

[msonnleitner]

The goal is to use this version to bump a Helm Chart appVersion with that value, before the release actually happens.

Since it does not work, I am currently doing something like (after auto shipit)

AUTO_VERSION=$(git tag --points-at HEAD)
sed -i 's|^appVersion:.*|appVersion: '"$AUTO_VERSION"'|g' Chart.yaml
// git commit, push

[thuringia]

@hipstersmoothie I tried using auto shipit --dry-run --quiet, which works fine, but doesn't match the released canary:
auto shipit --dry-run --quiet: 0.1.1-canary.2.88e44fd4e2aeb1f2425d0806c68781b9b3142627.0
auto shipit: ✔ success Published canary version: 0.1.1-canarycanary.2.88e44fd4e2aeb1f2425d0806c68781b9b3142627

So right now, I can't use that route to get the version number for the docker image published by auto.
I want to use it to automate AWS CloudFormation templates, which is similar to what @msonnleitner want to do.

I can work around this for (pre-)releases by running auto first, an then fetching the version from package.json. We are not rolling out canaries, so that's fine. Not sure where canarycanary is coming from though.

Which is fine, but means that we have releases in Github even if we could not deploy that code. This can be a good compromise for now, until I have time to wrap up the serverless framework deploy with a publishing plugin

[hipstersmoothie]

Okay. All this information is great and is really pushing me to resolve #1443. This might be a bit of work and won't land for around a month. But I want to move most of the dry-run "guess release version" code into plugins. This will need a breaking change so I'll probably also do some v10 renaming work. Thanks for your guys input!

---

The only idea I have for now to get the actual release version would be to make a plugin that taps afterVersion and abort the release based on an environment variable. Kinda hacky but it would stop the release before it's published. This would leave some extra commits in the history though, so if you ran auto again from the same CI run you would have extra commits. You might also be able to use this hook to make it so that you don't have to use --dry-run at all. Just tap the afterVersion hook, get the version from the package.json, make some calls, then let the publish happen

[thuringia]

Thanks for letting us know :)

For now, the route of first releasing and then reading from the package.json does the job.
I better wait for v10 to try the plugin idea

[hipstersmoothie]

@sherifkayad @msonnleitner Could you test and see if v10 solves your issues?

[msonnleitner]

OK so it seems that it works with Node 14, but I had Node 15 installed, so it seem that
--no-git-tag-version does not with Node 15 and npm 7. (Although I am not a Node expert)

for node 15:
auto shipit --dry-run is now creating a git tag and seems to be doing an actual release

> GH_TOKEN=737[REMOVED] auto shipit --dry-run 
ℹ  info      Full Release notes for next release:
  ...
  0.0.4-next.4

> glol
  * 20c3651 - (HEAD -> next, tag: v0.0.4-next.4) 0.0.4-next.4 (75 seconds ago) <REMOVED>

>auto -V                                                                                                                                                                                                                                                             
v10.0.0-next.1

[hipstersmoothie]

Having trouble recreating this on my machine.

[msonnleitner]

@hipstersmoothie Well given that I am not that experienced with Node and version switches, it is probably my fault. But for Node 14 it worked using NPM. It tried to debug it and it seemed that --no-git-tag-version does not work in npm version 0.0.3-next.27 --no-git-tag-version for Node 15. But maybe I was just confused.

But basically it works, probably just my fault.

[hipstersmoothie]

That definitely seem like a bug on npm itself. Could you submit a bug here? While that's being resolved I'd recommend downgrading to node@14/npm@6 until some of the bugs are shaken out.

[msonnleitner]

ok, it seems it is this issue npm/cli#1973

[sherifkayad]

@hipstersmoothie works like a charm! Thanks for that

[adierkens]

🚀 Issue was released in v10.0.0 🚀