You could be able to specify “build templates” in the
bitrise.yml, and then “build a template” both with CLI in local and on bitrise.io
“Build a template” would look like this: the inputs defined in the template have to be provided manually (in the CLI it’d ask for those in the Terminal/Command Line, on bitrise.io it’d present a popup with the inputs) then the build would run exactly the same as a normal build.
An example for a very minimal version number based release:
workflows: create-release: envs: - RELEASE_VERSION_NUMBER: opts: is_required: true title: "The version number for the release" steps:  publish-release: before_run: - create-release envs: - RELEASE_TYPE: opts: is_required: true title: "Type of release" value_options: - internal - external steps: 
If you’d run the
create-release workflow you’d have to provide the
RELEASE_VERSION_NUMBER input (via the UI on bitrise.io and via interactive input in the CLI), while if you’d run
publish-release you’d have to provide both
RELEASE_TYPE would be a dropdown on the UI (the same how
value_options are treated in Step inputs). If
title is specified then that will be printed, otherwise the env var’s key (
RELEASE_TYPE in the example) will be printed.
Basically when triggering a workflow the system would go through the whole workflow-graph, collecting all
is_required env vars from the specified workflow and every other workflow referenced via
after_run (recursive) workflow chaining.
The input provided will be handled the exact same way if you’d specify this input (env var) in the App Env Vars, so it’ll be 100% compatible with the current tooling/steps/mechanisms.
So, if you have this template and you want to create a release, you’d simply
bitrise run create-release or on bitrise.io select the template in the “Build Now” popup, fill out the required inputs (in this case “The version number for the release”) and then it’ll start a build with the specified workflow (
create-release in the example), just like if you’d do
/usr/bin/env RELEASE_VERSION_NUMBER="x.x.x" bitrise run create-release or specifying
.bitrise.secrets.yml and then
bitrise run create-release.
Important technical note: recognize inputs provided via Secrets!
What’s the purpose?
- A formalized dynamic input handling mechanism, both in the CLI and on bitrise.io, with validation that all required inputs are provided.
- To make it easy to define e.g. Release workflows which do require manual input (e.g. a version number and a release notes inputs).
- To be able to list required inputs of workflows and those be tested by the CLI instead of writing Script steps to validate that all required inputs were provided.
You can define a workflow on bitrise.io / in
bitrise.yml right now that can auto create everything for a release, but today you have two options to provide manual inputs (like a release note):
- Either require those inputs, doing custom checks with Script steps or similar, until the user provides it through e.g. bitrise secrets or as custom build env vars
- You bump the version number and write the changelog manually, and only after that you start a build which uses those
With “Build Templates” you could simply specify the required inputs, and a workflow which can do the release automatically for you. E.g. it’ll write the version number into a file in your project, and prepend your CHANGELOG file with the specified changelog text, then proceed with creating the release and publishing it.