Coder Social home page Coder Social logo

grunt-release's Introduction

grunt-release

Build Status Dependency Status devDependency Status

Grunt plugin for automating all the release steps of your node lib or bower component, with optional publishing to npm.

Repetition Killed the Cat

Releasing a new version of your killer Node/Bower/Component/JS lib looks something like this:

  1. bump the version in your package.json file.
  2. stage the package.json file's change.
  3. commit that change with a message like "release 0.6.22".
  4. create a new git tag for the release.
  5. push the changes out to GitHub.
  6. also push the new tag out to GitHub.
  7. create a .zip release on GitHub.
  8. publish the new version to npm.

Cool, right? No! What's wrong with you? Automate all that:

grunt release

Done. No more GitHub issues from angry people reminding you how often you forget to do one or more of the steps.

Setup

If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

npm install grunt-release --save-dev

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

grunt.loadNpmTasks('grunt-release');

Using grunt-release

Patch Release:

grunt release

or

grunt release:patch

Minor Release:

grunt release:minor

Major Release:

grunt release:major

Specific Version Release:

grunt release:1.2.3

Pre-release

grunt release:prerelease

prerelease will just update the number after MAJOR.MINOR.PATCH (eg: 1.0.0-1) If you want to add an alphanumeric identifier, you will need to add it by hand. Example: add -alpha.0 to get something like 1.0.0-alpha.0. Calling grunt release:prerelease will just update the last number to 1.0.0-alpha.1.

Releasing Unstable/Beta Versions Sometimes it is useful to publish an 'unstable' or 'beta' version to npm, while leaving your last stable release as the default that gets installed on an npm install. npm accomplishes this using the --tag myUnstableVersion flag. You can enable this flag in grunt-release either by setting the npmtag option:

  release: {
    options: {
      npmtag: 'canary',
    }
  }

or by passing the CLI arg:

grunt release --npmtag canary

NOTE: If the tag you pass is true, then the tag will be the new version number after the bump. Otherwise it will be the string you provided.

Bump multiple files at once

Sometimes you may need to bump multiple files while releasing.

  release: {
    options: {
      additionalFiles: ['bower.json']
    }
  }

You can also provide multiple files in this array or provide a string with multiple file paths separated by comma (,).

The version to bump is set in the master file defined with option 'file' (default : package.json). This version will be propagated to every additionalFiles.

Dry Run: To see what grunt-release does, without really changing anything, use --no-write option.

grunt release --no-write

You'll see something like:

>> Release dry run
>> bumped version to 0.8.0
>> staged package.json
>> committed package.json
>> created new git tag: 0.8.0
>> pushed to remote git repo
>> pushed new tag 0.8.0 to remote git repo
>> published version 0.8.0 to npm
>> created 0.8.0 release on github.

Done, without errors.

Options

The following are all the release steps, you can disable any you need to:

  release: {
    options: {
      bump: false, //default: true
      changelog: true, //default: false
      changelogText: '<%= version %>\n', //default: '### <%= version %> - <%= grunt.template.today("yyyy-mm-dd") %>\n'
      file: 'component.json', //default: package.json
      add: false, //default: true
      commit: false, //default: true
      tag: false, //default: true
      push: false, //default: true
      pushTags: false, //default: true
      npm: false, //default: true
      npmtag: true, //default: no tag
      indentation: '\t', //default: '  ' (two spaces)
      folder: 'folder/to/publish/to/npm', //default project root
      tagName: 'some-tag-<%= version %>', //default: '<%= version %>'
      commitMessage: 'check out my release <%= version %>', //default: 'release <%= version %>'
      tagMessage: 'tagging version <%= version %>', //default: 'Version <%= version %>',
      beforeBump: [], // optional grunt tasks to run before file versions are bumped
      afterBump: [], // optional grunt tasks to run after file versions are bumped
      beforeRelease: [], // optional grunt tasks to run after release version is bumped up but before release is packaged
      afterRelease: [], // optional grunt tasks to run after release is packaged
      updateVars: [], // optional grunt config objects to update (this will update/set the version property on the object specified)
      github: {
        apiRoot: 'https://git.example.com/v3', // Default: https://github.com
        repo: 'geddski/grunt-release', //put your user/repo here
        accessTokenVar: 'GITHUB_ACCESS_TOKE', //ENVIRONMENT VARIABLE that contains GitHub Access Token

        // Or you can use username and password env variables, we discourage you to do so
        usernameVar: 'GITHUB_USERNAME', //ENVIRONMENT VARIABLE that contains GitHub username
        passwordVar: 'GITHUB_PASSWORD' //ENVIRONMENT VARIABLE that contains GitHub password
      }
    }
  }

