Add revision information to plan.json

[fgaz]

Closes #6186

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• [x] Patches conform to the coding conventions.
• [x] 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.
• [x] The documentation has been updated, if necessary.
• [x] Manual QA notes have been included.
• [x] 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

[fgaz]

I'm trying to write one using withRemoteRepo

[fgaz]

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

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

[arrowd]

Just a note that FreeBSD Ports would benefit from this change as well. We're also parsing plan.json to get versions, but then have to query Hackage for a number of the latest revision available. Having this info in plan.json would make things easier.

[fgaz]

Apparently error -1073741510 (aka 0xC000013A STATUS_CONTROL_C_EXIT) means the program was Ctrl+C'd?? That makes no sense...

[geekosaur]

Isn't that how a timeout shows up?

[fgaz]

Isn't the default timeout 6 hours? The error appears at <1.5 hours

[geekosaur]

I think this is tasty's timeout, not GitHub's.

[fgaz]

Then wouldn't it would show which test is failing? And as far as I can tell we don't set the tasty timeout

[fgaz]

Maybe that error code is a red herring. It appears in other tests too, and it doesn't seem to affect them. It might be a coincidence that it appears at the end.

[fgaz]

Yes, I think that message appears when a test thread is done. We have 2 threads, PlanJson (the name of the test I added) never appears, and we see only one of those messages in that step, so my hypothesis is that the new test is hanging in one thread, while the other thread goes through all the other tests.

I'll disable the new test on windows for now