Migrating from Snap CI to Solano CI

As many in community are already aware, Snap CI will be retired in August of 2017. The offered migration is to GoCD, an on-premise CI/CD solution – as this product may not fit the needs to current SnapCI customers we felt it was appropriate for us offer a comparison to Solano CI so that customers migrating are choosing the most appropriate and easiest product to migrate onto.

Solano CI is a cloud-based CI/CD SaaS that allows customers to unlock incredible performance from their existing test suite. Solano CI customers have seen 10x improvements in testing time using our unlimited parallelism, advanced caching, and extremely customizable build process. Not only that, but Solano CI is extremely easy to get running and simple to customize to fit your exact build workflow.

Comparison of Solano CI to Snap CI

Here is a quick rundown of the main differences between Solano CI and Snap CI:

Solano CI to Snap CI Comparison


We’re confident that Solano CI can get existing Snap CI customers running with their desired CI workflow in no time at all. Sign up for a free account and try us out – check out our documentation or contact us at support@solanolabs.com if you’d like to have a conversation about the migration process.

Leave a comment

Outbound Web Hook Closures

Solano CI supports sending outbound web hooks that contain various information about the status of a Solano CI session. These web hooks are great for collecting data on your Solano CI builds, but many of our users wanted the flexibility to send custom-formatted JSON blobs directly to third party services. Introducing:  Web Hook Closures

Now, Solano CI supports adding a Javascript function that processes the JSON data before sending out web hooks. This will allow users to transform the JSON into a format that can be automatically recognized by any third party service that accepts incoming web hooks. Here is a simple example closure for posting session time stamps to New Relic insights (gist); simply replace the Insert Key with your API key.

Please let us know if you run into any issues, or have an exciting closure to share!

For additional information, consult the Solano CI Documentation or contact us directly at support@solanolabs.com


Leave a comment

Announcing Solano CI and Google Auth Integration

We’re happy to announce our integration with Google Auth. New users can now immediately sign-up using their Google credentials, and existing users can link their Solano CI and Google accounts to allow for quicker logins.

Screen Shot 2017-02-21 at 10.45.30 PM



Existing users can visit this link to manage their Google Authentication settings. Please contact us with your feedback!

Leave a comment

Shiny New Session Lifecycle Display

You might’ve already noticed, but your Solano CI report page may look a little different than you’re used to. We’re excited to release our newly redesigned Lifecycle display, giving you more insight into your build’s timing and progress.

Solano CI Lifecycle Header

This new lifecycle header splits your build into 4 logical sections:

  1. Startup – This phase includes the time it takes from receiving notification that you would like to start a build, to the time that Solano CI workers are assigned and your code changes have been pulled.
  2. Prepare – This phase includes any setup needed in order to successfully run your tests. This includes running setup and worker hooks, as well as initializing services you may have configured (postgres, mysql, elasticsearch, etc…)
  3. Run – This is where we run your tests. Nothing more complicated going on here.
  4. Finish – After your tests are completed, we run post build hooks, collect and upload logs, and complete any other teardown requested.

We’ve also made all of the timing data used to create this new heading available to users through our outgoing webhooks API.

Let us know what you think. This lifecycle update is a part of our ongoing focus on giving Solano CI users more visibility into every step of their CI build. Stay tuned for more releases in this vein.

Leave a comment

Managing AWS Credentials in the Cloud

Anyone who uses AWS and CI/CD long enough has invariably been told to store their AWS credentials in Environment Variables in order to use the AWS CLI to manage deployments or pull resources from S3. This is extremely unsafe for a variety of reasons.

AWS has been recommending cloud-platform providers to utilize the AssumeRole API to provide another layer of security and traceability to external AWS Credential access. As a proud APN DevOps Competency Partner, we’re excited to be the first cloud CI/CD provider to announce our adoption of AWS AssumeRole as the recommended & most secure way to use AWS Account Credentials with your Solano CI builds!


Using AssumeRole w/ Solano CI

Follow the instructions here on setting up a cross-account AssumeRole policy in AWS. Make sure to follow the section that mentions “Allows IAM users from a 3rd party AWS account to access this account”.

You will be prompted for the External ID and AWS Account ID for the external account, you can find this information in your organization’s settings page.

Continue through the instructions, and copy the ARN for the new policy into the organization settings page and click “Save AWS AssumeRole ARN”. We will run a test to make sure the role has been set up correctly, and you will be presented with the following success message:


You can now use the AWS Code Deploy / Solano CI integration without the requirement of having to include Environment Variables with your build! You will also have access to the following temporary AssumeRole Environment Variables that will allow you to authenticate AWS requests using the new role:


Use these exactly as you would’ve used hard-coded environment variables, without the guilt of hard-coding your secure never-expiring credentials!

As always, please reach out to us via support@solanolabs.com if you have any additional questions!


1 Comment

Announcing Solano CI Tutorial & New GitHub Integration

Solano Labs is excited to announce the release of our brand-new GitHub Integration!

