greenkeeperio/greenkeeper-lockfile

:lock: Your lockfile, up to date, all the time

greenkeeper-lockfile's Issues

I'm trying to set this up by myself, could you give me some pointers to finish it up?

Hi there,

I am considering using this for one of my open source projects and I wanted to see if I could set this up.
Could you give me some pointers too what is missing, so I can help finish the project?
Is there a feature list or set of missing and required functionality for this to work?

Thanks,
Michael

Allow overriding commit messages

I use more traditional commit messages so the chore(package): is annoying and creates ugly inconsistencies in my commit history.

"Only running on first push of a new branch" error on new greenkeeper branch

I am getting this error for new branches created by greenkeeper. I run greenkeeper-lockfile in CircleCI.
Branch: https://github.com/patkub/rmc1891-site/tree/greenkeeper/bs4-polymer-0.1.12
CircleCI: https://circleci.com/gh/patkub/rmc1891-site/736

Looks like issue #26 still occurs.

Add Codeship support

Not sure if this is being worked on already, which is why I'm creating this issue.
Looking at the source, this is what will have to be done:

• An entry must be added to tests.js to test for Codeship
  https://github.com/greenkeeperio/greenkeeper-lockfile/blob/master/ci-services/tests.js

• A file codeship.js needs to be created to take the correct environment variables from codeship.
  https://github.com/greenkeeperio/greenkeeper-lockfile/blob/master/ci-services/travis.js

• Because Codeship does not provide enough information (for performance reasons), hacky workarounds need to be tested very carefully.

If this is all, I'll be able to do this sometime this week.

Be smarter about when to upload the shrinkwrap

Right now this plugin uploads the updated shrinkwrap whenever it can.
In cases where the Greenkeeper update is an in-range update and the build passes this wouldn't be necessary anymore.
Furthermore as the branch is then modified Greenkeeper won't delete it anymore.

By figuring out whether the current update is in-range, or out of range, and looking at the result, we could avoid this.

Error: Cannot find module

Can you please help me figure out what is going wrong?

PR - sudo-suhas/elastic-builder#10
Travis build - https://travis-ci.org/sudo-suhas/elastic-builder/builds/247961511
Error message - Error: Cannot find module 'resolve-from'

Error stack trace

> [email protected] exec-tests /home/travis/build/sudo-suhas/elastic-builder
> cross-env NODE_ENV=test nyc --cache ava _build --concurrency 3
module.js:487
    throw err;
    ^
Error: Cannot find module 'resolve-from'
    at Function.Module._resolveFilename (module.js:485:15)
    at Function.Module._load (module.js:437:25)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/travis/build/sudo-suhas/elastic-builder/node_modules/import-local/node_modules/resolve-cwd/index.js:2:21)
    at Module._compile (module.js:569:30)
    at Module.replacementCompile (/home/travis/build/sudo-suhas/elastic-builder/node_modules/nyc/node_modules/append-transform/index.js:58:13)
    at module.exports (/home/travis/build/sudo-suhas/elastic-builder/node_modules/nyc/node_modules/default-require-extensions/js.js:8:9)
    at Object.<anonymous> (/home/travis/build/sudo-suhas/elastic-builder/node_modules/nyc/node_modules/append-transform/index.js:62:4)
    at Module.load (module.js:503:32)

Another instance
PR - sudo-suhas/elastic-builder#8
Travis Build - https://travis-ci.org/sudo-suhas/elastic-builder/builds/244604801
Error message - Error: Cannot find module 'tapable'

Error stack trace

> [email protected] precompile-tests /home/travis/build/sudo-suhas/elastic-builder
> cross-env NODE_ENV=test webpack --config webpack.config.test.js
module.js:487
    throw err;
    ^
Error: Cannot find module 'tapable'
    at Function.Module._resolveFilename (module.js:485:15)
    at Function.Module._load (module.js:437:25)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/travis/build/sudo-suhas/elastic-builder/node_modules/webpack/lib/Compiler.js:6:15)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)

travis.yml

language: node_js

cache:
  directories:
    - node_modules

node_js:
  - '8'
  - '7'
  - '6'
  - '4'

branches:
  except:
    - /^v\d+\.\d+\.\d+$/

