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_VERSION_NUMBER and RELEASE_TYPE, where 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_VERSION_NUMBER and 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 before_run and 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 RELEASE_VERSION_NUMBER in .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.
An example
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.
