PIM Deployment 2.0 [ArgoCD]


Overview

From IM 8.0, PIM instances are deployed through ArgoCD. This supersedes the GitLab pipelines that used to run inside your PIM repository — those pipelines are removed, and the deployment happens outside your repository.

This page describes what changes for you: what your repository looks like after the migration to 8.0, where your actions (restart, rollout, configuration changes) are applied now, and what delay to expect.


No more pipelines in your repository

After the migration to IM 8.0, your PIM repository no longer runs deployment pipelines:

  • A commit does not trigger a pipeline. The running instance picks your changes up itself — see Git Sync.

  • A restart, start, stop, or configuration change does not trigger a pipeline either.

  • Do not look for pipeline runs to confirm that an action happened — nothing runs in your repository anymore.

The only pipelines you can still see are the custom image build pipelines. They run only when a custom image build is requested (for example after you add custom dependencies), and they are the one exception to the rule above.


Your .gitlab-ci.yml looks different

The migration rewrites the .gitlab-ci.yml in your PIM repository. Two things change:

  1. The template reference is different. The file includes a new template project and file, and the ref now follows the latest infrastructure (main) instead of a pinned infrastructure version — see Latest Infrastructure Model.

  2. The variables: section is removed completely. The deployment configuration no longer lives in your repository.

Up to IM 7.x (GitLab pipeline deployment):

YAML
include:
  - file:
      - im-lifecycle-gitlab-ci.yml
    project: integration-k8s/deployment/gitlab-ci-templates
    ref: <pinned infrastructure version>
variables:
  CLOUD_PROFILES: "qa,awsqa"
  IM_CPU: 1000m
  IM_ENVIRONMENTS: ^dev$|^qa$
  IM_MEM: 4Gi
  IM_NAME: pim-example
  IM_PROFILE: qa,app_dev
  IM_PROP_FILES: src/main/resources/application-app_dev.properties
  IM_STATUS: STARTED
  IM_STORAGE: 8Gi

From IM 8.0 (ArgoCD deployment):

YAML
include:
  - file:
      - im-customer-gitlab-ci.yml
    project: integration-k8s/gitlab-ci-templates
    ref: main

Warning: You can no longer restart or reconfigure the instance by editing .gitlab-ci.yml — the old trick of changing IM_STATUS or another variable and committing does not work anymore, because the variables do not exist. Use Platform Manager for restarts and configuration changes.


Where your actions are applied now

Up to IM 7.x, every action — restart, rollout, memory change, status change — was written as a commit into your PIM repository and executed by a pipeline. This no longer happens.

From IM 8.0:

  • An action you trigger in Platform Manager creates no commit in your PIM repository. Do not expect one, and do not look for one.

  • The action is recorded in an internal deployment repository (under gitlab.pricefx.eu/dev-ops/infra). This repository is internal — you do not have access to it.

  • ArgoCD picks the recorded change up and applies it to the cluster.

Your PIM repository now holds only your integration content: routes, mappers, filters, classes, and property files.


Expect a delay

ArgoCD works by reconciliation: it continuously compares the recorded desired state of your instance with what actually runs in the cluster, and synchronizes the cluster to match. This synchronization runs periodically, not instantly.

In practice this means every action has a delay. When you trigger a restart, the instance restarts when the next ArgoCD sync runs — expect roughly 2 to 8 minutes between the action and the visible effect. This is normal; check the instance status in Platform Manager instead of expecting an immediate change.

Up to IM 7.x (pipelines)

From IM 8.0 (ArgoCD)

Action is executed by

A pipeline in your PIM repository.

An ArgoCD sync, outside your repository.

Visible trace in your repository

A commit and a pipeline run.

None.

Where to watch the result

The pipeline in GitLab.

The instance status in Platform Manager.

Typical delay

2 to 5 minutes (pipeline execution).

2 to 8 minutes (next ArgoCD sync).