Build Pipelines: All your questions answered – Part 1

We received a lot of questions during our Build Pipelines webinar in July, so in this article, you'll read part 1 of the Q&A about Build Pipelines and rerunning workflows, stages, or pipelines.

‍Build Pipelines was introduced in July and it helps break your Workflows into Stages, build and test in parallel, shard your tests, and get faster PR feedback. We received a lot of spot-on questions during our webinar. In part 1 of this article, you can read the Q&A for the general questions we received and the questions about partial reruns.

Should you need an introduction to the Build Pipelines feature,

check out the first 14 minutes of the webinar
or read the announcement here

Parallelize build, tests and accelerate feedback loops with Build Pipelines ⎸ Webinar

Webinar recording with Damien Murphy (Solutions Architect), Ákos Birmacher (Product Manager) and Anna Bátki (Product Marketer)

Questions and answers were edited for clarity.

General questions

When will a UI editor be available for Build Pipelines?

At the moment, there is no official UI editor available. However, there is an unofficial UI editor available that you can use to build out your pipeline. It's fully functional, but it is an unofficial, temporary solution that we built just to help people get their pipelines set up initially. We're in the process of building this into the product. So, now it's really just an open-source Github project that can find here.

Just be aware, that when you load the page, what you actually get is just a default YAML, that default YAML has to be deleted and then copy over your own YAML.

There is some validation, and you'd have to fix errors while setting it up as you go. When you paste your YAML the first time, when there's no Pipelines yet, it's going to ask you to fix the issues: adding a pipeline first and then a stage as well. And once you've added both of those, you can start adding workflows in.

Do you know when Pipelines will be out of beta?

Currently, Build Pipelines is available for all the customers as we wanted to collect a bit more feedback, and this is why we made it available for everybody (on credit-based plans) in beta. The GA release has not been finalized yet, but probably not before September.

Do Pipelines work from the local CLI?

So, unfortunately, since the Bitrise CLI is a single machine and pipelines are actually running on multiple machines, we're not able to spawn multiple pipeline workflows at the same time on a local machine.

While pipelines currently won't work in the Bitrise CLI, you can test out the workflows themselves in the CLI. You could build your Workflows subsequently with the Bitrise CLI. This can be helpful when you want to test or debug a Workflow configuration.

Will I be able to trigger Build Pipelines using the Bitrise API?

Yes, you can. Next to that you can abort, rebuild or even partial-rebuild a Build Pipeline. For more check the Bitrise Swagger UI

In the build trigger API, you can pass that pipeline ID, and that will trigger that pipeline for you via the API.

What does a pipeline look like as a bitrise.yaml file?

In the YAML, you're only adding a Pipelines and a Stages section. And it just references the workflows. These workflows mentioned here do need to exist for this pipeline to be considered valid.

You can find example Pipeline YML files here.

Does this work with Bitbucket/GitHub integration, e.g., failing a PR build if any workflow fails?

Yes, you can use Build Pipelines for status checks in our pull requests, just like you did with Standalone Builds and even us Github checks.

If you want even more control, you can have multiple status updates in a Workflow by using

Do Pipelines work with GitHub Enterprise accounts?

Yes. There is a caveat, though: GitHub Enterprise won't work with storing your YML with your app in the repository because most GitHub Enterprise accounts are private, they're not publicly accessible. So we can't actually reach in and read that YAML. But if you store it on Bitrise, that will work perfectly fine.

Now, that's not to say that you can't leverage Bitrise YAML in repo. So with GitHub Enterprise, you could use our Bitrise Run step, and the Bitrise Run step would let you run your YAML from your repo. And that YAML inside the repo can have a pipeline. And everything will work as expected.

Will Build Pipelines be available on legacy (concurrency-based) plans?

No, it's only available on credit-based plans on the new pricing, but it's available even for Hobby and Team plans.

Will this feature be available on dedicated build stacks?

Build Pipelines is available for all of our customers on credit-based plans: private, dedicated, and public.

