MettleCI works with assets that are kept in Git repositories, notably the repository associated with a DataStage project and the repository associated with the compliance rules. So part of the set up and integration process involves configure these within GitLab. Unfortunately GitLab uses terms in somewhat different ways than other similar tools which can lead to confusion.
Comparing confusing terms in GitHub, Bitbucket, and GitLab
Despite Git being a well established standard, different vendors' Git-based version control systems can each use terminology like Repository and Project differently, creating the potential for confusion.
In other platforms such as GitHub and Bitbucket, repositories contain the Git code repository, and other project-related assets such as issues, contribution metrics, etc. However GitHub users often use the terms repository and project interchangeably. In GitLab, we call that container a Project. That includes the Git repository, issues, merge requests, milestones, and more.
It's important to make this distinction because you import a Project in GitLab, regardless of whether that is called a Repository elsewhere. In GitLab, the Repository is a component part of a Project. Thus GitLab tightly couples project and repository, and each project typically has at most one Git repository.
Recommended practice is to create a new GitLab project for each DataStage project. You may want to collect your projects into groups. Begin by selecting “new project” from your dashboard, or visiting http://your.gitlab.server/projects/new as explained in GitLab - create project and create a blank project.
Since you will be cloning the project in order to populate it, you should create a README file, which ensures the Git repository is initialised, has a default branch, and can be cloned.
After you create the project you will want to set up access to it for MettleCI and your CI server. The most common way to do this is to create a (project specific or public) deploy key. Detailed nuances of the differences are out of scope, you may want to refer to GitLab - deploy keys for more information, but public keys can be used across projects, after the project administrator grants access, while private keys only grant access to one project.