Skip to content

Lingo.dev GitLab Pipeline

Overview

Setup

To use the Lingo.dev GitLab Pipeline, add this to your pipeline file (eg. .gitlab-ci.yml):

yaml
lingodotdev:
  image: lingodotdev/ci-action:latest
  script:
    - echo "Done"

You will also need to create two environment variables in your repository (Settings -> CI/CD -> Variables):

  • LINGODOTDEV_API_KEY with your Lingo.dev API key
  • GL_TOKEN with your GitLab access token
    • the default token provided by GitLab is not sufficient to push changes to your repository (the feature is being tested by Gitlab now)
    • you need to create a new access token for your repository (Settings -> Access tokens -> Add new token)
    • required scopes: api, read_repository, write_repository

Note: Make sure the CI/CD variables are protected only if the branch is protected as well. Otherwise the variables will not be accessible by your pipeline.

If you want to use the pull request feature, you need to enable it via a variable:

yaml
lingodotdev:
  image: lingodotdev/ci-action:latest
  variables:
    LINGODOTDEV_PULL_REQUEST: "true"
  script:
    - echo "Done"

Example

To run the action on every push to a branch that starts with feat/, you can use the following workflow. It will commit and push updated locale files to the branch as you push commits with new features. Add this config to your .gitlab-ci.yml file:

yaml
lingodotdev:
  image: lingodotdev/ci-action:latest
  script:
    - echo "Done"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH = /^feat/

How It Operates

Here's a breakdown of the action's process:

  1. It runs npx lingodotdev@latest i18n to process translations.
  2. It stages all changes (git add .).
  3. If there are staged changes, it either:
    • Commits them, pulls and rebases to avoid conflicts, and pushes the changes; or
    • Creates or updates a pull request with the changes.

This process ensures that translation updates are seamlessly integrated into your codebase. The action uses this approach because it allows for automatic conflict resolution (via rebase) and provides a clear audit trail of translation updates.

Customization

You can customize the behavior using the following input parameters:

  • LINGODOTDEV_API_KEY: Override the API key
  • LINGODOTDEV_PULL_REQUEST: Set to 'true' to create a pull request instead of pushing directly (default: 'false')
  • LINGODOTDEV_PULL_REQUEST: Customize the title of the pull request (default: 'feat: update translations via @lingodotdev')
  • LINGODOTDEV_COMMIT_MESSAGE: Customize the commit message (default: 'feat: update translations via @lingodotdev')
  • LINGODOTDEV_WORKING_DIRECTORY: Customize the working directory (default: '.')
  • GL_TOKEN: Override the GitLab access token

Example:

yaml
lingodotdev:
  image: lingodotdev/ci-action:latest
  variables:
    GL_TOKEN: $MY_GL_TOKEN
    LINGODOTDEV_API_KEY: $MY_LINGODOTDEV_API_KEY
    LINGODOTDEV_PULL_REQUEST: "true"
    LINGODOTDEV_PULL_REQUEST_TITLE: "Lingo.dev updated your translations"
    LINGODOTDEV_COMMIT_MESSAGE: "feat: new translations"
    LINGODOTDEV_WORKING_DIRECTORY: "apps/web"
  script:
    - echo "Done"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH = /^feat/

Note: The GL_TOKEN environment variable is required at all times. It allows the pipeline to create pull requests and push changes to the repository.

These customization options exist because different teams have different workflows and preferences. For instance, some teams might prefer pull requests for better review processes, while others might want direct commits for faster updates.