Deal with all those fails of test_docker_build

[yarikoptic]

I keep getting notifications regularly about CI fails like

❯ git shortlog -sn `git grep -l test_docker_build -- .github/workflows/ `
    54  Remi Gau
    14  Satrajit Ghosh
     5  dependabot[bot]
     2  Steffen Bollmann
     1  pre-commit-ci[bot]

hence attn @Remi-Gau @satra - should those particular ones be fixed or skipped? should overall workflow(s) be deprecated?

[satra]

there were several notions of those builds. they go into a dashboard indicating which ones don't work or do work. so calling them tests is probably a bit of a misnomer. they are testing whether that configuration can be built.

[Remi-Gau]

test_docker_build is actually the name of the branch where those builds are tested: https://github.com/ReproNim/neurodocker/actions?query=branch%3Atest_docker_build

[Remi-Gau]

note our "dashboard" was supposed to show which versions of the tools provided by neurodocker would actually fail when being built: https://github.com/ReproNim/neurodocker/blob/test_docker_build/docs/README.md

But the service we used to create images of the github CI matrices failures does not work anymore: see warning in this repo
https://github.com/40ants/github-actions

[Remi-Gau]

they are testing whether that configuration can be built

I would still call those tests as in end to end or system or integration tests

but without dashboard to easily know which ones are failing succeeding... not as useful...

[yarikoptic]

thanks for the explanation! Please provide guidance how to avoid floods from CI on those without completely unsubscribing from the repo?

[yarikoptic]

actually I am already at

so likely considered a "participant" for some reason (damn codespell contributions? ;) )

[Remi-Gau]

I do not get those notifications which makes me wonder if this has not something to do with the cronjob of the scheduled workflow to run those tests : https://docs.github.com/en/actions/concepts/workflows-and-actions/notifications-for-workflow-runs

Notifications for scheduled workflows are sent to the user who initially created the workflow.

• If a different user updates the cron syntax, in the schedule event in the workflow file, >subsequent notifications will be sent to that user instead.
• If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the >user who re-enabled the workflow rather than the user who last modified the cron syntax.

neurodocker/.github/workflows/bootstrap.yml

Line 23 in d06d9de

- cron: 0 0 * * 0

will update the schedule: we don't need to run this weekly, monthly or every 2 months is way enough