This PR introduces changes to add a scheduled CI workflow to run tests on all builds for SDK images. The schedule runs on a daily basis and uploads results to the SDK testing dashboard https://sdk.testing.exaworks.org/summary.html. Because the results are uploaded to the dashboard, failing tests do not trigger a failing pipeline and should not be interpreted as such. These tests test the images deployed on Docker Hub rather than building fresh containers from source.
Because we are using the containers from docker hub, it was identified that the docker hub containers are not built with the integration docker file, so the integration was added to the deployment pipeline. Because we now use the integration dockerfile as the last stage of the build, the default command of the SDK image is now bash.
Because the scheduled CI tests populate data to the dashboard, it seems reasonable to not upload results from Merge Request pipeline, ci.yml. This makes sense since that pipeline may be run during development and could populate the dashboard with failings for development purposes.
This PR introduces changes to add a scheduled CI workflow to run tests on all builds for SDK images. The schedule runs on a daily basis and uploads results to the SDK testing dashboard https://sdk.testing.exaworks.org/summary.html. Because the results are uploaded to the dashboard, failing tests do not trigger a failing pipeline and should not be interpreted as such. These tests test the images deployed on Docker Hub rather than building fresh containers from source.
Because we are using the containers from docker hub, it was identified that the docker hub containers are not built with the integration docker file, so the integration was added to the deployment pipeline. Because we now use the integration dockerfile as the last stage of the build, the default command of the SDK image is now
bash.Because the scheduled CI tests populate data to the dashboard, it seems reasonable to not upload results from Merge Request pipeline, ci.yml. This makes sense since that pipeline may be run during development and could populate the dashboard with failings for development purposes.
Addresses issues #120 #121 #66