Behind the scenes, when you build a pipeline in LambdaCD, you are actually building a small app in clojure so you’ll need some tools:
- A recent JDK
- Leiningen as a build tool
- A decent editor. To get started, whatever you are comfortable with is fine. If you want to really dive in, consider something with good Clojure support. Cursive and Light Table are popular choices, as are general purpose editors with Clojure support.
That’s it. You just generated a first pipeline that runs on http://localhost:8080 on your machine. You’ll have a choice of two UIs but for now, let’s stick with the reference UI that comes with the core of LambdaCD:
Click the arrow icon on the first step to trigger the pipeline. Now your pipeline runs, and you’ll notice the steps getting green or red one by one. Click on any of the steps the view the steps output.
A quick tour around the code
So let’s take a look what we just created. If you don’t know Clojure yet, don’t be scared if some of the syntax looks unfamiliar. Your first steps won’t require you to be a Clojure ninja.
This is a Leiningen project definition. You declare your dependencies here and other things about your project. We’ll get back to this later to add additional libraries to LambdaCD.
Your pipeline code lives in this namespace. By default, we split up the structure of the pipeline and the build steps but you can organize your code any way you want.
This file is contains the initialization and the structure of the pipeline.
Like any other clojure code file, it starts with the namespace declaration and imports of required namespaces:
More importantly, we define a constant
pipeline-def which holds your pipelines structure:
This file contains the custom build steps that were referenced in the pipeline structure you just saw.
Again, we start with the namespace header. Specifically, we import the
lambdacd.steps.shell namespace under the name
shell. This provides LambdaCD support for executing commands on the shell.
Next, we’ll define the simplest possible build step. Every build step is a clojure function (that’s what the
all about) with two parameters,
args is how build steps exchange information with each other.
contains the build steps LambdaCD context. It provides some functionality you’ll need as your build steps get more advanced.
For now, all you’ll need to know is that some things (like shell support) require you to pass this on.
Apart from taking in two arguments, each build step is required to return a map that contains at least if it succeeded or not. All in all, this is the simplest successful build step you could write:
Most of the time though, library functions will take care of actually assembling all that for you, so for now, we are just doing the most obvious thing to do in a build pipeline. We execute some shell commands:
This namespace includes the
-main entrypoint to your application, taking care of wiring everything together,
setting up configuration and starting pipeline and server:
This namespace contains the routes and HTML to give you a choice between two UIs. If you at some point have a preference for one UI or want to customize it, this is the place to make changes.
For now, don’t worry about it too much.
Checking out a git repo and doing some real work
Most build pipelines need to touch version control at some point. So let’s see how we can wait for commits, check out a repository and run some tests.
So let’s change our pipeline to something that does this:
A couple of things aren’t there yet:
wait-for-repoto wait for commits on a repository
cloneto check out the repository and run other steps on the checked out repository
run-some-testsactually run some tests.
Let’s get started!
We’ll also import the namespace it provides in
Also, let’s put the repository information into a constant so we can use them in both git-related steps we are going to build. We’ll use LambdaCDs own repository here as an example:
Now that we have everything we need set up, let’s create the build steps:
Nothing too surprising here: We call a library function to do the heavy git-lifting for us. Two things stand out: How do we know where to clone the repository and what revision to clone?
Well remember I mentioned before that
args is how build steps communicate with each other? We are using this here:
with-workspace passes in the path of the workspace directory it created as
wait-for-repo provides us with a
:revision value (we fall back to the branch in case the build was triggered manually).
Now all that’s left to do is actually run the tests (and remember to use our workspace (
cwd) as the working directory):
And that’s all you need.
lein run your pipeline again and see the it all work.
Where to go from here?
- Find out how to do implement some common, more advanced use cases
- Read the FAQs and the Documentation
- Check out how to refactor a complex pipeline
- Go through a comprehensive walkthrough, implementing a complete delivery pipeline and going deeper into the details of LambdaCD
You might notice that LambdaCD itself already contains git-support in the
lambdacd.gitnamespace. It has a number of drawbacks (mainly in terms of flexibility and robustness) and will probably be deprecated in the future. Therefore, we are using the newer, more feature-rich lambdacd-git in this guide. ↩