Skip to content

GitLab projects

AntFlow discovers workflows from GitLab projects. Configure the GitLab instance that hosts them and ensure the server can reach it.

For repository permissions and credential selection, see Authentication and project access.

Server GitLab token

Use a Personal, Project, or Group Access Token with the read_api scope, not a Deploy Token. The token must access every repository the server will read, including private dependencies. Its project role must satisfy the project permissions for the operations it performs. The read_repository scope alone is not sufficient for AntFlow's discovery and repository reads.

Configure the server's GitLab token through the Helm chart using configs.gitlab.token, or reference an existing Kubernetes Secret as shown below. This token is used by the server, not the UI container.

Replace gitlab.example.com in this template and the discovery example below with your GitLab instance URL; for GitLab.com, use https://gitlab.com. The Secret name and key must match the Secret you provision in the release namespace.

configs:
  gitlab:
    url: https://gitlab.example.com
    existingSecret: antflow-gitlab
    existingSecretTokenKey: gitlab_token

The Secret must contain the server token under the specified key. Keep this token confidential.

The authentication reference defines token selection and token use after submission.

Publishing projects

Configure AntFlow administrator email addresses in the Helm chart's configs.admins list. Their publication rights are defined separately from GitLab project roles.

The UI shows publishing controls only for projects whose server response includes admin-only publication metadata. Its Publish button is disabled when the server token cannot read the repository. The server independently enforces the administrator check and verifies that its token can access the project before recording the publication in AntFlow's database.

For visibility and group restrictions, see Published project access. For publication requests and responses, see Project API.

Project discovery and filters

Workflow repositories must contain CWL application packages following the OGC Application Package specification. AntFlow discovers workflows from .cwl files and builds process descriptions from their workflow definitions. Keep referenced tools and files accessible to the token that retrieves the package.

In the Helm chart, configs.topic defaults to antflow: projects must have that exact GitLab topic to appear in AntFlow. Matching is case-sensitive. Set it to "" to remove the topic filter and show all accessible projects. This does not change GitLab permissions.

Use configs.filterTags to offer tag filter chips:

configs:
  gitlab:
    url: https://gitlab.example.com
  topic: antflow
  filterTags:
    - flood
    - vegetation

The topic and filter tags map to SERVER_CONFIG.topic and SERVER_CONFIG.filterTags in the config.js served by the AntFlow UI container. Changing these settings does not require rebuilding the UI container image.

The SPACES integration uses its own project topic, independent of the workflow topic. See Integrations.

Project-sharing guidance

Set configs.defaultGroup to the GitLab group path shown in AntFlow's embedded project-sharing guidance. This setting is used only in the user documentation displayed in the UI. It maps to SERVER_CONFIG.defaultGroup in the config.js served by the AntFlow UI container.

configs:
  defaultGroup: my-organization/processes

This setting does not create the group or grant project access. Manage membership and sharing in GitLab.