Broken for 0.23.1 about heroku-buildpack-crystal

[straight-shoota]

This URL assumes package version 0.23.0-1 but for this release it is acually 0.23.1-3.
CRYSTAL_URL="https://github.com/crystal-lang/crystal/releases/download/$CRYSTAL_VERSION/crystal-$CRYSTAL_VERSION-1-linux-x86_64.tar.gz"

[ktaragorn]

Just ran into this.. am working around it by using 0.23.0 for now, by creating a file .crystal-version with that version in it.

[mverzilli]

We can either extract the correct tar.gz name from the response of curl https://api.github.com/repos/crystal-lang/crystal/releases/latest or change our naming policy so that the tar.gz name is a function of the version (that means either dropping the -1, -2, -3 suffixes so we end up with CRYSTAL_URL="https://github.com/crystal-lang/crystal/releases/download/$CRYSTAL_VERSION/crystal-$CRYSTAL_VERSION-linux-x86_64.tar.gz or adding them as a 4th component of the version so we end up with CRYSTAL_VERSION=0.23.1.3 in this case).

I'd vote to drop the -X suffixes in tar.gz names. @matiasgarciaisaia thoughts about going that way?

[matiasgarciaisaia]

Hi there!

It's effectively because of the released tar.gz name. The published 0.23.1 was the third build - there was a first build published in one of the issues, a second build shared internally that was plain wrong, and this last one that worked.

I'm still not sure about The Way™ to handle this. If it's not that much work to simply extract the name from the URL, I'd love to do that for now.

We have started discussing distribution channels (some beta channel vs a stable one) that will imply betas, release candidates, etc, so I think we should first define that, and then choose between a build version (like the -1, -X we have now) and some other suffix.

But I think a suffix will be there for a while, at least.

Any other thoughts?

[bcardiff]

To unblock this we can create a fallback from -1 to -5 in case a 404 is reached

[mverzilli]

The info is there, I just was wondering if it's worth having many builds per version, given the only reason that happens is because of packaging errors.

Anyway, there's an "assets" collection in the json response that holds the exact name of each file we distribute. We can iterate that and look for linux-x86_64.tar.gz suffix, and we'd be pretty sure that's the right file. I had started to work on this but ran out of time and won't be in front of a computer for two weeks. Just sharing the "research" in case someone wants to give it a try before!

[pedantic-git]

Something I neglected to mention in the original bug report is that this error took my app down, because the buildpack didn't fail after the 404 - it tried to deploy the app without a compiler installed.

Whatever the solution to the above, it's probably worth making sure that future filename changes / 404s don't take apps down with them.

[matiasgarciaisaia]

Please review #24 so we fix this 👍

[pedantic-git]

Thanks!