> On 28 Dec 2017, at 00:00, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
>
> On Wed, Dec 27, 2017 at 8:15 PM, Lars Schneider
> <larsxschneider@xxxxxxxxx> wrote:
>>
>>> On 27 Dec 2017, at 17:49, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
>>> +# Skip the build job if the same tree has already been built and tested
>>> +# successfully before (e.g. because the branch got rebased, changing only
>>> +# the commit messages).
>>> +skip_good_tree () {
>>> + if ! good_tree_info="$(grep "^$(git rev-parse $TRAVIS_COMMIT^{tree}) " "$good_trees_file")"
>>> + then
>>> + # haven't seen this tree yet; continue the build job
>>> + return
>>> + fi
>>> +
>>> + echo "$good_tree_info" | {
>>> + read tree prev_good_commit prev_good_job_number prev_good_job_id
>>> +
>>> + if test "$TRAVIS_JOB_ID" = "$prev_good_job_id"
>>
>> Under what circumstances would that be true?
>
> When the user hits 'Restart job' on the Travis CI web interface,
> $TRAVI_JOB_NUMBER and _ID remain the same in the restarted build job as
> they were in the original.
> So the condition is true when the user hits 'Restart job' on a build job
> that was the first to successfully build and test the current tree.
I think I would prefer it if Travis would rerun all jobs if I hit the
"refresh" button. What is your intention here?
>
>>> + then
>>> + cat <<-EOF
>>> + Skipping build job for commit $TRAVIS_COMMIT.
>>> + This commit has already been built and tested successfully by this build job.
>>> + To force a re-build delete the branch's cache and then hit 'Restart job'.
>>> + EOF
>>> + else
>>> + cat <<-EOF
>>> + Skipping build job for commit $TRAVIS_COMMIT.
>>> + This commit's tree has already been built and tested successfully in build job $prev_good_job_number for commit $prev_good_commit.
>>> + The log of that build job is available at https://travis-ci.org/$TRAVIS_REPO_SLUG/jobs/$prev_good_job_id
>>> + To force a re-build delete the branch's cache and then hit 'Restart job'.
>>> + EOF
>>
>> Maybe add a few newlines before and after EOF to make the text more stand out?
>> Or print it in a different color? Maybe red?
>>
>> See: https://travis-ci.org/szeder/git/jobs/322247836#L622-L625
>
> I considered using color for the first line, but then didn't do it,
> because I didn't want to decide the color :)
> Anyway, red is the general error/failure color, but this is neither. It
> could either be green, to match the color of the build job's result, or
> something neutral like blue or yellow.
You are right about red. I think I like yellow to express "warning".
But this is just a nit.
"skip_branch_tip_with_tag" could print its output yellow, too.
- Lars
