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:
- Start in the root directory of the repository
- Iterate through default buildpacks until one passes detection
- 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:
Variable | Description | Default |
---|---|---|
dir | Working directory | / |
pack | Buildpack ID | auto |
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:
Pack-ID | Output | Default |
---|---|---|
auto | First auto-detected type | ✓ |
ruby | RubyGem | |
npm | npm package | |
php | PHP Composer package | |
python | Python source build | |
bower | Bower package |