diff --git a/docs/bitrise-ci/workflows-and-pipelines/ai-configuration-assistant.mdx b/docs/bitrise-ci/workflows-and-pipelines/ai-configuration-assistant.mdx index 468e9305..590498b6 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/ai-configuration-assistant.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/ai-configuration-assistant.mdx @@ -7,6 +7,7 @@ sidebar_position: 5 import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; import GlossTerm from '@site/src/components/GlossTerm'; +import Partial_OpeningTheWorkspaceSettingsPage from '@site/src/partials/opening-the-workspace-settings-page.mdx'; Bitrise offers hundreds of integrations for all CI/CD purposes, allowing complex workflows. It takes time to become familiar with our Steps, our stacks, or the intricacies of configuration YAML - time that you could spend developing your app. To speed up the process, we introduced the AI configuration assistant. @@ -15,6 +16,31 @@ The AI config assistant is a chat-based assistant built into the Bitrise +1. Select **AI settings**. +1. Enable the **Enable AI features** toggle. This turns on Bitrise AI for the workspace. Individual AI features still need to be enabled separately in each project's settings. + + ![Workspace settings — AI settings page with the Enable AI features toggle](/img/workflows-and-pipelines/2026-07-03-workspace-settings-ai-settings.png) + +1. Open your project on the Bitrise CI page and click **Project settings**. +1. Select **Bitrise AI** in the left navigation. +1. Under **Workflows and pipelines**, enable the **Configuration generator** toggle. + + ![Project settings — Bitrise AI page with the Configuration generator toggle enabled](/img/workflows-and-pipelines/2026-07-03-project-settings-bitrise-ai-configuration-generator.png) + +:::note[AI credits] + +AI features consume monthly AI credits. The number of credits available depends on your plan. You can check your remaining credits on the **Bitrise AI** page in Project settings. + +::: + +Once both toggles are enabled, the AI configuration assistant is available in the Workflow Editor. + + ## Explaining a Workflow or a Pipeline You can get the AI assistant to explain how any part of your Bitrise configuration works and it can suggest improvements to existing Workflows and Pipelines. @@ -31,6 +57,13 @@ Use the Bitrise AI configuration assistant to create a fully validated, working 1. Open the Workflow Editor. 1. On the top bar, click **Ask AI**. 1. In the **Assistant** window, select **Create a new Workflow**. + + :::note + + You can also open the Workflow selector dropdown and click **Create Workflow with AI** at the bottom of the list. + + ::: + 1. Add your prompt in the input field. Use plain language to explain what you need the Workflow or Pipeline to do. You don't have to use Step names or Bitrise-specific terms. The more detailed your prompt is, the better the AI output. diff --git a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/build-pipelines-faq.md b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/build-pipelines-faq.md index fe786c08..561bfac7 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/build-pipelines-faq.md +++ b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/build-pipelines-faq.md @@ -20,7 +20,7 @@ You can keep using project-level and Workflow-level [Environment Variables](/en/ **Can I rerun a failed Pipeline?** -Yes. Go to the **Pipeline details** page, and click the **Rerun** button. From there you have the option to rerun failed and subsequent Workflows or to rerun the entire Pipeline. +Yes. Go to the **Pipeline details** page, and click the **Rebuild** button. From there you have the option to rebuild unsuccessful Workflows or to rebuild the entire Pipeline. Both options are also available with remote access. **Does the Rolling Builds feature work on Pipelines?** diff --git a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/configuring-a-bitrise-pipeline.mdx b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/configuring-a-bitrise-pipeline.mdx index cb482af9..12e3b704 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/configuring-a-bitrise-pipeline.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/configuring-a-bitrise-pipeline.mdx @@ -412,7 +412,7 @@ To set up the configuration: :::important[Value limitations] - The value has to be a fixed number. You can only use integers. The maximum accepted value is 50. You can use an Environment Variable as the value. + The value has to be a fixed number. You can only use integers. The maximum accepted value is 200. You can use an Environment Variable as the value. You can use an Environment Variable as the value: it allows you to dynamically calculate the optimal number of parallel copies during the build. diff --git a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/converting-a-pipeline-with-stages-into-a-graph-pipeline.md b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/converting-a-pipeline-with-stages-into-a-graph-pipeline.md index a9ece137..85d6702c 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/converting-a-pipeline-with-stages-into-a-graph-pipeline.md +++ b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/converting-a-pipeline-with-stages-into-a-graph-pipeline.md @@ -5,29 +5,31 @@ sidebar_position: 7 slug: /bitrise-ci/workflows-and-pipelines/build-pipelines/converting-a-pipeline-with-stages-into-a-graph-pipeline --- -You can convert your old, existing Pipelines that contain stages into graph Pipelines without stages. This unlocks the full benefits of using Pipelines: faster build times, more granular configuration, and a full editing capability in the GUI of the Workflow Editor. +You can convert your old, existing Pipelines that contain stages into graph Pipelines without stages. This unlocks the full benefits of using Pipelines: faster build times, more granular configuration, and a full editing capability in the Workflow Editor. -To convert a Pipeline, you need to create a new Pipeline based on an old Pipeline. The old Pipeline won't be removed and it will still work if you need it so your builds will not break. You can switch to using the new Pipeline when all your configurations are ready for it. +Pipelines with stages are read-only in the Workflow Editor. To edit them, you need to convert them first. The original Pipeline won't be removed and will still work after the conversion, so your builds won't break. You can switch to using the new Pipeline when all your configurations are ready. :::note -Be aware that all new Pipeline features and improvements will only be available for graph Pipelines. Pipelines with stages will have no further features added. +All new Pipeline features and improvements will only be available for graph Pipelines. Pipelines with stages will have no further features added. ::: -To convert a Pipeline +To convert a Pipeline: -1. Open the Workflow Editor. -1. Open the dropdown menu at the top. -1. Click **Create Pipeline**. -1. Name your new Pipeline. -1. In the **Based on** dropdown menu, select a Pipeline that contains stages. -1. Click **Save changes**. +1. Open the Workflow Editor and select the Pipeline you want to convert. +1. Click **Convert Pipeline** in the banner at the top of the canvas. + + ![Convert Pipeline banner](/img/workflows-and-pipelines/2026-07-06-convert-pipeline-banner.png) + + Bitrise creates a converted copy named `_converted` and selects it automatically. + +1. Review and adjust the converted Pipeline as needed. :::important[No cycles allowed] - If your Pipeline conversion creates a cycle in the graph, you won't be able to save the Pipeline. You have to manually edit the configuration to remove the cycle, as they aren't allowed. + If your Pipeline conversion creates a cycle in the graph, you won't be able to save the Pipeline. You have to manually edit the configuration to remove the cycle. ::: -That's it: the new Pipeline will no longer have stages but will contain the same Workflows as the old one. +1. Click **Save changes** in the top right corner. diff --git a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipeline-builds.md b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipeline-builds.md index 4f5b084a..63df6af9 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipeline-builds.md +++ b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipeline-builds.md @@ -9,7 +9,7 @@ You can run Pipeline builds the same way you would run builds of standalone Work - [You can start Pipeline builds manually](/en/bitrise-ci/run-and-analyze-builds/starting-builds/starting-builds-manually). - [Schedule Pipeline builds](/en/bitrise-ci/run-and-analyze-builds/starting-builds/scheduling-builds). -- [Trigger Pipeline builds automatically](/en/bitrise-ci/run-and-analyze-builds/build-triggers/configuring-build-triggers). For now, Pipeline triggers must be configured in YAML, however: [YAML syntax for build triggers](/en/bitrise-ci/run-and-analyze-builds/build-triggers/yaml-syntax-for-build-triggers). +- [Trigger Pipeline builds automatically](/en/bitrise-ci/run-and-analyze-builds/build-triggers/configuring-build-triggers). You can configure Pipeline triggers in the Workflow Editor or in YAML: [YAML syntax for build triggers](/en/bitrise-ci/run-and-analyze-builds/build-triggers/yaml-syntax-for-build-triggers). Pipeline builds are capable of sending build status reports: a Pipeline build will send a status report of the Pipeline itself and of any Steps that export test results: [Reporting the build status to your Git hosting provider](/en/bitrise-ci/configure-builds/configuring-build-settings/reporting-the-build-status-to-your-git-hosting-provider). diff --git a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-android-platform.mdx b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-android-platform.mdx index 183ac26c..06ceaa8f 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-android-platform.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-android-platform.mdx @@ -36,7 +36,7 @@ To test this configuration in a new Bitrise example project, do the following: 1. Enter `debug` as the specified variant. 1. Continue through the prompts as normal — no changes are needed. 1. Open the new Bitrise project’s Workflow Editor. -1. Go to the **bitrise.yml** tab, and replace the existing yaml contents with the contents of the example `[bitrise.yml](https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-ui-tests-on-multiple-devices.md#bitriseyml)`. +1. Switch to **YAML** at the top of the Workflow Editor, and replace the existing yaml contents with the contents of the example `[bitrise.yml](https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-ui-tests-on-multiple-devices.md#bitriseyml)`. 1. Click the **Start/Schedule a Build** button, and select the `ui_test_on_multiple_devices` option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. ### bitrise.yml @@ -68,7 +68,7 @@ This Pipeline contains one Stage — `stage_unit_and_ui_test` — that executes 1. Enter `debug` as the specified variant. 1. Continue through the prompts as normal — no changes are needed. 1. Open the new Bitrise project’s Workflow Editor. -1. Go to the **bitrise.yml** tab, and replace the existing yaml contents with the contents of the example `[bitrise.yml](https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-unit-and-ui-tests.md#bitriseyml)`. +1. Switch to **YAML** at the top of the Workflow Editor, and replace the existing yaml contents with the contents of the example `[bitrise.yml](https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-unit-and-ui-tests.md#bitriseyml)`. 1. Click the **Start/Schedule a Build** button, and select the `pipeline_unit_and_ui_test` option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. ### bitrise.yml @@ -100,7 +100,7 @@ This Pipeline contains one Stage — stage_unit_test — that executes two Workf 1. Enter `debug` as the specified variant. 1. Continue through the prompts as normal — no changes are needed. 1. Open the new Bitrise project’s Workflow Editor. -1. Go to the **bitrise.yml** tab, and replace the existing yaml contents with the contents of the example `[bitrise.yml](https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-testing-unit-test-shards.md#bitriseyml)`. +1. Switch to **YAML** at the top of the Workflow Editor, and replace the existing yaml contents with the contents of the example `[bitrise.yml](https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-testing-unit-test-shards.md#bitriseyml)`. 1. Click the **Start/Schedule a Build** button, and select the `pipeline_unit_test` option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. ### bitrise.yml diff --git a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-ios-platform.mdx b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-ios-platform.mdx index 1278950f..182314ee 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-ios-platform.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/build-pipelines/pipelines-with-stages/currently-supported-use-cases-for-the-ios-platform.mdx @@ -33,7 +33,7 @@ The example Pipeline config showcases how to run all the test cases of the proje There is no limitation on the number of files deployed to **Artifacts** per build. There is a limitation, however, on the file size which is 2GB per file. ::: -1. `run_tests_on_simulators` Stage runs three Workflows in parallel: `run_tests_iPad`, `run_tests_iPhone`, and `run_tests_iPod`. Both of these Workflows use the new `xcode-test-without-building` Step, which executes the tests based on the previous stage built test bundle. The pre-built test bundle is pulled by the `_pull_test_bundle`utility Workflow. +1. `run_tests_on_simulators` Stage runs three Workflows in parallel: `run_tests_iPad`, `run_tests_iPhone`, and `run_tests_iPod`. All three of these Workflows use the new `xcode-test-without-building` Step, which executes the tests based on the previous stage built test bundle. The pre-built test bundle is pulled by the `_pull_test_bundle`utility Workflow. ![iOS_example_modified.png](/img/_paligo/uuid-5b325bb0-a98a-bd3d-943f-c7d26897e362.png) @@ -74,7 +74,7 @@ The example Pipeline config showcases how to run different test groups in parall `run_tests_groups` Pipeline runs two Stages sequentially: 1. `build_tests` Stage that runs the `build_tests` Workflow. This Workflow git clones the sample project and runs the `xcode-build-for-test` Step to build the target and associated tests. The built test bundle is transferred to the next Stage (`run_tests_groups`) via the `deploy-to-bitrise-io` Step. -1. `run_tests_groups` Stage runs two Workflows in parallel: `run_ui_tests` and `run_unit_tests`. Both of these Workflows use the new x`code-test-without-building` Step, which executes the tests based on the previous Stage built test bundle. The pre-built test bundle is pulled by the `_pull_test_bundle` utility Workflow. +1. `run_tests_groups` Stage runs two Workflows in parallel: `run_ui_tests` and `run_unit_tests`. Both of these Workflows use the new `xcode-test-without-building` Step, which executes the tests based on the previous Stage built test bundle. The pre-built test bundle is pulled by the `_pull_test_bundle` utility Workflow. ![iOS_example_2.png](/img/_paligo/uuid-789ed335-aeab-b87c-6045-270c5e87a641.png) diff --git a/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/creating-your-own-bitrise-project-scanner.mdx b/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/creating-your-own-bitrise-project-scanner.mdx index aab5e683..7294e21b 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/creating-your-own-bitrise-project-scanner.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/creating-your-own-bitrise-project-scanner.mdx @@ -22,7 +22,7 @@ Build Steps and test Steps have specific requirements: ::: -When adding a new project on the website or initializing a project on your own machine, the [bitrise-init](https://github.com/bitrise-core/bitrise-init) tool iterates through every scanner, calls the scanner interface methods on each of them and collects their outputs. Based on these outputs, a basic configuration is generated. +When adding a new project on the website or initializing a project on your own machine, the [bitrise-init](https://github.com/bitrise-io/bitrise-init) tool iterates through every scanner, calls the scanner interface methods on each of them and collects their outputs. Based on these outputs, a basic configuration is generated. The possible Workflows are described in a scan result model. The model consists of: @@ -34,8 +34,8 @@ Here is the basic structure of the model, in YAML: ```yaml options: - DETECTED_PLATFORM_1: OptionModel - DETECTED_PLATFORM_2: OptionModel + DETECTED_PLATFORM_1: OptionNode + DETECTED_PLATFORM_2: OptionNode ... configs: @@ -80,20 +80,25 @@ Selecting an option can start a chain: it can lead to different options being pr ### The option model -The `OptionModel` represents an input option. It looks like this in Go: +The `OptionNode` represents an input option. It looks like this in Go: ```go -// OptionModel ... -type OptionModel struct { - Title string - EnvKey string +// OptionNode ... +type OptionNode struct { + Title string + Summary string + EnvKey string - ChildOptionMap map[string]*OptionModel - Config string + ChildOptionMap map[string]*OptionNode + + Icons []string + Components []string + Head *OptionNode } ``` - Title: the human readable name of the input. +- Summary: a short description of the option. - EnvKey: it represents the input’s key in the step model. - ChildOptionMap: the map of the subsequent options if the user chooses a given value for the option. @@ -167,7 +172,7 @@ An options chain’s last `options` cannot have a value_map. ## Scanners -Scanners generate the possible `options` chains and the possible workflows for the `options` per project type. The `ActiveScanner` variable holds each scanner implementation. Every specific scanner implements the `ScannerInterface`. +Scanners generate the possible `options` chains and the possible workflows for the `options` per project type. Scanners are returned by the `ProjectScanners()` and `AutomationToolScanners()` functions. Every specific scanner implements the `ScannerInterface`. ```go // ScannerInterface ... @@ -175,10 +180,10 @@ type ScannerInterface interface { Name() string DetectPlatform(string) (bool, error) - Options() (models.OptionModel, models.Warnings, error) - Configs() (models.BitriseConfigMap, error) + Options() (models.OptionNode, models.Warnings, models.Icons, error) + Configs(sshKeyActivation models.SSHKeyActivation) (models.BitriseConfigMap, error) - DefaultOptions() models.OptionModel + DefaultOptions() models.OptionNode DefaultConfigs() (models.BitriseConfigMap, error) ExcludedScannerNames() []string @@ -187,9 +192,9 @@ type ScannerInterface interface { - `Name() string`: This method is used for logging and storing the scanner output (warnings, options and configs). The scanner output is stored in `map[SCANNER_NAME]OUTPUT`. For example, the `options` for an iOS project is stored in `optionsMap[ios]options`. - `DetectPlatform(string) (bool, error)`: This method is used to determine if the given search directory contains the project type or not. -- `Options() (models.OptionModel, models.Warnings, error)`: This method is used to generate option branches for the project. Each branch should define a complete and valid option set to build the final bitrise config model. Every option branch’s last `Options` has to store a configuration id, which will be filled with the selected options. -- `Configs() (models.BitriseConfigMap, error)`: This method is used to generate the possible configs. BitriseConfigMap’s each element is a bitrise config template which will be fulfilled with the user selected option values. -- `DefaultOptions() models.OptionModel and DefaultConfigs() (models.BitriseConfigMap, error)` : These methods are used to generate the options and configs without scanning the given project. In this case every required step input value is provided by the user. This way even if a scanner fails, the user has an option to get started. +- `Options() (models.OptionNode, models.Warnings, models.Icons, error)`: This method is used to generate option branches for the project. Each branch should define a complete and valid option set to build the final bitrise config model. Every option branch’s last `Options` has to store a configuration id, which will be filled with the selected options. +- `Configs(sshKeyActivation models.SSHKeyActivation) (models.BitriseConfigMap, error)`: This method is used to generate the possible configs. BitriseConfigMap’s each element is a bitrise config template which will be fulfilled with the user selected option values. +- `DefaultOptions() models.OptionNode` and `DefaultConfigs() (models.BitriseConfigMap, error)`: These methods are used to generate the options and configs without scanning the given project. In this case every required step input value is provided by the user. This way even if a scanner fails, the user has an option to get started. ### Testing a scanner diff --git a/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/developing-a-new-step.mdx b/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/developing-a-new-step.mdx index ae28388a..797abe2b 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/developing-a-new-step.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/developing-a-new-step.mdx @@ -41,7 +41,7 @@ Before creating a new Step, you will need to install the Bitrise CLI, set it up, 1. Install the Step plugin with the following command: ```bash - bitrise plugin install step + bitrise plugin install --source https://github.com/bitrise-io/bitrise-plugins-step.git ``` @@ -168,6 +168,8 @@ The available values are: - `cordova` - `ionic` - `flutter` +- `web` +- `kotlin-multiplatform` ### Category @@ -196,10 +198,10 @@ Step inputs are Bitrise [Environment Variables](/en/bitrise-ci/configure-builds/ title: Git Clone Repository summary: Clone a repository to the specified path on the VM inputs: -- branch: master +- branch: $BITRISE_GIT_BRANCH ``` -The value of this input - master in the above example - is used to determine which branch of the repository will be cloned. +The value of this input — `$BITRISE_GIT_BRANCH` in the above example — is used to determine which branch of the repository will be cloned. Step inputs are visible on the Workflow Editor: they are presented in the order as they appear in the `step.yml`. As such, required and frequently used inputs should be at the top. @@ -383,7 +385,7 @@ first value\n \nsecond value ## Step outputs -Steps can generate outputs which can then be used in other Steps as inputs. That means that if a Step generates an artifact, the path to that artifact can be the input of another Step in the build. For example, the **Xcode Archive & Export for iOS** Step exposes the $BITRISE_API_PATH output which can then be used as an input value for the **Deploy to iTunesConnect** Step. +Steps can generate outputs which can then be used in other Steps as inputs. That means that if a Step generates an artifact, the path to that artifact can be the input of another Step in the build. For example, the **Xcode Archive & Export for iOS** Step exposes the $BITRISE_IPA_PATH output which can then be used as an input value for the **Deploy to Bitrise.io** Step. Outputs are also defined in the `step.yml` file, under the outputs property. They have the same structure as inputs: they consist of a key and value pair. An output’s key can be used as an input value in a subsequent Step, just as Environment Variables exposed by [bitrise.io](http://bitrise.io) or the Bitrise CLI can be. diff --git a/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/sharing-steps-with-all-bitrise-users.mdx b/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/sharing-steps-with-all-bitrise-users.mdx index 6dfa8737..83a6f849 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/sharing-steps-with-all-bitrise-users.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/sharing-steps-with-all-bitrise-users.mdx @@ -87,7 +87,12 @@ The share-this-step Workflow is included in the Step in any given Workflow, and you can also set conditions for Steps. You can do it either on your own computer, with the Bitrise CLI or by using the **bitrise.yml** tab of the Workflow Editor. +You can enable or disable a Step in any given Workflow, and you can also set conditions for Steps. You can do it either on your own computer with the Bitrise CLI, or by using the YAML editor in the Workflow Editor. We mostly use `run_if` expressions to do these things. Check out the examples for possible template expressions: [Examples of run_if expressions](#examples-of-run_if-expressions). @@ -58,7 +58,7 @@ To experiment with different configurations for a Workflow, without removing or -1. Open your app’s `bitrise.yml` file. +1. Open your project’s configuration YAML file. 1. Find the Step that you want to disable. 1. Add `run_if: false` to it. @@ -101,7 +101,7 @@ CI mode can be enabled on your own Mac/PC by setting the `CI` environment to `tr -1. Open your app’s `bitrise.yml` file. +1. Open your project’s configuration YAML file. 1. Find the Step you need. 1. Add `run_if: .IsCI` to its properties: @@ -133,7 +133,7 @@ It is possible to run a Step ONLY if the build failed before it got to that part -1. Open your app’s `bitrise.yml` file. +1. Open your project’s configuration YAML file. 1. Find the Step that you want to disable. 1. Add `run_if: .IsBuildFailed` to it. 1. Add `is_always_run: true` to it. @@ -156,13 +156,17 @@ It is possible to run a Step ONLY if the build failed before it got to that part ## Ignoring a failed Step without failing the build -Usually, when a Step fails during a build, the built itself fails, too. This isn't the case with every Step, of course: both the **Bitrise.io Cache:Pull** and the **Bitrise.io Cache:Push** Steps can fail without failing the build. You can also configure any other Step to ensure their failure doesn't fail the build. +Usually, when a Step fails during a build, the build itself fails, too. Cache, notification, and status reporting Steps (for example, **Save Cache** and **Slack**) are often configured by default to allow the build to continue even if they fail. You can also configure any other Step to ensure their failure doesn't fail the build. -:::note[YAML mode only] + + -You can't do this on the graphical UI of the Workflow Editor: you have to edit your app's `bitrise.yml` file. +1. +1. Click the Step you want to configure. +1. Under **When to run**, enable the **Continue build even if this Step fails** toggle. -::: + + 1. 1. Switch to **YAML** at the top of the Workflow Editor. @@ -170,17 +174,20 @@ You can't do this on the graphical UI of the Workflow Editor: you have to edit y 1. Add the `is_skippable` flag to it and set it to `true`: ```yaml - - script: - is_skippable: true - inputs: - - content: |- - # !/bin/bash - echo "Failing Step." - exit 1 - # exit 1 would mark this step as Failed, but it won't break the Build + - script: + is_skippable: true + inputs: + - content: |- + #!/bin/bash + echo "Failing Step." + exit 1 + # exit 1 would mark this step as Failed, but it won't break the Build # because of the is_skippable: true flag / property ``` + + + ## Setting up run_if conditions with Script Steps diff --git a/docs/bitrise-ci/workflows-and-pipelines/steps/setting-a-time-limit-for-steps.mdx b/docs/bitrise-ci/workflows-and-pipelines/steps/setting-a-time-limit-for-steps.mdx index 0a73e12d..548f0930 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/steps/setting-a-time-limit-for-steps.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/steps/setting-a-time-limit-for-steps.mdx @@ -1,6 +1,6 @@ --- title: "Setting a time limit for Steps" -description: "A Step timeout, defined in seconds, sets a maximum time a Step is allowed to run. If the Step exceeds that limit, the Workflow moves on to the next Step." +description: "A Step timeout, defined in seconds, sets a maximum time a Step is allowed to run. If the Step exceeds that limit, it is marked as failed and the build fails." sidebar_position: 9 slug: /bitrise-ci/workflows-and-pipelines/steps/setting-a-time-limit-for-steps --- @@ -11,11 +11,11 @@ import GlossTerm from '@site/src/components/GlossTerm'; Ensure that your builds do not exceed the time limit by setting up Step timeout for Steps that might cause builds to hang. -A Step timeout, defined in seconds, sets a maximum time a Step is allowed to run. If the Step exceeds that limit, the Workflow moves on to the next Step. This is useful if, for example, your builds hang for not immediately obvious reasons - you can set timeouts for the Step or Steps which are suspected to have caused the problem. +A Step timeout, defined in seconds, sets a maximum time a Step is allowed to run. If the Step exceeds that limit, it is marked as failed and the build fails. Steps with **Run even if previous Step(s) failed** enabled will still run. This is useful if, for example, your builds hang for not immediately obvious reasons — you can set timeouts for the Step or Steps which are suspected to have caused the problem. 1. Find the Step in the `bitrise.yml` file. - You can edit the file locally, or on the **bitrise.yml** tab of the Workflow Editor. + You can edit the file locally, or in the YAML editor in the Workflow Editor. 1. Add a `timeout` property before the other Step inputs and specify its value in seconds: ```yaml diff --git a/docs/bitrise-ci/workflows-and-pipelines/steps/skipping-steps.mdx b/docs/bitrise-ci/workflows-and-pipelines/steps/skipping-steps.mdx index 2fa54c7c..4ea54688 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/steps/skipping-steps.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/steps/skipping-steps.mdx @@ -23,6 +23,6 @@ To set a given Step to run even if a previous Step failed: 1. 1. Select the Step you want to configure to always run. -1. On the right, find and open the **When to run** section and toggle the **Run if previous Step failed** option. +1. On the right, find and open the **When to run** section and toggle the **Run even if previous Step(s) failed** option. ![run-if-previous-failed.png](/img/_paligo/uuid-26832e7b-a5be-8098-d683-cd04a9d2cc04.png) diff --git a/docs/bitrise-ci/workflows-and-pipelines/steps/step-bundles.mdx b/docs/bitrise-ci/workflows-and-pipelines/steps/step-bundles.mdx index e7819353..9c9c7678 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/steps/step-bundles.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/steps/step-bundles.mdx @@ -27,9 +27,9 @@ When running a build, each Step within the bundle will run at the position the b If you already have at least one Step bundle, open the dropdown menu in the middle and click **Create Step bundle**. ![create-step-bundle.png](/img/_paligo/uuid-955d7e00-c03b-fa26-f239-dcf2f2b2708a.png) -1. In the dialog, provide a name for your bundle. +1. In the dialog, provide an ID for your bundle. - ![create-bundle-dialog.png](/img/_paligo/uuid-35da65f6-1384-de64-328a-42f8232d2574.png) + ![Create Step bundle dialog](/img/workflows-and-pipelines/2026-07-06-create-step-bundle-dialog.png) 1. If you have existing Step bundles, you can select one from the dropdown menu: your new Step bundle will be a copy of the existing one. 1. When done, click **Create Step bundle**. 1. Add your first Step by clicking **Add Step or Step bundle**. @@ -306,7 +306,7 @@ workflows: ``` 1. Open your project's Workflow Editor. -1. Click **Step Bundles** on the left. +1. Click **Step bundles** on the left. 1. Select the **Configuration** tab and enter a value under **Additional run conditions**. ![2025_08_15_step_bundle_conditional_execution_runif.png](/img/_paligo/uuid-d84d9f1d-68d7-2706-a7cb-b2023ffe96a5.png) diff --git a/docs/bitrise-ci/workflows-and-pipelines/steps/step-inputs.mdx b/docs/bitrise-ci/workflows-and-pipelines/steps/step-inputs.mdx index d0108ceb..63cec21c 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/steps/step-inputs.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/steps/step-inputs.mdx @@ -13,11 +13,11 @@ import GlossTerm from '@site/src/components/GlossTerm'; Click on a Step to bring up its input variables on the right of the currently selected Workflow. Required inputs are marked as such in the Workflow Editor. If required inputs do not have valid values, the Step will fail. -![Adding_step_input.png](/img/_paligo/uuid-c09d6420-4a98-85f8-8bdc-c96e59c07779.png) +![Step input fields with Insert variable button](/img/workflows-and-pipelines/2026-07-06-step-input-insert-variable.png) Modify a Step input by either: - Clicking into the input field. -- Clicking the **CHANGE** option next to the input field. +- Clicking the **Insert variable** button next to the input field to insert an Environment Variable as the value. You can also use [Environment Variables (Env Vars) as Step inputs.](/en/bitrise-ci/configure-builds/environment-variables#using-an-env-var-in-a-step-input) diff --git a/docs/bitrise-ci/workflows-and-pipelines/steps/step-versions.mdx b/docs/bitrise-ci/workflows-and-pipelines/steps/step-versions.mdx index 4ff30442..5e7a0587 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/steps/step-versions.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/steps/step-versions.mdx @@ -38,14 +38,14 @@ Now let’s say the Example Step gets a new major version: 3.0.0! In that case, the Step will not be automatically updated either way. If you want to use the new version, you need to lock the Step to either major version 3.x.x or minor version 3.0.x. This way you can be sure that a new update will not break your builds. -To lock a Step to a major or minor version: +To set the update policy for a Step: 1. 1. Select the Step. 1. Go to the **Properties** tab. -1. Open the **Version updates** dropdown menu, and select your version. +1. Open the **Version** dropdown menu, and select your version. - ![step-versions.png](/img/_paligo/uuid-eec007b7-1459-0f25-5112-9c312f47a189.png) + ![Step Version dropdown in the Properties tab](/img/workflows-and-pipelines/2026-07-06-step-version-dropdown.png) ## Using a specific Step version @@ -82,7 +82,7 @@ Locking on to the latest release of a Step means that if a new version of the St To make sure your Workflow will always use the latest available version of a given Step, all you have to do is remove any version information from the Step reference in the `bitrise.yml` file of your app: 1. -1. Switch to **YAML** at the top of the Workflow Editor. from the navigation menu. +1. Switch to **YAML** at the top of the Workflow Editor. 1. Find the Workflow and the Step you need. 1. Make sure the Step has no version information: diff --git a/docs/bitrise-ci/workflows-and-pipelines/steps/steps-overview.mdx b/docs/bitrise-ci/workflows-and-pipelines/steps/steps-overview.mdx index 2db4d6fd..188273d7 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/steps/steps-overview.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/steps/steps-overview.mdx @@ -28,7 +28,7 @@ For the purposes of your builds, Steps can be managed directly from the -1. Click the **+** sign on the top. +1. Open the Workflow selector dropdown and click **Create Workflow**. - ![create-workflow.png](/img/_paligo/uuid-67fb8500-b869-116e-8e97-2b1427eec451.png) -1. In the dialog, give your Workflow a name. + ![Workflow selector dropdown with Create Workflow button](/img/workflows-and-pipelines/2026-07-06-create-workflow-dropdown.png) +1. In the dialog, give your Workflow an ID. - The name can be as long as you wish since longer titles get broken into multiple lines so that you can read the whole title conveniently. + The ID can only contain the following characters: `A-Za-z0-9-_.` - ![create-workflow-dialog.png](/img/_paligo/uuid-ca83e0fe-3980-65b0-809c-86ab6bd95b36.png) + ![Create Workflow dialog with ID field](/img/workflows-and-pipelines/2026-07-06-create-workflow-dialog.png) 1. From the dropdown menu labeled **Based on**, select the Workflow you want to use as the basis for the new one. Alternatively, choose the **An empty workflow** option to create an empty Workflow. 1. Add the Steps you need to your Workflow. - Click the **+** symbol between two Steps to insert a Step at that position. Remove Steps you do not need by clicking on the Step and clicking the little trash bin symbol. + Click the **+** (**Add Step or Step bundle**) symbol between two Steps to insert a Step at that position. Remove Steps you do not need by clicking on the Step, opening the three-dot menu, and selecting **Delete item**. 1. Click **Save changes** in the top right corner. diff --git a/docs/bitrise-ci/workflows-and-pipelines/workflows/default-workflows.mdx b/docs/bitrise-ci/workflows-and-pipelines/workflows/default-workflows.mdx index c8f57f36..cfb13c74 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/workflows/default-workflows.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/workflows/default-workflows.mdx @@ -26,7 +26,7 @@ For a new iOS project, Bitrise automatically generates several Workflows. You ca | Workflow ID | Workflow summary | Workflow description | | --- | --- | --- | -| `run_tests` | Run your project’s tests. | The Workflow clones your Git repository, installs Node Version Manager (NVM) and select the Node version, restores cached `node_modules` dependencies, runs your tests using the package manager appropriate to your project and saves the cache. | +| `run_tests` | Run your Xcode tests and get the test report. | The Workflow clones your Git repository, caches and installs your project’s dependencies if any, runs your Xcode tests and saves the test results. | | `build_for_testing` | Builds your Xcode project ready for testing. | The Workflow clones your Git repository, builds your app ready for testing, apportions tests into each test shard and deploys the app plus tests to Bitrise so they can be used in subsequent Workflows. This Workflow is part of a default Pipeline. | | `test_without_building` | Tests your iOS app without needing to rebuild it. | Retrieves the app and tests from the preceding Workflow in a Pipeline and tests compiled bundles using Xcode’s `test_without_building` command. This Workflow is part of a default Pipeline. | | `archive_and_export_app` | Run your Xcode tests and create an IPA file to install your app on a device or share it with your team. | The Workflow clones your Git repository, caches and installs your project’s dependencies if there are any, runs your Xcode tests, and [exports an IPA file from the project](/en/bitrise-ci/code-signing/ios-code-signing/creating-a-signed-ipa-for-xcode-projects). | diff --git a/docs/bitrise-ci/workflows-and-pipelines/workflows/managing-workflows.mdx b/docs/bitrise-ci/workflows-and-pipelines/workflows/managing-workflows.mdx index 2ea05f39..5242c4ae 100644 --- a/docs/bitrise-ci/workflows-and-pipelines/workflows/managing-workflows.mdx +++ b/docs/bitrise-ci/workflows-and-pipelines/workflows/managing-workflows.mdx @@ -24,14 +24,11 @@ Everything described here is also available in the [offline Workflow Editor](/en You can set up multiple Workflows to run in succession. The order of these Workflows can be rearranged, new Workflows can be added to the chain and existing Workflows can be removed from it at any time. 1. -1. Click the ellipsis button to the right of the name of the Workflow. +1. Hover over the Workflow card and click the **Chain Workflows** icon button that appears. - ![chaining-workflows-menu.png](/img/_paligo/uuid-69aa514f-9623-9dde-f80f-340c81d06044.png) -1. From the dropdown menu, select **Chain Workflow**. -1. Select a Workflow from the list and click either **Add before** or **Add after**. - - ![workflow-chain-options.png](/img/_paligo/uuid-eebfeceb-3b6a-7e5d-3f3e-4431b4c200ba.png) -1. Click **Save** in the top right corner. + ![Workflow card with the Chain Workflows icon button highlighted](/img/workflows-and-pipelines/2026-07-06-chain-workflows-button.png) +1. In the **Chain Workflows** drawer, select a Workflow from the list and click **Add before** or **Add after**. +1. Click **Save changes** in the top right corner. **Chaining Workflows in YAML** @@ -66,13 +63,10 @@ For more information on how to manage Workflows directly in the `bitrise.yml` fi Once you have a chain, you can easily rearrange the order of Workflows in a drag-and-drop menu. 1. -1. Click the ellipsis labelled **Manage Workflows**. - - ![chaining-workflows-menu.png](/img/_paligo/uuid-69aa514f-9623-9dde-f80f-340c81d06044.png) -1. From the dropdown menu, select **Reorder Workflow chain** to bring up a drag-and-drop menu where you can rearrange the Workflows of the chain. +1. On the Workflow card, hold down the drag handle on the left side of a chained Workflow and drag it to the desired position. - ![reorder-workflow-chain.png](/img/_paligo/uuid-71e4b862-efd1-ece7-3627-d970b41f2d43.png) -1. Click **Save** in the top right corner. + ![Chained Workflow card with the drag handle on the left side](/img/workflows-and-pipelines/2026-07-06-chain-workflows-drag-handle.png) +1. Click **Save changes** in the top right corner. ## Workflow priority diff --git a/docs/bitrise-platform/ai/ai-features-on-bitrise.md b/docs/bitrise-platform/ai/ai-features-on-bitrise.md index 3125eaf2..14a6fa6b 100644 --- a/docs/bitrise-platform/ai/ai-features-on-bitrise.md +++ b/docs/bitrise-platform/ai/ai-features-on-bitrise.md @@ -43,6 +43,17 @@ The [AI build summary](/en/bitrise-ci/run-and-analyze-builds/build-data-and-trou If you have a failed build, the [AI build fixer](/en/bitrise-ci/run-and-analyze-builds/build-data-and-troubleshooting/ai-build-fixer) corrects it right on the build’s details page without you having to switch to other tools and processes. The AI build fixer executes the suggested code changes and pushes a PR to your GitHub repository. You can check the changes through a link to the repo. Based on your configured build triggers, Bitrise kicks off a new CI build to validate the AI changes. This means less fragmented work and quicker debugging. +## AI configuration assistant + +The [AI configuration assistant](/en/bitrise-ci/workflows-and-pipelines/ai-configuration-assistant) is a chat-based assistant built into the Workflow Editor. You describe what you want in plain language and the assistant produces a working Workflow or Pipeline in validated YAML, which you can refine further, either with the assistant or manually. + +The assistant can also: + +- Explain any existing Workflow or Pipeline in plain language, including what each Step does. +- Suggest improvements to an existing configuration. + +The AI configuration assistant requires the **Configuration generator** feature to be enabled for each project in **Project settings > Bitrise AI**. + ## Bitrise MCP The [Bitrise Model Context Protocol (MCP) Server](/en/bitrise-platform/ai/bitrise-mcp) lets you talk to Bitrise via an AI client of your choice. It enables seamless interaction with your existing CI setup. diff --git a/static/img/workflows-and-pipelines/2026-07-03-project-settings-bitrise-ai-configuration-generator.png b/static/img/workflows-and-pipelines/2026-07-03-project-settings-bitrise-ai-configuration-generator.png new file mode 100644 index 00000000..7d3b9838 Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-03-project-settings-bitrise-ai-configuration-generator.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-03-workspace-settings-ai-settings.png b/static/img/workflows-and-pipelines/2026-07-03-workspace-settings-ai-settings.png new file mode 100644 index 00000000..9a51d77a Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-03-workspace-settings-ai-settings.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-chain-workflows-button.png b/static/img/workflows-and-pipelines/2026-07-06-chain-workflows-button.png new file mode 100644 index 00000000..0b0c702b Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-chain-workflows-button.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-chain-workflows-drag-handle.png b/static/img/workflows-and-pipelines/2026-07-06-chain-workflows-drag-handle.png new file mode 100644 index 00000000..84c3fb8d Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-chain-workflows-drag-handle.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-convert-pipeline-banner.png b/static/img/workflows-and-pipelines/2026-07-06-convert-pipeline-banner.png new file mode 100644 index 00000000..2da38c9f Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-convert-pipeline-banner.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-create-step-bundle-dialog.png b/static/img/workflows-and-pipelines/2026-07-06-create-step-bundle-dialog.png new file mode 100644 index 00000000..93c9317b Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-create-step-bundle-dialog.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-create-workflow-dialog.png b/static/img/workflows-and-pipelines/2026-07-06-create-workflow-dialog.png new file mode 100644 index 00000000..f9125976 Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-create-workflow-dialog.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-create-workflow-dropdown.png b/static/img/workflows-and-pipelines/2026-07-06-create-workflow-dropdown.png new file mode 100644 index 00000000..3cd99e86 Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-create-workflow-dropdown.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-step-input-insert-variable.png b/static/img/workflows-and-pipelines/2026-07-06-step-input-insert-variable.png new file mode 100644 index 00000000..d21c9424 Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-step-input-insert-variable.png differ diff --git a/static/img/workflows-and-pipelines/2026-07-06-step-version-dropdown.png b/static/img/workflows-and-pipelines/2026-07-06-step-version-dropdown.png new file mode 100644 index 00000000..b45f5e4a Binary files /dev/null and b/static/img/workflows-and-pipelines/2026-07-06-step-version-dropdown.png differ