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.
Steps
Create a blank GitLab project by selecting new project from your GitLab dashboard, or visiting http://your.gitlab.server/projects/new. The recommended practice is to create a new GitLab project for each DataStage project. You may want to collect your GitLab projects into groups. See GitLab - Create Project.
Clone the empty repository to somewhere convenient, such as your local client machine. Create a README file which ensures the Git repository is initialized, has a default branch, and can be cloned. A sample README file is supplied in the template repository supplied with MettleCI.
Set up access between GitLab and the MettleCI Workbench service (typically running on your DataStage Engine host) (How, Larry Pieniazek (Unlicensed) ?)
How?
How?
How?
Set up access between GitLab and your build server. The easiest way to do this is to create a (project-specific or public) deploy key. Public keys can be used across multiple GitLab projects, once the project administrator grants access, while private keys only grant access to one project. (What do I do with this key, Larry Pieniazek (Unlicensed) ?)
How?
How?
How?
How do we test it?