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
- I can’t enable a repo that was recently renamed
- Greenkeeper is creating branches and immediately deleting them again
- I would like to get pull requests for every dependency update
- I downgraded a dependency to see whether Greenkeeper works, but nothing happens
- I got a broken pull request (corrupted branch), and now I can’t git pull anymore
- Can I enable Greenkeeper on a different branch?
- Can collaborators enable Greenkeeper too?
- Can I pay for a whole year instead of by month?
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
masteronly, for example. Give the CI permission to access all branches, or whitelist branches with
greenkeeperin their name. Then reset.
- Your repo is in a Lerna/monorepo setup. We don’t support that at the moment, sorry.
- Your dependencies are all up to date and your repo’s
readmealready 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
readmeand 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.
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.Back to top
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):
That’s actually by design: In the Initial Pull Request, Greenkeeper updates all your depencies 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.
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.Back to top
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.Back to top
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, which requires admin access.
So no, unfortunately being a collaborator currently isn’t sufficient.Back to top
Not yet, sorry. We’re interested in this too, though.Back to top