this is the actual issue here #96707

These actions mess with CI status for no obvious reason.

They are needed for the editorconfig check.

They make it harder to tell a real eval failure from a pending build.

Will be fixed by NixOS/ofborg#527.

The ofborg builder for darwin is not working currently, so this marks many PRs with a failed state.

No it does not.

They are needed for the editorconfig check.

I would suggest removing it too. It affects a tiny fraction of pull requests, I would not be surprised if there is only a single digit number of people who actually consume this check. It makes no sense to me to keep it in the UI.

It affects a tiny fraction of pull requests, I would not be surprised if there is only a single digit number of people who actually consume this check.

https://github.com/NixOS/nixpkgs/actions?query=workflow%3A%22Checking+EditorConfig%22+is%3Afailure

Regardless of editorconfig we'll need the pending job if we want to work on #99722.

@zowoq What are you trying to say? If I'm not mistaken, following your link I see that the check has some spurious fails for unrelated PR's.

They aren't spurious.

They aren't spurious.

My bad. I see now.

The ofborg builder for darwin is not working currently, so this marks many PRs with a failed state.

No it does not.

Here it happens on my PR: #100121
Here the status was not cleared for no reason (at the moment, the PR is not finished): #98634

The ofborg builder for darwin is not working currently, so this marks many PRs with a failed state.

No it does not.

Here it happens on my PR: #100121

It isn't related to darwin. GrahamcOfBorg was called manually before eval finished which caused a conflict between the completed jobs, I've seen this in a couple of PRs and I haven't bothered doing anything about because it won't be an issue once NixOS/ofborg#527 and #96707 are merged.

Here the status was not cleared for no reason (at the moment, the PR is not finished): #98634

Not sure exactly what happened with this one (being closed/reopened without pushing changes may have caused it to glitch) but it wouldn't have happened if we had NixOS/ofborg#527 and #96707.

They are needed for the editorconfig check.

I would suggest removing it too. It affects a tiny fraction of pull requests, I would not be surprised if there is only a single digit number of people who actually consume this check. It makes no sense to me to keep it in the UI.

The editorconfig check is important. Before it we had lots of trailing spaces. And if you had an editorconfig-aware editor, then it would automatically strip them. I've made several PRs with unrelated (accidental) whitespace changes in all-packages.nix for this reason.

Maybe the editorconfig check should be a different actions workflow though.

Maybe the editorconfig check should first be announced on the mailing list (along with other CI plans), and at the least documented what is expected here from contributors. I'm pretty sure this has been said several times.

Speaking of EditorConfig, I'd like to suggest that it'll be more strict, also regarding spaces vs tabs (example). Also 👍 on whoever that decided it should notify users when this check fails.

CLosing this based on the discussions.

Apologies, seems I forgot about this PR.

Maybe the editorconfig check should first be announced on the mailing list ... I'm pretty sure this has been said several times.

Thought I'd already commented on this in another PR but if I did I can't find it.

As this is the fourth attempt at this check I was waiting until we didn't need the weird workarounds.

I'd like to suggest that it'll be more strict, also regarding spaces vs tabs

Disallowing tabs was done in #101530. Indentation size is more disruptive, I'm still looking at ways to enable it.

Also 👍 on whoever that decided it should notify users when this check fails.

Github, currently we aren't able to configure notifications. (IIRC users can disable them globally in their profile?)