When you push a Git repository, by default, Gemfury will auto-configure and build a package based on the structure of the incoming repository. However, you may want to go a step further and manually configure the build to suit any of the following needs:

• Multiple packages per repository
• Incorrect or failed auto-configuration
• Use a working directory other than root

Auto-detect by default

We are big fans of convention over configuration, so you don’t need to provide a configuration if your repository follows these convetions:

• Package is built from the root directory of the repository
• Only one package configuration is present

In this mode, the builder will take these steps when you trigger a build:

1. Start in the root directory of the repository
2. Iterate through default buildpacks until one passes detection
3. Compile and release using that chosen buildpack

Simple configuration

You can configure your build by placing a .fury.yml file in the root directory of your repository. A simple configuration allows to specify multiple builds via a YAML array of buildpack IDs. For example, the following will create both a npm package and a bower package from one repository:

# Simple .fury.yml example
- bower
- npm

Full configuration

To further customize your build, you can use the extended configuration format:

# Full .fury.yml example
builds:
  - pack: bower
  - pack: npm

This syntax allows more complex build definitions and fine-grained control.

Defining your builds with builds

builds is used to define the configuration of each build. This key is optional and if omitted, Gemfury will fall back on the auto-detect algorithm described above. The value of builds is an array of configuration hashes – one for each build. The following variables are supported in these per-build configurations:

Each build will start with a pristine source directory, so any artifacts created as part of one build process will not be available to a subsequent build.

Restricting triggers with only

only is used to control the triggers for builds based on incoming repository updates. By default, Gemfury has two ways to trigger a build:

• git push to master branch (refs/heads/master)
• fury git:rebuild command from the CLI

In some cases, you might not want to create a build on every git push, but rather restrict build behavior exclusively to tagged commits. In this case, you would use the following configuration:

# Example .fury.yml that only builds tags
only: tags

In this case, the builder will continue observing git push updates only to master branch, however, it will not trigger a build unless the tip of master is also tagged with a Semantic-Version-compatible tag.

The only configuration applies exclusively to git push; builds triggered from the CLI will not be affected.

Example

The following configuration will build all RubyGems in the Ruby on Rails repository only on tagged pushes:

# Example .fury.yml for Ruby on Rails repo
only: tags
builds:
  - dir: actionmailer
    pack: ruby
  - dir: actionpack
    pack: ruby
  - dir: actionview
    pack: ruby
  - dir: activejob
    pack: ruby
  - dir: activemodel
    pack: ruby
  - dir: activerecord
    pack: ruby
  - dir: activesupport
    pack: ruby
  - dir: railties
    pack: ruby
  - dir: /
    pack: ruby

Supported buildpacks

The following buildpacks can be specified via manual configuration: