With the recent migration to GH action, I just noticed that a merge that didn't update the Cabal file didn't break builds that should have been broken. This makes sense, in that the Cabal builds only view the currently checked in version of the Cabal file, where as stack builds regenerate it.
Notably, however, we publish via stack, which will then regenerate the file. So in this case, the builds would succeed, but the published version would be broken, which is not good.
One option would simply be to sync things before Cabal builds via something like stack build --dry-run. However, in many ways this defeats the purpose of checking in the file at all. If we are to check it in, ideally that means that users can use this package with Cabal via git checkout and no additional effort.
It may make sense to abort the build if the generated file were not going to match. That should theoretically prevent merges that don't keep master in sync.
With the recent migration to GH action, I just noticed that a merge that didn't update the Cabal file didn't break builds that should have been broken. This makes sense, in that the Cabal builds only view the currently checked in version of the Cabal file, where as stack builds regenerate it.
Notably, however, we publish via stack, which will then regenerate the file. So in this case, the builds would succeed, but the published version would be broken, which is not good.
One option would simply be to sync things before Cabal builds via something like
stack build --dry-run. However, in many ways this defeats the purpose of checking in the file at all. If we are to check it in, ideally that means that users can use this package with Cabal via git checkout and no additional effort.It may make sense to abort the build if the generated file were not going to match. That should theoretically prevent merges that don't keep master in sync.