marketing-parser/DEPLOYMENT.md

Deployment

This repository now uses the same GitLab shell-runner deployment pattern as call-center: no project CI/CD variables are required for the normal push deploy path.

What happens on push

1. GitLab runs the existing test job.
2. A dedicated shell runner with tag marketing-parser-prod picks up deploy_production.
3. The runner syncs the repository into /home/gitlab-runner/deploy/marketing-parser.
4. The runner builds a local Docker image from that synced checkout.
5. Docker Compose recreates konturai-parser-app from deployment/docker-compose.server.yml.

Files used

• .gitlab-ci.yml
• deployment/docker-compose.server.yml
• scripts/deploy_gitlab.sh
• scripts/bootstrap_gitlab_deploy.sh
• scripts/install_gitlab_runner.sh

One-time server setup

Install and register a shell runner on the target server:

cd /root/marketing-parser
RUNNER_TOKEN=glrt-xxxxxxxx bash scripts/install_gitlab_runner.sh

Then bootstrap the production env file from the current konturai-parser-app container:

cd /root/marketing-parser
bash scripts/bootstrap_gitlab_deploy.sh

That writes /home/gitlab-runner/deploy/marketing-parser/.env.production, which is used by the deploy job.

Important notes

• The deploy job runs for pushes and manual web-triggered pipelines on the branch that contains this CI configuration.
• The runner user must have Docker access.
• This setup expects a host shell runner. A minimal gitlab/gitlab-runner:alpine container is not enough unless you also provide Docker, Compose, and rsync inside that runner environment.
• This deploy path is intentionally independent from /root/docker-compose.yaml because /root is not accessible to the gitlab-runner user.
• The deployment compose file joins the existing external Docker network common_network and publishes the service alias parser-service.