Conversation
|
If we are going to keep the architecture of one runner type per controller, does it make more sense to make this a part of the runners variable or split it out into its own env variable? Alternative here |
I thought of that originally, too, but we're already instructing users to populate the environment variable with JSON, and so it makes sense to stay idiomatic there. I think that may come from ARC. |
|
Sounds good, defining the runner name and ID together makes sense as well. We should update the error message on a failed parse to include a reference to the ID then too. |
Will do, but it's worth keeping in mind that the ID should remain optional. |
|
The ID should stay (and is) optional. I was thinking of making sure that it referenced the ID in case someone set the runner like |
|
We should also add the documentation from the |
|
@cjflan not sure we want to add it to the |

Previously, we could define a runner group's name, but not its ID. This creates some challenges around specifying multiple runner groups and being able to retrieve information about them through GitHub's API. This allows us to set the group's ID using the same
RUNNERSenvironment variable that allows us to set its name.This change updates the
READMEwith the necessary information as well.It's worth noting that per our existing
READMEfile, all configuration parameters can be set via the documented environment variables at runtime, or with a.envdocument made available in the working directory at runtime.Closes #32
Closes #33
Closes #34
Closes #35