Build / Release templates - specify inputs the user have to provide before starting the build


#1

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:

template:
  create-release-template:
    workflow: _the-release-workflow
    envs:
    - RELEASE_VERSION_NUMBER:
        opts:
          title: "The version number for the release"
workflows:
  _the-release-workflow:
    steps: []

When this template is activated (create-release-template) you have to provide a version number. If title is specified then that will be printed, otherwise the env var’s key (RELEASE_VERSION_NUMBER).

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-template 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 (_the-release-workflow in the example), just like if you’d have bitrise run THAT-WORKFLOW after specifying the inputs.

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)

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):

  1. 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
  2. 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.


Parameterized builds
Templated manual builds
Templated manual builds
#2

In case of a Bitrise CLI release for example, where we do maintain manual version numbering and write manual changelogs, right now we have to:

  1. Bump the version number manually
  2. Write the changelog
  3. Commit & push
  4. Then once the release binaries are available create the GitHub release and upload there

With Build Templates we could specify the version number and the release notes as required inputs, and automate everything else:

  1. setting the version number
  2. creating the release binaries
  3. saving the changelog
  4. tagging the commit
  5. creating the github release
  6. specifying the changelog there
  7. and uploading the release binaries

The current checklist for a CLI release: https://github.com/bitrise-io/bitrise/pull/485/files

Which could be automated from the “Bump RELEASE_VERSION in bitrise.yml” point, simply by providing a Version Number and a Changelog input through the defined template


#3

Technical notes:

  • The inputs could be defined for the CLI as parameters, in which case the CLI won’t ask for the inputs. E.g. the inputs could be specified before the bitrise run .. in .bitrise.secrets.yml, which will be loaded and processed
  • The CLI should not ask for inputs in CI mode, it should just fail if a required input is not provided
  • Q: what if the input is specified in App Env Vars? Should that be valid, or should the template overwrite those values? Basically, the dynamic inputs provided for the Template should be appended or prepended to the App Env Vars (or to the target workflow’s Workflow Env Vars)?

#4

Separate Templates or build into Workflows?

It might be better to build it into Workflows, with Envs marked as Required.

That way you can compose a workflow chain, each one requiring its own set of params, and the CLI will simply parse through the whole chain.

Envs can have title, summary and description, so all the meta data are there, only a is required flag/handling is missing.


#5

Providing a combobox styles would be better.

12 PM


#6

That’s a good idea, but should be a separate #feature-request as this can also be useful for e.g. Step input fields; as well as this is not specific to release templates (e.g. combo box is not suitable for release notes, only for some input types).

@han.tran feel free to create a #feature-request for it! :wink:


#7

This is exactly what we want :slight_smile:


#8

@philipbjorge please vote, to bump its priority! :wink:


#9

Description of the feature request

Currently there are 2 variants to run the manual build: basic and advanced. Basic will run build with default “settings” and advanced will allow you to customize it and specify some environmental variables.

What is the problem?
Advanced build actually requires you to write both the variable key and it’s value by hand. So you should either remember or write down all things that you might want to change/add.

What is the solution?
Perfect solution will be to create some form of “Template” that will act just like Advanced Manual build view, but all environmental variable keys will be pre-defined and values will be not the text input, but the drop down selector.

Use case / for what or how I would use it

This will shine for building android apps that have many flavors/build types.
So you can just open this “Templated” build window, select desired build type (eg. release or debug) and select desired flavor (eg. demo, free, stage, full, etc). And then values you select will be translated to environmental variables that will be used for building your app.

I already saw solutions for running build for multiple flavors, but it requires creation of several workflows, what is not really efficient when you have 10+ flavors. (or building altogether, what is not efficient either)