Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom bump commit message #230

Closed
aleclarson opened this issue Jan 20, 2019 · 18 comments
Closed

Custom bump commit message #230

aleclarson opened this issue Jan 20, 2019 · 18 comments
Labels
enhancement New feature or request

Comments

@aleclarson
Copy link
Contributor

Feature: Add an .autorc option for customizing the commit message used by the NPM plugin when it bumps the package version.

{
  "bumpHeader": "{{version}}",
  "bumpFooter": "[skip ci]"
}
@aleclarson aleclarson added the enhancement New feature or request label Jan 20, 2019
@aleclarson
Copy link
Contributor Author

aleclarson commented Jan 20, 2019

I might prefer no bump commits (like semantic-release does it):

{
  "skipBumpCommit": true
}

With bump commits disabled, the latest NPM version is the source of truth (or maybe it already works that way?) and the "version" field in package.json can be set to 0.0.0-development or similar.

@hipstersmoothie
Copy link
Collaborator

is skip CI different on travis? without that in your commit messages you can easily fall into a loop

@hipstersmoothie
Copy link
Collaborator

auto will use look at the local version and the published version and choose the higher one to avoid npm errors. Is that sufficient?

@aleclarson
Copy link
Contributor Author

is skip CI different on travis? without that in your commit messages you can easily fall into a loop

I'm not actually sure. If it's required in the commit header, then so be it. 😆

auto will use look at the local version and the published version and choose the higher one to avoid npm errors. Is that sufficient?

Oh really? Nice. Is no bump commit created in that case?

@hipstersmoothie
Copy link
Collaborator

hipstersmoothie commented Jan 20, 2019

No in that case we bump the published version cause you can publish over an old version.

I'm having trouble visualizing how skipBumpCommit would work or what the end result would look like. To run shipit you have to change the version in some way, so i can't see how you could get out of that commit.

@aleclarson
Copy link
Contributor Author

What do you think of shipit skipping the bump commit when the version in package.json is something like 0.0.0-development?

@hipstersmoothie
Copy link
Collaborator

hipstersmoothie commented Jan 22, 2019

  1. Package starts at 0.0.0-development

  2. you run version it returns the bump based on PRs, it returns anything (patch, minor, major) - lets say it's patch

  3. Changelog creation - (0.0.0-development => 0.0.0). But you don't want that to happen? Instead add under the '0.0.0-development' changelog title?

  4. publish hooks time - it would 0.0.0-development => 0.0.0 and publish. but you want development to be detected and skip publish step all together

  5. make a github release - Instead of creating a new release, update the old one with the new commits

  6. Package stays at 0.0.0-development until ??? while changes accumulate

@hipstersmoothie
Copy link
Collaborator

Two options if thats what you want:

  1. Simply do not run auto shipit until you want to start releasing and publishing. Still add the labels to your PRs. When you are ready add auto shipit to your CI process and it will include all the labels PRs in your first release.

  2. Write a plugin. This behavior is pretty unique and doesn't really conform to the way npm does versioning. I think you could make a plugin to accomplish this stuff. Although I would probably have to add a hook or two for you to utilize.

@aleclarson
Copy link
Contributor Author

A package with a version of 0.0.0-development indicates the following:

  • The highest published NPM version is considered the "current version"
  • The version in package.json should never be changed

When a new NPM version should be published, Auto should increment the "current version" using npm version $(auto version).

The changelog uses the "current version" from NPM (instead of from package.json).

As always, a new Github release is created for every NPM version.

Am I being clear enough?

@hipstersmoothie
Copy link
Collaborator

The version in package.json should never be changed

To publish new versions to NPM you have to change this. The only way to increment the "current version" and never change the local one would be to:

  • change it to current version (NPM)
  • do the bump
  • change it back
  • but since it the tag would be the bump current version do ???

I'm pretty sure I understand your use case.

a. you don't want to publish a bunch of versions while you are developing a feature over multiple PRS
b. once a new version should be published you want all the changes included

In my eyes we already give you two ways to do this:

  1. use onlyPublishWithReleaseLabel. new versions aren't created until you add this label. So you could look at any PR/code without the label as VERSION-development

  2. as you are merging PRs for the big feature use skip-release until you are ready for a version, then just merge a PR. The new release contains all skipped PRs. In this case you can look at adding the skip-release label as signifying that your version is VERSION-development

How does this differ from the behavior you want?

It seem to me to boil down to: you want to add -development to your version to start skipping releases and remove it when your ready for all the changes to be released at once.

@hipstersmoothie
Copy link
Collaborator

to accomplish my last sentence you could probably make a plugin that uses beforeShipit to check for the presence -development in the version and throws an error if it's present. This would prevent shipit from moving forward until you remove -development.

The only problem I see with this is that it would also fail the CI job.

@aleclarson
Copy link
Contributor Author

aleclarson commented Jan 23, 2019

Interesting interpretation, but not quite what I intended. 😅

I'm basically describing how semantic-release works.

I should have said "The version in package.json is only changed temporarily in order for npm publish to succeed" (instead of "The version in package.json should never be changed"). All I'm really trying to do is avoid the bump commit altogether. :)

@hipstersmoothie
Copy link
Collaborator

Ok so the state you would end up in is:

repo: only ever has verison 0.0.0-dev

npm: Has the real version all the time (this is whats used for anything)

correct?

@hipstersmoothie
Copy link
Collaborator

hipstersmoothie commented Jan 23, 2019

Kinda like

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

@aleclarson
Copy link
Contributor Author

Yeah, looks good!

@hipstersmoothie
Copy link
Collaborator

auto v4.0.0 here we come lol. Looks like I'm gonna have to split up the publish hook. This will be another plugin

@aleclarson
Copy link
Contributor Author

If you want, you could bake this feature into Auto for now, and wait to split the publish hook until another plugin needs it too. 😛

@hipstersmoothie
Copy link
Collaborator

This should be possible via plugin now with #247 (the semver ability). The commit message thing requires a bit of config changes and doesn't really get you much. Closing but open to PRs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants