Custom Enumeration


Our recent changes to the way we handle SCM caching (read more here), has allowed us to improve the way Solano CI handles test enumeration. Previously test enumeration happened before any user provided commands were ran. Enumeration was thus limited to finding files that matched ruby globs and combining them with a list of tests provided in a yml file. While this works in a lot of cases its not very flexible– enter Custom Enumeration.

Custom Enumeration allows more control over which tests are run on a build. This feature adds a new hook that will replace the standard enumeration (old way) with a run time generated list of tests. Since the list of tests is generated at run time it is possible to have much more fine grained control over which tests are ran on your builds. The basic requirements of Custom Enumeration are a command to run (in most cases a script) that generates a json list of tests to run. That’s it, you have complete control over the way a build will decide what tests it will run. We have made some examples of custom enumeration scripts available here and the docs are available here.


Here are a few examples of what can be done with Custom Enumeration.

  • Recently Edited Files
  • Failed on last build
  • Integrations with other services (e.g. Jira, Github issues)
Recently Edited Files

This example uses a naive method of guessing which tests were likely affected by recent changes. It looks at what files have been changed since the last passed build and attempts to map those files to matching test cases. This enumeration would be used in a plan as the first step, and the second step would either run the remaining tests or run a full build. This type of enumeration tries to use a small subset of tests to fail sooner on builds that will fail.

Failed on last build

This type of enumeration can be used for multiple purposes.

  1. Could be used as the default profile and be made to run only tests that failed on the last build, or if all tests passed then run all tests. This could be helpful on development branches when you are working on fixing tests that are failing.
  2. This type of enumeration could also be used to have a rerun profile as the last step of a plan if you know that there are flaky tests in the build.

In the next post we will look at a specific example of using custom enumeration with parallel commands.

Have any questions or comments about this or any other Solano CI features – please don’t hesitate to contact us via email, twitter, or in the comments section below.

Leave a comment

Welcome to Solano: Concurrency and Parallelism

Welcome to Welcome to Solano! In this blog series, we’ll examine a few key concepts and features of Solano Labs’ flagship product, Solano CI. The goal of this series is to help orient new users while learning to use the system, and serve as a refresher for current users; we hope you find them handy. Please let us know what you think in the comments or if you have any questions send us a note at


Solano CI is a powerful and complex system; it is, by design, highly flexible in its configuration and potential scale so that it can support the large variety of use cases that CI/CD systems are often relied upon to perform. However, at its core, Solano CI’s primary function is to help its users produce higher quality software.

One way it does this is by returning the results of automated tests quickly. To do this, Solano CI supports the ability to perform multiple actions at the same time and thereby reduce turnaround time by simply doing more at once. There are two simple ways that Solano CI does this: (1) running multiple build “sessions” at once, or “Concurrency;” and (2) automatically subdividing the tasks performed within a session and distributing that work to “workers” to perform them at the same time, or “Parallelism.”

The number of concurrent sessions a user can perform at once is set by that user’s account plan. Each session occupies what we call a “build slot,” and users can only run as many sessions at once as their plan has build slots. When all build slots are occupied by actively running sessions, subsequent sessions that are started are queued until a running session finishes and a slot becomes available. [Editor’s Note: We’ll discuss Queues in more detail in a subsequent post; we’ll provide a link to that post here once it’s posted.]

Our free trial and metered hourly plans, e.g. the Large plan, by default all have two build slots. At the Pro and Enterprise plan levels, the number is customizable.

As a session goes through the build setup process, Solano CI spins up a number of parallel workers to actually perform tasks, usually tests, the user wants to execute. These parallel workers are Docker-based containers, and can run either all together on a single VM or on an orchestrated set of VMs. When the workers are up, the system will scan the repo’s filesystem for test files based on the user’s configuration settings, collect that set of files, and then subdivide it into discrete batches that are distributed to the workers for execution. This distribution of the batches over time over the duration of the test execution phase of the session is our automatic parallelism.

One important conceptual note: the number of workers used per session is set as part of the plan configuration, like the number of build slots, and are the same for all of a plan’s build slots, regardless of which repo they build, and are not free-ranging. This is often confusing for many new users, as they often think of workers as just a set of units in a resource pool that can be arbitrarily configured on a per-repo basis, and so if a smaller repo is built they want to redirect the superfluous workers towards other larger repos’ builds; this isn’t possible in Solano CI. A helpful analogy for constructing a mental model is that of lanes in a bowling alley: just as a bowling lane uses a predetermined number of pins and all other lanes use that same number, so to build slots have a number of workers they use by default as set by the user’s plan.

