Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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.

From teams to repositories to organizations, there’s potential for fresh confusion. In GitHub, repositories contain the Git/SVN repository, and the project assets such as issues, contribution metrics, etc. However users often refer to repos as projects interchangeably. So in GitLab, we call that container a Project. That includes the Git repository, issues, merge requests, milestones, and much 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 part of a project.
(from Comparing confusing terms in GitHub Bitbucket and GitLab)


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.

  • No labels