build: get previous payload by querying git #5122
Conversation
googlebot
added
the
cla: yes
devversion
force-pushed
the
build/payload-previous-sha
branch
2 times, most recently
from
c25888f to
26bfc91
Compare
tools/gulp/tasks/payload.ts
Outdated
| function getCommitFromPreviousPayloadUpload(): string { | ||
| if (isTravisMasterBuild()) { | ||
| const commitRange = process.env['TRAVIS_COMMIT_RANGE']; | ||
| const commitCount = spawnSync('git', ['rev-list', '--count', commitRange]).stdout |
There was a problem hiding this comment.
Can you add comments that write out the commit commands and describe what you're getting from them?
There was a problem hiding this comment.
Added comments. It was pretty hard to explain what those Git calls do. Please me know if you think something needs to be better explained.
devversion
force-pushed
the
build/payload-previous-sha
branch
from
72925dc to
8a06781
Compare
jelbourn
added
pr: lgtm
action: merge
tools/gulp/tasks/payload.ts
Outdated
| function getCommitFromPreviousPayloadUpload(): string { | ||
| if (isTravisMasterBuild()) { | ||
| const commitRange = process.env['TRAVIS_COMMIT_RANGE']; | ||
| // In some situations Travis will include multiple commits in a single Travis Job. This means |
There was a problem hiding this comment.
In some situations Travis -> In some situations, Travis
tools/gulp/tasks/payload.ts
Outdated
| const commitRange = process.env['TRAVIS_COMMIT_RANGE']; | ||
| // In some situations Travis will include multiple commits in a single Travis Job. This means | ||
| // that we can't just resolve the previous commit by using the parent commit of HEAD. | ||
| // By resolving the amount of commits inside of the current Travis Job we can figure out |
There was a problem hiding this comment.
By resolving the amount of commits inside of the current Travis Job we can -> By resolving the amount of commits inside of the current Travis job, we can
tools/gulp/tasks/payload.ts
Outdated
| // how many commits before HEAD the last Travis Job ran. | ||
| const commitCount = spawnSync('git', ['rev-list', '--count', commitRange]).stdout | ||
| .toString().trim(); | ||
| // With the amount of commits inside of the current Travis Job we can query Git to print |
There was a problem hiding this comment.
With the amount of commits inside of the current Travis job we can -> With the amount of commits inside of the current Travis job, we can
tools/gulp/tasks/payload.ts
Outdated
| return spawnSync('git', ['rev-parse', `HEAD~${commitCount}`]).stdout.toString().trim(); | ||
| } else { | ||
| // Travis applies the changes of Pull Requests in new branches. This means that resolving | ||
| // the commit, that previously ran on the target branch (mostly "master"), can be done |
There was a problem hiding this comment.
This means that resolving the commit, that previously -> This means that resolving the commit that previously
Currently the previous payload is just the latest uploaded payload result on Firebase. This is problematic because it can happen that the current payload is uploaded "too fast" and the payload task is comparing against itself. Just calculating before uploading could work most of the time, but there it would still fail if another Travis Job uploades payload results at the same time. The safest solution would be resolving the parent commit of the current Travis job. This way the payload diff would be always correct (even if multiple Jobs are running).
devversion
force-pushed
the
build/payload-previous-sha
branch
from
8a06781 to
cc56402
Compare
|
@kara Fixed all grammar comments. Thanks for those! |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently the previous payload is just the latest uploaded payload result on Firebase. This is problematic because it can happen that the current payload is uploaded "too fast" and the payload task is comparing against itself.
Just calculating before uploading could work most of the time, but there it would still fail if another Travis Job uploades payload results at the same time.
The safest solution would be resolving the parent commit of the current Travis job. This way the payload diff would be always correct (even if multiple Jobs are running).