Using the newly built GitHub Integration, we are able to provide a catered onboarding tutorial that shows you how CI/CD works within Solano CI – all using free open-source codebases. The tutorial walks users through:

  1. Forking one of our open source example repositories:
  2. Installing the Github Integration and granting access to your new fork
  3. Editing and automatically committing a solano.yml from Solano CI
  4. Watching the tests run and pass!

In addition to enabling this more robust onboarding flow, GitHub Integrations aim to give users more fine-grained control over the permissions granted to third-party applications. You can now give Solano CI access to your code on a repo-by-repo basis, eliminating the need for confusing bot accounts. The integration also gives the ability for Solano CI to have write access to your solano.yml, which will be used for smart  in-app editing of your Solano Configuration.

If you know of an Open Source project that has CI needs, and you’d like to see it featured as a part of our tutorial flow, please reach out to us at support@solanolabs.com.

This onboarding tutorial is available to all newly created trial accounts. Please give it a try and let us know what you think!

We’ll be giving the option for current GitHub OAuth Integration organizations to migration to the new GitHub Integration in the next few months – if you’d like to explore migrating sooner, please reach out to us at support@solanolabs.com.

1 Comment

Introducing Solano Labs 30/30: 30% Faster Builds or 30% Lower Bill

Solano Labs is proud to announce our most ambitious campaign to date. Our 30/30 promotion offers you 30% faster builds or a 30% lower CI bill. No catch. It truly is that simple.

Our technology is the most scalable in the industry and we are happy to issue an open invitation for anyone to try it by providing an extraordinary benefit in the form of faster builds or lower cost. We are bringing the classic soda blind taste test to the enterprise software world, so try Solano CI today and experience our patented auto-parallelization and newly redesigned onboarding flow and decide for yourself. It is easier than ever to set-up a Solano CI account and get your build turnaround time down to #coffeetime–  the time it gets to get a cup of coffee.

Here’s how you can get in on the 30/30 action:
Spending over $1000 on CI per month?

  • Sign up for this special offer on this page.
  • Connect your repo and provide your current CI configuration.
  • Give us a few days to show you how much time or money you can save.
  • Pick Faster builds or Lower Cost.
  • Use the time or money you saved to throw a party for your team. Cheers!

Spending less? We got you covered too. Save 30% on your CI bill with Solano CI, connect a repo to get started.

Now relax and brew some coffee with the confidence that by the time your cup is ready your tests will be done and your team ready to continue working on core mission, not wrangling with test environments. Welcome to #coffeetime.