before_install:
# package-lock.json was introduced in npm@5
  - npm install -g npm@5
  - npm install -g greenkeeper-lockfile@1

before_script: greenkeeper-lockfile-update

script: npm run check

# Only the node version 8 job will upload the lockfile
after_script:
  - greenkeeper-lockfile-upload
  - npm run coverage

Make this plugin easily extendable for more CI serv{ers,ices}

Right now everything is hardcoded to Travis CI and depending on environment variables set by it.

We should add a mapping for these values, so it's super easy to contribute other CI servers.

Strict mode error on Travis with Node.js 4 or 5

Hello,

When running greenkeeper-lockfile-upload on Travis with Node.js 4 or 5, I'm getting a strict mode error. Shouldn't 'use strict' be added to update.js and upload.js?

/home/travis/.nvm/versions/node/v5.12.0/lib/node_modules/greenkeeper-lockfile/upload.js:36
  let remote = `[email protected]:${info.repoSlug}`
  ^^^
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:387:25)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:148:18)
    at node.js:405:3

update-lockfile fails if npm install changed the package.json

It seems like update-lockfile fails if npm install changes the package.json.

In the following example, npm install added an empty line at the end of the package.json, which causes update-lockfile to fail: https://travis-ci.org/125m125/ktapi-js/jobs/335830733

Fix Yarn Dependency Prefix Bug

I know this a duplicate of #85, but I'm trying to draw attention to the fact that there is an open PR which appears to resolve the issue, but which is not receiving any feedback from Greenkeeper.

Can anyone from Greenkeeper advise on the issue / PR?

Frequent yarn errors seen while installing greenkeeper-lockfile

This is breaking several CI builds and preventing other tests from being run.

For example, https://travis-ci.org/ampproject/amphtml/jobs/337372959#L1575

Error logs:

30.66s$ yarn global add greenkeeper-lockfile@1
yarn global v1.3.2
[1/4] Resolving packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/greenkeeper-lockfile: ETIMEDOUT".
info If you think this is a bug, please open a bug report with the information provided in "/home/travis/.config/yarn/global/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/global for documentation about this command.
The command "yarn global add greenkeeper-lockfile@1" failed and exited with 1 during .

Fails on Semaphore CI

As per the settings,

I have

yarn global add greenkeeper-lockfile@1
yarn

Then before my build, when I run

greenkeeper-lockfile-update

I get:

/home/runner/.config/yarn/global/node_modules/greenkeeper-lockfile/ci-services/bitrise.js:8
  const repoUrlWithoutGitExtension = repoUrl.replace('.git', '')
                                             ^

TypeError: Cannot read property 'replace' of undefined
    at parseRepoSlug (/home/runner/.config/yarn/global/node_modules/greenkeeper-lockfile/ci-services/bitrise.js:8:46)
    at Object.<anonymous> (/home/runner/.config/yarn/global/node_modules/greenkeeper-lockfile/ci-services/bitrise.js:19:13)
    at Module._compile (module.js:641:30)
    at Object.Module._extensions..js (module.js:652:10)
    at Module.load (module.js:560:32)
    at tryModuleLoad (module.js:503:12)
    at Function.Module._load (module.js:495:3)
    at Module.require (module.js:585:17)
    at require (internal/module.js:11:18)
    at module.exports (/home/runner/.config/yarn/global/node_modules/greenkeeper-lockfile/ci-services/index.js:12:10)

Any suggestions?

publish in npm

Hey guys,

would you mind to publish the latest version on npm registry also? At the moment the setup is not working like expected:

$ npm install -g greenkeeper-shrinkwrap

npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/greenkeeper-shrinkwrap
npm ERR! 404 
npm ERR! 404  'greenkeeper-shrinkwrap' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)

Thanks!

Fails on yarn v1.0.x

First of all, I'd like to thank everybody who contributed to this useful library, it saved a lot of time and effort to manage things while working on an enormous number of repositories with a tree-like dependency structure among each other.

And I'd like to point out that this greenkeeper-lockfile repository fails to return success code using yarn v1.0.x - as seen below:

failed

• https://circleci.com/gh/fulls1z3/ngx-config/70
  fixed
• https://circleci.com/gh/fulls1z3/ngx-config/71