The number of workers per build slot is highly diverse by plan, even within the set of metered plans. A list of the workers by metered plan is available on our Product page; the Pro and Enterprise plans’ worker configurations are customizable.

Leave a comment

Testing at Tobi


The following is a guest post by Josh Brown, Senior DevOps Engineer at Tobi. Tobi is an online fashion label, a unique combination of fashion, technology, and retail requiring a world-class engineering process in order to maintain and grow such a robust e-Commerce platform. Solano CI helped Tobi achieve these goals by reducing their testing time to the time it takes to get a cup of coffee— coffee time! 

At Tobi, we serve millions of customers from around the world with an e-commerce platform that we built from scratch. Not only that, but all of our internal applications, like inventory tracking and product lifecycle management, are all built in-house. The entirety of our company’s infrastructure is built by us and so we’re acutely attuned to and invested in its performance and reliability. This need for a great and reliable platform and experience by both ourselves and our customers has led us to automated testing and Continuous Integration. Testing and CI are crucial to us, and here I’ll outline how we’re testing and with what systems we currently use, and why.

Our codebase is over 9 years old. Many of our engineers, then, interact with code that may not have changed in some time, let alone actually working directly on that code itself! So they rely on our unit, functional, and integration tests to confidently make changes to those portions of the code that have been frozen for years. These give us the confidence to build on that legacy with the assurance that it serves as a stable foundation.

Since we have over 400 employees using our in-house applications daily, we want engineers to write as many tests as possible so that our employees can execute optimally.  Our team is encouraged to write a lot automated tests and know that our CI system can handle as many tests as the codebase requires to remain stable. CI is a core part of our workflow and all engineers at Tobi utilize it for our multiple, daily releases.

The infrastructure we use to run our build and test process is based around Solano CI. We came to Solano CI in early 2016 from CircleCI, where our builds were taking about 50 minutes (a significant improvement over the 1.5 hours they took before on Jenkins). We liked both Circle and Solano because they were SaaS offerings (so we didn’t have to manage the underlying system). Both rely on a YAML configuration file to configure the build environment, select which tests to run, and manage parallelism.

The biggest reason we switched to Solano CI was, in a phrase, “coffee time.” Solano’s team encouraged me to think about what my team could do if we could get our build and test results back in the time it takes to get a cup of coffee, and intrigued, I challenged them to show me that Solano CI could make that happen. The system’s automated scheduling and parallelism were impressive, and between my conceptual understanding of setting up through a YAML config file from CircleCI and Solano’s docs I got most of the way by myself. But the biggest win, and the reason we decided to buy, was their team’s support: I took my own work to them and they offered recommendations for more efficient ways to do things like set up the database and precompile assets that, ultimately, got us to coffee time. That expertise was really valuable, and their Support team has continually shown that the Solano team are experts of CI and its best practices.

As Tobi’s operations have grown our processes needed to as well, and this set up is the current iteration of our continued efforts to create a strong testing infrastructure. We can confidently produce a resilient and dependable e-commerce platform for our customers and supporting backend infrastructure for our colleagues. And with the testing backstop secure we can focus on what matters most – providing the best service experience and bringing our customers amazing fashion.


You can learn more about Tobi and what they are up to by clicking here

Leave a comment

Announcing Build Pipelines

We’re very excited to announce the release of Solano Build Pipelines. Build Pipelines are a way for you to chain together multiple Solano CI sessions into a seamless Continuous Deployment pipeline.


Solano Build Pipeline Animated


Each pipeline step represents a separate Solano CI session, so each runs with its own set of Solano’s parallel workers. This means that you can utilize the power and flexibility of Solano CI’s auto-parallelization to get faster build results, thereby accelerating your deploy times. Writing a deploy step can be as simple as executing a custom shell script; or you can utilize one of our many deployment integrations. Pipelines will only continue execution if every step preceding a particular step successfully passes.

Along with the release of Build Pipelines, you’re now able to run Solano Build Profiles in parallel! This means that Build Matrices can also run in parallel by default. To enable this functionality users can change their plan key to pipeline, or can contact and we can turn on the functionality for the plan key.

We’re pumped to see how you’re planning on using Build Pipelines. Tweet us @SolanoLabs (and me @b_kendz) with your crazy pipeline configurations – see if you can come up with something useful that’s crazier than this pipeline:

a crazy Solano Build Pipeline

If you want to learn more about Build Pipelines, check out our documentation, or contact us directly at

