bellycard / napa

A simple framework for building APIs with Grape
Other
329 stars 72 forks source link

read gitsha from file created during slug build #226

Closed ashtonthomas closed 9 years ago

ashtonthomas commented 9 years ago

@bellycard/platform, here is an attempt to get our git version working on heroku

https://github.com/bellycard/heroku-buildpack-gitsha

https://github.com/bellycard/heroku-buildpack-gitsha.git
https://github.com/heroku/heroku-buildpack-ruby.git

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.

darbyfrey commented 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?

ashtonthomas commented 9 years ago

@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?

darbyfrey commented 9 years ago

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.

ashtonthomas commented 9 years ago

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

darbyfrey commented 9 years ago

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.

ashtonthomas commented 9 years ago

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

darbyfrey commented 9 years ago

:+1:

ashtonthomas commented 9 years ago

@darbyfrey, buildpack moved to: https://github.com/bellycard/heroku-buildpack-gitsha

darbyfrey commented 9 years ago

Looks good, :shipit: