Avoid re-executing PR tests if there aren't new commits

[lodo1995]

Currently a change in the PR title causes the auto-tester to re-execute all tests, even if no code change happened. I don't know anything about the GitHub API, but maybe this can be avoided, for better use of the available processor time?

[lodo1995]

Ping @braddr, it is my impression that the autotester triggers quite often even in the absence of new commits to the PR.

[wilzbach]

Yes all builds will be deleted if a PR in dmd, druntime or phobos has been merged to guarantee that there is no bug in the overlap.

[lodo1995]

@wilzbach I know that. I'm currently working on dlang/phobos#4741. It was 9/10 completed after a bugfix commit and suddenly it restarted everything. Very frustrating. No commit happened on any dlang repository and I didn't update my branch. So I thought it must have been my edit to the PR description.
But maybe I'm just missing something. I don't really know how the auto-tester works.

[wilzbach]

Don't worry about it, it doesn't matter for the reviewers that your PR is passing - as said before even if it would once there is a new commit your PR has zero passes.

Once a PR is approved (automerge on), it has superior priority and the auto-tester will automatically merge it once all tests pass.

It might be that the auto-tester is too sensitive, but it shouldn't be a big issue as you don't and even can't show that all tests pass.

[lodo1995]

Actually the only thing I'm worried about is overloading the autotester. I care about the test results not because they influence reviews, but because I want to be sure that my code is correct (on my own repo, I'm a compulsive clicker of the reload button until the CI finishes executing).

But you are right that this is not a big issue, it's only a minor problem.

[wilzbach]

Actually the only thing I'm worried about is overloading the autotester.

I agree that it should be fixed, but the machines run 24/7 anyways so there is no additional cost. Important PRs will have a higher priority.

I care about the test results not because they influence reviews, but because I want to be sure that my code is correct

I have a similar attitude, but there is not much you can do.
If you ran your code in 32 and 64-bit mode locally it's very uncommon that it fails on a different system (except you do a lot of FP math or system specific like IO), however I am not sure whether this helps your urge to check the real results.

[braddr]

It looks like there's situations where the head_date on a request can and does change independent of the sha itself changing. I'll need to dig into the current state of the github messages and see if changes are warranted. It's certainly safer to always build when the dates change, but it can be wasteful. Looking through the rest of the logs, MOST of the time, both head_date and head_sha change in unison, but there's enough where just the date changes that not triggering rebuilds for those would help.

the log snippit from one update for the referenced pull:
09403 - 2016-08-22T17:18:56 - processing request: /github_hook
09403 - 2016-08-22T17:18:56 - updating dlang/phobos/4741:
09403 - 2016-08-22T17:18:56 - updated_at: 2016-08-22T16:28:11Z -> 2016-08-22T17:18:55Z
09403 - 2016-08-22T17:18:56 - head_date: 2016-08-22T16:10:29Z -> 2016-08-22T17:18:55Z
09403 - 2016-08-22T17:18:56 - deprecating old test results