Publish Haddocks from CI as part of release

[pbrisbin]

Since implementing Kafka functionality, Hackage has been unable to build
our Haddocks due to the system library requirement that introduced.
Since then, we've been sporadically uploading docs using the
docs/upload script, which relied on (nix and) cabal to use its
--haddock-for-hackage flag.

With the release of stack-v2.15, we can now:

• Use its new --haddock --haddock-for-hackage options
• Use the new stack upload -d option
• Use HACKAGE_KEY to authorize stack for uploads

So we can do all of this on CI, without incurring the need to use cabal
instead of Stack there. We also don't really need stack-upload-action
anymore, so that's been removed.

I decided to add an additional build within release.yml, rather than:

1. Conditionally release from ci.yml after building, or
2. Attempting to upload artifacts from ci.yml for use in release.yml

The reason for this is:

• It made this the simplest change to accomplish the goal
• It's somewhat valuable to add a requirement the thing builds before
  releasing, which wasn't the case before
• The addition of Haddocks makes the build 23m cached-or-not, which we
  don't want to do except during release, and is fine to do post-merge,
  which is not holding anyone up

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1206121516414618

[chris-martin]

Why such an old resolver here?

[pbrisbin]

I actually meant to comment this and will now, but:

The --pvp-bounds lower option uses the resolver to decide the lower bounds. Since this is the oldest resolver we test with, the versions of the packages in this resolver are exactly what we want to be our lower bounds.

https://illuminate.atlassian.net/wiki/spaces/EN/pages/17185976662/Preferred+Supported+Compilers+in+Haskell+OSS#Lower-Bounds

[chris-martin]

Haddock in the release workflow only seems fine. I would love to someday have "haddocks build without warning" asserted in CI though.

[pbrisbin]

I would love to someday have "haddocks build without warning" asserted in CI though.

Me too, but I think that's going to require upstream improvements in how the build vs docs interact before that's possible. Making a cached build in this project go from 2m to 23m is potentially worth it, but it's absolutely untenable in a project like fancy-api, where it would move the cached build time to over an hour.