Only enable FreeBSD private runner on demand

[hasufell]

Fixes #11145

[ulysses4ever]

How do we plan to manage this new variable? I.e. who and when will flip it? Will we get the same problem when sometime sets it to 1 for some reason?

[hasufell]

Well, the variable is set to 1. But it is set in this repository only, so any CI that runs on a fork is unaffected. Forks do not inherit repository variables.

[ulysses4ever]

Sounds good, let's try it. Thanks!

[hasufell]

Can this be merged without the mergebot?

[ulysses4ever]

@hasufell we can skip the delay by putting the appropriate label but there's no reason to not use the bot I think. Let me set the label.

[mpickering]

Would there be a suitable place to document which repository variables might be set by forks in order to influence CI?

[hasufell]

Would there be a suitable place to document which repository variables might be set by forks in order to influence CI?

I don't think forks would want to set this variable, unless they have the means to replicate a private FreeBSD runner, which is no easy task and cannot be done with just the official GitHub agent.

[ulysses4ever]

Would there be a suitable place to document which repository variables might be set by forks in order to influence CI?

That would be CONTRIBUTING.md. There's already a beefy section (with subsections) about PRs, for instance.

[hasufell]

I'm afraid I don't think I will write an entire section on how to set up a private FreeBSD runner in the cabal contribution docs.

[ulysses4ever]

I don't think that's what Matt suggested. I think the suggestion is to document the repository variable: its mere existence and purpose. It could go into a broader description of how the new workflow is set up, as there's still frustratingly little documentation around it. I think you were going to update the release wiki page: that would be very welcome. And the variable, I agree with you, will be of little interest to outside contributors. But it'd be good to mention it in the documentation for maintainers (so, the wiki), perhaps: just on principle of less magical undocumented things in the big chunk of YAML that we just merged for the new CI workflow.

The label "run release ci" should be documented somewhere as well: it took me a minute to figure it out when I was looking in the freebsd issue (and I'm still not sure why the release CI seems to try running on PRs without the label). This feels like something closer to the user-visible surface, so maybe CONTRIBUTING.md isn't a bad plae.

[philderbeast]

Could we please expedite the merge, say by adding the [merge delay passed] label?

[hasufell]

@ulysses4ever I don't understand how this is relevant to normal contributors. This is a release management matter only and I was instructed to add such information to the wiki. Normal PRs should never run this workflow.

[ulysses4ever]

@hasufell I agree. Let's update the release wiki?

[ulysses4ever]

@philderbeast this is already done by the "priority: high" label. As to why it's not merged yet, I'll have to double check when I'm at my computer. Maybe the review requested from Brandon stops the bot. Maybe something else. But we should be confident that all normal requirements are satisfied (apart from the 2-day delay requirement, which the priority label lifts).

[geekosaur]

Nobody set merge me.

Eventually the right place to document this will be the documentation added by #10503.