4

One of the steps in our deployment process requires a configuration file that we don't want to commit to the repository and rather have it passed in by the Bamboo itself. Is there some sort of task/way to conveniently add it? It can be either a task that creates a file in work directory or assigns the file content to a variable.

What we want to avoid is to have the file on the disk and passing in the path to the file - I'd rather have a way of pasting the file directly into a task.

Currently, the deployment step calls a script that expects the content of said config file to be passed in (shortened for brevity):

deploy.ps1 --settings=<file_content>

edit: The settings file is a lengthy json file, with several arrays on few levels. I've been considering just assigning an inlined content of that file to the environment variable, but I was wondering if there was a better way to pass it as well as allow maintainers edit the values, if necessary.

Splitting the config into several Bamboo environment variables is not really feasable, especially since one of our use cases requires the ability to run the deployment script without Bamboo, in case of server failure, for example.

5

It is convenient to use Environment Variables to provide runtime configuration for such scripts. Especially when it contains secrets that you don't want to hold in any persistent storage or in version control.

When you do actually have secrets, it is even better to use some kind of secret management system that will provide these secrets on request. One such tool that I highly recommend is HashiCorp's Vault.

Depending on how you are executing the jobs on the Bamboo Server, another option might be to store a local file on the server and reference that during builds. This is not really recommended since the server then becomes a special snowflake that only a few people know how to actually set up. It is much better to allow malfunctions with the server, or even the loss of all server data, to not affect your ability to deploy code. Thus having special files on the server itself is not so great.

  • I want to avoid storing the config file on disk for the very reason you stated. I've been using Environment Variables in the past, but that specific deployment project takes in quite a big json file with different settings, mostly secrets. I was considering just outputting the the configuration in an inline json format and assigning it to an Environment Variable, but that gets quite messy to edit.. – DemoBytom Jan 8 '18 at 20:58
  • HashiCorp Vault to the rescue! – Evgeny Jan 8 '18 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.