Introducing CI Pipelines v2 With More Flexibility

2023-06-206 minute read

We’re thrilled to introduce version 2 of Argonaut’s CI pipelines. This update brings several changes that enable our users to go beyond 1 build and 1 deploy stage and create more complex deployment flows. In this blog, we will guide you through these changes and show the new components in the create and edit deployments flows.

When you click on the applications from the sidebar, you will see a familiar list of applications and pipelines. However, these screens can now show the states of more than 2 stages for each of your pipelines. This is the status of your pipeline’s latest run.

You’ll see the new screens once you select an existing pipeline or create a new pipeline.

The previous pipeline builder had a Builder tab and a Run History tab.

In the new version, you see the builder view on the right side and the history on the left side of the screen. The History tab shows the latest runs of the selected pipeline. And on the top left, you will see a Configure pipeline button that allows you to customize and add new stages to the pipeline.

New pipeline builder

Unlocking more deployment possibilities

With the new updates, our UI is also updated to support different combinations stages. This can allow more use cases, some of which are discussed here.

Deployment types

Parallel deployments

These deployments use one build stage and have different deployment stages. Using one build image across deploy stages helps save on costs and create identical copies of your app across environments. An example where such a pipeline can be used would be for deploying an app across different cloud provider regions.

Sequential deployments

These pipelines have one build image and multiple deployment stages. They are arranged in a sequential manner, and the user can also have the option to trigger a deployment manually. An example use case would be to deploy the app first in the pre-prod environment before deploying it to prod.

Deploy without building

Sometimes, you might have a pre-built image in your repo, in such cases, you can go ahead and directly initiate the deploy stage, which deploys the app in your environment. Examples of this could be deploying third-party tools with pre-built images.

Tracking unsaved changes

The pipeline builder will now track changes whenever you make a change to the pipeline or to one of the stages in the pipeline. This is done to ensure you don’t lose any unsaved changes to the configurations or pipeline stages.

Whenever a new change is made to the pipeline, you will see a “Pipeline has unsaved changes” alert next to the Save Pipeline button. There is also an additional prompt that pops up when you reload the page or navigate away.

Each pipeline stage also shows an alert if the info populated in that stage isn’t yet saved.

While creating a new stage in the pipeline, you will see an amber dot to indicate unsaved changes in that stage. And only once those stages are saved, can you save the pipeline and trigger the pipeline.

Changes in pipeline

Here are some common user actions that can lead to unsaved changes. Some are on a stage level, while others are on a pipeline level.

ActionUnsaved changes
New stage addedStage & Pipeline
New pipelineStage & Pipeline
Stage configurations changedStage & Pipeline
Stage configurations are savedPipeline
A stage is deletedPipeline
Git user modifiedPipeline
Git repo modifiedPipeline
Git branch modifiedPipeline
Triggers added/removedPipeline

Pipeline’s run history

On the left side of the screen, you will see the history. This stores records of all your previous pipeline runs, along with time, branch, commit ID, and other useful information. Previously, you could only see the history but not interact with it on a stage level.

Now, we provide a more detailed view of your history in read-only mode. This shows more information about the stages used in that pipeline, along with the configs, env. values, and more!

You can still get more details on the history of specific stages in your latest deployment.

Click on Configure Pipeline and click on your desired stage.

Build stage - You can view the build history of the selected Build stage

Deploy stage - You can view deployment logs, monitoring, as well as the history of the selected Deploy stage

We currently do not have a rollback option. The history tab is only meant to check the previous configs and can be useful to debug failed runs.

New Stage creation flow

By default, each pipeline is created with a build and a deploy stage.

To create a new deploy stage, click on the + icon to the right of any of the existing stages.

  • Enter a custom name for the deployment
  • Click Continue
  • Inside the stage Configs page, make the necessary changes, and click Save

💡 Note: All deploy stages are automatic by default. To change it to manual deploy, click on the ▶️ button in the Pipeline builder view.

Each pipeline can also have more than one build stage. To create a new build stage, click on Init Stage + on the top bar.

  • Enter a custom name for the build stage
  • Click Continue
  • Inside the stage Configs page, make the necessary changes, and click Save

Creating a new stage

Overflow menu for each stage

In each stage, users get access to quick actions for that particular stage. This can be accessed by clicking on the three dots next to the stage’s name. Currently, it only has a delete action. We will be adding more actions in the future.

Deleting a stage

A stage can be deleted by clicking on the three dots to bring up the overlay menu. Then click on delete. This removes the stage and creates a direct connection between the previous and the next stage in the pipeline. Stages, once deleted, cannot be restored.

Reset layout button

If you have multiple stages and your pipeline looks messy, you can use the auto-align button to bring your stages in order. Find it in the bottom left of your builder next to the + / - zoom buttons.

Reset a pipeline layout

Status indicators

Here’s a reference to the different status indicators of build and deploy stages.

Status indicators

Keep in mind

  • Every new pipeline will have just one Git Repo, which cannot be changed later.
  • The build stage now has two save options - Commit to Repo and Raise a PR.
  • Triggers are useful when you want to deploy only on changes to a specific path in the repo.
  • Use the ▶️ / ⏸️ button to switch between automatic and manual deployments.
  • Default stage names have been made more readable now; we recommend you rename them while creating, as the name of the stage cannot be changed once they are created.

Video walkthrough

Last post

Helm Best Practices: Proven Strategies to Streamline Kubernetes Deployments Using Helm

21 June 2023
Next post

Helm Guide: An Introduction to the Kubernetes Package Manager

14 June 2023