-
Notifications
You must be signed in to change notification settings - Fork 5
A CI is used to make sure that the SEE project can be built and certain quality criteria are met (dynamic tests and static checks) whenever a pull request is to be merged into the master branch or even if anything is checked in or pushed.
Tip
The run_all file, which runs all shell scripts in /GitScripts/, is also run as a pre-commit hook automatically if you executed the ./generateHook.sh scripts.
Note
The CI currently only runs on the sts5 machine, with four runners in parallel.
If we want to run it on another machine, the scripts would need to be changed, as it currently assumes everything runs on a single machine.
This is the main file of the GitHub Actions pipeline. It starts the
pipeline when a push or a pull request happens for the master
branch. One notable exception to this is that the Build workflow
can be manually triggered.
If there is already a pipeline running from the same source (i.e., the same PR), it is cancelled, and only the pipeline with the newest changes is run.
The following jobs are run when the pipeline is started (in parallel, if possible):
- make sure the CI should be run (
conds) - check the repo with the scripts in
/GitScripts/(gitscripts) - run static checks (
static)- this uses the
check_for_bad_patterns.pyandreview_helper.jsfiles underGitScripts, which scan the changes (via regular expressions) for unwanted patterns, such as trailing whitespace. If something undesirable is detected, a comment will be left under the PR.
- this uses the
- run the editmode tests (no Unity UI needed) (
test) - setup build targets for the next step (
setup_build_targets) - create builds (
build)- This step can also be triggered manually.
For all of these, the cloning step is kept in a separate repository to be reusable across jobs: https://github.com/uni-bremen-agst/clone-see-action.
We shouldn't need to run this task, its purpose is to retrieve an activation file for Unity so we can actually run it, but this only needed to be done once.
This runs the Axivion CI to update the data about SEE in the Axivion Dashboard. It is only run on merges into master.
This workflow is triggered every Monday on 4 AM. It does two things:
- It cleans up older artifacts that are stored on GitHub. This is to avoid SEE builds (which are quite large) taking up too much space as CI artifacts.
- It cleans old caches (see "Local Cache") if there are more than four entries.
There are some tasks for which we use GitHub-provided runners (such as the static checks), since they don't need to fully clone SEE. For every task that does need to fully clone SEE, we use sts5, since the LFS clone is much faster due to it being in the same network as the GitLab server.
On sts5, there are four active runners: sts5-α, sts5-β, sts5-γ, and sts5-δ. These are all running in tmux instances under my account (falko1), with their files stored at /local/users/falko1.
We also have an axivion runner, which is a Windows machine with a pre-configured Axivion Suite, which we use to update the Axivion Dashboard with SEE's data (this only happens on merges into master).
As mentioned above, the CI pipeline currently only works if everything is run on the same machine.
One reason for this is that we've configured a local cache—after Unity has generated the Library folder, it is copied to a cache on sts5.
If that cache exists at the start of a job (the cache is keyed per Unity version), it will be copied over first, which greatly speeds up the runtime.
The cache is kept under /local/users/falko1/.actions-cache, and the oldest cache entry will be cleared every Monday if there are more than four entries.
As of now (2025-01-15), each cache entry takes up about 25 GB.