Achieve a first successful Build & Test

Once infrastructure is installed and the CI provider is sending traffic to it, it's time to send a first build to it. This setup stage is intended to reach a point where most of the tests are passing, so that developers can start to experience how fast Workflows is, compared with the legacy CI setup.

Create a Machine Image

If the build is not hermetic (for example, some C++ dynamic-linked library needs to be on the machine), use Packer to make a reproducible build of a custom machine image. See Building Machine Images.

Disable some tests

Some test targets might depend on infrastructure that's only accessible from the legacy CI system. You can add a tag to these, following whatever convention you choose.

For example, you could follow this convention:

BUILD.bazel

some_test(
    name = "only_works_on_legacy",
    # Add this tag to exclude from Aspect Workflows
    tags = ["requires-legacy-ci"],
)

Then in the .aspect/workflows/config.yaml file, exclude these targets:

bazel:
    flags:
        # Subtract test targets that work only on the legacy CI system
        - --test_tag_filters=-requires-legacy-ci

Relax some Bazel restrictions

It's useful to start out with less strict settings to get the CI green, then return to enable them as a separate effort in a later commit.

For example, setting --spawn_strategy=processwrapper-sandbox relaxes constraints making the filesystem read-only, which might allow some tests to pass that rely on writing files. See Bazel sandboxing strategies.

Dark launch

We now want to have regular traffic sent to the Workflows runners. You might choose to turn on builds from main, or from Pull Requests, or both.

Aspect recommends a "dark launch" that is not blocking for developer workflows. That way, you can experiment with the workflows setup without fear of breaking something.