Update GitHub runners to use ubuntu-latest since they have nested virt

[jeefy]

cc @mrbobbytables

[ahrtr]

@fuweid @ivanvc are you ok to use the default runner ( 4 cores)?

@fuweid note that the default runner supports nested virtualization.

@ivanvc I recall the may concern on the benchmark workflow is that it's too long to finish the workflow. Using the default runner (4 cores) may take even longer.

bbolt/.github/workflows/benchmark-template.yaml

Line 17 in 7b6185a

default: "['ubuntu-latest-8-cores']"

[ivanvc]

@fuweid @ivanvc are you ok to use the default runner ( 4 cores)?

I compared the execution times for test-linux-amd64 and test-linux-amd64-race and they look the same. I think it's because we never used the 8 cores. Our tests use up to 4 cores. I'll check again when the robustness tests finish running.

@ivanvc I recall the may concern on the benchmark workflow is that it's too long to finish the workflow. Using the default runner (4 cores) may take even longer.

It took a long time to run the workflow, but when we were testing with benchstat. We're now using our bench, I never tested the performance with the default 4-core runners. It may be ok, the best would be to check the execution times.

@jeefy, do you have more context for the motivation for switching to the default runners? I'm not sure if I understand the pull request title.

[jeefy]

Glancing at the current robustness tests, they take less than 3 hours to complete so I'd like to at least test that these workflows do-or-do-not fit in the six-hour window.

If they don't, I'd then like to try putting them on runners that the CNCF hosts. :)

[ivanvc]

/ok-to-test

[ivanvc]

Robustness tests take about the same amount of time.

@jeefy, feel free to also change the benchmark runner. I don't think we're saturating the 8 cores.

Did you have a chance to read my previous comment?

@jeefy, do you have more context for the motivation for switching to the default runners? I'm not sure if I understand the pull request title.

[ahrtr]

@jeefy, do you have more context for the motivation for switching to the default runners? I'm not sure if I understand the pull request title.

I think that the motivation is to save cost. CNCF is billed for the large runners, while the regular runners are free.

[ivanvc]

I got it; thanks. The jobs seem to be running fine with the 4 cores. We could also try updating the benchmarking job.

[ahrtr]

@jeefy Please update the following runner to ubuntu-latest as well,

bbolt/.github/workflows/benchmark-template.yaml

Line 17 in 7b6185a

default: "['ubuntu-latest-8-cores']"

[fuweid]

REF: #612

The original motivation is not for nested virt. The free-tier runner has limitation. It seems that there was runner agent monitoring memory or cpu usage. If the resource usage is higher than expected, the agent will kill the process actions/runner-images#6680 (comment)

By default, the free-tier runner only has 3 cores. I'm not sure that it can do nested virt.

[mrbobbytables]

The free tier has been upgraded 👍 They are 4 core with 16gb of ram now.

EDIT: They now support nested virtualization as well.

[fuweid]

Thanks for the information 👍

https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

[ivanvc]

There's an if condition in .github/workflows/tests-template.yml, which can be simplified:

bbolt/.github/workflows/tests-template.yml

Line 19 in 6f8410b

if: ${{ github.repository == 'etcd-io/bbolt' || inputs.runs-on == 'ubuntu-latest' }}

But I can do that in a follow-up PR.

LGTM. Thanks, @jeefy.

[ahrtr]

@jeefy Please squash the commits.

[ahrtr]

LGTM

I will squash the commits this time.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahrtr, ivanvc, jeefy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ahrtr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jeefy]

Sorry didn't see the comment re: squashing 😅

Thanks!!!