The site that you are currently viewing is a static version of the Software Factory documentation delivered with the

version v7.2.
For up-to-date documentation, see the latest version.

NextGen CICD

NextGen CICD

NextGen CICD is an Inner Source project that provides a standalone catalogue of ready-to-use reusable steps and pipelines that support CI/CD best practices. Virtually every step runs in a container based on a trusted image we provide.

The objective is to speed up the lead time for a project to set up a CI/CD pipeline by using templates with the ability to customize them or create their own pipelines based on individual steps that we provide in the catalogue.

The change log of the catalogue is available in the Change log, but also in this Teams release channel .

Additionally, our team provides support for the catalogue, including usage and contribution. Two ways to get support:

You are also welcome to contribute!

Get Access

Accessing NextGen-CICD requires the DevOps offer; refer to Getting Started instructions.

Requirements

Why should you use it?

To speed up and standardize continuous integration, continuous delivery, and continuous deployment steps. With this, you can design pipelines that are standardized and platform-independent. If the catalogue doesn’t fit your needs, you can contribute or ask for support on a specific step or use the Teams support channel for direct support.

We provide the integrated project in GitLab available at:

For information Artifactory repositories are also mirrored on carma as nextgen-cicd-docker and nextgen-cicd-generic .

Access to the NextGen CICD project is granted by default when you have access to TDP C2, TDP C3 or CASTLE.

For RTDP, see the specific note in the get-started page.

Features

Feature NameLevel of availability (EA/GA)Value
Use a step in the catalogueAvailable (GA)Pick a step in the catalogue

With the Teams support channel , we provide support for all these features if they are not working properly or if you encounter issues on our side.

For official documentation, see usage

How to

… use?

Current set of step available is:

