Add revision information to plan.json

[fgaz]

Closes #6186

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

QA Notes

• cd to any project that uses packages from hackage
• Run cabal build --dry all to produce a plan.json
• inspect dist-newstyle/cache/plan.json
  • it should contain a pkg-revision field under all remote-repo or secure-repo packages
  • the field should correspond to the latest hackage revision published before the used index-state

[geekosaur]

Tests would be nice, granting that we'd have to find a stable repo that has revision fields.

[fgaz]

I'm trying to write one using withRemoteRepo

[fgaz]

Okay, this should work, please have a look ^_^

[mpickering]

Perhaps the revision should be adjacent to "repo" in the RepoTarballPackage but either way it seems good to get the info into the plan.json somehow.

[fgaz]

I put it there because I thought it didn't apply to all repo types (RepoLocalNoIndex in particular), but indeed it's a bit weird to have it inside repo.
And even though I don't really see a use case for exposing revisions from local repos, I don't see any disadvantage either, so maybe I should just do it.

[geekosaur]

"If it's there, someone will come up with a use for it". And consistent behavior is generally a good thing.

[fgaz]

Now I wonder if we should just have it at top level, next to pkg-name and pkg-version.
It's just a field that can be extracted from any cabal file that contains it anyway

[mpickering]

Now I wonder if we should just have it at top level, next to pkg-name and pkg-version. It's just a field that can be extracted from any cabal file that contains it anyway

That doesn't seem too bad to me.

[ulysses4ever]

@fgaz 3.16 is rapidly approaching. Do you want to push this over the line?

[fgaz]

I moved it to the top-level unit info.

---

3.16 is rapidly approaching. Do you want to push this over the line?

@ulysses4ever It'd be nice, however I'm planning to open another pr that adds source-repository-package revision information, and I'll need both for my purposes, so waiting for the next release is fine by me.

[ulysses4ever]

3.16 looks out of reach by now sadly. Looking forward to see it in 3.18!

[fgaz]

Windows is failing :-/

GHCi exited with ExitFailure (-1073741510) (use -v for more information)

[geekosaur]

Windows validates are getting wedged and killed-but-undead by GHA timeout for some reason. I canceled the jobs and am trying again to see if they wedge at the same place this time.

---

ETA: no, they're really undead. The actions panel said I canceled them successfully, the UI thinks they're still running and when I went back to the actions panel it said "Waiting for pending jobs" meaning they're still running despite their logs saying they cleaned up and terminated and the post-job saying it got their statuses. This smells like some GHA hosage.

---

ETA: just more UI hosage: shift-reloading got me it having restarted them as expected, and I'm tracking it running lib-tests now.

[geekosaur]

Okay, it's failing as mentioned above, after tests\ok.test.hs repeatably. So, what test follows that and why is it failing this way? Can cabal-testsuite (or tasty) be convinced to show what tests it's running/planning to run?