Build flags

Fire CI allows to define a lot of useful options on your build on top of the commands to be run. You can define how to auto merge code, which branches and events to run your builds on, and so on.

Here is a fully feature .fire.yml with all the available options and the associated comments.

version: 2

build_options:

  # Specify the branches the builds need to be triggered for. If this is specified any branch
  # that is not on the list will be ignored. In case of pull requests, the builds will be
  # executed only if the PR target branch is on the list.
  branches_whitelist:
    - develop
    - test

  # Exclude branches from being built. This is not needed if you have specified branches_whitelist.
  # In case of pull requests, the builds will be executed if the PR target branch is on the list
  # but the build resulting from the merge will not be executed. Usually this is where your 
  # continuous delivery or deployment tool should kick in and take over.
  branches_blacklist:
    - master

  # Turn this option to true if your repository is using git submodules. The initialization
  # of submodules will be executed right after cloning the repository, and after merging
  # to the main branch of the repository (or target branch of the PR if the build is from a PR).
  init_git_submodules: false

  # By default logs from your builds are stored in the cloud so you can download or view them
  # easily online. To share with your team mainly. We use AWS S3 as an online storage. If you
  # don't feel comfortable uploading logs to S3 you can turn this flag to true to prevent the
  # logs upload. In the case of GitHub builds the logs are still uploaded to GitHub via their
  # API. For Bitbucket builds it means your build logs will only be available locally in your
  # agent.
  disable_logs_cloud_storage: false

pipeline:
  ...

That's it. Everything is in the example above.

If you have questions or think of something that we need to support do not hesitate to contact us at support@fire.ci


Environment variables

There are things you might want to keep out of your repository like passwords or environment specific data. Fire CI provides an environment variables vault to store sensitive and environment specific varaibles.

In your dashboard there is a little gear icon next to each repository. Once in you can edit key/value pairs that will be exposed as environment variables to your builds in your Docker and Docker compose files.

Here is how to use environment variables in Docker compose and in Dockerfiles (section 'Environment replacement' on the page).


What next?

See how to configure your pipeline:


If you have questions or ideas do not hesitate to contact us at support@fire.ci.