Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rm .github/workflows/pending-* #100269

Closed
wants to merge 1 commit into from

Conversation

@veprbl
Copy link
Member

@veprbl veprbl commented Oct 11, 2020

These actions mess with CI status for no obvious reason. They make it
harder to tell a real eval failure from a pending build. The ofborg
builder for darwin is not working currently, so this marks many PRs
with a failed state.

cc @zowoq

These actions mess with CI status for no obvious reason. They make it
harder to tell a real eval failure from a pending build. The ofborg
builder for darwin is not working currently, so this marks many PRs
with a failed state.
@worldofpeace
Copy link
Contributor

@worldofpeace worldofpeace commented Oct 11, 2020

this is the actual issue here #96707

@zowoq
Copy link
Contributor

@zowoq zowoq commented Oct 11, 2020

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.

@veprbl
Copy link
Member Author

@veprbl veprbl commented Oct 11, 2020

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.

@zowoq
Copy link
Contributor

@zowoq zowoq commented Oct 11, 2020

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

@zowoq
Copy link
Contributor

@zowoq zowoq commented Oct 11, 2020

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

@veprbl
Copy link
Member Author

@veprbl veprbl commented Oct 11, 2020

@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.

@zowoq
Copy link
Contributor

@zowoq zowoq commented Oct 11, 2020

They aren't spurious.

@veprbl
Copy link
Member Author

@veprbl veprbl commented Oct 11, 2020

They aren't spurious.

My bad. I see now.

@veprbl
Copy link
Member Author

@veprbl veprbl commented Oct 12, 2020

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

@zowoq
Copy link
Contributor

@zowoq zowoq commented Oct 12, 2020

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.

@gebner
Copy link
Member

@gebner gebner commented Oct 13, 2020

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.

@FRidh
Copy link
Member

@FRidh FRidh commented Oct 14, 2020

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.

@doronbehar
Copy link
Contributor

@doronbehar doronbehar commented Oct 14, 2020

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.

@SuperSandro2000
Copy link
Member

@SuperSandro2000 SuperSandro2000 commented Nov 27, 2020

CLosing this based on the discussions.

@zowoq
Copy link
Contributor

@zowoq zowoq commented Nov 27, 2020

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?)

@veprbl veprbl deleted the pr/drop_github_pending_fail branch Dec 1, 2020
@veprbl veprbl restored the pr/drop_github_pending_fail branch Dec 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants