Text file, newlines at end of files

[philderbeast]

Fixes #9802 for *.hs and *.project files and adds a script taking a file glob pattern for doing this, adding newlines at the ends of files where needed. Adds back the whitespace github workflow and uses fix-whitespace to fix non-conformance. Add a short note about this in the contributing readme.

• Patches conform to the coding conventions.

[ffaf1]

@andreasabel created whitespace.yml, let us see what he has to say.

[philderbeast]

@ulysses4ever I see you are a fix-whitespace contributor. Do you think we can get fix-whitespace and fourmolu to play nicely together?

[andreasabel]

You could also use https://github.com/andreasabel/fix-whitespace-action:

steps:
- uses: actions/checkout@v4
- uses: andreasabel/fix-whitespace-action@v1

This action downloads the pre-build binary of fix-whitespace and runs it, and also caches it.

[philderbeast]

Thanks @andreasabel fix-whitespace-action is way less configuration. I reverted one of the corrections and it shows violations in the output.

[philderbeast]

Label merge+no rebase is necessary when the pull request is from an organisation.

[ulysses4ever]

Instead of creating a separate workflow, can we add it to the quick-jobs workflow?

Can you check that fix-whitespace is run with a flag that will show the actual violations?

[philderbeast]

I reverted one of the corrections and it shows violations in the output.

@ulysses4ever I checked and it shows violations.

[ulysses4ever]

Very cool, thanks!

[philderbeast]

@ulysses4ever, funny thing about moving it to quick jobs is that it now doesn't run nearly as quickly (the ghcup, hackage and alex stuff takes a lot longer to run)!

[philderbeast]

In terms of developer feedback, putting it alongside (at the end of) quick jobs is a big degradation.

[ulysses4ever]

Mm, good point. My intention was not having it run quickly, though, and rather I dislike proliferation of standalone workflows. But maybe it’d be good to get an actually quick feedback from this job…

We need to fix quick-jobs to only download binaries and not build anything with ghc!

[philderbeast]

@ulysses4ever I see there is something wrong with the cache in quick jobs;

Post job cleanup.
Warning: Path Validation Error: Path(s) specified in the action for caching do(es) not exist,
hence no cache is being saved.

[ulysses4ever]

Interesting... Maybe worth a new ticket with the continuous-integration label.

[philderbeast]

How much squashing should I be doing with this given that the advice is:

If you push a fix of a whitespace violation, please do so in a separate commit.

[philderbeast]

Sorry @Mikolaj for the lack of squashing. I asked about squashing but forgot to come back to it. Noticed when I got the cabal.head email.

[Mikolaj]

Ouch. With no-rebase and no manual rebase nor squash just before merging, the 12 commits are strewn artistically across other PRs from the several last days. I guess we have to get used to git art. :D

[andreasabel]

For the sake of bisecting, a linear history is really a plus. Can't we enforce it on this repo? (On the Agda repo, I disabled merge commits.)

[ffaf1]

Some contributors — and most importantly, some employers — do not fancy cabal to have write access their repos (e.g.).

At first we did some manual cherry-picking, but then we gave in and merge+no rebase was introduced.

[andreasabel]

Can mergify do the rebase by copying the contributor branch to a new branch on this repo first? Can this be set up? This might be a technical solution.

If a PR cannot be rebased then it should be rejected by default. Otherwise, we'll not get a linear history.

Contributors with write access could be encouraged to push to a branch here rather than on their own repo.

[geekosaur]

Contributors with write access could be encouraged to push to a branch here rather than on their own repo.

This could be difficult if the contributor is working on an employer's tree as part of their job.

[ffaf1]

This requires a new issue for visibility and discussion.

[ulysses4ever]

@mergify backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #10007 Text file, newlines at end of files (backport #9804) has been created for branch 3.12 but encountered conflicts

[ulysses4ever]

@philderbeast

Can you check that fix-whitespace is run with a flag that will show the actual violations?

I checked and it shows violations.

Apparently, we misunderstood each other. What I meant is that it should show not only the names of the files with whitespace issues but also the issues themselves. It could be done by the verbose: true option of the action:

https://github.com/andreasabel/fix-whitespace-action/blob/2a7678e2f1319ae6e9595acb06b8cfb46e38af23/action.yml#L17-L20