Introduction to Amazon Code Pipeline with Java part 19: the job worker initialisation and the job poller interface

Introduction

In the previous post we first discussed the idea of a daemon thread. A daemon thread is most often used to initiate a long running task on its own thread so that the main executing thread is not blocked. A daemon thread is a good candidate to execute the Code Pipeline monitoring task. It will run in the background after executing the servlet initiator class which in turn is run automatically upon application start-up. We also saw how the daemon thread is started in code. However, we still know very little about the class that implements the daemon thread.

We’ll dive into that in this post.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 18: the job worker thread

Introduction

In the previous post we looked at an implementation stub for the JobProcessor interface. The implementation reflects our real life Code Pipeline third party action job process. The business specific logic has been omitted of course as that is not crucial for understanding the code. Probably the most important bit was checking whether the continuation token was present in the incoming Code Pipeline job. That was the basis for distinguishing new load tests from ongoing ones. We also saw how to indicate to CP that a job is ongoing or whether it has finished with success or failure.

In this post we’ll start looking into how to start the job checking thread.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 17: the JobProcessor implementation

Introduction

In the previous post we continued to explore the job processor interface of the job agent. In particular we looked at the WorkResult object which holds a number of properties that describe the job result. These include a summary message, the failure reason, the progress made and various others.

In this post we’ll discuss a possible implementation of the JobProcessor interface. Note that the exact implementation will depend on your business since this is where the actual Code Pipeline work item is processed. Our implementation the interface is also very tightly coupled with the load testing domain of our business. Hence I won’t present every single detail around that code as much of it irrelevant for Code Pipeline and the job agent.

Read more of this post

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