ci: avoid ugly "failure" annotation in the GitHub workflow

Whenever the GitHub workflow runs in a fork that does not contain the special-purpose ci-config branch, a big fat failure annotation greets the casual reader. See e.g.
https://github.com/gitgitgadget/git/actions/runs/233438295

This is caused by the (non-fatal) failure to clone said branch. Let's avoid that. It's distracting.

Johannes Schindelin (2):
ci: fix indentation of the ci-config job
ci: avoid ugly "failure" in the ci-config job

 .github/workflows/main.yml | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

base-commit: e19713638985533ce461db072b49112da5bd2042
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-719%2Fdscho%2Favoid-error-in-ci-config-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-719/dscho/avoid-error-in-ci-config-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/719

gitgitgadget

From: Johannes Schindelin <[email protected]>

The section added in e76eec35540f (ci: allow per-branch config for GitHub Actions, 2020-05-07) contains a &&-chain that connects several commands. The first command is actually so long that it stretches over multiple lines, and as per usual, the continuation lines are indented one more level than the first.

However, the subsequent commands in the &&-chain were also indented one more level than the first command, which was almost certainly unintended.

---
 .github/workflows/main.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 30425404eb..6fd1d1a2c8 100644
@@ -23,8 +23,8 @@ jobs:
             --filter=blob:none \
             https://github.com/${{ github.repository }} \
             config-repo &&
-            cd config-repo &&
-            git checkout HEAD -- ci/config
+          cd config-repo &&
+          git checkout HEAD -- ci/config
       - id: check-ref
         name: check whether CI is enabled for ref
         run: |

gitgitgadget

Yeah, I'm pretty sure this was unintentional in my original (and got carried through the recent re-indentation).

-Peff

From: Johannes Schindelin <[email protected]>

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.

---
 .github/workflows/main.yml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

index 6fd1d1a2c8..fcfd138ff1 100644
@@ -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: |

gitgitgadget

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.

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

"Johannes Schindelin via GitGitGadget" <[email protected]>

Thanks. Anything that reduces the CI noise is very much welcomed.