Versions Compared

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 usable a MettleCI 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 GitLab - Create Project. <<< Broken link.

    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.

  2. For integration with MettleCI Workbench, with CI/CD pipelines, and with external entities in <<< What’s an example of this? 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: Configuring MettleCI Workbench SSH Authentication to GitLab

    2. Create a public/private key pair and then add it to the project. SeeAdding public keys to GitLab for more details <<< RedundantIs this bullet redundant, given the contents of 2.a.?

  3. 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. See Refer to MettleCI Workbench Configure First Project for more detailsinstructions.

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

  4. 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 at via the same project repository settings page and you must record them for later use, you only have one chance to see them. You only get a single opportunity to view them during the setup process. This makes them both more secure and less convenient <<< Than what, specifically?. See GitLab deploy tokens for more information.

...