GithubHelp home page GithubHelp logo

vercel / release Goto Github PK

View Code? Open in Web Editor NEW
3.5K 74.0 113.0 745 KB

Generate changelogs with a single command

Home Page: https://npmjs.com/release

License: MIT License

JavaScript 100.00%
github releases npm vercel

release's Introduction

Release

Release is a command line tool to automatically generate a new GitHub Release and populates it with the changes (commits) made since the last release.

Usage

Firstly, install the package from npm:

npm install -g release

Alternatively, you can use Yarn to install it:

yarn global add release

Once that's done, you can run this command inside your project's directory:

release <type>

A <type> argument can be passed. If you leave it out, a GitHub Release will be created from the most recent commit and tag.

According to the SemVer spec, the argument can have one of these values:

  • major: Incompatible API changes were introduced
  • minor: Functionality was added in a backwards-compatible manner
  • patch: Backwards-compatible bug fixes were applied

In addition to those values, we also support creating pre-releases like 3.0.0-canary.1:

release pre

You can also apply a custom suffix in place of "canary" like this:

release pre <suffix>

Assuming that you provide "beta" as the <suffix> your release will then be 3.0.0-beta.1 – and so on...

Options

The following command will show you a list of all available options:

release help

Pre-Defining Types

If you want to automate release even further, specify the change type of your commits by adding it to the title or description within parenthesis:

Error logging works now (patch)

Assuming that you've defined it for a certain commit, release won't ask you to set a type for it manually. This will make the process of creating a release even faster.

To pre-define that a commit should be excluded from the list, you can use this keyword:

This is a commit message (ignore)

Custom Hook

Sometimes you might want to filter the information that gets inserted into new releases by adding an intro text, replacing certain data or just changing the order of the changes.

With a custom hook, the examples above (and many more) are very easy to accomplish:

By default, release will look for a file named release.js in the root directory of your project. This file should export a function with two parameters and always return a String (the final release):

module.exports = async (markdown, metaData) => {
	// Use the available data to create a custom release
	return markdown;
};

In the example above, markdown contains the release as a String (if you just want to replace something). In addition, metaData contains these properties:

Property Name Content
changeTypes The types of changes and their descriptions
commits A list of commits since the latest release
groupedCommits Similar to commits, but grouped by the change types
authors The GitHub usernames of the release collaborators

Hint: You can specify a custom location for the hook file using the --hook or -H flag, which takes in a path relative to the current working directory.

Why?

As we at Vercel moved all of our GitHub repositories from keeping a HISTORY.md file to using GitHub Releases, we needed a way to automatically generate these releases from our own devices, rather than always having to open a page in the browser and manually add the notes for each change.

Contributing

You can find the authentication flow here.

  1. Fork this repository to your own GitHub account and then clone it to your local device
  2. Uninstall the package if it's already installed: npm uninstall -g release
  3. Link the package to the global module directory: npm link
  4. You can now use release on the command line!

As always, you can use npm test to run the tests and see if your changes have broken anything.

Credits

Thanks a lot to Daniel Chatfield for donating the "release" name on npm and my lovely team for telling me about their needs and how I can make this package as efficient as possible.

Author

Leo Lamprecht (@notquiteleo)

release's People

Contributors

4cm4k1 avatar aesopwolf avatar augustinlf avatar chabou avatar dependabot[bot] avatar dinoboff avatar facel3ss1 avatar fregante avatar greenkeeperio-bot avatar hoodwink73 avatar ijjk avatar leerob avatar leo avatar lgraubner avatar maiertech avatar mcansh avatar rafaelalmeidatk avatar sarupbanskota avatar styfle avatar timneutkens 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  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

release's Issues

Support for feature branches

My team uses feature branches, and we also use the "Squash and merge" feature within GitHub. This makes our master branch look like this (by default):

image

So, do you think it would be possible for release to detect commit messages in that format (instead of using parenthesis such as Error logging works now (patch))? The Angular guidelines could be used:

