[2/2] ci: avoid ugly "failure" in the `ci-config` job

Commit Message

Jean-Noël Avila via GitGitGadget Sept. 1, 2020, 8:19 p.m. UTC

From: Johannes Schindelin <[e-mail]>

In the common case where users have _not_ pushed a `ci-config` branch to
configure which branches should be included in the GitHub workflow runs,
there is a big fat ugly annotation about a failure in the run's log:

	X Check failure on line 1 in .github

	  @github-actions github-actions / ci-config

	  .github#L1

	  Process completed with exit code 128.

The reason is that the `ci-config` job tries to clone that `ci-config`
branch, and even if it is configured to continue on error, the
annotation is displayed, and it is distracting.

Let's just handle this on the shell script level, so that the job's step
is not marked as a failure.

Signed-off-by: Johannes Schindelin <[e-mail]>
---
 .github/workflows/main.yml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

Jeff King Sept. 2, 2020, 12:40 a.m. UTC | #1

On Tue, Sep 01, 2020 at 08:19:27PM +0000, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <[e-mail]>
> 
> In the common case where users have _not_ pushed a `ci-config` branch to
> configure which branches should be included in the GitHub workflow runs,
> there is a big fat ugly annotation about a failure in the run's log:
> 
> 	X Check failure on line 1 in .github
> 
> 	  @github-actions github-actions / ci-config
> 
> 	  .github#L1
> 
> 	  Process completed with exit code 128.
> 
> The reason is that the `ci-config` job tries to clone that `ci-config`
> branch, and even if it is configured to continue on error, the
> annotation is displayed, and it is distracting.

Hmm. I thought we handled this with the "continue-on-error" flag.
Unsurprisingly I have a ci-config branch in my repo, but git/git
doesn't, and here's a sample run there:

  https://github.com/git/git/runs/1053619435?check_suite_focus=true

Both the "ci-config" task, as well as the individual "try to clone
ci-config branch" step are marked with a green check.

...Oh, I think I see what you mean. In the "Annotations" summary we
still see an ugly "X" box.

> Let's just handle this on the shell script level, so that the job's step
> is not marked as a failure.

OK, that makes sense. We could do differentiate clone failing versus cd
versus checkout (or for that matter, clone failing because the branch
doesn't exist versus a network error). But it's probably not worth
getting too fancy.

My next question was going to be: should we also drop the
continue-on-error flag? But I see you did that already.

So the patch looks good to me. Sorry for introducing CI noise in the
first place. :)

-Peff

Patch

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 6fd1d1a2c8..fcfd138ff1 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -12,7 +12,6 @@  jobs:
       enabled: ${{ steps.check-ref.outputs.enabled }}
     steps:
       - name: try to clone ci-config branch
-        continue-on-error: true
         run: |
           git -c protocol.version=2 clone \
             --no-tags \
@@ -24,7 +23,7 @@  jobs:
             https://github.com/${{ github.repository }} \
             config-repo &&
           cd config-repo &&
-          git checkout HEAD -- ci/config
+          git checkout HEAD -- ci/config || : ignore
       - id: check-ref
         name: check whether CI is enabled for ref
         run: |