If you want to use multiline commit messages just pass an array to the commitMessage option instead of a string.

Notes on queued tasks

By default, the queued tasks ran through the beforeBump, afterBump, beforeRelease, afterRelease options will not inherit the flags specified when the release task is ran. To preserve those flags, you can optionally pass an object to those arrays in the following format:

{
   name: 'taskName',
   preserveFlags: true // defaults to false
}

You can still pass only strings to that array, or mix the two as need be. For example:

  release: {
    options: {
      beforeRelease: ['oneTask', { name: 'anotherTask', preserveFlags: true }]
    }
  }

Notes on GitHub Releases:

  1. Yes, you have to use environment variables.
  2. The GitHub Releases API is still unstable and may change in the future.
  3. You should use an environment variable to set an access token and "link" it via accessTokenVar.
  4. You can use environment variables for username (referenced in usernameVar) and password (passwordVar).
  5. We don't encourage you to use username and password for the GitHub release.

For node libs, leave file option blank as it will default to package.json. For Bower components, set it to bower.json.

License

MIT

grunt-release's People

Contributors

astik avatar billymoon avatar bobbyrne01 avatar btford avatar colineberhardt avatar corburn avatar dorgan avatar drublic avatar elenadotedu avatar geddski avatar kevva avatar koshuang avatar loicmahieu avatar mash avatar miguelcastillo avatar moox avatar necolas avatar niclashoyer avatar ovax3 avatar pcdevil avatar pkaminski avatar searls avatar shahata avatar sunyatasattva avatar trhodeos avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

grunt-release's Issues

Support updating config vars

I have an existing conig var in my Gruntfile:

pkg: grunt.file.readJSON('package.json'),

I'd like to be able to have this var updated after the version is bumped, so that subsequent tasks which refer to pkg see the updated version. grunt-bump supports this with a updateConfigs option:

bump: {
  options: {
    updateConfigs: ['pkg']
  }
}

Currently I'm using this task and grunt-bump to achieve what I need. If grunt-release supported an updateConfigs option I would not need to use grunt-bump.

Allow specifying the remote to push to

We're planning to use grunt-release to sign and push releases to heroku and then github if that succeeds.

It would be great to set the remote to push to. Even better, it would be great to specify an array of remotes to push to in succession.

Would this be a PR that you'd consider accepting?

Bump version for 2 files at the same time

Hi all,

It would be cool to have an option to update 2 JSON file's version. For example, we have a bower exposed project so that we have a package.json and a bower.json. Both need to be bumped while releasing. For now, only one of them can ='(
Some plugin like "grunt-update-json" take care of synchronizing bower.json with package.json, but to work correctly with grunt-release, it needs to be executed in between the firsst and second step :

>> bumped version to 1.0.1
  -- need to update bower.json !
>> staged package.json

The easier way would be to do "grunt-update-json" manually, then to do the "grunt-release" classic process. But for that to work, we need an option to bump multiple files.

Am I doing it wrong ? Would it be a needed feature ?

Allow third party tasks

On every release we also generate documentation and other things. Would be really helpful if we could fully automate this during the release cycle as well :-)

Ability to specify a version number

I'm just getting started with grunt so maybe I missed this, but it'd be cool if you could specify the version number. Like I just bumped something that was at version 1.4.2 up to version 1.5.0 as it was sort of in between a patch and a major version change.

Parity with `npm version`?

This should support everything npm version supports.

The two things that immediately stand out are:

bumping the build version: grunt release:build
releasing with a specific version: grunt release:1.2.3

Also, an option (or automatic based on environment detection) for signing the tag.

There may be other features as well.

Don't report success if a command failed

The commands that interact with the network are due to all sorts of failures, but no matter the outcome the plugin reports a success. This is quite misleading, and since output is silenced, there's no indication that something unexpected happened.

Focus on the git part?

Just a thought, inspired by the discussion on #21 (and #7 ): maybe this module tries to accomplish too much?
I am quite new to this node/grunt framework, but if I understand correctly, bumping, adjusting the source, and finally committing are all (potentially) complex in itself.

If this plugin does only one thing really good - tagging and committing - it can be easily used as one plugin in a custom grunt task.

Some ideas:

  • default bump: false (or even remove this option)
  • default npm: false (not used for query-plugins, for example)
  • read version number from a canonical place (default: package.json)
  • rename to 'grunt-git-release' or s.th.

'Warning: Error creating github release.', "Published releases must have a valid tag"

This warning is occurring intermittently, I normally run grunt release but added the --stack option hoping to find more info.

Before running command, project was at 0.7.0, why is this error occuring?

rob@work:~/git/project$ grunt release --stack
Running "release" task
>> bumped version of addon/package.json to 0.7.1
>> bumped version of package.json to 0.7.1
>> staged addon/package.json package.json
>> undefined committed
>> created new git tag: 0.7.1
>> pushed to remote
>> pushed new tag 0.7.1 to remote
Warning: Error creating github release. Response: {"message":"Validation Failed","errors":[{"resource":"Release","code":"custom","message":"Published releases must have a valid tag"}],"documentation_url":"https://developer.github.com/v3/repos/releases/#create-a-release"} Use --force to continue.

Aborted due to warnings.

Gruntfile.js ..

release: {
    options: {
        file: 'package.json',
        additionalFiles: ['addon/package.json'],
        bump: true,
        add: true,
        commit: true,
        tag: true,
        push: true,
        pushTags: true,
        npm: false,
        npmtag: false,
        github: {
            repo: 'bobbyrne01/project',
            usernameVar: 'GITHUB_USERNAME',
            passwordVar: 'GITHUB_PASSWORD'
        }
    }
}

Run default task after bump, before commit

A lot of libraries inject the version into the banner of an artifact being released or elsewhere. Without updating those before the commit and tag, the version numbers in the tagged/published release are always out of date.

Bump additional version number in separate package.json, for firefox addon

I have a firefox addon, which requires it's own package.json. I'd like the have grunt-release update both package.json files. But I'm getting a warning, which stops execution, when I set an additionalFiles value in my Gruntfile.js.

Any ideas why?

The directory structure of my project is as follows ..

rob@work:~/git/repo$ tree
.
├── addon
│   └── package.json
├── Gruntfile.json
└── package.json

Console output ..

rob@work:~/git/repo$ grunt release --no-write
Running "release" task
Warning: Object addon/package.json has no method 'push' Use --force to continue.

Aborted due to warnings.

Extract from ~/git/repo/Gruntfile.json ..

release: {
    options: {
        file: 'package.json',
        additionalFiles: 'addon/package.json',
        bump: true,
        add: true,
        commit: true,
        tag: true,
        push: true,
        pushTags: true,
        npm: false,
        npmtag: false,
        github: {
            repo: 'bobbyrne01/project',
            usernameVar: 'GITHUB_USERNAME',
            passwordVar: 'GITHUB_PASSWORD'
        }
    }
},

Below is my package.json specific to the firefox addon (that lives at ~/git/repo/addon/package.json).

It has the same version number as the node package.json residing at ~/git/repo/package.json ..

{
    "name": "repo",
    "title": "Repo",
    "id": "jid1-randomid",
    "description": "this is my description",
    "author": "bobbyrne01",
    "license": "GNU GPL v3",
    "version": "0.5.2"
}

grunt-release is always asking for my github username and password

Hi,

I've added the GITHUB_USERNAME and GITHUB_PASSWORD variables to environment but grunt-release is always asking to input them:

Username for 'https://github.com':
Password for 'https://github.com':

I'm totally sure that they're correctly specified because I can see them with a console.log(process.env.GITHUB_USERNAME) in the grunt-release.js code.

I must say that I'm using it with grunt-hub, so maybe this could be the problem.

Workflow issue with prereleases

Suppose you have a project that is version 1.6.1 tagged and released.
Someone reports a bug and you start working on the code. At some point you are done and you want to make a release candidate to give your testers or so.
Currently to do so, you need to do the following steps:
(version is 1.6.1)
Manually(!) change the version to 1.6.2
Run grunt release:prerelease (version is now 1.6.2-0)
(test)
Manually change the version back to 1.6.1
Run grunt release (version is now 1.6.2)

Wouldn't it be better if the flow was:
(version is 1.6.1)
Run grunt release:prerelease (version is now 1.6.2-0)
(test)
Run grunt release (version is now 1.6.2)

If you want to be really nice, also have flags or something to make a prerelease of a minor or major version, eg.
(version is 1.6.1)
Run grunt release:preminor (version is now 1.7.0-0)

Add option to display `git push` output

Heroku gives useful output on the deploy and its success. Would be great if grunt-release didn't swallow this useful data :)

Let me know if this sounds alright, and I'm happy to submit a PR.

sensible defaults for github release

Presently, the github release step requires environment variables with username/password/token.

Git already has a mechanism for accessing this information: .gitconfig.

I submit that grunt-release should get the username/token from git config github.user and git config github.token respectively.