listed under ### Minor Changes:

  • feat
  • feature

listed under ### Patches:

  • fix
  • docs
  • style
  • refactor
  • perf
  • test
  • chore

So anything that begins with those words would automatically be sorted to minor or patch.

Use Bluebird

...unless this project is specifically a test case for native async/await.

Bluebird's implementations are still faster & more memory efficient than Node v7's version. Relying on Bluebird would also open the door to more Node versions.

GitHub Enterprise compatibility?

I've got GHE compatibility working in a fork I created, and was wondering if that is something you'd be open to accepting a PR for? Or is that something that you'd expect developers to fork-and-maintain their own version?

The configuration variables I had to override were:

  • host for GHE domain
  • pathPrefix for the api root path (typically api/v3)

And probably these too, but haven't confirmed yet:

  • username to replace zeit reference
  • clientId for custom oauth integration
  • authUrl for customizing the oauth server endpoint

Let me know what you think! I don't mind keeping a fork but would like to help contribute if that's something you eventually want.

Shows incorrect commits

I wanted to try release to make the next release for one of my project pixi-multistyle-text whish is currently 0.4.0. But when running it, it shows commits before that release, instead of showing only commits after that.

Here's what I get:

~/d/pixi-multistyle-text master ❯ release
✔ Checking if release already exists
✔ Loading commit history
! Please enter the type of change for each commit:

? chore: Remove gruntfile + new readme image (Use arrow keys)
❯ Minor Change (backwards-compatible functionality) 
  Patch (backwards-compatible bug fix) 
  ──────────────
  Ignore 

But as shown in the history, the commit is from Nov 5, 2016 and between 0.3.0 and 0.4.0, not after 0.4.0.

release-auth.now.sh is down

When going to release-auth.now.sh, I currently see an 502 error. The logs are:

▲ npm install
01/02/17 11:09:06 AM
Installing package micro@^6.1.0
01/02/17 11:09:07 AM
Installing package request@^2.79.0
01/02/17 11:09:07 AM
Installing package request-promise-native@^1.0.3
01/02/17 11:09:07 AM
Installing package xo@^0.17.1
01/02/17 11:09:16 AM
▲ npm start
01/02/17 11:09:17 AM
> Ready! Listening on http://0.0.0.0:5000
01/04/17 2:20:21 AM
TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
    at fromObject (buffer.js:284:9)
    at Function.Buffer.from (buffer.js:116:10)
    at new Buffer (buffer.js:95:17)
    at /home/nowuser/src/index.js:61:29
    at Generator.next (<anonymous>)
    at c (/home/nowuser/src/index.js:94:99)
    at process._tickCallback (internal/process/next_tick.js:103:7)

help doesn't work

~ ❯ release -h
Error! Directory is not a Git repository.

If it's a git repo, it will suggest to make a release.

Support for redirections

Right now, if a project has been renamed, release fails, even though git push does handle the redirection

Opening authentication page does not work on Bash @ Windows

When running release it tries to open the GitHub authentication page, but the only thing I see is a flickering console message.

robert@HODOR:/mnt/c/Users/robert/Documents/GitHub/release-test$ release
⠼ Opening GitHub authentication page...

Running Bash on Windows Version 10.0.14393 Build 14393, node version 7.3.0. Happy to supply more info if needed 😃

Move commit hash to before commit message

Instead of having commit hashes at the end of the commit message like we have now:

After message

It would align the changes better if they were before the commit message, since the commit hashes are always the same length:

Before message

Custom middleware support

Would be nice to create an image that you can easily share on twitter.

Some things can could be there:

  • The name of the project + version in one line
  • A facepile of all the contributors that helped with the release
  • Generated by release so more people know about this

That would be pretty sweet :)

Integration support for management tools (JIRA, Trello, etc.)

