The auto-milestoning feature will tag PRs with the wrong milestone when they are part of a rollup that is created/merged around the time that the version gets bumped.
The problem is here. It uses the SHA of the merge commit of the PR. This works for normal PRs since the merge commit is the one generated when the PR goes through bors. However, for rollups, this SHA is the merge commit of the rollup itself. This SHA is generated when the rollup is created, not when it gets merged.
Thus if there is a sequence:
Rollup created
Version bump gets merged
Rollup is merged
The code will use the milestone version from the point in time of step 1, when it should be step 3.
One possible solution is for triagebot to notice that the PR was merged as part of a rollup, and use the parent of that merge commit instead. I'm not sure if there is a simple way to get that answer. Typically I would use something like git merge-base, but I don't know what options we have with the GitHub API.
The auto-milestoning feature will tag PRs with the wrong milestone when they are part of a rollup that is created/merged around the time that the version gets bumped.
The problem is here. It uses the SHA of the merge commit of the PR. This works for normal PRs since the merge commit is the one generated when the PR goes through bors. However, for rollups, this SHA is the merge commit of the rollup itself. This SHA is generated when the rollup is created, not when it gets merged.
Thus if there is a sequence:
The code will use the milestone version from the point in time of step 1, when it should be step 3.
One possible solution is for triagebot to notice that the PR was merged as part of a rollup, and use the parent of that merge commit instead. I'm not sure if there is a simple way to get that answer. Typically I would use something like
git merge-base, but I don't know what options we have with the GitHub API.