Normally making a commit that does not change the revision or version will not 
trigger a rebuild, assuming the previous port revision built OK on a given 
platform. If this is the case then again the builds do not need to be 
cancelled. If the previous builds in fact did not build, then yes another 
rebuild will be attempted, so if nothing has changed to fix the previous build 
failure it will fail again. If this is the case then its best not avoid making 
such commits until you are able to do so at the same times as fixing the build 
failures. If this cannot be done the the port should use the known_fail pattern 
for the OSes known to fail, to avoid needless failing rebuilds.

Chris

> On 6 Dec 2021, at 7:35 pm, Jason Liu <[email protected]> wrote:
> 
> 
> Neither the revision nor the version numbers were changed in the Portfile (in 
> fact, no changes were made to the Portfile at all), only the new file got 
> added to the files/ folder. But builds got queued up on the buildbot anyway 
> after the PR got merged.
> 
> Adding the file to the port (PR #12976) was only in preparation for the PR 
> that actually includes bugfixes (PR #13266), which obviously will change what 
> is installed, and do indeed need builds to be rerun. I'm trying to get the 
> queued builds for PR #12976 removed from the builders.
> 
> -- 
> Jason Liu
> 
> 
>> On Mon, Dec 6, 2021 at 2:02 PM Chris Jones <[email protected]> wrote:
>> Hi,
>> 
>> If the revision and version numbers have changed, because what is installed 
>> on disc has changed, then the builds need to be rerun, otherwise you are 
>> forcing the long builds on users, which is worse than tying up the buildbots 
>> for a while.
>> 
>> Cheers Chris
>> 
>>>> On 6 Dec 2021, at 6:10 pm, Jason Liu <[email protected]> wrote:
>>>> 
>>> 
>>> Hi all,
>>> 
>>> Would it be possible to remove the queued builds for my PR that was 
>>> recently merged on the 10.13 and 12_x86_64 watchers? That PR only added an 
>>> auxiliary file, and really shouldn't be re-built. Since there's such a long 
>>> queue on the 10.13 and 12 builders, I'm thinking that cancelling a fairly 
>>> length build that isn't needed would help clear up the backlog a bit 
>>> faster. If there's an easy way to cancel the build on all of the builders 
>>> (not just 10.13 and 12), that would probably be even better. On the other 
>>> hand, if cancelling the build would be a hassle, then don't worry about it.
>>> 
>>> The commit is identified by the hash
>>> 
>>> 14e7b489f630...
>>> (Jason Liu <[email protected]>)
>>> 
>>> -- 
>>> Jason Liu

Reply via email to