Tag for 0.9.0 is currently broken

[Eric Bailey]

===> Failed to fetch and copy dep: {git,"https://github.com/lfex/lutil.git",
                                  {ref,
                                      "0ee02e01d643caba7a0b8365c477aea8d92bf309"}}

[Eric Bailey]

This happens on Travis as well as locally.

rebar3 does the following:

$ git clone -n https://github.com/lfex/lutil.git /tmp/lutil
$ cd /tmp/lutil
$ git checkout -q 0ee02e01d643caba7a0b8365c477aea8d92bf309
fatal: reference is not a tree: 0ee02e01d643caba7a0b8365c477aea8d92bf309

It seems like this patch fixes it:

diff --git a/rebar.lock b/rebar.lock
index 742f0a7..b3231fb 100644
--- a/rebar.lock
+++ b/rebar.lock
@@ -16,5 +16,5 @@
   3},
  {<<"lutil">>,
   {git,"https://github.com/lfex/lutil.git",
-       {ref,"0ee02e01d643caba7a0b8365c477aea8d92bf309"}},
+       {ref,"1132c09949d22fcbd413b6a779bcb40a629c44d3"}},
   0}].

See lutil 0.9.0, which now says 1132c09949d22fcbd413b6a779bcb40a629c44d3 is the right commit hash.

[Duncan McGreggor]

Yeah, everything is going to be affected:

• the symptom arises due to the fact that rebar.lock files are kept in repo and save a particular commit id
• the actual source of the problem is that all the commit ids in both ltest and lutil have changed, due to a rewrite (bad emails in the history for 100s of my commits)

As you noted, the workaround for this is to remove the rebar.lock file locally and let rebar3 regenerate it with the new commit ids for the various tags.

The good news:

• all of the projects that I maintain will be updated and published to Hex.pm
• due to issues with generating a Hex.pm release in a profile, rebar.lock files will not be saved with my projects anymore, so this particular issue won't occur, should commit ids ever change again

So, have patience -- once these projects are out of the RC stage, they should be in pretty good shape and all these issues will have been worked around.

[Eric Bailey]

Noted. Sounds great!

Excluding rebar.lock from the Hex packages makes me a bit nervous, since builds that depend on such packages become potentially less reproducible, but the tradeoff seems seems probably worth it and fine.

[Eric Bailey]

Looks like the ltest 0.9.0 tag is still broken. I'm using this override for now:

{overrides, [
  {override, ltest, [
    {deps, [
      {lutil, {git, "https://github.com/lfex/lutil.git", {ref, "1132c09"}}},
      {color, {git, "https://github.com/julianduque/erlang-color.git", {tag, "v0.2.0"}}}
    ]}
  ]}
]}.

To anyone else reading this: The issue will be resolved once lutil and ltest see their next release. ltest tags > 0.9.0 should work fine, but I'm holding off on using the release candidates for now.

[Duncan McGreggor]

@yurrriq Could you point me to a project where the tag is broken? I'm surprised that the rebar.lock regen doesn't work; I'd like to see what's going on.

[Eric Bailey]

Any project that depends on ltest 0.9.0, e.g. kla 0.7.0, because of this. Dependencies in the test profile (which is where I have ltest) aren't locked anyway. The problem is with ltest itself.

[Eric Bailey]

I think if you apply the patch above and then force push the 0.9.0 tag, all will be well for projects that depend on it.

[Duncan McGreggor]

I've just removed the rebar.lock file from 0.9.0 -- try that out.

I'm testing it on kla 0.7.0 right now ...

[Duncan McGreggor]

Build worked for me.

[Eric Bailey]

Works for me too, thanks.