Does Insights offer performance analysis insights for pipelines and stages?

It doesn't have any specific pipeline analysis or stage analysis yet, but it does have all of the build and test analysis. We have plans to introduce new analytics for both pipelines and stages in the future, so keep an eye on it as it should be coming.

Why does a 47-second build cost 4 credits, is it 1 credit per 15 seconds? What is the minimum amount of credit a workflow costs?

Pricing is not based on seconds, but on minutes. Every build minute that you start costs a certain amount of credits, depending on what type of machine it uses.

The credit-based plans are the future, with them, you’ll be able to have way more concurrent bills than you can have on a current currency plan. In addition, for Standard machines, you're also getting really high gigs of RAM and vCPU.

Some of the stacks, for example, the Android ones are even cheaper, there is one with 1 credit/minute. So if you have a simple task that's not even mobile related, you can run that on our Linux machines and save a lot of credits there. We recently doubled the size of all these VMs: EliteXL is up to 16 vCPU, 64 gigs of RAM, and Standard is now 4. We doubled the CPU, we doubled the RAM, and we even changed the underlying CPU architecture to a faster 3.1 gigahertz model. (Read more about the Linux machine updates.)

Rerunning workflows, stages, or pipelines

Can a pipeline decide to retry a workflow if it fails?

Automatically, no it can’t.

But you can ‘partial rebuild’ a Build Pipeline when it’s finished running, and it will only rebuild the failed and aborted Workflows. If the Workflows were successful in the new attempt, then the pipeline will continue.

How can you build a pipeline that waits for two workflows to complete before starting a third workflow?

This is really easy with pipelines actually.

So let's say we want to wait for ‘iOS’ and ‘macOS’ before we build ‘tvOS’ and ‘watchOS’. And this would essentially be the way that you would achieve it. So your first stage must complete before your second stage runs.

The workflows in Stage build_test_all2 will both run in parallel. Once those are finished, the other 2 workflows in the next stage (build_test_all) will run.

Another example:

The first stage called ‘build_tests’ is going to build first. This one has to build before the following stages can start. And then all these have to finish before the test results can be collected.

If I want to abort just one of the parallel jobs running, would that make the build fail, or how does that work? (In a scenario where only one of the jobs is required to pass, to mark the build pipeline as passed.)

You can achieve that by not sending the status to GitHub about that workflow.

Now, the pipeline itself would fail, because one of its components fails. Unfortunately, we don’t have an is_skippable on a stage yet. (We do have this concept on a step: is_skippable true. And that will mean that even if this fails, the build won't fail.)

Would partial re-run of a pipeline require checking out the source code again? If stages are not run because of a failed workflow, and the workflow is retried and succeeds, do the stages get triggered and does that update the status of the whole pipeline?

In this example, iPhone and iPad pass but iPod fails.

You won't be able to rerun a failed workflow until the stage itself has completed, but once we've got a failed pipeline, we have the option here to rebuild unsuccessful workflows or to rebuild the entire pipeline.

The main benefit is that you don't have to build the app again, you're able to reuse the earlier stages and the other things in the stage as well. Prior to this feature, sometimes an app had to be built for 45 minutes only to be able to work on the testing part of it. But now, with the first stage passing, this is not needed anymore.

PRO TIP: Yeah, and if you ever want to speed up your tests, think about using smaller screens because it does use less memory.

Will $BITRISE_BUILD_NUMBER be the same for all stages? Are there new environment variables introduced?

Yes. Build numbers are defined for the workflows, and the pipeline has a specific pipeline number.

On the screenshot above, you can see that the pipeline build number is 46, but if you click any of the workflows in a stage, you will see different workflow numbers. Each has a unique one.

To be continued.

Help us make Build Pipelines better!

Build Pipelines is currently in open beta on credit-based plans. This means that not all planned functions are available and several features will be introduced later to make sure we cover as many use cases as possible. We are collecting your feedback to deliver the best possible feature set for the stable version.

Try Build Pipelines now and tell us how it goes: