Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate mattes/migrate to new repo golang-migrate/migrate #256

Closed
djui opened this issue Aug 2, 2018 · 2 comments
Closed

Migrate mattes/migrate to new repo golang-migrate/migrate #256

djui opened this issue Aug 2, 2018 · 2 comments

Comments

@djui
Copy link
Contributor

djui commented Aug 2, 2018

The mattes/migrate repo is archived since 8th May and superseded by golang-migrate/migrate now. Support for this repo instead (or mid-term both side-by-side to not break current app deployments) would be nice to keep up with features and security patches (v3.0.1 vs v.3.4.0).

Of course, one can fork the buildpack or use install it as a vendored go get dependency, but would be nice to maintain that feature.

I might give the PR a try, but seeing how the repo patch is regexp in different tools (sed, grep, jq, tq) will likely make supporting both more complex that the benefit it offers.

@djui djui changed the title Migrate migrate to new repo Migrate mattes/migrate to new repo golang-migrate/migrate Aug 2, 2018
@djui
Copy link
Contributor Author

djui commented Aug 2, 2018

Looking a bit closer, I actually believe this feature never worked, as the release binary filename (at least nowadays is migrate.linux-amd64.tar.gz not migrate-linux-amd64.tar.gz, which should have caused any in-the-wild users to raise issues.

So maybe a breaking change (and only supporting the new repo) is tolerable here.

@djui
Copy link
Contributor Author

djui commented Aug 2, 2018

Looking a bit further into the code, the additional-tools only supports migrate currently, which is not obvious from the README and support article. Maybe simplifying that feature and making it more flexible by letting its value be a script (as file or command[s]) in the repo to be run, is easier.

For example (and for compatibility reasons likely with a different key script|additional-script:

[metadata.heroku]
  additional-tools = ["./scripts/download_migrate.sh"]

or

[metadata.heroku]
  additional-tools = [
    [
      "curl -s -f -O migrate.tar.gz -L https://github.com/golang-migrate/migrate/releases/download/v3.4.0/migrate.linux-amd64.tar.gz", 
      "tar xvz migrate.tar.gz",
    ]
  ]

Anyway, whole different can of worms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant