Multi-purpose Commerce Tool · CloudOps for Kubernetes

note

The Jenkins job multi-purpose-commerce-tool was previously called commerce-ci-pipeline. The name of the job was changed in CloudOps for Kubernetes v2.6 to better reflect how it is used and the breadth of capabilities and options that are available in the job.

The multi-purpose-commerce-tool job provides callers with a way to orchestrate and run multiple Self Managed Commerce build and deployment jobs in a single location. It can be used to complete the following tasks:

Build the Commerce deployment package
Run Commerce unit tests, either all tests or just those under the Commerce extensions folder
Build necessary Docker images
Run data population
Deploy a Self Managed Commerce stack
Run Cortex system tests

The job works by calling other Self Managed Commerce build and deployment Jenkins jobs beneath the covers. The multi-purpose-commerce-tool job is highly-configurable; each time it is run the caller can select which Self Managed Commerce tasks they want to run and which they do not want.

Jenkins job parameters

The following parameters are available in the Jenkins job multi-purpose-commerce-tool:

`containerUser`

Indicates whether the container images will be built to run as the root user or the non-root user. It cannot be empty.

Set to non-root if the container images are built to run as non-root (for example, they are built with release 4.2.x or newer of the Elastic Path Docker repository).

Set to root if the container images are built to run as root (for example, they are built with release 4.1.x or earlier of the Elastic Path Docker repository).

`buildCommerce`

If buildCommerce is set, the Jenkins job builds a Commerce deployment package from the provided Commerce branch and Git URL.

If the parameter is not set, ensure that a deployment package has been built at least once matching the Commerce branch and Git URL passed to this job.

`buildCoreImages`

If buildCoreImages is set, the Jenkins job builds core Docker images. This includes base images, ActiveMQ, MySQL and the information page images.

If the parameter is not set, ensure that core Docker images have been built at least once matching the Elastic Path Docker branch passed to this job.

`buildCommerceImages`

If buildCommerceImages is set, the Jenkins job builds Commerce Docker images including:

Cortex
Commerce Manager
Search
Integration server
Batch server
Data Population Tool

If the parameter is not set, ensure that Commerce Docker images have been built at least once matching the Elastic Path Docker branch, and Commerce branch and Git URL passed to this job.

`runBlockingTests`

If runBlockingTests is set, the Jenkins job waits for unit tests to finish successfully before proceeding with deployment.

`runNonBlockingTests`

If runNonBlockingTests is set, the Jenkins job runs unit tests in parallel to deployment. If the unit tests fail, the Jenkins job is marked as unstable.

`runCortexSystemTests`

If runCortexSystemTests is set, the Jenkins job runs Cortex system cucumber tests.

`deployActiveMq`

If deployActiveMq is set, the Jenkins job deploys an ActiveMQ service.

If the parameter is not set, ensure that an ActiveMQ service exists in the same Kubernetes namespace that was deployed using CloudOps for Kubernetes.

`deployMySQL`

If deployMySQL is set, the Jenkins job will deploy a MySQL service.

If the parameter is not set, ensure that a MySQL service exists in the same Kubernetes namespace that was deployed using CloudOps for Kubernetes.

`useMySQLServer`

If useMySQLServeris set, the pipeline uses a production-style database. If it is not checked, a MySQL Pod is used. If both deployMySQL and deleteMySQL are not checked, it does nothing.

`deployCommerce`

If deployCommerce is set, the Jenkins job deploys a Self Managed Commerce stack, including the Wiremock (mock) service.

If the parameter is not set, ensure that a Self Managed Commerce stack exists in the same Kubernetes namespace.

`restartApps`

Select this if you want to ensure that the Self Managed Commerce applications restart. Without this set, the applications will restart only if the Docker image tag changes.

`enableUITests`

Enables Eclipse widget IDs in Self Managed Commerce manager to facilitate Commerce Manager user interface (UI) testing. Set this parameter to true if your team will run Commerce Manager Selenium tests against the Self Managed Commerce stack deployed by this job.

`plan_mode`

When selected, this runs Terraform in plan mode when deploying the Commerce stack and ActiveMQ container. You are prompted to approve changes before the pipeline can continue.

`includeHorizontalPodAutoscalers`

Creates or deletes horizontal pod autoscalers. It automatically scales the number of pods in the deployment based on CPU usage. The default setting is false.

`makeActiveMQHighlyAvailable`

If makeActiveMQHighlyAvailable is set, it deploys the ActiveMQ service in a high-availability configuration. Typically, this will not be set in development and test environments but is set in production environments. Both makeActiveMQHighlyAvailable and deployActiveMq have to be set to true for ActiveMQ to be deployed in this configuration. The default setting is false.

`runDataPop`

If runDataPop is set, the Jenkins job runs data population against the ActiveMQ and MySQL services.

If the parameter is not set, ensure that data population has been run in reset-db mode at least once against existing ActiveMQ and MySQL services.

`deleteOldStack`

If deleteOldStack is set, the Jenkins job deletes the Commerce stack from a previous run of this job, if any exists.

`deleteNewStack`

If deleteNewStack is set, the Jenkins job will teardown the Commerce stack deployed by this run.

`deleteActiveMQ`

When you run this job you can choose to clean up any ActiveMQ services left behind by previous runs or to delete new ActiveMQ services created by the run itself. Both deleteActiveMQ and deleteOldStack have to be set to delete the service deployed by a previous run. To delete the service deployed by the job itself deleteActiveMQ and deleteNewStack have to be set.

`deleteMySQL`

When you run this job you can choose to clean up any MySQL services left behind by previous runs or to delete new MySQL services created by the run itself. Both deleteMySQL and deleteOldStack have to be set to delete the service deployed by a previous run. To delete the service deployed by the job itself deleteMySQL and deleteNewStack have to be set.

`passBuildEvenIfCommerceTestsFail`

Set the parameter to true to mark the Jenkins job as unstable when any Commerce tests fail. Set the parameter to false to mark the Jenkins job as failed when any Commerce tests fail.

`passBuildEvenIfCortexTestsFail`

Set the parameter to true to mark the Jenkins job as unstable when any Cortex tests fail. Set the parameter to false to mark the Jenkins job as failed when any Cortex tests fail.

`allowedCidr`

A comma-separated list of CIDRs allowed to access deployed services.

`allowOpenAccess`

Verification that you are deploying Self Managed Commerce with the Jenkins job parameter allowedCidr set with the CIDR 0.0.0.0/0. Set this parameter to true to acknowledge that you allow the Self Managed Commerce services to be accessible by the open internet.

`epStackResourcingProfile`

The resourcing profile of your Commerce stack.

`dataPopToolCommand`

The Data Population tool command to run on the ActiveMQ and MySQL services. Ensure that the command is either reset-db or update-db.

If runDataPop is set to false, nothing is run. Ensure that the command reset-db has run at least once against the ActiveMQ and MySQL services.

`epEnvironment`

The Commerce environment to deploy and initialize with the Data Population tool. The Data Population tool will not initialize the environment if runDataPop is false.

`dnsZoneName`

The DNS zone created when initializing the cluster you are deploying to.

The hostname of deployed Commerce services will include this value. For more information see the parameter dnsSubDomain.

`clusterName`

The Kubernetes cluster where to deploy services.

The hostname of deployed Commerce services will include this value. For more information see the parameter dnsSubDomain.

`kubernetesNickname`

This job uses the value of kubernetesNickname as the Kubernetes namespace where services are deployed and secrets stored, and as part of the Self Managed Commerce environment’s domain name. If the namespace does not exist, this job creates it. To be compatible with Terraform, Kubernetes, and DNS domain name requirements, ensure that the kubernetesNickname is lowercase and alphanumeric.

If you specify a nickname and namespace value where resources are already deployed, then those resources will updated.

An example of how the various input values are used to create the DNS host names can be seen in the following table:

Parameter	Example value
`kubernetesNickname`	`default`
`clusterName`	`hub`
`dnsZoneName`	`ep.example.com`

The hostnames for Commerce services would be:

Service	Hostname
Cortex	`default.commercehub.ep.example.com/cortex`
Studio	`default.commercehub.ep.example.com/studio`
Commerce Manager	`default.commercehub.ep.example.com/cm`
Integration	`default.commercehub.ep.example.com/integration`
Information Page	`default.commercehub.ep.example.com/`

`cloudOpsForKubernetesBranch`

The CloudOps for Kubernetes branch to use when cloning the Jenkinsfile that defines how the CI pipeline is run.

`cloudOpsForKubernetesRepoURL`

The CloudOps for Kubernetes Git repository to use when cloning the Jenkinsfile. The Jenkinsfile defines how the CI pipeline is run.

`dockerRepoURL`

The Elastic Path Docker Git repository to use when building Docker images.

`dockerBranch`

The Elastic Path Docker branch to use when building Docker images.

`dockerCredentialId`

The Jenkins credentials to use when checking out the Elastic Path Docker code.

`epCommerceRepoURL`

The Commerce Git repository to use when building Commerce related artifacts.

`epCommerceBranch`

The Commerce branch to use when building Commerce related artifacts.

`epCommerceCredentialId`

The Jenkins credentials to use when checking out the Self Managed Commerce code.

Next Steps

After you deploy and (optionally) test the Elastic Path stack, continue to the post deployment steps.