greenkeeperio / greenkeeper-lockfile Goto Github PK
View Code? Open in Web Editor NEW:lock: Your lockfile, up to date, all the time
Home Page: https://greenkeeper.io
:lock: Your lockfile, up to date, all the time
Home Page: https://greenkeeper.io
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
I use more traditional commit messages so the chore(package):
is annoying and creates ugly inconsistencies in my commit history.
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.
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.
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.
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'
> [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'
> [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)
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
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.
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
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
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?
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 .
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?
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!
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
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 π
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.
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
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
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).
$ 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....
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):
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.
$ 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
.
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?
[@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.
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!
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
?
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.
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.
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
.
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:
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).
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
which is determined by
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!
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?
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
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.
For us it tries to run yarn add -S [email protected]
lint-staged is a dependency in the project
I think it happens here:
But since yarn doesn't accept -S and does that by default it fails
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!
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
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
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!
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.
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:
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?
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.
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
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."
.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. π
Here are some example PR's where this happened:
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.
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.
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?
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?
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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.