Leave a comment

SCM Caching


Part of the motivation for our recent change to queues (read more here) was to allow us to change to the way we handle SCM caching. We were using a git- and hg-native SCM cache cluster that was approaching a scaling limit. To address this, we’re moving to a much more scalable, distributed repo caching system that can handle repos from all different types of SCMs and uses a snapshot-based approach instead. After the switch, the SCM cache cluster will be retired and the workers will directly handle updating the snapshots after a build has run. This will remove some setup overhead at the beginning of a build (win!), and will enable us to add a lot of new features that people have been asking for – for example:  integration with more SCM and code review systems (i.e., Phabricator), pre-merging with master before a GitHub Pull Request build, or running your own code to enumerate tests.


We’ll gradually migrate users to the new SCM cache system over the next few months. We’ve already switched over our internal builds, and have begun testing some customer builds.

If you use Custom Queues, you will need to enable the new routing before we can switch your account over. (See blog post above.)

New Features

One of the first new features allowed by the new these changes is test enumeration for all SCMs. Enumeration allows the usage of Ruby-globs to include and exclude test scripts from your repo to run in your build.

Git builds have had test enumeration for a while, but Mercurial has been missing out. For example, you can add the following to your solano.yml file:

That will include all files in the spec folder that end in _spec.rb then it will exclude any files that are in spec/flaky/. If you still want to select tests manually you can add the following instead.

In the upcoming weeks we will provide a status update on the rollout and provide a more technical dive.

Have any questions or comments about this or any other Solano CI features – please don’t hesitate to contact us via email, twitter, or in the comments section below.

Leave a comment

Queues are on the Move

Update July 22nd 2016 – Queue Routing has been moved to the UI, routing using solano.yml is no longer supported


A little over a year ago we released a feature called Custom Queues which exposed some of our internal routing logic to better select the compute resource that your build runs on. If you wish to use Docker containers you can route your builds to the “docker” queue to take advantage of Solano CI’s built-in Docker environment (read more). If you have a large test suite that needs to run using beefy machines with multiple GPUs, we’ll set up a queue for you to route your vector processing jobs through. 

Moving configuration items from the source-controlled solano.yml file isn’t a decision we take lightly. We’re big fans of moving away from the decade-old model of having your build’s configuration settings stored within the build system in a cryptic XML format. We are working on changes to the method we use to process configuration files very early in the session lifecycle. Configuration values that we absolutely must know before a worker starts now need to be set using the UI. We have some exciting enhancements coming soon that we’re super jazzed to share with you all, and moving to a UI-based queue routing configuration is the first step in enabling these enhancements.


For users who don’t currently use Custom Queues, this change won’t have any impact on your builds. For those of you that are using Custom Queues, we’ve pre-migrated the queue settings from your most recently run session to help you in the transition. All you need to do is verify that the auto-generated Queue Routers are correct, and click a button to enable the new routing scheme. We will be deprecating the config file approach to queue routing in July 2016 – we will be in contact with you prior to the cutoff to make sure everyone is migrated and ready for the change.

How to migrate

Step 1.

Visit your Solano CI Dashboard page, and click the gear icon for the repo you wish to configure. This will take you to the Repo Settings page.

repo setting page link location

Step 2.

Click “Queue Routing” in the left sidebar to bring up the Queue Routing settings page. Using the form at the bottom of the page, add branch/profile combinations and indicate which queue you want each combination to route to. You can use ‘*’ in the branch field to match all branches. If you’re not using profiles or don’t wish to change routing rules based on profile you can simply leave the field blank.Queue Routing settings page

Step 3.

Click “Save” to add the new route to your list of active Queue Routers. The routes are evaluated from top to bottom, the first rule that matches the branch & profile of the session that is being routed will be the one that determines the queue to use.

Step 4.

Once you validate that your Queue Routers are configured correctly, you can turn on Queue Routing for this branch by toggling the slider at the top of the page so that “Enabled” is highlighted in green. Congratulations, you’re fully migrated! Now would be a good time to remove any references to queue routing in your solano.yml to avoid any future confusion.

enable queue routing

Like I mentioned earlier, we’ve automatically populated Queue Routers for repos that have queues defined in their solano.yml configuration file. All you should need to do is verify that the rules are correct, and click “Enable” to turn on the new Queue Routing. If you don’t see your queues auto-populated, please send us a link to a Session that has a queue defined in its solano.yml, and we’ll auto-generate the routers for you.

Stay tuned for some exciting news about upcoming changes that will have a big positive impact on your build performance.

Have any questions or comments about this or any other Solano CI features – please don’t hesitate to contact us via email, twitter, or in the comments section below.

Leave a comment

Webinar Recap: Easy Continuous Deployment You Can Trust

Thank you to everyone who joined us for our webinar last week, produced in collaboration with Sauce Labs, titled “Easy Continuous Deployment You Can Trust”, featuring Solano Labs Founding Engineer, Brian Kendzior, and Sauce Labs Solutions Architect, Neil Manvar.

In this presentation, Brian and Neil demonstrated a continuous deployment release process that used GitHub, Solano CI, Sauce Labs, and AWS CodePipeline. The release process included smoke, unit, integration and browser tests to guarantee issue-free deployments, enabling a safe and easy push-button deploy process.

Brian and Neil also demonstrated how to:

  • Build your software release pipeline by connecting different steps into an automated workflow using AWS CodePipeline
  • Run your automated web tests on any browser and operating system combination using Sauce Labs
  • Auto-parallelize your test runs with a Continuous Integration server using Solano CI

Check out the video here:

Slides are available here:

NOTE: These slides do not include the demo – please watch the video above for the demo.

Handy Resource Links:

Got questions, comments, or requests for what we should do for our next webinar?  Feel free to use the comment section below, email us at, or send us a tweet @SolanoLabs!

Leave a comment

Report Page Interface Enhancements

We are very pleased to present the first design update of 2016 to the Solano CI product: a new Report Page layout that is better organized, introduces new interface components, and is much easier to use.

The Challenge

The “Report Page”—as we call it here at Solano Labs—is the primary view into any given session on Solano CI. It shows every state of a session, from its initial creation, through to a complete collection of test results, build lifecycle timings, and build artifacts.

It has also served as a way for many users to navigate through their workflow, and view other pieces of information that relate to the state or configuration of the organization and repo. Over time, in an effort to provide as much information and control as possible over a growing number of factors, the interface had become less intuitive for long-time users and not as easily ’learnable’ for new users. This causes friction and inefficiency; it is, in a sense, user experience debt.

With so much data and navigation to present in one place, the challenge is this: how do we improve the usability of such a complex view? How do we introduce incremental enhancements while maintaining the best possible usability overall?

First, we listened to you, and we sat with you and watched you use the application; we challenged our own assumptions. We learned a lot.

Second, we reviewed both new and long-time users’ primary expectations of the view to ensure different team roles will be well served by the interface.

And third, we mapped out a plan to arrive at an overall redesign via a careful sequence of incremental improvements to specific areas of the interface.

Then we got to work on the first design update.

New Layout

The first thing you’ll notice about the new layout is that we have removed the sidebar. This is a major change in the interface, and it was made based on both our own use of the Report Page, as well as in response to user feedback. Many users found the placement of status and navigation related to other sessions distracted from the current session’s status and results. By focusing the layout on the current session status, and moving other status and navigation elements to more intuitive locations, we created a new view that is easier to understand at a glance, and affords more comfortable navigation.

Tabbed Sections for Supporting Information

In addition to simplifying the top of the Report Page so you could more easily focus on session status, we also wanted to simplify how you view and navigate the supporting information, such as setup logging, test results, important messages—everything below the main session status display. For complex builds especially, viewing these different sections resulted in lots of scrolling, and intra-page navigation that was often confusing to new users.

Through observation and research it became clear that you were interested in specific kinds of information at specific times, and being able to choose what information was visible by type or purpose would be very helpful. So we divided the supporting information into separate tabbed sections shown immediately below the primary session status. [see 1 below] Now, rather than needing to scroll the length of the view past info you may not need in order to find what you’re looking for, there is a clearly labelled tab such as ‘Build Artifacts’.

The tabbed sections also provide a flexible yet well-structured way for us to present supporting information that would have cluttered the view unnecessarily: the Session History that was in the sidebar is now shown in a tab; in the future important new features on our roadmap will also be found under a new tab.


Active Session Menu

Another new addition to the Report Page is the Active Session menu. [see 2 below] Having committed to removing the sidebar, we set out to optimize the usability around certain tasks. As mentioned earlier, various components on the Report Page became central to many user’s workflow, and we needed to make sure we didn’t break those flows while solving other things. We found that the most used element in the sidebar is the list ’Current Sessions’, and therefore it would be more useful if it was available on all views in the app. A simple solution emerged quickly: place a control in the header of the page that allows you to quickly see a drop-down that shows all active sessions from not only the Report page, but also the Dashboard, or any other section. The added benefit of this new component is that it provides a convenient way to quickly see just the number of active sessions without needing to click on the drop-down—and see at a glance from one session when the most recent session has started.

