Should the pathogen-repo-ci be louder if no workflows are run?

[joverlee521]

TODO

• move nextstrain-pathogen.yaml file checks out into a single step prior to workflow run steps
• add aggregate success step, modeled on pathogen-repo-build wait-conclusion logic to trigger failure when no build steps are run

Original issue content

Follow up to #89

Just noticed in our docker-base CI workflow that all the pathogen-repo-ci jobs have "succeeded" even though none of them ran any workflows.

This outcome is pretty misleading and can potentially lead to us missing when changes actually break pathogen workflows if we don't notice that the workflows never actually ran within CI.

[joverlee521]

I think fine to leave each ingest/phylogenetic/nextclade workflow as optional, but maybe we should have a final conclusion job that checks at least one of the workflows ran?

[genehack]

I think fine to leave each ingest/phylogenetic/nextclade workflow as optional, but maybe we should have a final conclusion job that checks at least one of the workflows ran?

In this particular case, every repo where the pathogen-repo-ci workflow is being used lacks the nextstrain-pathogen.yaml file in the repo root.

Maybe instead of testing for the presence of that file in the individual build steps, and skipping if it's absent, there should be a preliminary job that checks once, and generates a failure (e.g., exit 1 or the like) if the file is missing.

[joverlee521]

In this particular case, every repo where the pathogen-repo-ci workflow is being used lacks the nextstrain-pathogen.yaml file in the repo root.

Maybe instead of testing for the presence of that file in the individual build steps, and skipping if it's absent, there should be a preliminary job that checks once, and generates a failure (e.g., exit 1 or the like) if the file is missing.

Yup, definitely support erroring early on this! In addition, I still think it'd be helpful to fail when none of the expected workflows ran.

[genehack]

Yup, definitely support erroring early on this! In addition, I still think it'd be helpful to fail when none of the expected workflows ran.

You wouldn't happen to be able to point me to an example of that sort of aggregated failure check in a GitHub Action, would you?

[joverlee521]

You wouldn't happen to be able to point me to an example of that sort of aggregated failure check in a GitHub Action, would you?

I think the wait-conclusion job in the pathogen-repo-build workflow is a good example:

.github/.github/workflows/pathogen-repo-build.yaml

Lines 596 to 613 in 7f910e6

	# Since the wait-N jobs use "continue-on-error: true" out of necessity (to
	# avoid failing the whole workflow when they time out and get cancelled), we
	# use a final job here to succeed or fail the whole workflow based on the
	# aggregate of their "attach" step conclusions.
	wait-conclusion:
	needs: [wait-1, wait-2, wait-3, wait-4]
	if: always()
	runs-on: ubuntu-latest
	steps:
	- name: All attach steps in wait-N jobs were successful (or skipped)
	run: |
	# shellcheck disable=SC2242
	exit ${{ contains(needs.*.outputs.attach-step-conclusion, 'failure') && '1' || '0' }}
	# XXX TODO: Jobs can fall off the end of our wait-N chain and appear to be
	# successful/complete in GitHub but still running on AWS. Probably very
	# rare in reality, though, for an AWS job to take longer than 24h?
	# -trs, 12 Sept 2023

[genehack]

You wouldn't happen to be able to point me to an example of that sort of aggregated failure check in a GitHub Action, would you?

I think the wait-conclusion job in the pathogen-repo-build workflow is a good example:

Ah, yeah, cool, I can do the couple changes here.

[joverlee521]

Resolved by a combination of #95, #96, #98, and #99.