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

Include information on GitHub runners setup in README.MD #168

Open
pdewilde opened this issue Nov 1, 2023 · 3 comments
Open

Include information on GitHub runners setup in README.MD #168

pdewilde opened this issue Nov 1, 2023 · 3 comments
Labels
documentation Improvements or additions to documentation good first issue Good for newcomers

Comments

@pdewilde
Copy link
Contributor

pdewilde commented Nov 1, 2023

The "build" job in the ci.yml workflow uses a special group "Beefy" to run on, which behind the scenes is a GitHub large runner group (before adding larger runners, this step took over 5 minutes).

If this repo is forked, that step will hang as no "Beefy" runner group will exist. Documentation should describe how to make your own "Beefy" group, or that you can switch back to "ubuntu-latest" to use a default runner.

@pdewilde pdewilde added documentation Improvements or additions to documentation good first issue Good for newcomers labels Nov 1, 2023
@sethvargo
Copy link
Contributor

Alternative option: can runs-on accept dynamic input? For example, would the following work:

jobs:
  do-something:
    runs-on: '${{ vars.runner || "ubuntu-latest" }}'

@pdewilde
Copy link
Contributor Author

pdewilde commented Nov 1, 2023

I had been looking into that earlier and it seemed like the answer was "no", but now using a different search term the answer seems to be "yes".

If we can do dynamic input, that is absolutely the way to go. I would recommend vars.build_runner since the runner argument is only used for the build step.

@sethvargo
Copy link
Contributor

I believe you can do it with vars and secrets, but not with env? I don't have a strong opinion on the name, but it would be great if there was a default fallback.

My initial suggestion was going to be "use this really complicated expression that checks whether the org == "abcxyz" and then do something else if it's not", but that felt really bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation good first issue Good for newcomers
Development

No branches or pull requests

2 participants