Further, the upstream branch that is used as the push target can be taken from git. It shouldn't need duplicated in the gruntfile:

git rev-parse --symbolic-full-name --abbrev-ref @{upstream}

bitbucket support?

i'm using bitbucket for some projects.

as it is pretty much the same as github, and there seems to be an api too, it might be possible to enhance...

regards

github auth via token

readme says that tokens can be used, but checking the code I don't see any reference to where the auth token would be configured.

is the readme a bit premature?

Configurable git hosting service

Hi,

We use an internal git management tool for our components, and although open them to the github community can be an option at some point is not a posible option for us today.

Do you have plans to make github as an optional hosting?

Suport multiple files

Would be great be able to pass multiple files for projects that uses multiple package managers.

Publishing ignores npm errors

When running grunt release, errors in NPM publishing are swallowed:

Running "release" task
>> Version bumped to 0.0.10
>> package.json committed
>> New git tag created: v0.0.10
>> pushed to remote
>> pushed new tag 0.0.10 to remote
>> published 0.0.10 to npm

Looks successful, but nothing was actually published to npm!

Publishing manually reveals:

npm ERR! need auth auth and email required for publishing
npm ERR! need auth You need to authorize this machine using `npm adduser``

When not identified to npm, publish does not fail

If I'm not introduced to npm with my user and passwort. grunt-release will still work and behave like the package was published.

I think it would not hurt to display the output from npm-publish command (just to verify).

best regards and thank you for the plugin
philipp

Support multiple files

Would be nice to be able to increment both a package.json and a manifest.json for Chrome extensions using Grunt, so that various Grunt tools do the right thing when reading from package.json.

Publishing should respect package.json's private value

It seems that with default values (npm: true), grunt-release does not respect the value of the private key found on package.json. Even with private: true, grunt-release tries to publish it.

Is this as planned? We use grunt-release to automate our release process, but it's a private package.

Preserve indentation after bumping the version

Currently it defaults to 2 spaces, which can create unnecessary diff lines if other indent level is used:

grunt release
--- a/package.json
+++ b/package.json
@@ -1,47 +1,48 @@
 {
-    "name": "my-app",
-    "version": "0.2.0",
-    "main": "server.js",
-    "repository": {
-        "type": "git",
+  "name": "my-app",
+  "version": "0.2.1",
+  "main": "server.js",
+  "repository": {
+    "type": "git",

Break out into a separate a module?

Really love grunt-release but moving away from grunt to gulp. Would be awesome if the core functionality could be broken out into an independent module so it could be used in other build tools like gulp. Any interest in doing this? I'd be willing to help in any way I can.

Rename Tasks not possible

The grunt-release plugin registers release as a Task.
The release task of the grunt-release plugin conflicts with an existing release task in ourt project. Our existing 'relase' task is part of a complex build process. So renaming our 'release' task would not be a solution here. To avoid such problems grunt allows to rename tasks using
grunt.renameTask('release','grunt-release');

As statet in http://gruntjs.com/api/grunt.task#grunt.task.renametask it should be possible to rename tasks. As I understood correctly the plugin should lookup its configuration using:

grunt.template.process(grunt.config.getRaw(this.name'+'.options.tagName')
instead of using hardcoded plugin name
grunt.template.process(grunt.config.getRaw('release.options.tagName')

Support renaming

At the moment the it always looks for a task named release, even if you changed its name with grunt.renameTask.

I think it will be as simple as using this.name instead of directly release when looking for config options.

Allow callbacks and command line parameter to create tag names

I have the following use case. From time to time I have to deploy a branch on a test stage. As this just a branch in development, I dont want bump the version number, but I have to create a new tag and update a CMakefile with a release number. It would be good if the tagName option could be a function and not just a string with place holders. This function, in my case, could read the actual branch name and could then create a branch name like 0.1.2-mybranch-1. The 1 would be passed in as command line parameter. And is also used to update my CMakefile, using the changes I"ve made in this pull request: #25

Releases are silently failing to npm

Last three lineman releases have failed when running grunt-release. Output claims that it was published to npm, but an immediate npm show command indicated it wasn't actually published. Had to resolve by manually publishing afterward

Add ability to bump prerelease version after release

For CI purposes, it'd be nice to have the release tasks do an additional commit that bumps the version to something like -alpha.0 or -1. So move the version in package.json from 0.1.0 (release) → 0.1.1 (commit, tag, push, publish) → 0.1.2-1. This assumes that a subsequent run of release would recognize 0.1.2-1 and properly release 0.1.2.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.