Closed ashtonthomas closed 9 years ago
This looks great @ashtonthomas!
Only comment I would make is that we should be pulling the heroku-buildpack-metadata
repo from the bellycard
org. You can just create a fork of it there and reference https://github.com/bellycardd/heroku-buildpack-metadata.git
in the .buildpacks
file. Make sense?
@darbyfrey, I've moved everything to: https://github.com/bellycard/heroku-buildpack
This is slightly more generic with the thinking that we could add other checks in it. However, now that I'm thinking about it, I think it is probably better to keep the different buildpacks separate.
That way each project can have different buildpacks setup. My thinking is that we may have a buildpack that does something like check git ref is part of master, or some other cool slug pre-compile thing, but not all projects (internal and external to Belly) will have the same needs.
Example of how each project can pick and choose:
.buildpacks
https://github.com/bellycard/heroku-buildpack-gitsha.git
https://github.com/bellycard/heroku-buildpack-ensure-master-ref.git
https://github.com/bellycard/heroku-buildpack-notify-with-custom-message.git
https://github.com/heroku/heroku-buildpack-ruby.git
Thoughts?
Would it be possible to configure a generic buildpack to perform different actions based on ENV variables? If so, then we could bake all the functionality into one buildpack and just turn those features on/off with in the ENV. Not sure if that's possible, but it would be nice to have one buildpack for all of it.
The ENV's are available (read-only) to buildpacks, so we could do things differently depending on the variables.
My goal was to make napa more flexible for internal and external projects not using the exact same process. Breaking things into different buildpacks would allow for a pick and choose setup as well as explicitly showing what will happen in the .buildpacks
file
Yea, that's true. Being more declarative about what you're doing with the buildpacks is probably a good idea. If it's easy enough to make new ones then that seems like a good solution.
Okay, I'm going to create a public repo in bellycard specific to the gitsha and update these PR notes.
Then we can incrementally figure out other buildpacks as we go
:+1:
@darbyfrey, buildpack moved to: https://github.com/bellycard/heroku-buildpack-gitsha
Looks good, :shipit:
@bellycard/platform, here is an attempt to get our git version working on heroku
https://github.com/bellycard/heroku-buildpack-gitsha
I looked into if we could just create a new environment variable (and not need a napa change) with ENV_DIR, but that only reads the existing ones. This makes sense, but I wasted a lot of time trying to add a new config instead of thinking about how bad it would be if buildpacks could change those as they pleased...
I also looked into seeing if we could prevent a build if the gitsha didn't match master HEAD (or something like that), but I don't think we will be able to grab this information during a build (??). Someone smarter than me will have to look into that.