Session Navigation

While the Active Session menu allows you to quickly access the most recent build activity in your organization, we also wanted to provide a simple way to navigate to the previous and—when it exists—next builds on the same branch. We added text links in the heading of the Session component for paginated navigation so you can quickly move up and down the timeline of sessions. [see 3 above]

In the future we plan on providing richer controls for navigating the app, so this was an ideal time to step incrementally in that direction by moving the branch name up to the top of the page. Now you’ll see organization, repositories, and branches all in one line. [see 4 above] This will soon become convenient “breadcrumb” navigation into all three areas.

Support Drop-down

Consistent with the changes made to the Active Sessions component, we also moved the Notify Support form. We felt that having a control accessible near the Action menu for opening up a support form made the most sense—often the need for support arises once a user has taken actions such as rebuilding, or opening up a debug console. [see 5 below] In addition, for users on laptop screens the details of the report are now easily visible while entering the details of your support requests.



Visual Refresh, Part One

In addition to the new layout and navigation elements, we are also introducing a simplified visual style that is more clear and readable. While we won’t be embracing a trendy ‘flat design’, I’m a firm believer that too much design interferes with usability; by simplifying the visual styling of each component, a complex interface becomes much more clear, and as a result provides a much better experience. We’ll be transitioning to this new style in all areas of the app over the coming months.

One of the promises of Solano CI is to save you time; the more the interface gets out of your way and allows you get your work done quickly and efficiently—less scanning the page for the information you’re after, less searching for a control—the more design has helped deliver on that promise.

The Other CI

For all of us collaborating on design at Solano Labs, CI also stands for Continuous Improvement. This design update is the result of a continuous cycle of learning, ideating, and building: learning what you need to work more confidently and efficiently; ideating ways to meet your needs; building a reliable and usable product for you. As a designer, the most important part of this cycle is the learning: there is nothing that motivates me more than learning about what is and isn’t working for you when you’re logged in to So log in, take a look at the latest updates, and please tell us what you think.

Send us any questions or comments via Twitter @SolanoLabs, email at, or the comments section below.


Displaying Reports Earlier

We’re changing how you can view Solano CI’s processing of events that trigger builds, for example like the webhooks sent from GitHub. An event can be a webhook, a push from the command line, a “build now”, or a scheduled build.

We’ve always tracked incoming events (e.g. pushes) separately from viewable Sessions (i.e. Builds), and there hasn’t been a good presentation of events that haven’t had associated Sessions.

 Since Solano CI will (by default) collapse pushes on a branch together into a new build if there’s an existing build running (“CI Squash”), we use this distinction between event and Session to minimize the number of running Sessions, in order to keep your build queues free of extra work.  Also, incoming webhooks are often filtered out or dropped based on repo settings, and it made sense to hide the dropped events from view. This has had the negative UX impact that it may have taken many minutes for a push to be displayed as a visible report, even though it was received successfully and is being properly processed.  We provide controls in your Repo Settings for CI Squash”, and the related behavior of not re-running a new build if there’s already a build on the same commit (“Dedup”).

This change allows us to share more information about these events sooner.

We’re now making visible and linkable reports for the event(s) that will turn into the next build on a branch.  These will show up as “initializing”, and will remain like this while there’s already a running build.  Once the running build on a branch completes, the initializing build will progress to “queued” as normal.  A build that shows up as “initializing” won’t take up a build slot.

Initially we are adding three new report pages:

  1. An updated page for builds in “initializing” state
  2. A page for builds that have been squashed,
  3. A page for duplicate builds that were skipped because of a pre-existing build on the same commit.

Build Initializing

First, let’s talk about the updated “initializing” page. This page will be available as soon as an event is received. As not much has happened yet in this build, it will just contain some basic information such as creation time, type (ci, cli, scheduled), commit id (if available), and event initiator. Once a build actually starts running it will return to the normal report page view.

Screen Shot 2016-01-06 at 4.17.18 PM

Squashed Builds

Next up is “squashed” builds. Until now there has been no display for squashed builds. They now have their own report page that contain a link to the build that ran, and a link to the repo settings page where squash is set. Quick primer on squashed builds: “Solano CI will build only the most recent un-built push on the current branch, skipping intermediate pushes.” Here is an example of what a squashed build now looks like:

