Child pages
  • AWS CodePipeline Plugin

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

General Info

Author

JetBrains (Victory Petrenko / JetBrains)

License

Apache 2.0

Type

free, open-source

StatusBeta

Download

Latest nightly build on public TeamCity server.

 

Everybody is encouraged to try the plugin and provide feedback in the forum or post bugs into the issue tracker.

Download

Latest  builds on the public TeamCity server compatible with

TeamCity 2017.x

TeamCity 10.0

TeamCity 9.1

Plugin Description

The plugin makes a TeamCity build a part of a an AWS CodePipeline stage by providing a custom job worker for the TeamCity Build and Test AWS CodePipeline actions.

It adds the AWS CodePipeline Action build trigger which polls the AWS CodePipeline for jobs. After the trigger detects a job, it adds a build to the queue. The build downloads input artifacts (depending on the AWS CodePipeline TeamCity action settings), runs the configured build steps and, in case of success a successful build, publishes output artifacts to the AWS S3 for usage in the following steps.

...

subsequent CodePipeline stages.

See Building End-to-End Continuous Delivery and Deployment Pipelines in AWS and TeamCity for step-by step instructions.

TeamCity Versions Compatibility

The plugin is compatible with TeamCity 9.1 and newer.

...

To use the plugin, you need to have a correctly pre-configured AWS resources including:

...

For more information on configuring a CodePipeline pipeline and the required resources, see CodePipeline documentation.

...

Security settings

The currently supported credential credentials types are AWS account access keys (access key ID and secret access key) or temporary access keys received from AWS from the AWS security token service by assuming a role.

Both types are supported by the AWS CodePipeline Action build trigger via the the default credential provider chain.

AWS CodePipeline trigger settings

A CodeDeploy deployment object, an application revision, is an archive (zip, tar or tar.gz) containing the application source files accompanied by the application specification file appspec.yml. The archive is uploaded to an AWS S3 bucket and registered as an application revision in a CodeDeploy application.

To configure the application revision in the AWS CodeDeploy Runner, you need to specify either a path to a ready-made application revision archive (containing appspec.yml) or a set of build checkout directory-relative paths to application files which will be packaged into a zip archive. Ant-style wildcards and target folders like dir/**/*.html => dist/pages are supported. The archive name can be optionally specified via the  S3 object key runner parameter (by default, the corresponding build type external id is used).

To provide a custom appspec.yml file (which will replace the existing appspec.yml if there is one in the build checkout directory) for deployments created by AWS CodeDeloy Runner, the codedeploy.custom.appspec.yml configuration parameter containing valid appspec.yml content or a path to a custom appspec.yml can be specified.

In most cases one needs to register and/or deploy the latest application revision from an S3 bucket, but, if you are using a versioned S3 bucket, you can address a particular S3 object version by adding the codedeploy.revision.s3.version configuration parameter.

Poll interval config parameter

...

ActionID property

To identify an action when making requests to the CodePipeline, the plugin needs the ActionID property. The value must be unique and match the corresponding field in the TeamCity Action settings in the CodePipeline,  and satisfy the regular expression pattern: [a-zA-Z0-9_-]+] and have length <= 20.

 

Action input and output artifacts

Anchor
Action_input_and_output_artifacts
Action_input_and_output_artifacts

CodePipeline TeamCity Build and Test actions can have from 0 to 5 input and/or output artifacts.

If any input artifacts are configured for the corresponding CodePipeline TeamCity action, they are downloaded from the S3 to the temporary directory before the build starts. The folder is specified by the codepipeline.artifact.input.folder configuration parameter which is by default %system.teamcity.build.tempDir%/CodePipeline/input.

In the directory each input artifact can be found by artifact name, e.g. if TeamCity CodePipeline action is a part of a pipeline, has an input artifact named MyApp and the previous action has uploaded some zip file for this artifact name - then during the corresponding TeamCity build, the artifact will be available as %codepipeline.artifact.input.folder%/MyApp.zip.

Similarly, after the build finishes, the files found under the artifact output folder specified by the codepipeline.artifact.output.folder configuration parameter (which is %system.teamcity.build.tempDir%/CodePipeline/output by default) are uploaded to the S3. Each artifact must be represented by an <artifact_name>.zip archive, e.g. to publish some zip file as an artifact named MyAppBuild, place it to %codepipeline.artifact.output.folder%/MyAppBuild.zip. You can achieve this, for example, by adding a Command line build step to your build which runs 

cp MyAppBuild.zip %codepipeline.artifact.output.folder%/

It's recommended by the AWS to use one of zip, tar, tar.gz (tgz) archive types to package artifacts for the AWS CodePipeline.

Trigger poll interval

By default TeamCity build triggers are polled every 20 seconds. To change this period for the AWS CodePipeline Action build trigger, specify codepipeline.poll.interval configuration parameter.

Public repository: https://github.com/JetBrains/teamcity-aws-codepipeline-plugin.

Feedback

The plugin is in active development. Everybody is encouraged to try the plugin and provide feedback in the forum or post bugs into the issue tracker.

...

Original issue in the tracker.

Announcement blog post