@GrahamcOfBorg build hello

@GrahamcOfBorg build hello

@GrahamcOfBorg build hello

@GrahamcOfBorg eval

Something that might be an issue with this approach is the limits on github actions, if ofborg goes down we'll start burning through our allocation.

It is limited to 10min. How much time on github actions do we have?

It is limited to 10min.

Which could end up adding up quickly if ofborg does down for any length of time.

It is limited to 10min.

Which could end up adding up quickly if ofborg does down for any length of time.

Where do you have the information from that we have limits? This looks like there are only for private repos: https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/managing-your-spending-limit-for-github-actions#about-spending-limits-for-github-actions

Where do you have the information from that we have limits? This looks like there are only for private repos:

Ah, must have misremembered. Concurrent jobs and API requests may be an issue?

https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits

Not really. It would just means that the job is started later...

Any idea why ofborg is not picking up this PR? Do I need to modify nix files?

@GrahamcOfBorg eval

Any idea why ofborg is not picking up this PR? Do I need to modify nix files?

No. AFAIK, you shouldn't need to modify a nix file for it to start.

I have noticed that ofborg has been a bit flakey the last day or two, not picking up pushes or stopping after eval/meta checks and not triggering builds.

Let's keep the wip label as long as we flip the gnuhello tests, so we don't accidentially merge it ;-)

This is working now. In case it timeouts its still clear that ofborg should have been run so users are not tricked into thinking that the CI run successfully.

Let's see how this works out in practice.

Builds started by an manual ofborg build *** satisfy this check, can we limit it to successful evals?

Builds started by an manual ofborg build *** satisfy this check, can we limit it to successful evals?

It could check for a specific eval, but to be honest before we do this we rather should consider making the eval job a required check...

It could check for a specific eval, but to be honest before we do this we rather should consider making the eval job a required check...

Should we disable the actions for now until we get the required checks working?

The timeout job is a nice workaround but I think the drawbacks may be outweighing the benefits of having it just for the editorconfig check.

It could check for a specific eval, but to be honest before we do this we rather should consider making the eval job a required check...

Should we disable the actions for now until we get the required checks working?

The timeout job is a nice workaround but I think the drawbacks may be outweighing the benefits of having it just for the editorconfig check.

This is a problem with or without github actions. If someone triggers ofborg build it will mark the build as green. I don't see how this is worth than the status quo. In fact having github actions increases seeing the absence of ofborg runs. If ofborg is down for example github actions would still mark the build as failed. So just having the Waiting for ofborg action provides value on its own.

In fact having github actions increases seeing the absence of ofborg runs. If ofborg is down for example github actions would still mark the build as failed. So just having the Waiting for ofborg action provides value on its own.

There was a 3hr wait for ofborg evals earlier, needed to clear a page of errored PRs after ofborg caught up.

Let's continue discussion in #94658