Detect when git commit refs are unlikely to be SHAs

[mgsloan]

Currently, if you have a git ref which is not a SHA, such as

- location:
    git: https://github.com/commercialhaskell/stack
    commit: master

Then it leads to non-reproducible builds, because you will just get the most recent version of the repo. Perhaps less expected, is that it will not attempt to update the repo, instead it will just use the version that you have. This is documented:

Note: it is highly recommended that you only use SHA1 values for a Git or
Mercurial commit. Other values may work, but they are not officially supported,
and may result in unexpected behavior (namely, stack will not automatically
pull to update to new versions). Another problem with this is that your build
will not be deterministic, because when someone else tries to build the project
they can get a different checkout of the package.

Since git dependencies can now be shared via extensible snapshots, it seems even more dangerous to have non SHA refs. Should warn about this, and perhaps refuse to share such packages.

[dbaynard]

Thanks for the heads up about this issue.

Unless a non-SHA ref can be resolved and the SHA version used to replace it, I agree that snapshots should never use them. Working within the new extensible snapshots framework, it becomes simple enough to override a fixed snapshot SHA with a local stack.yaml SHA. Is there ever a reason to support branch identifiers in a stack.yaml file, rather than SHA?

On the other hand, one potential difficulty with git repos in snapshots is that they are not immutable. This affects SHA in addition to branches, although with the former at least git won't pick the wrong commit. I haven't yet tested an extensible snapshot with an SHA that can't be resolved; I would imagine the git checkout step would fail. The point is, even using SHA doesn't solve all the problems.

Incidentally, the user interface could help simplify this. Ideal scenario is a command, say stack snapshot append github:commercialhaskell/stack#master that adds a package to a mutable custom snapshot or prints the line to be added to an immutable one. This would resolve to the full sha. For a stack.yaml the command might be stack extra-deps add.

Furthermore, it would be helpful to know that a git repo contains the desired SHA before downloading. This may require github/lab/bitbucket/etc specific code.

In any case, I hope this contribution helps the final extensible-snapshot design. As a user, I'm keen that something doesn't build by default if there are issues (say the SHA can't be found) but that it is possible, with minimal work, to override and fix this.

[torgeirsh]

What about tags? Unlike branches they usually don't change, and something like "version-1.3" is a lot more human friendly than a SHA.

[dbaynard]

Since my comment, a great deal has changed. Thanks to pantry, the way the implementation of stack handles git dependencies has changed. See #4288 for the most relevant part to this discussion. I believe it is likely to allow a workflow like what you have proposed, @torgeirsh.