Hey guys, is there a plan to add integration support for management tools such as JIRA, Trello, etc.? We have a mapping between PR & commit with JIRA tickets and it'd be really cool to be able to set the release versions after generating the changelog on those management platforms.

The integration itself is very easy. Was just wondering if you have plan to incorporate them, through a plugin system perhaps?

Branch Needs to be Up-to-date

My repo is up to date with origin and on master:

parzival:react-color case$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
parzival:react-color case$ release
Error! Your branch needs to be up-to-date with origin.

Install fails on windows

Hello! I'm trying to upgrade release from 1.0.7 to 1.1.2 but I got this error:

> [email protected] preinstall C:\Users\Emanuele\AppData\Roaming\npm\node_modules\.staging\release-cca351ce
> bin/preinstall.js

'bin' is not recognized as an internal or external command, operable program or batch file.

CLI hangs after GitHub auth

👋 This is a great tool! I'm looking forward to using this on numerous projects.

I hit a few snags setting it up:

  1. I came back to my terminal after authenticating in the browser.
  2. The Opening GitHub authentication page... message remained on the screen for several seconds.
  3. I hit 'Enter' a few times.
  4. Eventually the GitHub step completed.
  5. My previous Enter keystrokes were buffered and used as input to answer the patch/minor/major question(s).

screen shot 2017-01-06 at 10 43 23 pm

A quick fix might be to lower this sleep value to something like 100ms. https://github.com/zeit/release/blob/d977a4a6c9878e643fa7fc43d959b8b77be14631/lib/connect.js#L107

Support maintenance branch and hotfix release

Add support for this workflow:

git checkout master
git tag v1.0.0
git push --tags
release
[...]
git tag v2.0.0
git push --tags
release
git chechout v1.0.0
git checkout -b maintenance
[...]
git tag v1.0.1
git push --tags
release

Currently (without #56), the last release call would try to create a release for v2.0.0 with the logs from HEAD to v1.0.0. If there was a v2.0.1 version, the release would be for v2.0.1 and would include all the logs from HEAD to the initial commit.

instead of releasing the tag with the highest semantic version, release should get the latest tag in relation to HEAD.

With ikhemissi/tagged-versions#14 we could filter tags by git revision range and the latest tag from HEAD.

With #57, the release would point to the correct tag.

FR: exit for node version is <7

It would be useful to message the user and exit in case of node version mismatch?

Something like:

const semver = require('semver')

// Check if the current version of node is >=7
if(!semver.satisfies(process.version, '>=7.0.0')) {
  console.log('Please use node version >=7, needed for `--harmony-async-await` flag.')
}

New mechanism

  • We shouldn't expect a git tag to exist
  • Based on whether or not the user selected any major changes, minor changes or patches, the package should create a new tag by itself (incremented from the last tag)

Offline mode

It would be nice to have an option to just output the release message instead of asking to authenticate with Github.

Couldn't check if release exists

I'm getting this error Error! Couldn't check if release exists. when trying to use release or access the options with release -h. What would cause this error? Are there any logs somewhere?

Using Node v7.2.1 on Mac OS 10.12.2

Use npm version tag for the release draft tag version

Using v1.1.0, release create a draft targeting tag "x.x.x" instead of "vx.x.x". It would then create a tag from master instead of using the tag created by npm version.

Steps

npm version patch
git push origin master vx.x.x
release

Result

Open browser to a release draft with the "Tag version" field set "x.x.x" and an empty "Release title" field.

Expected

It should create draft release with "Tag version" set to "vx.x.x" and "Release title" set to "x.x.x"

version prefix

Not sure if this is intended or a bug, but npm version .... creates a version with the v prefix ( eg: v0.2.0) while release creates a separate one without the prefix (eg: 0.2.0).

node: bad option: --harmony-async-await

running release shows

node: bad option: --harmony-async-await

More Info

node -v

v6.9.1

npm -v

3.10.8

cat /etc/lsb-release

DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

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.