StepLink to C2Link to C3*Link to CASTLE
“Ansible           “Ansible on C2Ansible on C3*Ansible on CASTLE
“Antora            “Antora on C2Antora on C3*Antora on CASTLE
“Artifactory       “Artifactory on C2Artifactory on C3*Artifactory on CASTLE
“AsciiDoctor       “AsciiDoctor on C2AsciiDoctor on C3*AsciiDoctor on CASTLE
“Badge             “Badge on C2Badge on C3*Badge on CASTLE
“Bats              “BATS on C2BATS on C3*BATS on CASTLE
“Black Duck        “Black Duck on C2Black Duck on C3*Black Duck on CASTLE
“C/C++ compiler    “C/C++ compiler on C2C/C++ compiler on C3*C/C++ compiler on CASTLE
“Cinc Auditor      “Cinc Auditor on C2Cinc Auditor on C3*Cinc Auditor on CASTLE
“Clamav            “Clamav on C2Clamav on C3*Clamav on CASTLE
“Commitlint        “Commitlint on C2Commitlint on C3*Commitlint on CASTLE
“Confluence        “Confluence on C2Confluence on C3*Confluence on CASTLE
“Cosign            “Cosign on C2Cosign on C3*Cosign on CASTLE
“Coverity          “Coverity on C2Coverity on C3*Coverity on CASTLE
“Dependency-manager”Dependency-manager on C2Dependency-manager on C3*Dependency-manager on CASTLE
“Dive              “Dive on C2BATS on C3*Dive on CASTLE
“Doc2pdf           “Doc2pdf on C2Doc2pdf on C3*Doc2pdf on CASTLE
“Docker            “Docker as a CI component on C2 or legacy stepDocker on C3*Docker on CASTLE
“Dotnetcore        “Dotnetcore on C2Dotnetcore on C3*Dotnetcore on CASTLE
“Fortify           “Fortify on C2Fortify on C3*Fortify on CASTLE
“GitLab-SCA        “GitLab-SCA on C2GitLab-SCA on C3*GitLab-SCA on CASTLE
“GitLab CLI (glab) “GitLab CLI (glab) on C2GitLab CLI (glab) on C3*GitLab CLI (glab) on CASTLE
“Golang            “Golang on C2Golang on C3*Golang on CASTLE
“Gradle            “Gradle on C2Gradle on C3*Gradle on CASTLE
“Hadolint          “Hadolint on C2Hadolint on C3*Hadolint on CASTLE
“Hugo              “Hugo on C2Hugo on C3*Hugo on CASTLE
“Helm3             “Helm3 on C2Helm3 on C3*Helm3 on CASTLE
“JMeter            “JMeter on C2JMeter on C3*JMeter on CASTLE
“Markdown lint     “Markdown lint on C2Markdown lint on C3*Markdown lint on CASTLE
“Maven             “Maven on C2Maven on C3*Maven on CASTLE
“McAfee            “McAfee on C2McAfee on C3*McAfee on CASTLE
“MkDocs            “Mkdocs on C2Mkdocs on C3*Mkdocs on CASTLE
“NexusIQ           “NexusIQ on C2NexusIQ on C3*NexusIQ on CASTLE
“npm and nodejs    “npm and nodejs as a CI component on C2 or legacy stepnpm and nodejs on C3*npm and nodejs on CASTLE
“Pipeline utils    “Pipeline utils on C2Pipeline utils on C3*Pipeline utils on CASTLE
“Polarion-CI       “Polarion-CI on C2Polarion-CI on C3*Polarion-CI on CASTLE
“Python            “Python as a CI component on C2 or legacy stepPython on C3*Python on CASTLE
“Release           “Release on C2Release on C3*Release on CASTLE
“Renovate bot      “Renovate Bot on C2Renovate Bot on C3*Renovate Bot on CASTLE
“Robot Framework   “Robot Framework on C2Robot Framework on C3*Robot Framework on CASTLE
“Rust              “Rust on C2Rust on C3*Rust on CASTLE
“Semantic release  “Semantic release on C2Semantic release on C3*Semantic release on CASTLE
“Semversioner      “Semversioner on C2Semversioner on C3*Semversioner on CASTLE
“Skopeo            “Skopeo on C2Skopeo on C3*Skopeo on CASTLE
“SonarQube         “SonarQube as a CI component on C2 or legacy stepSonarQube on C3*SonarQube on CASTLE
“Syft              “Syft on C2Syft on C3*Syft on CASTLE
“Terraform         “Terraform on C2Terraform on C3*Terraform on CASTLE
“Trivy             “Trivy on C2Trivy on C3*Trivy on CASTLE
“Vale              “Vale on C2Vale on C3*Vale on CASTLE

See also details of the steps inside the catalogue on C2 , on C3* or on CASTLE .

Here is a demo of usage and contribution to nextgen-cicd .

… use elsewhere than TDP C2

On TDP C2, containers are stored inside GitLab in internal project container registries. Therefore, the GitLab default token grants access to them.

On other platforms, you need to set DOCKER_AUTH_CONFIG as described in GitLab documentation .

For example, group and/or project variables can be:

DOCKER_AUTH_CONFIG: { "auths": { "artifactory.XXXX": { "username": "$DOCKER_AUTH_CONFIG_USERNAME", "password":"$DOCKER_AUTH_CONFIG_PASSWORD"}, "$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"} } }
DOCKER_AUTH_CONFIG_USERNAME:` with user or service account email
DOCKER_AUTH_CONFIG_PASSWORD:` with user or service account identity token as a masked variable to preserve the secret

RACI

  • Responsible, Accountable, Consulted, Informed
ActionDescriptionFactory SupportSoftware SolutionBusiness adminProject team adminProject team memberRequest *
Contribute to an existing or a new stepFrom GitLab, you contribute to a step development in GitLab on C2.CNA
Validate a contribution and publish a step in the catalogueFrom GitLab, Software Solution validate a merge request in GitLab on C2 and publish a step.R/ACNA
Use a stepFrom GitLab, you use a step in the catalogue.R/ANA

Contact Us