Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

beaker: Make vagrant installation optional #63

Merged
merged 1 commit into from
Aug 20, 2024
Merged

beaker: Make vagrant installation optional #63

merged 1 commit into from
Aug 20, 2024

Conversation

bastelfreak
Copy link
Member

When we run beaker jobs for vagrant_libvirt on dedicated servers, we control the host. That means we can already install the apt repo + packages. We even have to do it because when multiple beaker jobs start and they want to call apt in parallel, it fails.

When we run beaker jobs for vagrant_libvirt on dedicated servers, we
control the host. That means we can already install the apt repo +
packages. We even have to do it because when multiple beaker jobs start
and they want to call `apt` in parallel, it fails.
@bastelfreak bastelfreak added the enhancement New feature or request label Aug 19, 2024
@bastelfreak
Copy link
Member Author

This is a requirement for us to run beaker jobs on self-hosted / persistent runners.

@@ -176,6 +181,7 @@ jobs:
bundler-cache: true
cache-version: ${{ inputs.cache-version }}
working-directory: ${{ inputs.working-directory }}
self-hosted: ${{ inputs.acceptance_runs_on != 'ubuntu-24.04' }}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my other idea was to match on the name of self-hosted runner, instead of a negative match on the github runners. But we already have two different self-hosted runner groups and maybe more in the future, so the negative match is easier.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one would think! Basically: If the OS of the self-hosted runner doesn't look like the OS GitHub uses, auto-detection works. The CERN-provided runners are on EL9, so that works. Now this time I wanted to be smart and thought 'it is easier to configure the runner software if my OS is the same as GitHub uses', so our new runners are... Ubuntu 24.04. And that breaks auto-detection :sadface:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦‍♀️

okay!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my problem with this is that if anyone decides to set acc_runs_on to anything but 24.04, it will trigger, even if it's not really a self-hosted runner.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
self-hosted: ${{ inputs.acceptance_runs_on != 'ubuntu-24.04' }}
self-hosted: ${{ ! startsWith(inputs.acceptance_runs_on, 'ubuntu-') }}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will test it and provide a PR if it works

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

works: #64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants