...
| Info |
|---|
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. |
Notes: Unless you keep your compliance rules in the same repository as your DataStage assets, you will want a special repository for compliance that many different pipelines (across all your DataStage related GitLab projects) will reference. That means you will need to do a clone of the compliance repo explicitly in your pipelines. (where does this go?)
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.
For integration with MettleCI Workbench, with CI/CD pipelines, and with external entities in general, you will need to set up access to the repository associated with the project
Decide what access style you will use, userid/password, userid/PAT, deploy keys or SSH (we recommend SSH, see Configuring MettleCI Workbench SSH Authentication to GitLab for more details)
Create a public/private key pair and then add it to the project. SeeAdding public keys to GitLab for more details
Set up access between GitLab and the MettleCI Workbench service (typically running on your DataStage Engine host) (How, Larry Pieniazek (Unlicensed) ?)
...
How?
...
How?
...
Obtain the “clone URL” for the project
Configure the project in MettleCI Workbench. See MettleCI Workbench Configure First Project for more details.
Test this setup by using MettleCI Workbench to run a compliance check (this tests read only access to Compliance) and perform a commit (this tests write access to the Project repository)
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?
...
This page, while targeted at MettleCI Workbench setup, also covers how to create Deploy keys (Configuring MettleCI Workbench SSH Authentication to GitLab )
Pipelines use a .gitab-ci.yml file to hold configuration information.
How?
How do we test it?