== Problem ==
For the toolforge build service Beta ({T267374}) we have to decide what buildpacks do we allow (that means allow and test).
Some definitions first:
**Note:** Build and build__er__ images are different
* Application image -> This one is the product, it's built by the builder image, by running the buildpacks on top of the build image, and copying the result over to the run image.
* Builder image -> This one defines what run and build image to use, and which buildpacks to include (ties the run+build to buildpacks, it's the one that builds the final application image)
* run + build image -> This ones defines the image the code will be build with and run in (ex. decides which OS will be running), this is sometimes called stack
* buildpacks -> Scripts that will build and prepare the app image (run at build time, define the tooling to build, how to run it, are tied to the build and run image through the OS)
There's three things to decide here, and they are bound to each other (so not easy to decide separately):
* The buildpacks to use
* The build+run image to use
* The builder image to use
There's some upstream built builders, run and build images, and buildpacks from different organizations:
* Paketo
* Heroku
* Google
* Us (wikimedia cloud services)
Some details:
[[https://gerrit.wikimedia.org/r/plugins/gitiles/cloud/toolforge/buildpacks/+/refs/heads/master | Current house-made buildpacks]]:
* Languages:
** Python
* Build tools:
** pip + uwsgi
* Http Servers:
** uwsgi
* Base OS: Debian
* Community buildpacks: Our own community! :)
* Allows to install packages: limited (not tested), through our [[https://gerrit.wikimedia.org/r/plugins/gitiles/operations/docker-images/toollabs-images/+/refs/heads/master/bullseye0/build/install-packages|own script]]
Upstream **officially supported** buildpacks:
* [[https://paketo.io/|Packeto]]:
** Languages:
*** Go, Java, Node.js, PHP, Python, Ruby, Static files, .Net
** Build tools:
*** Too many combinations, [[ https://github.com/paketo-buildpacks/samples |see this for the whole list]]
** Http servers:
*** Nginx
*** Httpd
*** Your own (through procfile, ex. gunicorn, uwsgi, node, ...)
** Base OS: Ubuntu
** Community buildpacks: They all are, paketo is an Open Source project
** Allows to install packages: no, we have to build our own buildpack (might be able to cross-use the heroku one)
* [[https://devcenter.heroku.com/articles/buildpacks#officially-supported-buildpacks|Heroku]]
** Languages:
*** Clojure, Go, Gradle, Grails, Java, JVM, Node.js, PHP, Python, Ruby, Scala
*** [[ https://elements.heroku.com/buildpacks/heroku/heroku-buildpack-static| Static files are experimental]], using dummy PHP/ruby buildpacks as alternative.
** Build tools:
*** TBD
** Http Servers:
*** Your own (through procfile)
** Base OS: [[https://github.com/heroku/stack-images | Ubuntu]]
** Community buildpacks: [[https://elements.heroku.com/buildpacks|large marketplace]]
** Allows to install packages: yes, through [[https://elements.heroku.com/buildpacks/heroku/heroku-buildpack-apt|custom buildpack]]
* [[https://cloud.google.com/docs/buildpacks/overview|Google Cloud Buildpacks]]
** Languages:
*** Go, Java, Node.js, PHP, Python, Ruby, .Net
** Http Servers:
*** Your own (through procfile)
** Base OS: [[https://cloud.google.com/docs/buildpacks/builders|Ubuntu]]
** Community buildpacks: None (you have to find your own)
** Allows to install packages: no, we have to build our own buildpack (might be able to cross-use the heroku one)
=== Constraints and risks ===
* A first subset of them have to be decided before the beta, with the possibility of expanding them after.
* We have to be able to restrict to some extent the buildpacks allowed so it's not easy to break the terms of usage of toolforge (only open-source software).
* We have to be able to support a set of common language build flows, with best practices and how-to's
* We will probably have to maintain the selected choice for a long time
* We might want to change direction after/during the Beta/Alpha/RC stages
* For the [[https://phabricator.wikimedia.org/T325799|multistack buildpacks]], we might have to maintain our own builder image
== Decision record ==
In progress
https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T330102_What_buildpacks_to_allow_and_include_for_toolforge_build_service_beta
== Options ==
=== Option 1 ===
Use our own builder with a subset of the selected upstream buildpacks, starting with Heroku Python one, decide after which ones to continue supporting.
Pros:
* Upstream maintained buildpacks
* Upstream maintained run and build image
* Shared best practices with upstream platforms
* Users might be familiar with other providers, ease to move between them when needed
* Wide support of languages, build tools, and web servers
* We can limit which buildpacks to put in the builder
* Possibility to add selected non-official buildpacks
Cons:
* Not Debian
* We have to maintain our own builder image
=== Option 2 ===
Use upstream builder with included official buildpacks.
Pros:
* Upstream maintained buildpacks
* Upstream maintained run and build image
* Shared best practices with upstream platforms
* Users might be familiar with other providers, ease to move between them when needed
* Wide support of languages, build tools, and web servers
Cons:
* Not debian
* No control on which buildpacks are included or not
* No possibility to add selected non-official buildpacks
=== Option 3 ===
Support our builder + buildpacks, and upstream builders too
Pros:
* Debian based buildpacks if wanted
* Minimal difference with current code setup (no need to change anything)
* Upstream maintained buildpacks and stacks
* Shared best practices with upstream platforms
* Users might be familiar with other providers, ease to move between them when needed (for the ones that did not use our buildpacks)
* Wide support of languages, build tools, and web servers
Cons:
* Maintain our own buildpacks for each of the langs we want to support
* Maintain our own base run and build images (debian)
* Maintain our own builder image
* No control on which buildpacks are included or not (due to upstream builders)
* No possibility to add selected non-official buildpacks (due to non-compatibility of our build+run image with upstream buildpacks)
=== Option 4 ===
Support our builder + buildpacks, and limited upstream buildpacks
Pros:
* Debian based buildpacks if wanted
* Minimal difference with current code setup (no need to change anything)
* Upstream maintained buildpacks and stacks
* Shared best practices with upstream platforms
* Users might be familiar with other providers, ease to move between them when needed (for the ones that did not use our buildpacks)
* Wide support of languages, build tools, and web servers
* Control on which buildpacks are included or not
* Possibility to add selected non-official buildpacks
Cons:
* Maintain our own buildpacks for each of the langs we want to support
* Maintain our own base run and build images (debian)
* Maintain our own builder image