-
Notifications
You must be signed in to change notification settings - Fork 70
Workflows
The workflows in the actions are here to test that the functionality we need keeps working when changes happens.
The main developments at the moment, and the VMs we are using, are on Fedora. This is also desirable because commercial and open source alternatives that are enterprise solutions are based in this distribution.
We want to test that:
- A component that was working keeps working
- The existing circuits works
- The villas interface works
- The python bindings works
Our real-time experiments run on Rocky Linux. Sometimes the version existing can be a bit old. This is intentional, we can add the newest version but we also want to ensure that older versions in our servers can still compile.
We want to be sure that the compilation of the python package to be deployed in PyPI is possible.
If there is a tag Major.Minor.Patch-rcX where X is a number of the release candidate, the TestPyPI will receive an artifact upload.
If the tag is Major.Minor.Patch, both TestPyPI and PyPI workflows are activated. Do this only for the Releases. Use the tag to release the new version.
There is a compilation that test basic functionality that is supported in windows.
We publish the containers manually. The container workflow is very slow with the free tier. Select the branch where the container file is. This is also needed when there is a new change that needs to be tested against. In that case, this cannot be done from forks.