GitLab Pipelines for Customer Projects

This guide is a hard copy, the original resides in: https://gitlab.pricefx.eu/public-tools/build-templates

 

First, ensure that you have a .gitlab-ci.yml file in the root directory of your project.

Generate the file from Pricefx Studio by right clicking the root folder > Pricefx > Create ‘.gitlab-ci.yml’.

This will generate a file that refers to the common template .gitlab-ci.yml in the public repo https://gitlab.pricefx.eu/public-tools/build-templates which contains the common definition of the stages.

include: - project: 'public-tools/build-templates' ref: master file: '/test+analyze+deploy/.gitlab-ci.yml'

This template test+analyze+deploy says it will run:

  • test = automatic unit testing

  • analyze = SonarQube analysis

  • deploy = automatic deployment using the pfxpackage tool

For each partition where you want to use the automatic deployment there will be a block like this:

# Deploy dev branch to dev partition deploy-dev: extends: .deploy when: manual only: - dev variables: PARTITION: partition-dev URL: https://dev.pricefx.eu

Notes:

  • You should set the name of the job to correspond to your partition, eg. deploy-qa or deploy-prod.

  • You must set the PARTITION and URL variables for your environment.

  • You must set which branch to use for the source under the only section.

  • PFX_USER and PFX_PASS CI variables must be set up by Gitlab admin as CI variables in the repository settings.

    • Contact a Gitlab admin to add these CI variables to your repo either via Gitlab channel in MS Teams or via a support ticket. If you are the admin of the repo, you can do this fully on your own.

    • Ask to set PFX_USER to pfx.deploy and PFX_PASS to a strong password (at least 14 characters, at least 1 digit, at least 1 capital letter).

    • Create a user account pfx.deploy which has General Admin privileges in each of the partitions where you want to enable deployment and set the password provided by the Gitlab admin.

  • If you want to change the deployment behavior, you can use:

    • when: always – Automatically triggers the deployment when the Git branch is updated. This is preferred for QA/PROD where merging to branch should always trigger deployment.

    • when: manual – Creates the job but needs to be manually triggered in Gitlab in order to run. This is preferred for DEV where you normally do not want to deploy to a partition but you have the manual option if needed.

A typical CI file with unit test + analyze + deployment stages (for 3 partitions) looks like this:

include: - project: 'public-tools/build-templates' ref: master file: '/test+analyze+deploy/.gitlab-ci.yml' # Deploy dev branch to dev partition deploy-dev: extends: .deploy when: manual only: - dev variables: PARTITION: partition-dev URL: https://dev.pricefx.eu # Deploy qa branch to qa partition deploy-qa: extends: .deploy when: always only: - qa variables: PARTITION: partition-qa URL: https://qa.pricefx.eu # Deploy master branch to prod partition deploy-prod: extends: .deploy when: always only: - master variables: PARTITION: partition URL: https://prod.pricefx.eu

 

After following the above instructions, the deployment can still fail with errors like this:

ProcessingException:'RestPricingParameterSupplier': Failed to get lookup table tree! : Not authorized for command: LOOKUPTABLETREE_FETCH

[main] ERROR net.pricefx.pckg.processing.ProcessingContext - Unable to fetch advanced configuration : Not authorized for command: APPLICATIONPROPERTIES_FETCH

To overcome such errors, the pfx.deploy account will need to have user roles. This depends on what “elements“ you checked in Git and what needs to be deployed. For all components that need to be deployed like PP tables, workflow, Datamart etc. the pfx.deploy account needs to have all required administer roles to manage these objects. This is in addition to the General Admin user role.

Found an issue in documentation? Write to us.

Â