All buildpacks except the binary buildpack perform build at push time.
Both "buildpacks" and "12-factor" came out of Heroku.
That said, whether to use the Go buildpack vs binary buildpack is an
interesting question. One thing that's highly desirable is to build one
thing, which you can then promote from test, to staging, to production. To
that end, a CI pipeline that builds a binary, and promotes it between jobs
that deploy to various environments would be the best way to achieve this.
On the other hand, as Rash points out, this requires a leaked abstraction
of your build pipeline having to know the target platform to compile for.
In theory, test, staging, and prod might be using different stacks, though
you're probably always safe assuming 64-bit linux, so I'd say the risk of
having to cross-compile is fairly low.
That said, for small projects, I definitely just use the Go buildpack for
its convenience.
Amit
On Sun, Apr 10, 2016 at 4:05 PM, Rasheed Abdul-Aziz <rabdulaziz(a)pivotal.io>
wrote:
Buildbacks are still environmentally aware of the target build
environment. They mean you don't need to worry about cross platform
support.
On Sun, Apr 10, 2016 at 6:57 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:
On a lazy sunday evening experimenting with the Go and Binary buildpacks,
a thought came to my head regarding cloud native patterns, and in
particular 12 factors' Build, Release, Run.
To me, the Go buildpack is somewhat of an outlier amongst most of the
other buildpacks, it performs compilation (build) at push time and violates
12 factor.
Now this doesn't make it wrong, I'm sure many people are using Cloud
Foundry for apps that may not "cloud native" and violate one or two of the
12 factors, but I'm curious how people approach Go based apps in large
scale production environments? Do they allow the Go buildpack or push
people to the binary buildpack? What do people see as the main reasons for
one over the other?
John.
