You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current bare metal self-hosted runners are going away, so we are working on setting up a bare metal instance in Oracle Cloud as a GitHub self-hosted runner.
So far
Set up the Bare Metal instance in Oracle Cloud
Set it up as a GitHub self-hosted runner as (but need to leave it disabled for now, see below)
Todo:
Migrate all existing usages of runs-on: self-hosted to runs-on: equinix-bare-metal
This is needed because all self-hosted runners have the self-hosted label, and so as soon as we enable the new self-hosted runner, those workflows will sometimes get one and sometimes get the other.
Usages of the new self-hosted runner should use runs-on: oracle-bare-metal-64cpu-512gb-x86-64 to differentiate.
Decide if we want to use container-based workflows in order to isolate environments, or do we want to run the jobs directly on the host, in which case what software do we need to install on the host?
I’ll let @cijothomas and @clhain explicitly answer the questions mentioned in this issue. From my perspective, a key criterion is selecting a solution that maximizes our chances of obtaining benchmark results with minimal external interference and dependencies, ensuring the results remain as stable as possible over time.
Uh oh!
There was an error while loading. Please reload this page.
Our current bare metal self-hosted runners are going away, so we are working on setting up a bare metal instance in Oracle Cloud as a GitHub self-hosted runner.
So far
Todo:
runs-on: self-hosted
toruns-on: equinix-bare-metal
self-hosted
label, and so as soon as we enable the new self-hosted runner, those workflows will sometimes get one and sometimes get the other.runs-on: oracle-bare-metal-64cpu-512gb-x86-64
to differentiate.Related to
The text was updated successfully, but these errors were encountered: