PDM

Application actions ​

An application action is an operation you can run for a particular platform service without opening GitLab. Every action answers the same question: which image tag should end up on the stand. They differ only in where that tag comes from.

Which actions exist ​

Most services have the same set of three actions:

ActionWhat it does
Сборка ветви (branch build)Starts a GitLab build from the code branch you name. The tag of the resulting image is the result of the action
Сборка версии (version build)Writes the version number you give (3.14.2, for example) into the repository and starts a build from it
Установить тег (set tag)Builds nothing: it takes an existing image tag from what was built earlier

The first two are marked in the system as buildable — they really do start a pipeline and take time. Setting a tag starts no build and completes instantly.

The set of actions depends on the service

Some services do not have all three — a branch build, for instance, may be missing. The interface only shows the actions actually configured for that application. Action names are defined by the platform itself and are not translated.

Where actions are started ​

An action can be started in two places, and the outcome differs:

  • The CI Builds page — building for the sake of building. The image is built and pushed to the registry but rolled out nowhere. See Builds and pipelines.
  • The Services tab of a stand — building in order to deploy. The action is used as the value of the version field, and once the changes are applied the built image lands on the stand.

Running actions requires the matching permissions: starting builds and changing stand configuration are granted separately. If a button is missing, the permission has not been granted — ask an administrator.

Running an action on a stand ​

This is the main scenario: "put a fresh build of such-and-such branch on the stand".

  1. On the stand's Services tab, pick an action next to the service's version field: a branch build, a version build or set tag.
  2. Fill in the value — the branch, the tag or the version number. For a version build PDM prefills the service's current version as the starting point; correct it as needed.
  3. The chosen action lands in the pending changes panel. Nothing has been started yet at this point: the action is saved as an intention.
  4. Click Deploy changes and confirm.

Once confirmed, PDM creates a workspace — a long operation broken down into steps — and returns control immediately. You can watch it run, or leave the page: the operation carries on.

Only changed fields are applied

PDM applies exactly the values you changed. Untouched settings and the versions of other services are left alone.

What happens after the start ​

The order of steps for a buildable action:

  1. PDM starts a pipeline in GitLab. The pipeline name is marked as started from PDM and carries your login, which makes your build easy to spot among everyone else's.
  2. While the pipeline runs, the workspace step stays in the Running state. PDM polls GitLab roughly every 10 seconds, so a long build means a long-running step — that is normal.
  3. When the pipeline succeeds, PDM resolves the tag of the built image and uses it as the value of the version field.
  4. The resulting set of values is applied to the stand's live environment, and the values themselves are written to the stand configuration file.

For a set tag action the first three steps are skipped: the tag is known up front.

How to follow the progress ​

Right after the start the operation appears in the Workspaces section. Its page shows the steps and their statuses, the log of each step and, on a build step, a link to the pipeline in GitLab — see Running and watching.

Where to check the result ​

What to checkWhere
The operation ran to the endWorkspace status — Completed
What exactly was builtThe log of the build step and the link to the pipeline
What is on the stand nowThe Deployed version column on the Services tab
The stand came back up after the deployThe stand's Dashboard tab — status and service readiness

If something went wrong ​

A failed operation has the workspace status Failed. What to do:

  1. Read the error text on the failed step.
  2. If the build itself failed, follow the link to the pipeline and look for the cause in GitLab: the problem is almost always in the code or in the pipeline, not in PDM.
  3. Typical causes, recognisable from the error text:
    • the pipeline finished unsuccessfully — the build did not pass, there is no tag and PDM goes no further;
    • no GitLab token found — some operations (writing the version number during a version build, in particular) run on your behalf. The token is set in your account settings;
    • insufficient permissions — the operation was refused on the server side.
  4. Once the cause is fixed, run the action again. Every run creates a new workspace — a failed one cannot be nudged along, it stays in the history as it is.

A failed operation does not roll back what was already done

If the error happened on one of the last steps, part of the changes may already have been applied. Before running it again, look at the stand's current state rather than its original one.

See also ​