Build service v2

Optimizely has introduced a new build service for Configured Commerce that runs in Kubernetes instead of the legacy system that uses TeamCity. Running on Kubernetes provides additional scalability and security, such as:

• Using Configured Commerce's internal Kubernetes infrastructure for dynamic scaling of build resources to reduce queue time and overall build times.
• Using a GitHub app to receive webhooks that notify the new build service of code changes that must be built and deployed. This helps add requested builds to the queue faster and removes the need for Optimizely to add a public SSH key into extension repositories.

Configure existing instances

To migrate an existing instance to the new build service, follow these steps:

1. Install the Configured Commerce Build Service GitHub app in the repository.
2. Open a ticket with Optimizely Support to move your existing instance from the legacy build service to the v2 build service. The ticket should include the following:
   • The GitHub respository (full URL is required) and branch for each commerce instance – Each instance should be associated to a different branch, but multiple lower environments can share a branch. URL redirects are not supported and must be the actual repository URL.
   • The email address for build notifications – This applies to all commerce instances.

Configure new instances

To create an instance on the build service, follow these steps:

1. Install the Configured Commerce Build Service GitHub app in the repository.
2. Open a Project Initiation request with Optimizely Support to provision the instance. The ticket should include the following:
   • The GitHub respository (full URL is required) and branch for each commerce instance – Each instance should be associated to a different branch, but multiple lower environments can share a branch. URL redirects are not supported and must be the actual repository URL.
   • The email address for build notifications – This applies to all commerce instances.

GitHub app

The Configured Commerce Build Service GitHub app lets the Configured Commerce Build Service interact with the source code repository, including the following:

• Allowing commits to the repository to trigger builds in the Configured Commerce Build Service, removing the need to add the insite-teamcity-build user to the repository.
• Allowing the Configured Commerce Build Service to generate temporary tokens to clone the repository for building.

Install the app

Full instructions and additional information on installing GitHub apps can be found directly on GitHub (Optimizely uses their standard process).

Follow these steps for Configured Commerce:

1. Open the GitHub app install page.
2. Click Configure.
3. Select the organization associated with the repository where you intend to add the Kubernetes build service.
4. Select the Only select repositories option.
5. Select the repository where you want to incorporate the Kubernetes build service.
6. Select Install if you have admin privileges. If you do not have admin privileges, select Request or Install & Request, depending on your permissions. You must follow-up with the repository admin to approve the app install. You can provide the information below to explain the permissions and events requested.

Required permissions and events

Permissions
The following read-only permissions are required for the GitHub app to function correctly:

• Contents – Gets webhooks for pushes to the repository (which trigger builds).
• Metadata – Gets webhooks for pull requests to the repository.
• Pull Requests – Gets webhooks for merged pull requests to trigger builds.

  📘

  Note

  The Pull Requests permission is not currently used by Optimizely but is intended for future functionality.

Events
The build service uses the following event subscriptions to trigger builds:

• Meta – Lets the GitHub app know if the app was deleted and the webhook was removed.
• Pull Request
• Push

Build logs

Read build logs

The build logs are attached to the email sent when the build completes (successful or otherwise). Each set of logs is sectioned into discrete build steps in the following format:

========= Start Build Step: dogfood-sandbox-123-qc8mp-build-container-3105298733/ =========
Copy extensions.dll (if exists) to artifacts directory
'./dist/Extensions.dll' -> './artifacts/Extensions.dll'
Building init container
...
========= Finish Build Step: dogfood-sandbox-123-qc8mp-build-container-3105298733/ =========

The build step name (noted at the beginning and end of the step above) is a concatenation of information in the following format:
{project}-{branch}-{build number}-{build system unique ID}-{build step}-{build system unique ID}

Using this format, you can take the example build step in the above snippet dogfood-sandbox-123-qc8mp-build-container-3105298733 and identify the following details:

• Branch – sandbox
• Build number – 123
• Unique ID from build system – qc8mp
• Build step – build-container (most important detail)
• Unique ID from the build system – 3105298733

Important notes

• The build log does not contain all available logs because some logs could contain sensitive information (notably deployment logs). If a failure occurs in an area where Optimizely restricts logs (like during the deployment), you may not receive pertinent failure information in the build email. Contact Optimizely Support who will find and provide the relevant information.
• A failing step may display twice in the logs due to the automatic retry mechanism implemented to mitigate intermittent failures (for example, during intermittent network unavailability or other external resource outages).