Haskell release automation

What tools do you all use for automating release of Haskell libraries to Hackage?

Automating the following would be of relevance in this workflow:

  • Tag a release on GitHub
  • Create sdist cabal sdist and docs cabal haddock --haddock-for-hackage
  • cabal upload --publish both the sdist and haddock

(My projects all use Nix, FWIW)

Additional integration like CHANGELOG (whether or not based on conventional commits) are rather optional, but would be nice to have.

2 Likes

Do you have a specific need with regards to docs? Lately I have not witness Hackage failing docs builds.

Personally I cannot be of much help, I do it manually, because I want to check candidates before publishing the real package.

I manually upload haddock only because it gives me an instant preview on hackage. I don’t know how long it takes for Hackage to automatically generate docs, but it doesn’t seem to be < 5minutes.

3 Likes
8 Likes

I decided to write my own script. What I wanted was an “one click” workflow—basically I just run nix run github:srid/hackage-publish on the package source … and it publishes without any manual intervention (except for using my fingerprint to approve password request).

It is hardcoded to 1Password, but this can potentially evolve into general software depending on user interest. I also want do ‘sanity checks’ (like fail if there’s no CHANGELOG.md).

1 Like

I’m using a simple nix wrapper on top of a Haskell package built with Nix (haskell-flake).

...
  packages = {
    “ClickHaskell-dist” = import ./contribution/hackage.nix {
      inherit pkgs;
      distPackage = self’.packages.ghc984-ClickHaskell;
    };
  };
...
{pkgs, distPackage}:
with pkgs.haskell.lib;
pkgs.runCommand "${distPackage.name}-dist" {} ''
  mkdir $out
  mkdir -m 777 $out/packages $out/docs
  cp -r ${sdistTarball distPackage}/${distPackage.name}.tar.gz $out/packages
  cp -r ${documentationTarball distPackage}/${distPackage.name}-docs.tar.gz $out/docs
''

This builds a result directory with dist suitable for the haskell-publish GitHub Actions workflow (with candidate deployment in my case):

jobs:
  runs-on: ubuntu-latest
  handle-push-to-master:
      # install nix...

      - name: Build ClickHaskell-dist
        run: nix build .#ClickHaskell-dist
      
      - name: Deploy ClickHaskell release candidate
        uses: haskell-actions/hackage-publish@v1
        with:
          hackageToken: ${{ secrets.HACKAGE_API_KEY }}
          packagesPath: result/packages
          docsPath: result/docs
          publish: false ### release candidate flag

On the release date, I create a GitHub tag and use the “publish” button on Hackage

1 Like

I recently dubbled with hkgr: Simple Hackage release workflow for package maintainers which I really liked.

@f-a

I do it manually, because I want to check candidates before publishing the real package.

hkgr, for one, publishes a candidate by default, so there’s a room for manual double-checking. And I agree that writing to an append-only database like Hackage should use some good-old human-in-the-loop sanity checking…

4 Likes

Simon Hengel automates releases of Hpack at hpack/.github/workflows/publish.yml at main ¡ sol/hpack ¡ GitHub.

He makes use of an action that creates Git tags on Cabal file version bumps: GitHub - sol/haskell-autotag: A GitHub action that creates git tags on .cabal version bumps.

3 Likes