Introduction to Amazon Code Pipeline with Java part 16: the WorkResult object

Introduction

In the previous post we looked at the job processor interface of the Code Pipeline third party action job agent. The job processor is responsible for processing a new job item returned by polling a Code Pipeline endpoint. The interface has a single method called process which accepts a WorkItem object and returns a WorkResult object. We discussed the WorkItem object in detail. In this post we’ll go through the WorkItem object.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 15: the job processor interface and related objects

Introduction

In the previous post we looked at a helper class that’s responsible to carry out operations related to load tests. We didn’t actually look at any implementation details as those are bound to our business and don’t have much to do with Code Pipeline. However, it is still important to know its role so that we can follow the code examples. We also briefly looked at some other classes like the one that parses the string that describes the load test thresholds into “real” objects.

We are now ready to move on to the job processor interface and a couple of related objects. We’ll look at the implementation in a later post.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 14: the loadtest executor service

Introduction

In the previous post we took a closer look at how the client token lookup service could be implemented. The client lookup service is responsible for locating the Code Pipeline client token that matches the client ID which CP sends as the first signal of a new job. Without a matching client token CP won’t hand out the job details. It’s up to you how you implement the service exactly. The implementation details will probably depend on how you stored the client token and the client ID of a given user in your backend system.

In this post we’ll keep digging into the code in the job agent by looking at the LtpApiLoadtestJobExecutorService class.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 12: the job agent entry point in code

Introduction

In the previous post we started looking into the Code Pipeline job agent application. The job agent can be any application that is capable of executing long-running threads that periodically communicates with a Code Pipeline endpoint through the AWS SDK. The model application we’re going to look at is a Java Maven web app. It can be deployed directly on a Tomcat server or in AWS Elastic Beanstalk – which is actually a wrapper around an EC2 server with Tomcat installed.

In this post we’ll start looking into some actual Java code within the job agent. Note that I won’t provide every single detail in this series as most of the code is related to our business and is therefore irrelevant to the current discussion. You should also have at least some experience with Maven and things like the web.xml file. I will also omit infrastructure related code such as reading the properties or logging with log4j as much as possible. I’ll only show that type of code where it would otherwise be difficult to follow where a certain variable is coming from. We’ll actually see some of that in this post. This is in order to minimise the “noise”. You are welcome to ask specific questions in the comments section.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 11: starting with the job agent

Introduction

In the previous post we looked a bit at the web pages that must be up and running for the third party action to work with code pipeline. There are 3 types of URL that must be set up. The external configuration URL defines a web page where the CP user can provide the necessary inputs for the job execution. The execution URL is where the CP user can follow the job execution, i.e. where you can show tables, graphs etc. that show the job progress. Lastly we have the entity URL which is a web page to show some resources or job summary page to the user.

In this post we’ll start looking into the job agent itself. It’s probably the largest component you’ll need to build for the CP integration.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 10: the client web pages

Introduction

In the previous post we looked at an important component that comes up during a job execution in CodePipeline, namely the continuation token. The continuation token can be supplied in the response to CP when a new job is processed. The token will then appear the next time the job agent gets a signal about a new job. That way the job agent will know that it’s a job that has already been initiated. The job is in effect divided up into multiple small partial jobs coming from CP. The partial jobs will keep coming until the job agent has indicated a 100% completion rate.

We’re almost at the point where we can start looking at the structure of the job agent itself. Before we do that I’d like to present you what type of web pages you’ll need to build for a third party action. We’ve already seen some pictures but I’d like to provide some further details.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 9: the job agent continuation token

Introduction

In the previous post we went through the details behind the communication between CodePipeline and the third part action. The job agent is responsible for for this communication on the side of the third party action. It must monitor a CodePipeline endpoint for new jobs and then acknowledge the job in some way, e.g. by sending a success or failure message. We also mentioned the role of AWS S3 which will store the artifact that enters the pipeline.

We’re at the point where the job agent will act upon the job details received from CP and start the actual work. There’s, however, at least one remaining implementation detail that is important to be aware of when designing this communication process. It’s called the continuation token and this is what we’ll look at in this post.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 8: the job agent communication process

Introduction

In the previous post we went through the details behind the communication between your web site and CodePipeline when a CP user selects your third party action. The third party action developer will be responsible to set up and maintain an external configuration page where CP users can complete their action configuration. CP and the external page communicate with each other using HTTPS POST calls and URL-encoded JSON objects. CP sends a number of properties to the configuration page in the JSON object. These include the client ID and client token that you’ll need to save in your data store and map them to a user in your system. The configuration page redirects the user to the CP GUI with the list of key-value pairs that contain the configuration values for the test runner. These values will be available to the job agent when the job runs.

In this post we’ll look into the details of the communication between CP and the job agent. This post will go through the process at an overall level. The upcoming code examples will show a lot more details.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 7: the third party action user signup process

Introduction

In the previous post we went through an overview of third party actions in Amazon CodePipeline. They are similar to custom plugins in other CI tools like TeamCity and Jenkins. However, their structure, architecture and deployment are very different. The third party action developer must be aware of the job agent and how it communicates with an Amazon CodePipeline endpoint to pull new jobs and process them in some way. The job agent is the connecting tissue between CodePipeline and your backend services. You can deploy multiple job agents for load balancing.

In this post we’ll continue looking at the communication flow between the third party action and CodePipeline.

Read more of this post