- In ci.sh just print the path to the debug log file on errors.
- In GHA workflow, dump the debug log in a separate final step if there
were errors. This will make it more usable for tracking down errors.
This should be the default if things are working correctly so logging
this now is just noise that causes the summaries that are relevant to
get folded in the UI.
A major maintainability issue for years has been that the CI assumes
that a docker image for the implementation exists in Docker's registry
(named kanaka/mal-test-IMPL). This means the upstream maintainers have
to be involved in the PR loop to build the implementation Dockerfile,
push to the docker registry and then have the PR submitter re-run CI.
To address this, in ci.sh, the docker-build-push action will try to pull
the image and then continue as normal. If the pull fails then it will
build the image and push it (if the build is running in the context of
the upstream repo's main branch) and then continue.
Also, this switches to using ghcr.io as the default repo for images
which will make image transfer more local (during CI) and hopefully
a fair bit faster (and avoid potential docker pull limits).
Add a steps to the GHA main workflow that do a docker login to ghcr.io
and then call `ci.sh docker-build-push ${IMPL}`.
- Dynamically generate a strategy matrix based on the list of changed
files in this push/pull_request. If the changed files are restricted
to implementations then only generate a matrix with those
implementations. If the changes are to tests or other
non-documentation files (runtest.py, IMPLS.yml, .github/*, etc) then
run the full set. The matrix generation is done in get-ci-matrix.py.
- Split the implementation list for Github Actions out into a separate
yaml file IMPLS.yml
- Reduce the travis file to just the OS X / XCode related builds that
aren't supported on Github Actions.
- Rename the .travis_test.sh script to ci.sh since it is the general
CI script used for both Travis CI and Github Actions.
