Frequently Asked Questions

Welcome to Greenkeeper’s FAQ. Since you’re here, we’ll assume that you’re having trouble with something, and we’re sorry things didnt work out smoothly for you. Hopefully the FAQ will help. If you can’t find what you’re looking for here, there’s also the documentation page, and if that doesn’t help, you can contact us directly.

Greenkeeper isn’t creating the Inital Pull Request

The first thing to note: the Initial Pull Request can take up to 30 minutes to arrive. It’s usually much faster, but the time it takes depends on the complexity of your tests and the state of your CI service. If nothing happens after 30 minutes, something probably went wrong.

Basic troubleshooting: make sure you’ve completed the installation correctly. Then please read the requirements Greenkeeper has for each repo. If you’ve missed one or more and fixed them, please reset the repo and check if it works now.

Here are all known possible causes and their fixes:

There is no CI configured. Set up a CI integration for your repo and reset it.
You’re using a CI service that does not report statuses to branches. Greenkeeper cannot work without these statuses, so there is no solution to this.
The CI service cannot work on the branches Greenkeeper creates, it might be limited to master only, for example. Give the CI permission to access all branches, or whitelist branches with greenkeeper in their name. For example:
```
branches:
  only:
    - master
    - /^greenkeeper.*$/
```
Then reset.
Your dependencies are all up to date and your repo’s readme already has a Greenkeeper badge for some reason. Greenkeeper will not send a PR in this case (because there are no changes for it to make), and instead begin its work silently. If it turns out not to be doing anything even when you know one of your dependencies has updated, remove the badge from the readme and reset the repo.
Issues are not enabled on your repo. Greenkeeper will inform you about updates through both pull requests and issues, so it can’t work without them. Enable issues in the repo settings and reset the repo.
The repo is a fork. Issues are disabled on forks by default, which makes it impossible for Greenkeeper to work. See the previous point for details and the solution.
The default branch of the repo was changed while Greenkeeper was waiting for your CI to complete. You’ll have to trigger Greenkeeper again by resetting the repo.
The repo was moved or renamed. This is impossible for us to detect, since GitHub doesn’t inform Greenkeeper about these events. In both cases, the repo’s ID is not changed by GitHub, so Greenkeeper could be forgiven for thinking it’s already activated. The only solution is to contact support and let us reset the offending repo for you.

Greenkeeper is creating branches and immediately deleting them again

This is intentional. Greenkeeper creates the branches so your CI can run on them, and if the dependency updates are within your specified ranges and not breaking your tests, there’s no need to keep the branch around. Also, there’s no point in bothering you with issues or a PR, since everything still works as you intended.

You’ll only receive pull requests when an in-range dependency breaks your build, or when a dependency updates outside your specified range. Read up on how Greenkeeper works step-by-step for a more detailed explanation.

I would like to get pull requests for every dependency update

If you pin your dependencies to a specific version, you will see an update for every new version that is released for that dependency. You’ll get a PR per dependency, with an issue per update.

Pin your versions like this, with one specific version number instead of a range (no caret, tilde, comparisons or ranges):

        {
  "dependencies": {
    "lodash": "4.0.0"
  }
}

I downgraded a dependency to see whether Greenkeeper works, but nothing happens

That’s actually by design: In the Initial Pull Request, Greenkeeper updates all your dependencies to the latest version. You make sure all tests pass, and merge the PR. If any of your dependencies updates past this point, Greenkeeper will run your tests against the update. If you now downgrade a dependency in your package.json, say from ^1.5.0 (latest) to ^1.2.0, nothing actually changes: when your CI runs, it will install 1.5.0 either way. The same is true if your users run npm install on your package. So there’s actually no point in Greenkeeper doing anything: the outcome wouldn’t change.

Greenkeeper works when it runs your tests when a dependency updates, all it really cares about is whether your tests pass with the latest versions of your dependencies, not whether all dependencies in your package.json are actually set to their latest versions.

If you want to be explicitly notified of every update for a dependency, you can pin it.

If you downgrade to a pin (say, from ^1.5.0 (latest) to 1.2.0 (notice the absence of a caret, this is not a range, but a specific version), Greenkeeper also won’t immediately spring into action to bump this up back to 1.5.0 (latest) because that would counteract what it sees as a purposeful human decision. It will however still let you know when a newer version is released.

I got a broken pull request (corrupted branch), and now I can’t git pull anymore

If this is what the changed files tab in a Greenkeeper PR looks like, you’ve probably got this issue

This sometimes happens when GitHub garbage collects things we still need. It’s less severe than it looks, and the fix is simple: delete the offending branch. Greenkeeper will recover and try again. We’re aware of the issue and are working to find a way to prevent it.

Some PRs are stuck on "Some checks haven’t completed yet" because of greenkeeper/verify

This happens because the greenkeeper/verify status was set to required in the repo’s branch settings. That requirement will apply to all pull requests, not only those opened by Greenkeeper. Since Greenkeeper doesn’t verify non-Greenkeeper PRs, the greenkeeper/verify status will never be reported, and your PRs will be stuck on "Some checks haven’t completed yet" forever. To fix this, go to https://github.com/[user/org]/[repo]/settings/branches/master and make sure that the greenkeeper/verify status is not checked.

Can I enable Greenkeeper on a different branch?

At this point, there is no configuration setting for the branch, but Greenkeeper picks the default branch that is set up on GitHub as the source for Pull Requests, so that’s a place where you can change it.

Can collaborators install Greenkeeper too?

No, only admins of the organisation. Greenkeeper creates branches on your repository to send you PRs, and we need push access to the repository. On top of that we need to create webhooks so we can keep your package.json content in sync. Giving Greenkeeper these permissions can only be done by an admin of the organisation. Having admin rights to an individual repo in an organisation is not sufficient.

Can I pay for a whole year instead of by month?

Yes, in both versions of Greenkeeper:

If you subscribed directly via greenkeeper.io, you can switch to yearly billing in the account dashboard.
If you bought Greenkeeper in the GitHub Marketplace, you’ll be billed on the same billing cycle as your GitHub subscription, so if that’s yearly, Greenkeeper is too.

I only have private repositories, can I try Greenkeeper for free anyway?

Yes, in the GitHub Marketplace version of Greenkeeper, where all billing is handled by GitHub, we offer a 14-day free trial for all plans.

If you install Greenkeeper directly as a GitHub App, where all billing is done separately via Stripe, we don’t offer free trials. We will however refund your first month if you’re unhappy with the service, no questions asked.