Solano CI is the only hosted Continuous Integration (CI) provider listed as a build step for AWS CodePipeline.
The AWS blog post, Continuous Delivery for a PHP Application Using AWS CodePipeline, AWS Elastic Beanstalk, and Solano Labs’ blog post, as well as the implementation below demonstrate integrating Solano CI with AWS CodePipeline.
To get setup using AWS CodePipeline with Solano CI, you will need:
- One (1) AWS Account
- One (1) GitHub account
- Repo set up to use SolanoCI - set up your own repo using our guide on Configuring With solano.yml - or fork our Solano CI sample application
- Completed AWS CodePipeline’s setup guide
This video follows the below instructions as a demonstration of a successful setup:
Step 1 - Name¶
Give your pipeline a name. This name will be displayed on the Solano CI dashboard to allow you to keep track of each of your pipelines.
Step 2 - Source¶
Choose and set up your source provider. For this example we’ll use AWS CodePipeline’s Github integration. After allowing AWS CodePipeline to access your source code, choose the repository and branch that you wish to test.
Step 3 - Build¶
Select Solano CI as your build provider and click ‘Connect’. If you do not already have a Solano CI account, you will be directed to a page where you can sign up for our 14-day no-strings-attached free trial using your GitHub account. Existing Solano CI customers without a linked GitHub account should follow the instructions for Linking GitHub with an existing Solano CI Account. Solano CI only needs permission to use your account for authentication, all the source will come from AWS CodePipeline.
After creating an account, you will be brought to the AWS CodePipeline integration page.
Select the organization you want to create the pipeline under and click ‘Connect’ to link your Solano CI and AWS CodePipeline accounts. You will be automatically redirected back to the AWS CodePipeline setup page.
A success banner will be displayed when your account has been successfully connected. You can now continue to the rest of the AWS CodePipeline setup.
Step 4 - Beta¶
Select your deployment target. For this demo we’ve prepared an AWS CodeDeploy Resource. For more information on setting up and managing a deployment target, please see the AWS CodePipeline deployment documentation.
Step 5 - Service Roles¶
Give your pipeline access to the correct IAM User Role. For more information on creating and assigning IAM Roles for AWS CodePipeline see Step 7 in AWS’s how to create a pipeline guide.
Step 6 - Review¶
Review the details of your pipeline and when you’re ready, click ‘Create Pipeline’ to create and test your pipeline.
Congratulations, now all that is left to do is test your new pipeline
Running your pipeline¶
If you wish to test your pipeline, you can click the ‘Release Changes’ button to begin a pipeline run.
Once Solano CI has received the test request, Solano CI begin the process of pulling your source code from the pipeline and registering the session in our system. Once a session is successfully registered Solano CI will update the pipeline with a details link that will take you directly to the running session.
Clicking the details link will bring you to the Solano CI reports page for that particular session. Here you can view the status of your tests and watch them pass in real-time.
Once your tests pass, Solano CI compresses and uploads the source directory for use with the next pipeline step. If you wish to modify the contents of the build directory (i.e. remove source code or .git folder, compile assets) you can use Post-Build Hooks to specify actions to perform on the build directory before Solano CI uploads to the next pipeline step.
Solano CI also reports the status of the session to AWS CodePipeline - a Successful build in Solano will allow the pipeline to continue in its execution.
Solano CI modifies or adds certain files to ruby/rails repos to better collect results
from our parallel test runners (typically
config/boot.rb and various
files). Before delivering your repo to the next step in your pipeline, you may want to
revert these changes with a command like
git reset --hard $TDDIUM_CURRENT_COMMIT in
post_build setup hook.