Silent failure for.. not sure what
aaronjensen opened this issue · comments
mix release fails silently and with --verbosity=verbose returns:
===> Provider (resolve_release) failed with: {error,
{rlx_prv_release,
{failed_solve,
[{[{[sasl,iex,elixir,
{booking,
{<<"2.6.1-7291-gcac66cd">>,
{[],[]}}}],
[sasl,iex,elixir,
{booking,
{<<"2.6.1-7291-gcac66cd">>,
{[],[]}}}]}],
[]}]}}}
I have no idea what this means... If I blow away my build directory and try again it works
I haven't seen that one before. There was no other output, just that?
/cc @tsloughter Do you know offhand what step would produce that error? Normally if it's just an issue of finding a dependency, the error is pretty clear, this appears to be something else.
Here's the complete log https://gist.github.com/aaronjensen/65b6580d7a810726de0bbd1733e8dc98
This happens when the depsolver can't find a solution. It looks like the error handling is broken maybe for that case... I am not positive but it looks like it can't find that specific version of booking that it is told to use.
It's the version that is being built, so that seems odd.
Yea, those complete logs show it finds a different version then what it is looking for.
@aaronjensen The version it's finding is booking-2.6.1-7244-gc18eebc, does that offer any clues?
@bitwalker that's the old version. This machine builds upgrades
I'm on freenode if a screenshare would help and you have time @bitwalker @tsloughter
Removing _build/prod/lib/booking and recompiling then releasing works. This is a new issue for us, 1.0.0-rc7 did not have this
Btw @bitwalker it'd be great if exrm printed the above error when an error occurred rather than requiring us to rerun w/ --verbosity=verbose. Sometimes they're actionable.
@aaronjensen I think that's workable - I can just capture the output and dump it if an error occurs, and otherwise swallow it. I'm not sure what would've changed to cause the original issue though. Can you easily reproduce?
This one, not easily. We added mix clean back into our build and that has made it go away. I was hoping to avoid that for performance reasons, but accuracy trumps performance.
@aaronjensen I've made that change in 797397d. I also went through and added translation of many of the relx error tuples, so general error reporting should be a bit more useful.
@aaronjensen Are you running mix compile prior to running mix release? When running with MIX_ENV=prod you have to do that. I wonder if that's what's causing the problem here.
@aaronjensen I've made that change in 797397d. I also went through and added translation of many of the relx error tuples, so general error reporting should be a bit more useful.
awesome!
@aaronjensen Are you running mix compile prior to running mix release? When running with MIX_ENV=prod you have to do that. I wonder if that's what's causing the problem here.
Yes, we're using edeliver and it does that.
I'm confused as hell how a clean would fix what a compile wouldn't - the .app in the build output has the old version in it, the only thing that makes sense is that the compile isn't occurring. I suppose I'll need to dig into edeliver to understand better what the deployment flow looks like - at the moment I'm at a bit of a loss.
yeah, same here. I can disable the clean again and see if we can get into the repro state and then I can try and dig in a little and/or screenshare w/ you if you're avail.
Ok, we hit another issue w/o the clean. I think the issue is that our mix.exs actually computes the version based on the git sha, which means that if it doesn't change, it doesn't recompute the version. If I modify mix.exs it rebuilds the entire project any way, so it seems like skipping clean is actually meaningless on my project. I'd be happy to close this issue because I can't reproduce this exact issue and we're going back to cleaning before each build.
Super strange, but yeah, I guess let's close this for now, and if it crops up again in a more reproducible fashion, we can go from there. I suspect your guess is not far from the truth though.