Screen Shot 2016-01-06 at 2.56.44 PM

The build number in the title (i.e.#1096) is a link to the build that actually ran. It leads to the normal report page.

Screen Shot 2016-01-06 at 3.02.00 PM

Duplicate Builds

Finally Duplicate builds: Solano CI will not run a build for a webhook (by default) or scheduled build (if you set the option) whose latest commit has already run on the same branch within the past few days. Additionally it is possible to enable this feature repo-wide, to not run a new build if the same commit has been run on any branch in the repo. The Duplicate build page will contain a link to the build that ran, and the latest commit sha, in addition if it was a scheduled build it will contain the Schedule Info. Scheduled builds can be set to always run by selecting “always run” in the schedule builds options.

Screen Shot 2016-01-16 at 12.21.27 PM

Send us any questions or comments via Twitter @SolanoLabs, email support at, or use the comment section below.

We hope you like this change!

Leave a comment

Solano CI Integrates with Amazon EC2 Container Registry at Launch

Today, we are proud to announce our integration of Solano CI with Amazon EC2 Container Registry (ECR).  With Amazon ECR and Solano CI, you can now reliably build, test, and deploy your Docker workflow without operating your own container repositories or scaling your infrastructure.  Amazon ECR is a fully-managed, secure, and highly-available Docker container registry that makes it easy for developers to store, manage, and deploy Docker container images.  In addition to the simplified workflow, you can configure policies to manage permissions and control access to your images using AWS Identity and Access Management (IAM).  There is no easier way to gain fine-grain permission control over your Docker images today.

We decided to create an example repository to demonstrate integrating Amazon ECR and Amazon EC2 Container Service (ECS) with Solano CI. Each commit to the repository will trigger a build, and when all of the tests pass, the new Docker image will be pushed to Amazon ECR and Amazon ECS will start a new container. The step-by-step process we used:

Prepare your local system

  1. Since Amazon ECR is a new service, we had to install a new version of the AWS Command Line Interface to enable the aws ecr command.
  2. Set the environment variables for the aws command:

Setup Amazon ECR and ECS

For Amazon ECR enabled accounts, the Amazon ECS first run wizard allows creating the private Docker image repository in a few easy steps:

Set the repository name:

Aws ECR Step 1

Upon creation of the Amazon ECR registry, run the provided commands. The aws ecr get-login command will output a docker login command to run, but this can be done in one step by running it in a subshell: $(aws ecr get-login --region $AWS_DEFAULT_REGION)

AWS ECR Step 2

After setting up Amazon ECR, the wizard continues with the standard Amazon ECS setup steps.

Amazon ECS Step 3

On the task definition step, clicking the Advanced button allows us to set our own entry point and ensure the command field is empty.

Amazon ECR Step 3 Advanced

Configure the service:

Amazon ECS Step 4

Configure the cluster:

Amazon ECS Step 5

Review the settings and Launch!

Amazon ECS Step 6

Setup Solano CI

After AWS has launched the container, we set Solano CI to automatically build and test on each git push. When all of the tests pass, the new Docker image is pushed to Amazon ECR and Amazon ECS launches a new container from the image.

Inform Solano CI of the repository:

Now that the repository has been registered with Solano CI, we went into the repositories settings by clicking the gear icon for the repository on the Solano CI dashboard:

Repository on Solano CI Dashboard

On the CI Setup tab of Solano CI’s repository settings page we used the values to link the GitHub repository. The values under #2 are set in GitHub’s Tddium service hook. The value under #3 is Solano CI’s repository public key and is added as a GitHub deploy key.

Github configuration

To set the auth credentials necessary for connecting to AWS, the solano config:add command is the recommended way to set sensitive environment variables:


Now the example repository will trigger a build and deploy to both Amazon ECR and ECS upon passing builds. In particular there are a couple of files that we recommend taking a look at:

solano.yml: This file informs Solano CI to use a Docker enabled queue and specifies the setup hooks, tests, and other settings.

scripts/ Installs aws-cli and jq (for JSON processing), logs into Amazon ECR, builds a Docker image, and installs dependencies.

scripts/ Starts the docker container and prepares the test database.

scripts/ Verifies the tests pass, pushes the new image to Amazon ECR, registers a new task definition with Amazon ECS, and updates the Amazon ECS service.

Give it a try and send us any questions or comments via Twitter @SolanoLabs, email support at or use the comment section below.

With Amazon ECR and ECS alongside Solano CI: May green builds be with you!

Yoda Broken Build

Leave a comment