allow multiple heroku install directives

[zkrzyzanowski]

Overview

This PR updates our fork of the heroku-buildpack-go project to allow installation of multiple pkgs via the
//+heroku install pkgName directive.

Story

• n/a

Things That I Tested

• deployed buildpack of this branch to analytics-api-staging dyno
• deployed assessment-api#db-updates branch
• multiple install directives are successfully run via

// +heroku install ./analytics/cmd/...
// +heroku install github.com/rubenv/sql-migrate/[email protected]

Where More Testing Might Be Necessary

• I'll do some QA on identity and assessment staging environments to ensure this isn't a breaking change.

Implementation Notes

• Normally, we would have just been able to run something like // +heroku install ./anaytics/cmd/.. github.com/rubenv/sql-migrate/[email protected]. However, this fails due to a version mismatch between the packages. Based on this comment from a go maintainer, its recommended that you run go install multiple times, and this is expected behavior.
• the awk command used to interpolate the //+heroku install directive terminates early after 1 loop. Removing the early exit will gather every instance of the //+heroku install directive instead of just the 1st. I'm unsure if this will break anything else, but the pkgs variable seems like it was intended to be used for multiple packages based on other usages of for loops in the script.
• I attempted to use the already built in functionality for bin/go-pre-compile and bin-go-post-compile, but was unable to get it working. I opened an issue in the original heroku repo here

Dependencies

• n/a

Code Review Best Practices

Use code best practices for PR reviews

[zkrzyzanowski]

@jalandis Requesting a review from you here since I believe you were the one who originally did the setup for our custom heroku buildpacks. Let me know if I can provide any more context here for the changes being made.

[jalandis]

The code changes look great and I appreciate you reporting the issue upstream also 💯

I will approve now but wanted to confirm local dev expectations. Will developers be required to install this package version globally?

[zkrzyzanowski]

Thanks for the speedy review!

I will approve now but wanted to confirm local dev expectations. Will developers be required to install this package version globally?

Could you elaborate on this? When you say developer will be required to install this package version globally, are you referring to github.com/rubenv/sql-migrate/[email protected] or something else.

[jalandis]

Thanks for the speedy review!

I will approve now but wanted to confirm local dev expectations. Will developers be required to install this package version globally?

Could you elaborate on this? When you say developer will be required to install this package version globally, are you referring to github.com/rubenv/sql-migrate/[email protected] or something else.

Yah. To be more precise, I was wondering how identity migrations would be executed when starting up the local dev server. Or how developers would run up/down manually when creating new migrations.

[zkrzyzanowski]

Thanks for the speedy review!

I will approve now but wanted to confirm local dev expectations. Will developers be required to install this package version globally?

Could you elaborate on this? When you say developer will be required to install this package version globally, are you referring to github.com/rubenv/sql-migrate/[email protected] or something else.

Yah. To be more precise, I was wondering how identity migrations would be executed when starting up the local dev server. Or how developers would run up/down manually when creating new migrations.

Ah, gotcha! I'm unsure how the identity team is managing their own migrations, but for the analytics side of things, you would need to install the sql-migrate package to be able to run our local dev server w/ migrations.

My hope is that by the time we get to the point where engineers outside of the analytics team actually need to run it, we'll have sql-migrate set up in nix or docker, so folks don't have to worry about polluting their local env with more packages.