CI: This and that #33
Conversation
- Many projects just use a `main.yml` workflow file, if they do not need to discriminate between different workflows for different purposes. - The title can be anything, but in this case let us propose a shorter and more concise one: "CI status".
Each push operation to a feature branch would regularly trigger a CI workflow run. When quickly pushing in succession, the previous runs become redundant and obsolete instantly, so let's cancel them.
| types: [published] | ||
| workflow_dispatch: | ||
| schedule: | ||
| - cron: '0 4 * * *' |
There was a problem hiding this comment.
Does it make sense that we run this every day when we already run on PRs and merges?
There was a problem hiding this comment.
I think so. It is about to feed the downstream Build Status page and GitHub Actions reports, that notify us about negative side effects, infrastructure or not, which happen on spots of the time axis other than on-PR, or on-merge.
In this case, it is about validating that the little infrastructure that invokes the test suite, including installing its requirements, does not break. In this case, because the packages listed in requirements.txt do not use version pinning yet, which is fine, it gives us confidency that it will always work, or otherwise that we know before. For example, there would be a signal if the location of tdvt @ git+https://github.com/tableau/connector-plugin-sdk/#subdirectory=tdvt changes, because upstream relocates it.
Maybe it's utter nonsense, still after my explanation attempt, then please let me know about it, and I will remove that cron configuration again.
There was a problem hiding this comment.
Oh I understand now, didn't think of that, it makes sense, thanks for the explanation!!
About
Submitting a few little improvements to the CI/GHA configuration, nothing wild.
Details
References