This week in new features - Build-time variables

As we wrote about recently, all of the inputs to an application running on Platform.sh are clearly defined, predictable, and with one exception entirely under your control as a user. We’re happy to announce that we’ve added one more input, and it’s also under user control: Project-level variables available at build time.

Project variables are, as the name implies, just like the other variables we already support but bound to a project rather than to a specific environment. That is, they become available for all environments in a project unconditionally rather than just selected environments/branches. If a given environment has a variable of the same name it will override the project variable, but otherwise a project-level variable will be available to all environments.

“So what?” you may say. Variables defined on the master environment already inherit that way, so what’s the big deal? The big deal is that project variables are available at build time, too.

Environment variables are only available on a running container. That is, they’re available to the running application and can be used in a deploy hook, but not in a build hook. Project variables, by contrast, are also available during a build hook.

Why would you want build-time variables? Shouldn’t the build be controlled entirely by what’s in Git? Generally speaking yes, but just as you may need runtime values that are not stored in Git, such as API keys, you may need secret values for the build process, too. The most common use for that is for downloading non-public 3rd party dependencies. In other words, and at the risk of burying the lead:

We now support private Composer repositories on Platform.sh

That includes the newly-announced Private Packagist.

We’ve written up a tutorial to show how to use a private Composer repository. Give it a try.

There are of course plenty of other things you can do with build-time variables. Let us know what else you are able to do with them.