1 | # grunt-release
|
2 |
|
3 | [![Build Status](https://travis-ci.org/geddski/grunt-release.svg?branch=master)](https://travis-ci.org/geddski/grunt-release)
|
4 | [![Dependency Status](https://david-dm.org/geddski/grunt-release.svg)](https://david-dm.org/geddski/grunt-release)
|
5 | [![devDependency Status](https://david-dm.org/geddski/grunt-release/dev-status.svg)](https://david-dm.org/geddski/grunt-release#info=devDependencies)
|
6 |
|
7 | [Grunt](http://gruntjs.com) plugin for automating all the release steps of your node lib or bower component, with optional publishing to npm.
|
8 |
|
9 | ## Repetition Killed the Cat
|
10 | Releasing a new version of your killer Node/Bower/Component/JS lib looks something like this:
|
11 |
|
12 | 1. bump the version in your `package.json` file.
|
13 | 2. stage the package.json file's change.
|
14 | 3. commit that change with a message like "release 0.6.22".
|
15 | 4. create a new git tag for the release.
|
16 | 5. push the changes out to github.
|
17 | 6. also push the new tag out to github.
|
18 | 7. create a .zip release on github.
|
19 | 8. publish the new version to npm.
|
20 |
|
21 | Cool, right? No! What's wrong with you? Automate all that:
|
22 |
|
23 | ```shell
|
24 | grunt release
|
25 | ```
|
26 |
|
27 | Done. No more github issues from angry people reminding you how often you forget to do one or more of the steps.
|
28 |
|
29 | ## Setup
|
30 | If you haven't used [Grunt](http://gruntjs.com/) before, be sure to check out the [Getting Started](http://gruntjs.com/getting-started) guide, as it explains how to create a [Gruntfile](http://gruntjs.com/sample-gruntfile) as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
|
31 |
|
32 | ```shell
|
33 | npm install grunt-release --save-dev
|
34 | ```
|
35 |
|
36 | Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:
|
37 |
|
38 | ```js
|
39 | grunt.loadNpmTasks('grunt-release');
|
40 | ```
|
41 |
|
42 | ## Using grunt-release
|
43 |
|
44 | **Patch Release:**
|
45 | ```shell
|
46 | grunt release
|
47 | ```
|
48 | or
|
49 | ```shell
|
50 | grunt release:patch
|
51 | ```
|
52 |
|
53 | **Minor Release:**
|
54 | ```shell
|
55 | grunt release:minor
|
56 | ```
|
57 |
|
58 | **Major Release:**
|
59 | ```shell
|
60 | grunt release:major
|
61 | ```
|
62 |
|
63 | **Pre-release**
|
64 | ```shell
|
65 | grunt release:prerelease
|
66 | ```
|
67 |
|
68 | `prerelease` will just update the number after `MAJOR.MINOR.PATCH` (eg: `1.0.0-1`)
|
69 | If you want to add an alphanumeric identifier, you will need to add it by hand.
|
70 | 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`.
|
71 |
|
72 | **Releasing Unstable/Beta Versions**
|
73 | 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`.
|
74 | `npm` accomplishes this using the `--tag myUnstableVersion` flag. You can enable this flag in grunt-release either by setting the `npmtag` option:
|
75 |
|
76 | ```js
|
77 | release: {
|
78 | options: {
|
79 | npmtag: 'canary',
|
80 | }
|
81 | }
|
82 | ```
|
83 |
|
84 | or by passing the CLI arg:
|
85 |
|
86 | ```shell
|
87 | grunt release --npmtag canary
|
88 | ```
|
89 |
|
90 | 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.
|
91 |
|
92 |
|
93 | **Bump multuple files at once**
|
94 |
|
95 | Sometimes you may need to bump multiple files while releasing.
|
96 |
|
97 | ```js
|
98 | release: {
|
99 | options: {
|
100 | additionalFiles: ['bower.json']
|
101 | }
|
102 | }
|
103 | ```
|
104 |
|
105 | You can also provide multiple files in this array or provide a string with multiple file paths separated by comma (`,`).
|
106 |
|
107 | The version to bump is set in the master file defined with option 'file' (default : package.json).
|
108 | This version will be propagated to every additionalFiles.
|
109 |
|
110 | **Dry Run:**
|
111 | To see what grunt-release does, without really changing anything, use `--no-write` option.
|
112 |
|
113 | ```shell
|
114 | grunt release --no-write
|
115 | ```
|
116 |
|
117 | You'll see something like:
|
118 | ```
|
119 | >> Release dry run
|
120 | >> bumped version to 0.8.0
|
121 | >> staged package.json
|
122 | >> committed package.json
|
123 | >> created new git tag: 0.8.0
|
124 | >> pushed to remote git repo
|
125 | >> pushed new tag 0.8.0 to remote git repo
|
126 | >> published version 0.8.0 to npm
|
127 | >> created 0.8.0 release on github.
|
128 |
|
129 | Done, without errors.
|
130 | ```
|
131 |
|
132 | ## Options
|
133 | The following are all the release steps, you can disable any you need to:
|
134 |
|
135 | ```js
|
136 | release: {
|
137 | options: {
|
138 | bump: false, //default: true
|
139 | changelog: true, //default: false
|
140 | changelogText: '<%= version %>\n', //default: '### <%= version %> - <%= grunt.template.today("yyyy-mm-dd") %>\n'
|
141 | file: 'component.json', //default: package.json
|
142 | add: false, //default: true
|
143 | commit: false, //default: true
|
144 | tag: false, //default: true
|
145 | push: false, //default: true
|
146 | pushTags: false, //default: true
|
147 | npm: false, //default: true
|
148 | npmtag: true, //default: no tag
|
149 | indentation: '\t', //default: ' ' (two spaces)
|
150 | folder: 'folder/to/publish/to/npm', //default project root
|
151 | tagName: 'some-tag-<%= version %>', //default: '<%= version %>'
|
152 | commitMessage: 'check out my release <%= version %>', //default: 'release <%= version %>'
|
153 | tagMessage: 'tagging version <%= version %>', //default: 'Version <%= version %>',
|
154 | beforeBump: [], // optional grunt tasks to run before file versions are bumped
|
155 | afterBump: [], // optional grunt tasks to run after file versions are bumped
|
156 | beforeRelease: [], // optional grunt tasks to run after release version is bumped up but before release is packaged
|
157 | afterRelease: [], // optional grunt tasks to run after release is packaged
|
158 | github: {
|
159 | repo: 'geddski/grunt-release', //put your user/repo here
|
160 | usernameVar: 'GITHUB_USERNAME', //ENVIRONMENT VARIABLE that contains Github username
|
161 | passwordVar: 'GITHUB_PASSWORD' //ENVIRONMENT VARIABLE that contains Github password
|
162 | }
|
163 | }
|
164 | }
|
165 | ```
|
166 |
|
167 | If you want to use multiline commit messages just pass an array to the `commitMessage` option instead of a string.
|
168 |
|
169 | ### Notes on Github Releases:
|
170 | 1. Yes, you have to use environment variables. I would be a terrible person if I let you check in your username and password into your source code.
|
171 | 2. The [Github Releases API](http://developer.github.com/v3/repos/releases/) is still unstable and may change in the future.
|
172 | 3. You can use an [access token](https://help.github.com/articles/creating-an-access-token-for-command-line-use) if you'd rather.
|
173 |
|
174 | For node libs, leave `file` option blank as it will default to `package.json`. For Bower components, set it to `bower.json`.
|
175 |
|
176 | ## License
|
177 | MIT
|