It’s a bold move, but we are confident in our industry-leading speed and customer support. For more information on Solano Labs 30/30 visit www.solanolabs.com/3030, visit us at AWS re:Invent (Booth #2320), or join the conversation on Twitter at #coffeetime.

1 Comment

Solano Platform Status Update- November 2016

First and foremost, we want to apologize for delays that some customers have recently experienced with Solano CI. We are in the process of addressing a chain of related issues that emerged over the last week. We’d like to explain what these issues are and how we’ve been addressing them.

The first issue emerged on Tuesday, Nov. 1, when Solano CI began to experience capacity constraints that limited the number of sessions we could support in our SaaS production environment. To the best of our understanding, this capacity issue was due to an unusually high demand for the AWS instance type that Solano CI commonly uses for its production workloads. For some time, Solano was unable to allocate new, healthy AWS instances with our preferred type and region.

In an attempt to mitigate this issue, the Solano team migrated capacity to different instance types that we determined as suitable backups when our preferred types are unavailable. These instance types required enough additional storage that using many of them bumped against an account-level volume limit size imposed by AWS; this killed some instances in use. Because of decreased supply (fewer instances available) and increased demand (restarting killed sessions), build queues backed up. We manually managed them during peak hours to limit slowness and worked with AWS to increase that storage limit, but it took multiple days to complete the process. With the higher limit, we are again able to spin up sufficient capacity for our full peak load.

Coupled with that, the high number of restarts affected other parts of the Solano system. Last week’s unusual load stressed Solano’s infrastructure, including the database, in unprecedented ways. Although most issues are resolved, we are working on one component that seems to be causing some customers’ builds to restart unexpectedly. This is still affecting queue throughput, and is now the critical priority for our engineering team.

Again, we apologize for the effect this has had. We understand how valuable fast builds are to your productivity, and are working to correct the problem as quickly as possible. We will continue to update this blog as more information is available. In the meantime, please don’t hesitate to contact support@solanolabs.com if you have any questions or concerns.


The Solano Support Team

Leave a comment

Welcome to Solano- Test execution

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 them while learning to use the system, while refreshing current users too; we hope you find them handy. Please let us know what you think or if you have any questions.


The key goal of any CI server is to execute automated tests written to evaluate whether software code functions correctly and thereby provide the development team with enough confidence to release that code to users and customers. While the notion of ‘functional correctness’ is a thorny subject, roughly speaking it can mean that the code causes its constituent app to behave in a way that conforms to the developers’ intentions as a discrete thing, and when interacting with the rest of the app’s codebase.

Automated testing, then, is crucial to the success of software development, since it provides feedback about the quality of the codebase and its behavior. And so Solano CI was created as a market-leading way of executing those tests in a fast and efficient manner. It does this by standardizing the method of test execution and providing easily understood reporting of those tests’ results. Below are brief explanations of the two primary means of controlling and implementing that execution: the `solano.yml’ file, and its parallel workers.

Solano will use the user-provided settings in a solano.yml file that is added to the code repo to be tested to determine which tests to run (or commands to execute). (See our docs on configuring with that file here.) The most typical way of selecting which tests you want to run is by test pattern, which filters down the whole list of test files to the desired subset using the syntax of the test file names. You can configure multiple patterns to run in a build.

The YAML file provides a centralized and version-controlled way of configuring the build environment, setup process, and tests run, as well as a source of truth for historical review of individual builds.

Once that set of tests is determined, Solano CI will use a scheduling algorithm driven by machine-learning that takes into account various metadata, like historical runtimes of each of the tests and their IO and CPU usage, to determine the most efficient order in which to execute the tests and the best way to subdivide this set of tests into smaller batches for optimal load balancing and compute utilization. Those batches are then automatically distributed to the parallel workers for execution. And as you continue to run builds in Solano over time, and add or remove tests, Solano will continue to automatically optimize to achieve the best runtimes for your builds.

As each batch is disseminated to the workers, Solano CI will then use whichever command you’ve configured to perform the tests. We recommend using the same command you use locally so that the results in Solano CI should be the same in both environments. If they’re not, we’ve prepared a Troubleshooting Guide that you should reference for suggested debugging steps.

Leave a comment

Solano CI integrates with Google Container Registry


Today, we are proud to announce our integration of Solano CI with Google Container Registry (GCR). With GCR and Solano CI, you can now reliably build, test, and deploy your Docker workflow without operating your own container repositories or scaling your infrastructure. GCR 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 Google 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 GCR and Solano CI. Each commit to the repository will pull a container from GCR, trigger a build, and when all of the tests pass, the new Docker image will be pushed to GCR. Here’s the step-by-step process we used:

Set up necessary projects / permissions

Create a new project within Google Cloud Platform (GCP) for storing your container images.

You’ll need to create a service account, and download the JSON key file in order for Solano CI to authenticate with GCR. More information on creating a service account and downloading the .json key file are in Google’s support docs.

Once you have a new account, you’ll need to add the credentials to your Solano CI repository. Sign up for an account at our website and locate the repository you’re going to be using for your docker container. Download the Solano CLI and from within your repository, run:

solano suite

This will set up your Solano CI build environment.

Use the Secure Environment Variables UI or the Solano CLI to securely add the credentials:

$ solano add:repo GCR_PROJECT_ID project_id_here
$ solano add:repo GCR_SERVICE_ACCOUNT_EMAIL service_account@email.here
$ solano add:repo GCR_SERVICE_ACCOUNT_JSON '{downloaded_json_blob_here: true}'

Push initial image to GCR

We’ll be pulling our initial image from GCR, so you’ll need to build and deploy your docker image using the Google SDK’s gcloud command.

Install the Google Cloud SDK

Follow instructions on pushing your docker image to GCR


Set up Build & Deploy Scripts

The environment section of the solano.yml needs to be modified to use your container’s information.


 'DEPLOY_GCR': 'true'
 'GCR_DOCKER_APP': 'your_app_name_here'
 'GCR_DOCKER_USER': 'your_docker_user_here'
 'GCR_DOMAIN': 'us.gcr.io' (your region's registry url can be found here)
 'GCR_DOCKER_TAG': 'latest'

timeout_hook: 900

 pre_setup: ./scripts/solano-gcr_build.sh
 post_build: ./scripts/solano-gcr_deploy.sh 

 - sudo docker run $GCR_DOCKER_USER/$GCR_DOCKER_APP:$GCR_DOCKER_TAG bash -c /run_tests.sh

Once your solano.yml looks correct, make sure to commit it to your repository.

Our example uses two scripts to build and deploy the GCR containers.  These scripts can be modified to fit your specific use case, but are set up now to use the environment variables supplied in the solano.yml

Start a Build

From within your repository simply use:

$ solano run

and a Solano CI build will initiate. It will run the build script which will attempt to authenticate using the credentials you securely stored in the first step, and if successful will pull down the container you pushed in the second step.

For the test phase, Solano will run the docker container that was pulled down, and execute the `run_tests.sh` script from within the container. If this `run_tests.sh` script exits successfully, Solano CI will start the deploy script.


The deploy script will tag the newly build container, and push it back to GCR for use in the future.


That’s all there is to it! As you can see, GCR is a powerful and robust tool for all your container storage needs!

For more information on deploying to Docker using Solano CI, visit our documentation or contact us, we will be happy to answer your questions :) 

Leave a comment