Allow global config file to be fetched from an HTTP endpoint #299
Comments
|
I like having the runs-on.yml living in git alongside the rest of my configuration so that people can reference it. I think what would make more sense for our needs would be to fetch it from the same branch the workflow is running on, instead of from the same commit that the pull-request is coming from. But I can definitely see other people wanting more dynamic configuration (time-of-use, availability of spot instances, etc) where a design like this would be really powerful. |
|
We have little need for a non-git global config, especially if the stack parameter needs to point at the config. This would make testing difficult without having to build out infra to test changes. Maybe if it supported pulling from a specific ref in another private repo, and we could point the local runs-on.yml at that via an extends key, then it might get used. We would much rather just have runs-on.yml read the config from the sha of the current/triggering event. This would alleviate all of our pain. We stopped using the local runs-on.yml config because every config change that merged to our default branch was breaking CI for existing PRs until they were updated with the latest. |
@dgolombek Not sure what you mean by the same branch the workflow is running on. Could you share an example? Thanks! |
@nick-fields just to be sure: are you talking from the perspective of public repos here? Where the config is taken from the default branch and not the current branch of the PR? |
@crohr No, we have a private repo. If I add a new runner config to runs-on.yml and merge it into the default branch, all open PRs that do not yet have that change result in errors such as: If I update the PR with the latest change from the default branch, then the error goes away and everything works. If I only configure runners via repo variables or job outputs in the workflow, then it works as I expect where the runner config for the given commit is what the PR uses. |
|
@nick-fields thanks. In your case I suppose the change you are doing in the default branch removes a runner spec that was still used by the other PRs? Or do you mean that it breaks all PRs irrespective of the change? |
I was thinking of github.base_ref or github.head_ref, but those only work for PRs, and wouldn't work with more complicated branching strategies either. So that's sadly harder than I thought. |
Uh oh!
There was an error while loading. Please reload this page.
Instead of using the
.github-privaterepository to host the RunsOn global configuration file, add a stack parameter that makes RunsOn pull the config file from an HTTP endpoint.Use cases:
When retrieving the config file for a job, also send:
runs-on-custom-tag(if any)Add caching (1min), and fallback to cached value (or error) after at most 5s.
Open questions:
_extendsdirective? This is most likely what users expect.The text was updated successfully, but these errors were encountered: