-
Notifications
You must be signed in to change notification settings - Fork 2
machines: enable the use of a more compact labels format #25
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
base: main
Are you sure you want to change the base?
Conversation
This makes it easier to tell which information from the Machine struct `RunDir::new()` actually uses.
A triplet, in forrest speek, is the combination of a username, repository and machine type. This is about to change, because another kind of triplet will be added, containing username, repository and labels. Rename the module to indicate that it contains different kinds of triplets. The old and now name are still not good though, because it is very non-descriptive and because the file also contains e.g. the OwnerAndRepo struct, which only has two components. Leave proper naming to future us.
This is more descriptive of what it actually contains, and it prepares us for the addition of a `OwnerRepoLabels` struct in the next step.
This is only slightly different from the `OwnerRepoMachine` struct. It does not care if the contained Labels actually correspond to what we expect in forrest (e.g. `runs-on: [self-hosted, forrest, machine-name]`) and just preserves them as-is. Why add this struct if `Triplet`/`OwnerRepoMachines` worked fine until now? We have to register runners with exactly the same set of labels as those specified by the job and given to us via the API or webhooks, otherwise the job will not be assigned to the runer. This is much easier if we do not have to reproduce the labels from the machine name and will allow us to accept the labels in different formats in the future.
This allows using the following format in a workflow file:
jobs:
build:
runs-on: self-hosted/forrest/build
In addition to the previous format:
jobs:
build:
runs-on: ["self-hosted", "forrest", "build"]
In this simple example the more compact nature of this format does not
benefit us too much, but it becomes more relevant when `runs-on` is the
result of some computation:
jobs:
build:
runs-on: ${{ github.repository == 'forrest-runner/forrest' && 'self-hosted/forrest/build' || 'ubuntu-22.04' }}
versus:
jobs:
build:
runs-on: >-
${{
(github.repository == 'forrest-runner/forrest' && fromJSON('["self-hosted", "forrest", "build"]')) ||
'ubuntu-22.04'
}}
| if let Some(triplet) = oar.into_triplet_via_labels(&workflow_job.labels) { | ||
| self.job_manager.status_feedback( | ||
| &triplet, | ||
| workflow_job.id, | ||
| workflow_job.run_id, | ||
| workflow_job.status, | ||
| workflow_job.runner_name.as_deref(), | ||
| ); | ||
| } | ||
| let orl = oar.into_orl(workflow_job.labels); | ||
|
|
||
| self.job_manager.status_feedback( | ||
| &orl, | ||
| workflow_job.id, | ||
| workflow_job.run_id, | ||
| workflow_job.status, | ||
| workflow_job.runner_name.as_deref(), | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This removes the "does this job name look like we should handle it?" test e.g. is it runs-on: [self-hosted, forrest, machine] instead of e.g. runs-on: ubuntu-latest.
The jobs will still be discarded later on (like jobs that have a machine type the is not available in the config file), but I think we should have a basic early check nevertheless.
This PR allows using:
Instead of:
Or, more importantly:
Instead of:
This is a early draft, lacking polish, splitting into commits and commit messages.