In order to find this information, I had to play with some config/env values, and it's not fair to say the reason that the library fails 100% because of yarn v1.0.x - however, I think this information/observation would be useful to develop a fix.

If I can find some time, I'll try to make some contributions with a PR.

Cheers 👍

Bug: shrinkwrap commit fails on dev dependency update

We are being flooded with breaking greenkeeper branches, because whenever a dev dependency is updated, this script tries to commit without changes, because the shrinkwrap file does not need an update.

It should either skip dev dependency updates, or check if there are changes to be committed before trying to commit anything.

Add option to shrinkwrap devDependencies

We shrinkwrap our devDependencies because we had a lot of build failures due to in-version breaking changes or bugs in build tools. To include them, you need to run npm shrinkwrap --dev

Running on a git tag errors

On Circle CI, when CI checks out a tag and runs the build from the git tag:

greenkeeper-lockfile-update
fatal: ambiguous argument 'undefined': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
/home/ubuntu/.config/yarn/global/node_modules/greenkeeper-lockfile/update.js:35
  if (!info.branchName.startsWith(config.branchPrefix)) {
                      ^

TypeError: Cannot read property 'startsWith' of undefined
    at Module.update [as exports] (/home/ubuntu/.config/yarn/global/node_modules/greenkeeper-lockfile/update.js:35:23)
    at Object.<anonymous> (/home/ubuntu/.config/yarn/global/node_modules/greenkeeper-lockfile/update.js:56:37)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3

greenkeeper-lockfile-update returned exit code 1

Action failed: greenkeeper-lockfile-update

Fails on Node 4

I have a package-lock.json but no npm-shrinkwrap.json nor yarn.lock.
On Node 4 it fails with the following error:

/home/travis/.nvm/versions/node/v4.8.4/lib/node_modules/greenkeeper-lockfile/lib/update-lockfile.js:39
      const flag = flags[dependency.type]
      ^
SyntaxError: Identifier 'flag' has already been declared
    at updateLockfile (/home/travis/.nvm/versions/node/v4.8.4/lib/node_modules/greenkeeper-lockfile/lib/update-lockfile.js:23:42)
    at Module.update [as exports] (/home/travis/.nvm/versions/node/v4.8.4/lib/node_modules/greenkeeper-lockfile/update.js:60:3)
    at Object.<anonymous> (/home/travis/.nvm/versions/node/v4.8.4/lib/node_modules/greenkeeper-lockfile/update.js:68:37)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:140:18)
    at node.js:1043:3

Here is an example: https://travis-ci.org/vanduynslagerp/karma-rollup-preprocessor/jobs/263515447

It works fine on Node 6 and up (I didn't test for Node 5).

core dump on TravisCI

$ npm install -g greenkeeper-lockfile@1
npm WARN npm npm does not support Node.js v9.0.0
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8.
npm WARN npm You can find the latest version at https://nodejs.org/
/home/travis/.nvm/versions/node/v9.0.0/bin/node[2988]: ../src/node_zlib.cc:430:static void node::{anonymous}::ZCtx::Init(const v8::FunctionCallbackInfo<v8::Value>&): Assertion `args.Length() == 7 && "init(windowBits, level, memLevel, strategy, writeResult, writeCallback," " dictionary)"' failed.
 1: node::Abort() [npm]
 2: node::Assert(char const* const (*) [4]) [npm]
 3: 0x1251ea1 [npm]
 4: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) [npm]
 5: 0xb74c3c [npm]
 6: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [npm]
 7: 0x111383e042fd
/home/travis/.travis/job_stages: line 57:  2988 Aborted                 (core dumped) npm install -g greenkeeper-lockfile@1
The command "npm install -g greenkeeper-lockfile@1" failed and exited with 134 during .
Your build has been stopped.

Likely it's npm@5 + [email protected] issue. Checking on it....

Consider --force option when reinstalling package

Current version of updateLockFile function calls npm install without --force flag. Such method fails when package is a dev-dependency of itself (e.g. bundler, which bundles itself; it's the case with rollup and my project, in which I encountered this issue):

Travis CI log

	Error: Command failed: npm install -D --save-prefix="^" @comandeer/[email protected]
	npm ERR! code ENOSELF
	npm ERR! Refusing to install package with name "@comandeer/rollup-lib-bundler" under a package
	npm ERR! also called "@comandeer/rollup-lib-bundler". Did you name your project the same
	npm ERR! as the dependency you're installing?
	npm ERR! 
	npm ERR! For more information, see:
	npm ERR!     <https://docs.npmjs.com/cli/install#limitations-of-npms-install-algorithm>
	npm ERR! A complete log of this run can be found in:
	npm ERR!     /home/travis/.npm/_logs/2018-02-03T21_18_40_904Z-debug.log
	    at checkExecSyncError (child_process.js:601:13)
	    at execSync (child_process.js:641:13)
	    at updateLockfile (/home/travis/.nvm/versions/node/v8.9.4/lib/node_modules/greenkeeper-lockfile/lib/update-lockfile.js:44:7)
	    at Module.update [as exports] (/home/travis/.nvm/versions/node/v8.9.4/lib/node_modules/greenkeeper-lockfile/update.js:54:3)
	    at Object.<anonymous> (/home/travis/.nvm/versions/node/v8.9.4/lib/node_modules/greenkeeper-lockfile/update.js:62:37)
	    at Module._compile (module.js:643:30)
	    at Object.Module._extensions..js (module.js:654:10)
	    at Module.load (module.js:556:32)
	    at tryModuleLoad (module.js:499:12)
	    at Function.Module._load (module.js:491:3)

Addition of --force flag should be enough. It also should be safe in this context as greenkeeper just reinstalls already installed package.

"error Missing list of packages to add to your project."

With yarn on Travis CI:

$ greenkeeper-lockfile-update
error Missing list of packages to add to your project.
child_process.js:518
    throw err;
    ^
Error: Command failed: yarn add -S  [email protected]
error Missing list of packages to add to your project.
    at checkExecSyncError (child_process.js:475:13)
    at execSync (child_process.js:515:13)
    at updateLockfile (/home/travis/.config/yarn/global/node_modules/greenkeeper-lockfile/lib/update-lockfile.js:34:7)
    at Module.update [as exports] (/home/travis/.config/yarn/global/node_modules/greenkeeper-lockfile/update.js:49:3)
    at Object.<anonymous> (/home/travis/.config/yarn/global/node_modules/greenkeeper-lockfile/update.js:56:37)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)

-S doesn't appear to be a valid option for yarn add.

Update all lockfiles?

Right now my project just has a lockfile for yarn, but now that npm@5 is out and uses a lockfile, I'd like to have one for both. Would greenkeeper keep both of them up-to-date, so user could choose which they'd like to use?

Have Greenkeeper bot run this as part of the initial PR.

[@janl 2017-10-18: Edited for clarity, original version in detail view]

It would be a benefit to those who have a lockfile in their repo for the original greenkeeper PR to include an update to the lockfile. This would make that be included and prevent the issue as described in #24.

Original Post

Providing GH_TOKEN access in Travis can be viewed as a security risk. https://medium.com/@gajus/distributing-a-self-replicating-malicious-code-using-npm-cf2bf3209293

Then, the integration scoping would be used for commit access and you wouldn't have to provide a personal access token to Travis or whatever CI system you use. It can remain a GitHub integration.

It would be a benefit to those who have a lockfile in their repo for the original greenkeeper PR to include an update to the lockfile. This would make that be included and prevent the issue as described in #24.

Thank you!

Commit with --no-verify

Woops. It seems that my commit hook is running in CI when greenkeeper-lockfile-update makes the commit. See here. And by the way, ignore the warnings there—they're a different issue. Perhaps we should commit with --no-verify?

No longer getting "greenkeeper/verify - Greenkeeper verified pull request" on PR after using this plugin

yarn cannot install greenkeeper-lockfile correctly anymore

As of today the greenkeeper-lockfile binaries are not found anymore by default when installing greenkeeper-lockfile on travis with yarn as described in the README.

I receive this error:

greenkeeper-lockfile-update: command not found

It might have todo with the latest update of the travis images. https://blog.travis-ci.com/2017-12-12-new-trusty-images-q4-launch

Example:
https://travis-ci.org/researchgate/react-fast-highlight/jobs/316007440

I haven't tested with npm.

doesn't run as part of the initial: Update dependencies to enable Greenkeeper

We are currently introducing greenkeeper to our projects and the greenkeeper-lockfile tool does not run.

I suspect that this is due to the fact that the greenekeeper/initial branch contains the following two commits:

chore(package): update dependencies
docs(readme): add Greenkeeper badge

But the greenkeeper-lockfile tool expects only one commit.

Incorrect dependency prefix after upgrade

Everytime we get a PR for a dependency upgrade, our lockfile gets corrupted so that running yarn --frozen-lockfile gives the error:

error Your lockfile needs to be updated, but yarn was run with `--frozen-lockfile`.

We get two commits in our PR (example with a recent typescript dependency upgrade):

and

As you can see, the first commit correctly keep the dependency range (tilde in our case). While, in the second commit, the tilde is removed in the yarn.lock file. This is what makes it corrupt.

I've looked through the implementation here and it seems to boil down to the command:

yarn add -D --tilde [email protected]

Which updates yarn.lock and package.json - and removes the tilde from both.

greenkeeper-lockfile only stages and commits the lockfile which causes the corruption.

However, we want to maintain our version ranges, so even if it staged package.json too it wouldn't be right.

It seems like if I do yarn add -D typescript@~2.6.1 (that is, put the range in the dependencies version), it works as expected.

We've been using version 1.2.1 of yarn, but see the same behavior in 1.3.2 (latest right now) and 0.24.8.

No update to lock file on pull request additions

Greenkeeper creates a pull request to bump a dependency that is out of date. If a newer version of that dependency is released while that pull request is open, greenkeeper adds another commit to the pull request to increase the version of the dependency to match the latest release. However, these subsequent bumps do not update the lockfile

Example:

atlassian/react-beautiful-dnd#213 (comment)

Greenkeeper should update lockfile if branch is updated from master

Greenkeeper should also update the lockfile if I update the branch from master. This happens when two packages have updates, I merge one, update the second branch from the new master, and now CI complains the lockfile needs to be updated (I run yarn with --frozen-lockfile).

See https://circleci.com/gh/winsleague/winsleague/1158

CircleCI never updates

Hey guys,

we've noticed that on CircleCI greenkeeper-lockfile always skips to update.

This already happens when greenkeeper creates the branch (first commit).

By looking at the code it seems that the problem comes from correctBuild being false.

greenkeeper-lockfile/update.js

Lines 33 to 35 in e4ba1a3

	if (!info.correctBuild) {
	return console.error('This build should not update the lockfile. It could be a PR, not a branch build.')
	}

which is determined by

greenkeeper-lockfile/ci-services/circleci.js

Line 9 in e4ba1a3

correctBuild: _.isEmpty(env.CI_PULL_REQUEST),

Now, if I look at the CI variables the CI_PULL_REQUEST is set

CI_PULL_REQUEST=https://github.com/xxx/xxx/pull/2204

So it seems that for CircleCI it will always skip to update.

What is the reason for using _.isEmpty(env.CI_PULL_REQUEST)? Is this supposed to work differently?

Thanks for the help!

The key you are authenticating with has been marked as read only

I want to run greenkeeper-lockfile-upload on CircleCI but I am getting the following error:

#!/bin/bash -eo pipefail
greenkeeper-lockfile-upload
ERROR: The key you are authenticating with has been marked as read only.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
child_process.js:611
throw err;
^

Error: Command failed: git push gk-origin HEAD:greenkeeper/binance-api-node-0.5.2
ERROR: The key you are authenticating with has been marked as read only.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

at checkExecSyncError (child_process.js:568:13)
at execSync (child_process.js:608:13)
at Module.upload [as exports] (/usr/local/share/.config/yarn/global/node_modules/greenkeeper-lockfile/upload.js:53:3)
at Object. (/usr/local/share/.config/yarn/global/node_modules/greenkeeper-lockfile/upload.js:56:37)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
at Function.Module.runMain (module.js:605:10)
Exited with code 1

Do I need to add a GitHub SSH Key on CircleCI to solve this issue?

GitHub Token exposed in output of greenkeeper-lockfile-upload

I am not sure if this is intended

See "Upload greenkeeper-lockfile" step in anishkny/realworld-e2e-test/39

#!/bin/bash -eo pipefail
greenkeeper-lockfile-upload
To https://[email protected]/anishkny/realworld-e2e-test
   9bdee0e..aa83790  HEAD -> greenkeeper/puppeteer-0.13.0

The authenticity of github.com

My build on Travis now hang on:

$ greenkeeper-lockfile-upload
The authenticity of host 'github.com (192.30.253.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? 

For reference see my Travis build.

Updating yarn dependencies fails on travis

For us it tries to run yarn add -S [email protected]
lint-staged is a dependency in the project

I think it happens here:

greenkeeper-lockfile/lib/update-lockfile.js

Line 26 in 590bc5f

const flag = flags[dependency.type]

But since yarn doesn't accept -S and does that by default it fails

Sample CircleCI config

Hey all, I'm new to CI config, and feeling a bit lost around getting this working with CircleCI. Would someone be willing to share an example of a basic CircleCI config file?

Really appreciate it!

Greenkeeper lockfile update fails with permission denied

First, thanks for making an awesome open source product! 💖

I've noticed a quirk on Travis CI where the lockfile package appropriately handles updating the lockfile locally in CI for testing, but is unable to upload the results to generate a lockfile update commit. 🤔

Is this a misconfiguration from the continuous integration side? Or is this coming from the greenkeeper lockfile side?

Log output

Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
child_process.js:635
    throw err;
    ^
Error: Command failed: git push gk-origin HEAD:greenkeeper/@commitlint/cli-4.0.0
Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
    at checkExecSyncError (child_process.js:592:13)
    at execSync (child_process.js:632:13)
    at Module.upload [as exports] (/home/travis/.nvm/versions/node/v8.6.0/lib/node_modules/greenkeeper-lockfile/upload.js:53:3)
    at Object.<anonymous> (/home/travis/.nvm/versions/node/v8.6.0/lib/node_modules/greenkeeper-lockfile/upload.js:56:37)
    at Module._compile (module.js:624:30)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)
    at Function.Module.runMain (module.js:665:10)

Travis CI configuration

{
  "language": "node_js",
  "node_js": 8,
  "before_install": [
    "npm i -g npm@5",
    "npm i -g greenkeeper-lockfile@1"
  ],
  "before_script": "greenkeeper-lockfile-update",
  "after_script": "greenkeeper-lockfile-upload",
  "group": "stable",
  "dist": "trusty",
  "os": "linux"
}

full log: https://travis-ci.org/ChristianMurphy/json-schema-keyref/jobs/283327834
pull request: ChristianMurphy/json-schema-keyref#34

Cannot run with yarn option --ignore-engines

The way we update the lock file currently is using the --ignore-engines option as we're using packages on node 4 which require a higher version (e.g. 6.5), one example below
Therefore the greenkeeper-lockfile-update command in CI fails with error e.g:

error [email protected]: The engine "node" is incompatible with this module. Expected version ">=6.5.0".
error Found incompatible module

We should be able to pass options to yarn via the greenkeeper-lockfile-update script

Lockfile update being skipped with "Only running on first push of a new branch" even though there's only one commit

We recently enabled greenkeeper and greenkeeper-lockfile for our project at github.com/ampproject/amphtml, which uses yarn for package management, and therefore, contains the package.json and yarn.lock files.

We now have a handful of PRs opened by the greenkeeper bot with updates to package.json, but with no updates to yarn.lock. I made sure we were setting a GH_TOKEN and then rebased the greenkeeper/* branches on the latest HEAD on our master branch in the hope that the lockfiles are updated with the new GH_TOKEN present.

When I look at the Travis CI logs, I see that greenkeeper-lockfile-update is returning the status Only running on first push of a new branch in spite of the fact that the branch has only one commit pushed to it. As a result, we cannot merge any of the PRs created by greenkeeper.

Any idea what's going on here, and what I can do to make sure greenkeeper-lockfile-update actually updates the lockfile?

Here's an example of a PR: ampproject/amphtml#12793
And here are the corresponding Travis CI logs: https://travis-ci.org/ampproject/amphtml/jobs/327981188#L673

Alternatively, if these PRs are a lost cause due to the "first push" rule being violated, would it help to delete the greenkeeper branches so that they can be freshly generated by the bot in due course of time and have the lockfile properly updated?

Thanks!

"Only running on first push of a new branch" error even on first push

I was hoping to make use of this to update my yarn.lock but the first branch pushed from @greenkeeperio printed out this message:

Only running on first push of a new branch

This is on a private CircleCI repo.

How should I handle yarn.lock conflicts?

The repository I'm asking about: https://github.com/sweetalert2/sweetalert2-adonisjs-nuxtjs

At the same time Greenkeeper submits 2 PRs because 2 dependencies were updated:

• https://github.com/sweetalert2/sweetalert2-adonisjs-nuxtjs/pull/21
• https://github.com/sweetalert2/sweetalert2-adonisjs-nuxtjs/pull/22

If I merge one of them, another will have the yarn.lock conflict and I won't be able to merge it. what is the right way to handle such cases?

Docker support

We're trying to run greenkeeper-lockfile commands from within a docker container and are running into 'master' is not a Greenkeeper branch.

I'm not sure if it's possible to run greenkeeper-lockfile commands from within a docker container, but if it is the documentation around what needs to be passed in, or why it fails is not very clear.

I suppose my main request is updating documentation around exactly what volumes/environment variables greenkeeper expects when running inside of a container.

Jenkins w/ Jenkinsfile pipeline not working properly

It reports Only running on first push of a new branch, even on the first push of the branch.

I debugged a bit and ran the commands I see in git_helper manually:

$ git for-each-ref '--format=%(refname)' refs/ | grep /PR-15904
refs/heads/PR-15904
refs/remotes/origin/PR-15904

$ notArg=$(git for-each-ref '--format=%(refname)' refs/ | grep -v /PR-15904)
...
refs/remotes/origin/another-update
refs/remotes/origin/greenkeeper/aws-sdk-2.125.0
refs/remotes/origin/greenkeeper/file-loader-1.1.0
refs/remotes/origin/greenkeeper/file-loader-1.1.1
refs/remotes/origin/greenkeeper/file-loader-1.1.2
refs/remotes/origin/greenkeeper/file-loader-1.1.3
refs/remotes/origin/greenkeeper/file-loader-1.1.4
refs/remotes/origin/stuff
refs/remotes/origin/things
...

$ git log refs/heads/PR-15904 --oneline --not "${notArg}"

No output from this command

Current instructions for Travis-ci.org setup are either wrong or incomplete

hi all,

I try to enable greenkeeper-lockfile on Travis-ci.org, on an open source package, string-remove-duplicate-heads-tails.

I tried the provided snippet for Travis,

before_install:
# package-lock.json was introduced in npm@5
- '[[ $(node -v) =~ ^v9.*$ ]] || npm install -g npm@latest' # skipped when using node 9
- npm install -g greenkeeper-lockfile@1
before_script: greenkeeper-lockfile-update
after_script: greenkeeper-lockfile-upload

it does not work. Each commit I publish consists of two commits actually, "master" and another that is incurred by npm version .... I thought, maybe isolating "master"-only would help. Apparently, not. See the last line "except" I nicked from this package's .travis.yml:

language: node_js
node_js:
  - node
before_install:
# package-lock.json was introduced in npm@5
- '[[ $(node -v) =~ ^v9.*$ ]] || npm install -g npm@latest' # skipped when using node 9
- npm install -g greenkeeper-lockfile@1
before_script: greenkeeper-lockfile-update
after_script: greenkeeper-lockfile-upload
after_success: npm run coverage
notifications:
  email:
    on_success: never
    on_failure: change
branches:
  except:
  - /^v\d+\.\d+\.\d+$/

I tried specifying latest Node and targeting different Node versions, no luck.

I thought maybe I need to provide GH_TOKEN explicitly for this package. I generated the token, ran the Travis CLI travis encrypt GH_TOKEN=<token> --add, it added bunch of encrypted characters onto my .travis.yml, but that didn't work either. Looks like it didn't recognise Node project and ran rake. Apparently, language: node_js row is obligatory...

I tried other variations of .travis.yml and none worked, often causing whole Travis build to fail.

---

The documentation of this package is either incomplete or dare I say, also erroneous. Besides Travis snippets in this documentation that don't work out-of-the-box, I want to make some observations:

"First create a GitHub access token with push access to your repository and make it available to your CI's environment as GH_TOKEN."

1. does this apply to open source libraries ran from travis-ci.org?
2. do I have to generate a token for each library separately and add onto each libraries' .travis.yml?

"Have a look at our Travis CI reference implementation."

Your implementation is not standard since it is not using your supplied snippets. Technically speaking, you're cheating - your .travis.yml links to JS files with a fancy custom setup. What we need is a link to a normal open source library which uses travis-ci.org and which used your setup instructions verbatim and where Greenkeeper updated its lockfiles.

Dear maintainers, I challenge you to find at least one open source library uses your supplied Travis snippets and link to it.

---

Personally, I find this tool impossible to set up. It took me all Saturday morning and within 8 attempts/tweaks/releases I could not get string-remove-duplicate-heads-tails Greenkeeper to update lockfiles. Greenkeeper itself, on other hand, activated automatically.

Dear maintainers, do you see my frustration here?

On the positive side, thank you for all this anyway; some tooling is better than no tooling and hopefully we can automate lockfile updates eventually. That would save lots of time maintaining OS libraries. 👍

greenkeeper-lockfile deletes a bunch of dependencies

Here are some example PR's where this happened:

• StoDevX/AAO-React-Native#1833 (Travis build)
• StoDevX/AAO-React-Native#1829 (Traivs build)

So yeah, it seems as though greenkeeper-lockfile now deletes optional dependencies, or development dependencies, or something like that. Note that simply running npm i works perfectly fine for us to correct this, and I feel like that's what this thing should do.

CircleCI always gives "Error: Could not detect a CI Service."

Circle sets the CIRCLECI=true env var by default. Even with manually setting this, I still always get an Error: Could not detect a CI Service..

I'm stuck on not being able to use this at this point.

Questions regarding support for Heroku.

Hey Greenkeeper,

I use Heroku CI for my project, and I'd like to create a PR that adds support for it. However, there's a few things that Heroku does not give me in their CI environment, one of which the GitHub repo URL. However, I can set environment variables in the CI environment.

Would you be against me pulling the GitHub URL from the environment, expecting that users of greenkeeper-lockfile will have set that value themselves? This will of course lead to errors if the user doesn't set the variable.

Next, there's a the concept of firstPush. I understand this to mean that the lockfile should be checked and updated if a PR is opened, but not if a PR is updated.

Unfortunately, Heroku's CI environment completely removes the .git directory after cloning, and as far as I can tell, there's no way for me to actually run git commands locally on the CI server (which would prevent me from using the getNumberOfCommitsOnBranch helper). I don't want to force update checks on every single commit, but I'm not sure what a good solution would be.

Lastly, I don't fully understand what correctBuild means. I would expect that I'd want to run the lockfile check on every PR, so that things are fully updated before I merge into master. Can this key be clarified?

CI Reruns after pushing lockfile commit

After a greenkeeper successful upgrades a dependancy and the lockfile commit is pushed, travis creates new jobs because of the new commit. Is there a way around this as it's effectively testing the same build or is this just a limitation of regenerating the lockfile independently?

Travis + Yarn not updating lockfile

Just got first PR after initial config with greenkeeper-lockfile. This is the output from travis:

$ greenkeeper-lockfile-update
error Received malformed response from registry for undefined. The registry may be down.
child_process.js:526
    throw err;
    ^
Error: Command failed: yarn add -D --save-prefix="" [email protected]
error Received malformed response from registry for undefined. The registry may be down.
    at checkExecSyncError (child_process.js:483:13)
    at execSync (child_process.js:523:13)
    at updateLockfile (/home/travis/.config/yarn/global/node_modules/greenkeeper-lockfile/lib/update-lockfile.js:26:7)
    at Module.update [as exports] (/home/travis/.config/yarn/global/node_modules/greenkeeper-lockfile/update.js:49:3)
    at Object.<anonymous> (/home/travis/.config/yarn/global/node_modules/greenkeeper-lockfile/update.js:56:37)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
The command "greenkeeper-lockfile-update" failed and exited with 1 during .

$ node --version
v6.9.2
$ npm --version
3.10.9
$ nvm --version
0.33.2

--save-prefix does not appear to be a valid option for yarn.

Release 1.7 with Wercker support

First thanks for lockfile support for Greenkeeper. However, I was wondering why Werker support has been merged to master but not released as 1.7 yet. Anything the release bot did not detect in the commit message namings?