will/github-changelog-generator
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

README: Update the token failure example to OctoKit 404 failure (#525)

Browse Source
This commit is contained in:
Alexander Delgado 2017-05-28 23:54:32 -07:00 committed by Olle Jonsson
parent 20d059b78e
commit a26bcc326b
1 changed files with 10 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
README.md
View File

@ -104,7 +104,7 @@ since-tag=1.0.0
### GitHub token
GitHub only allows 50 unauthenticated requests per hour.
GitHub only allows 50 unauthenticated requests per hour.
Therefore, it's recommended to run this script with authentication by using a **token**.
Here's how:
@ -118,8 +118,12 @@ You can set an environment variable by running the following command at the prom
export CHANGELOG_GITHUB_TOKEN="«your-40-digit-github-token»"
So, if you got an error like this:
>! /Library/Ruby/Gems/2.0.0/gems/github_api-0.12.2/lib/github_api/response/raise_error.rb:14:in `on_complete'
So, if you get a message like this:
``` markdown
API rate limit exceeded for github_username.
See: https://developer.github.com/v3/#rate-limiting
```
It's time to create this token! (Or, wait an hour for GitHub to reset your unauthenticated request limit.)
@ -135,7 +139,7 @@ If you have a `HISTORY.md` file in your project, it will automatically be picked
### Rake task
You love `rake`? We do, too! So, we've made it even easier for you:
You love `rake`? We do, too! So, we've made it even easier for you:
we've provided a `rake` task library for your changelog generation.
Just put something like this in your `Rakefile`:
@ -208,14 +212,14 @@ An auto-generated changelog really helps, even if you manually fill in the relea
For example:
When you find a closed bug, it is very useful to know which release fixed it.
When you find a closed bug, it is very useful to know which release fixed it.
So that you can easily find the issue by \# in `CHANGELOG.md`.
- it's not quite as easy to find this in handwritten releases notes
- a generated file saves you the trouble of remembering everything;
sometimes people forget to add things to a handwritten file
Ultimately, I think GitHub Releases are ideal for end-users.
Ultimately, I think GitHub Releases are ideal for end-users.
Meanwhile, `CHANGELOG.md` lives right in the repository, with its detailed list of changes, which is handy for developers.
Finally, there's nothing wrong with using GitHub Releases alongside `CHANGELOG.md` in this combination.