Tools used by Dart's continuous integration (CI) testing that aren't needed by Dart SDK contributors. Mirrored from dart.googlesource.com/dart_ci. Do not land pull requests on Github.
BSD 3-Clause "New" or "Revised" License
18
stars
5
forks
source link
Don't create patchset record for final rebase patchset created when landing CL #85
This bug causes no actual failures in the system right now, but should be addressed.
The code that creates the record for a review and records for the patchsets in a review runs when a tryjob runs on a patchset that hasn't been seen yet. At that time, it creates records for all the new patchsets that exist at that time.
We plan to stop using the patchset groups for so much, so that we will use approvals from all patchsets, not just those in the latest patchset group, when copying approvals to landed CLs. Then this wouldn't be such a problem. In the try results web UI, we always specify which patchset we are looking at, so the final patchset group is never used.
We have just been lucky that no tryjobs complete after the CL is landed, and so the final spurious patchset group is not created. We would need to find a way to distinguish the final rebase.
It seems that only the final patchset has the "commit" property, which gives the commit that it landed as:
"commit": {
"parents": [
{
"commit": "0ce39a7c1083a651dfa84f9b7d501835129de9d8",
"subject": "[vm] Do not allocate when evaluating arguments to StorePointer."
}
],
Also, its uploader is "uploader": {
"_account_id": 5260,
"name": "commit-bot@chromium.org",
This bug causes no actual failures in the system right now, but should be addressed.
The code that creates the record for a review and records for the patchsets in a review runs when a tryjob runs on a patchset that hasn't been seen yet. At that time, it creates records for all the new patchsets that exist at that time.
We plan to stop using the patchset groups for so much, so that we will use approvals from all patchsets, not just those in the latest patchset group, when copying approvals to landed CLs. Then this wouldn't be such a problem. In the try results web UI, we always specify which patchset we are looking at, so the final patchset group is never used.
We have just been lucky that no tryjobs complete after the CL is landed, and so the final spurious patchset group is not created. We would need to find a way to distinguish the final rebase. It seems that only the final patchset has the "commit" property, which gives the commit that it landed as: "commit": { "parents": [ { "commit": "0ce39a7c1083a651dfa84f9b7d501835129de9d8", "subject": "[vm] Do not allocate when evaluating arguments to StorePointer." } ],
Also, its uploader is "uploader": { "_account_id": 5260, "name": "commit-bot@chromium.org",