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

**URL:** <https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447>\
**Category:** Website\
**Created:** [April 12, 2017, 11:33am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447 "2017-04-12T11:33:24Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [April 12, 2017, 11:33am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/1 "2017-04-12T11:33:24Z")

</div>

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](http://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](http://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:

```auto
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](http://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](http://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](http://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](http://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.

---

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [April 12, 2017, 11:38am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/2 "2017-04-12T11:38:59Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [April 12, 2017, 11:51am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/3 "2017-04-12T11:51:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [May 7, 2017, 3:36pm UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/4 "2017-05-07T15:36:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![han.tran](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/han.tran/32/927_2.png) [@han.tran](https://discuss.bitrise.io/u/han.tran)\
**Post date:** [September 20, 2017, 6:21am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/5 "2017-09-20T06:21:58Z")

</div>

Providing a combobox styles would be better.

![12 PM](https://sea2.discourse-cdn.com/flex016/uploads/bitrise/original/1X/eb01c236e359d2c55fc59f423b7d719370349194.png)

---

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [September 21, 2017, 10:44am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/6 "2017-09-21T10:44:17Z")

</div>

> [@han.tran](#):
>
> Providing a combobox styles would be better.

That’s a good idea, but should be a separate #Feature Requests 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 Requests for it! 😉

---

<div class="post-metadata">

**Author:** ![philipbjorge](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/philipbjorge/32/1121_2.png) [@philipbjorge](https://discuss.bitrise.io/u/philipbjorge)\
**Post date:** [January 19, 2018, 9:01am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/7 "2018-01-19T09:01:36Z")

</div>

This is exactly what we want 🙂

---

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [January 19, 2018, 10:25am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/8 "2018-01-19T10:25:01Z")

</div>

@philipbjorge please vote, to bump its priority! 😉

---

<div class="post-metadata">

**Author:** ![Ekalips](https://avatars.discourse-cdn.com/v4/letter/e/3be4f8/32.png) [@Ekalips](https://discuss.bitrise.io/u/Ekalips)\
**Post date:** [December 21, 2018, 2:21pm UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/9 "2018-12-21T14:21:29Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [March 6, 2019, 1:18pm UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/10 "2019-03-06T13:18:42Z")

</div>

I made a revision on the proposed format and example, to include all the requested features from the comments above in this thread.

---

<div class="post-metadata">

**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\
**Post date:** [March 6, 2019, 2:06pm UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/11 "2019-03-06T14:06:35Z")

</div>

Update: in the new proposal there’s a use case which isn’t addressed: how to handle **optional** inputs. We should still list these but not require a value. The original proposal addressed this use case, but that was too redundant:

```auto
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: []

```

---

<div class="post-metadata">

**Author:** ![eugen.cazacu](https://avatars.discourse-cdn.com/v4/letter/e/ed8c4c/32.png) [@eugen.cazacu](https://discuss.bitrise.io/u/eugen.cazacu)\
**Post date:** [August 16, 2022, 11:38am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/12 "2022-08-16T11:38:44Z")

</div>

any news about required user inputs env vars when manually triggering build in UI?

---

<div class="post-metadata">

**Author:** ![bernard.poulin](https://avatars.discourse-cdn.com/v4/letter/b/ebca7d/32.png) [@bernard.poulin](https://discuss.bitrise.io/u/bernard.poulin)\
**Post date:** [October 6, 2023, 5:43pm UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/13 "2023-10-06T17:43:33Z")

</div>

Simply showing the Workflow description in the Build Trigger Popup would go a long way towards the end goal. This is discussed in #4884 but it is marked as “Released”. [Add support for workflow description](https://discuss.bitrise.io/t/add-support-for-workflow-description/4884)

I have people triggering builds manually and they need to know what key/values to enter as Env. variables in the Advanced section. The only piece of info visible I can control is the name of the workflow.

---

<div class="post-metadata">

**Author:** ![MaximGorin](https://avatars.discourse-cdn.com/v4/letter/m/df788c/32.png) [@MaximGorin](https://discuss.bitrise.io/u/MaximGorin)\
**Post date:** [November 13, 2024, 9:25am UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/14 "2024-11-13T09:25:42Z")

</div>

any news? any plans?

---

<div class="post-metadata">

**Author:** ![RaedGhazal.Jodel](https://avatars.discourse-cdn.com/v4/letter/r/d26b3c/32.png) [@RaedGhazal.Jodel](https://discuss.bitrise.io/u/RaedGhazal.Jodel)\
**Post date:** [September 23, 2025, 1:32pm UTC](https://discuss.bitrise.io/t/build-release-templates-specify-inputs-the-user-have-to-provide-before-starting-the-build/1447/15 "2025-09-23T13:32:31Z")

</div>

yeah this would be very helpful, would love to see it implemented
