cannot complete repo info for a non sha1 commit, but it's just a short version?

[silky]

using the latest stack to build a project that has always worked, i now get this error message:

09:35 AM noon ∈ src (master*) stack run
Cannot complete repo information for a non SHA1 commit due to non-reproducibility: Git repo at https://github.com/silky/diagrams-pandoc.git, commit d1b122b

this is my extra-deps of my stack.yaml:

extra-deps:
    - git: https://github.com/silky/hakyll-diagrams.git
      commit: 4dd69ad9ce81949b872295ac475453d808399aba

    - git: https://github.com/silky/diagrams-pandoc.git
      commit: d1b122b

so the point is that this short-form commit is no-longer valid?

[Keruspe]

stack/subs/pantry/src/Pantry.hs

Line 759 in 0b2c555

unless (isSHA1 (repoCommit repo)) $ throwIO $ CannotCompleteRepoNonSHA1 repo

is the culprit.

Note that this also prevents from using tags

[juanpaucar]

Does anyone know if this is still an ongoing issue? I tried to look @Keruspe code, But I couldn't find it. I could help with a PR to allow tags again. I've been using stack 1.9.3 because any newer version presents this issue:

Cannot complete repo information for a non SHA1 commit due to non-reproducibility: Git repo at [email protected]:org/repo, commit v1.0.0

[morganthomas]

If I'm understanding the situation correctly, this is by design, working as intended. The idea is that disallowing non-SHA1 commits is a necessary condition for Stack builds to be reproducible. This is true, because tags are pointers to commits and the commit they refer to can change. While it is nice from a usability standpoint to be able to refer to tags in our Stack configurations, it does prevent Stack from having a reproducible build property.

Maybe users should be able to pass Stack an option to allow for non-SHA1 commits. This could make sense for use cases like Holland and Hart, where we control all the repos we're pointing to using non-SHA1 commit references, and we trust ourselves, and any failures of reproducibility due to allowing non-SHA1 commits would be intended by us. However, I could still see the potential for unintended consequences / headaches due to pursuing such a policy direction of intentionally allowing for changes in Github to break our builds.

[hasufell]

The idea is that disallowing non-SHA1 commits is a necessary condition for Stack builds to be reproducible.

Stack builds are not reproducible at all. That would require much more work. Stack just picks fixed versions of dependencies. That is not what a reproducible build is.

This is true, because tags are pointers to commits and the commit they refer to can change.

This ticket is not about tags, but short versions of SHA1.

[mpilgrem]

I am going to close this issue given the passage of time and because it appears to me that the original question was answered.