Skip to content

Update the token failure example to OctoKit 404 failure #525

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

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 10 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand All @@ -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.)

Expand All @@ -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`:
Expand Down Expand Up @@ -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.

Expand Down