We were having some difficulty on a server running this
`apt-apt-repository` command due to suspected firewall issues. On
further inspection is appear to be superfluous as git can be obtained
easily through `apt-get` without adding this repository.
Unfortunately Actions uses docker contaienrs to create files on the
system with root permissions. The 'vagrant' user which we login to run
the Actions Runner, can't remove these files. However, 'vagrant' is part
of the sudo group and can therefore use sudo to remove these files.
I don't like this, but it works.
This patch:
1. Adds setup scripting to "provision_root.sh" to setup and enable KVM,
for the 'vagrant' user, for VMs which are capable of this.
2. Runs a check on each VM to see if KVM can be run sucessfully within a
docker container. If so, the GitHub Actions runner is given a 'kvm'
label. It is unknown at this time if GitHub Runners can utlized KVM
but it is open to their processes.
Change-Id: Idfcbb7bfa3e5b7cc47d29aea50fb1ebcafdb7acc
Without `--all` `docker prune --force --volumes` will remove everything
exception non-dangling images. For an image to be considered dangling it
must be untagged and/or not used by a container at that time. As most of
the images we download are tagged (e.g., `:latest`) then most of our
images are never removed without the inclusion of `--all` which will
remove any image not currently used by a container.
Images were starting to accumulate on runners. This will ensure they do
not and are cleaned after each job run.
Change-Id: I6d8441a11d22fdcf827e9c44422dbcf02cf600e0
THe `lvextend` command extends the logical volume. However, the
`resize2fs` command is needed to extend the filesystem to fill the
logical volume.
Prior to this patch the filesystem ran out of space despite there being
enough room in the volume. This was just wasted free space.
This patch removed the bespoke "vm_manager.sh" script in favor of a
Multi-Machine Vagrantfile.
With this the users needs to only change the variables in Vagrantfile
then use the standard `vagrant` commands to launch the VMs/Runners.
Change-Id: Ida5d2701319fd844c6a5b6fa7baf0c48b67db975
Prior to this change we were limited to a root partition with only 60GB
of space which caused issues when running larger simulations (see:
https://github.com/gem5/gem5/issues/165).
There are two factors in this issue which this patch resolves:
1. The root partition in the VM was capped at 60GB despite the virtual
machines size being capped at 128GB. This resulted in libvirt giving the
VM free space it couldn't use. To fix this `lvextend` was added to the
"provision_root.sh" script to resize the root partition to fill the
available space.
2. The virtual machine size can be set via the `machine_virtual_size`
parameter. The minimum and default value is 128GB. This wasn't exposed
previously. Now, if we required, we can increase the size of the VM/Root
partition if we require (though I believe 128GB is more than sufficient
for now).
Fixes: https://github.com/gem5/gem5/issues/165
Change-Id: I82dd500d8807ee0164f92d91515729d5fbd598e3
The "action-run.sh" action replaces inline scripting in the Vagrantfile.
The major improvement is this script runs an infinite loop and
configures the runners to be ephemeral. This means they cease to exist
after a job is complete. The script then cleans the VM workspace and the
loop restarts by configuring and setting up another runner. This means
our VMs no longer accumulate files that eventually lead to the VM
running out of space.
Change-Id: Iba6dc9a480f5805042602f120fc84bdc47a96d55
There are two places self-hosted runners can exist on GitHub:
1. At the level of the repository: In this case the runners can only be
used by that repository and runners can only be distinguished from one
another by labels.
2. At the level of the organization: In this case the runners can be
used by any repository in the organization, thus increasing their
versatility. In addition to labels, runners in the level of the
organization can be organized into groups.
While we do not use our self-hosted runners on other repositories, there
may be future use for this, so we might as well enable it now.
Change-Id: Id5e113194314336221dcdc8c2858b352afcbaf6e
Having two types of GitHub Action Runners has not yielded much benefit
and caused confusion and inefficiencies. This change simplifies things
to having just one runner with 8-cores and 16GB of memory. It is
sufficient to build gem5 and run most simulations.
Change-Id: Ic49ae5e98b02086f153f4ae2a4eedd8a535786c8
This reverts commit 0249d47acc,
https://github.com/gem5/gem5/pull/271.
This solution doesn't work. GitHub runners pull the images they need at
the start of job (i.e., all the images they may need for each step).
They then create the containers later, at the step they are needed.
This solution therefore breaks in the case a cleanup happens during the
running of a job. I.e., a `docker system prune` happens after setup,
therefore deleting all the images, then the job tries to use one of the
images during a step.
This crontab solution may work if we can only do it when the runner is
in an idle state. Whether this is possible is unknown.
Change-Id: I7cb5b2d98d596e9380ae1525c7d66ad97af1b59b
