search

greenkeeperio / greenkeeper-lockfile

:lock: Your lockfile, up to date, all the time
https://greenkeeper.io
182 stars 72 forks source link

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

Closed itsjamie closed 1 year ago

itsjamie commented 7 years ago

[@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!
ntwb commented 7 years ago

It would also fix the issue I just had with https://github.com/stylelint/stylelint/pull/2845 where I had to change the Travis CI config to pin npm 5.3.0 due to a 5.4.0 bug, Greenkeeper won't try updating the lockfile again as it only attempts this with the initial push:

Via https://travis-ci.org/stylelint/stylelint/jobs/271580111#L1967

$ greenkeeper-lockfile-update Only running on first push of a new branch

janl commented 7 years ago

Confirming this is an issue we want to address. We’d have to square it with the “do not run on the second commit/push to a branch” restriction, but we could make an exception to that if it is the initial branch, but we haven’t worked through all the consequences yet. Stay tuned :)

mightyiam commented 7 years ago

I didn't even notice this. Perhaps because I've used only on small projects that have short CI runs.

travi commented 6 years ago

my team is starting to see more of the impact of this as our queue depth is more regularly not empty on travis pro. it is especially noticeable since travis doesn't have a way to prioritize builds in the queue. for PRs that are more time sensitive, we wait for the PR builds to make their way through the queue, but then the lockfile updates trigger two more builds that are added to the end of the queue, so they wait in the queue all over again.

since there is really no code change being tested in the second round, it would be great if the second one could be skipped, but that's already been discussed and wouldnt be simple.

any chance this has enough priority that it will be looked into further sometime soon?