Versions Compared

Old Version 25

changes.mady.by.user Larry Pieniazek

Saved on

compared with

New Version 26

changes.mady.by.user Justin McCamish

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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. Achieving a usable MettleCI instance includes the configuration of these repositories within GitLab. Note: GitLab differs from similar tools in its application of meanings to common terms.

...

  1. 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, plus one for your Compliance rules. You may want to collect your GitLab projects into groups. See https://docs.gitlab.com/ee/user/project/ for more information on projects<<< Broken link << Fixed.

  2. Clone the empty repository to somewhere convenient, such as your local DataStage client machine. Create a README file in the root folder of the repository which ensures the repository is initialized, has a default branch, and can be cloned. A sample README file is supplied in the template repository supplied with MettleCI. <<< This seems like its own step << Fixed.

  3. For integration with MettleCI Workbench, with CI/CD pipelines, and with external entities (such as code authoring systems) <<< What’s an example of this? <<Fixed in in general, you will need to set up access to the repository associated with the project.

    1. Decide what credentials type you will use: userid/password, userid/PAT, deploy keys (a kind of SSH key) or regular SSH. SSH is recommended and this page has more details on why: Configuring MettleCI Workbench SSH Authentication to GitLab

    2. If following the above recommendation, create a public/private key pair and then add it to the project. SeeAdding public keys to GitLab for more details<<< Is this bullet redundant, given the contents of 2.a.? << I don’t think so, one page talks about why to use SSH, the other talks about how

  4. Set up access between GitLab and the MettleCI Workbench service (typically running on your DataStage Engine host)

    1. Obtain the “clone URL” for the project

    2. Configure the project in MettleCI Workbench. Refer to MettleCI Workbench Configure First Project for instructions.

    3. Test this setup by using MettleCI Workbench to run a Compliance check (confirming read-only access to Compliance) and perform a commit to the repository (confirming write access to the Project repository).

  5. 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. You can also use a deploy token instead.

    1. This page, while targeted at MettleCI Workbench setup, also covers how to create Deploy keys (Configuring MettleCI Workbench SSH Authentication to GitLab ). They are created the same way you create other SSH keys, and are actually a pair of keys, public and private.

    2. Once you have a deploy key you will place the public part in the http://your.gitlab.server/your_project/-/settings/repository repository portion of the project settings page.

    3. Deploy tokens are generated for you by GitLab via the same project repository settings page and you must record them for later use. You only get a single opportunity to view them during the setup process. This makes them both more secure and less convenient than deploy keys, which are retained on the file system of the machine communicating with GitLab <<< Than what, specifically? <<Fixed. See GitLab deploy tokens for more information.

...