Skip to main content

Admin settings

Git Providers​

IBM Industry Solutions Workbench gives the flexibility to connect to one or many Git providers. Using these Git providers, one has the possibility to decide with every microservice, where the modelled data and the implemented code should be stored. The permissions that are defined at the Git provider will be automatically applied to the Solution Designer and therefore full control over the available capabilities for the users is guaranteed.

About Git Providers​

Admin users can manage the available Git providers in the Admin Settings area. Before creating a microservice, the Git provider has to be defined there. Each Git provider is identified by a unique alias.

The supported Git provider types are:

  • GitLab (self-managed)
  • Bitbucket Server
  • GitHub (Enterprise)

Use Git Providers​

To use a Git provider, every user has to define an access token for the Git. All supported Git providers provide the possibility to create these personalized access tokens. Each user can only specify one token per provider. This token will be from then on used for every interaction with the remote Git and also to restrict the capabilities of the user to the permissions that are set in the remote Git repository.

Use Multiple Git Providers​

If microservices should be stored at different places, an admin user can define multiple Git endpoints. While creating a microservice, the creator could define, where the microservice should be stored. Also, a specific group could be specified while creation. These groups are usually used to restrict permissions on certain microservices for dedicated users.

Manage Git Providers​

In order to create and manage Git providers you must have admin privileges. To access the Admin Settings page use the Settings capability on the top right of the page. There you will get an overview of the already existing Git providers and their master data.

Create Git Provider​

To create a new Git provider use the Create capability.

The master data of a Git provider consists of:

  • Alias: Used to specify a Git provider under the given alias name (required)
  • Type: The Git provider platform. There are three options: GitHub Enterprise, GitLab and Bitbucket Server ( required)
  • Base URL: The URL to the Git provider. This value must be unique (required)
  • Label: Short description of the Git provider (optional)
  • Read-only Git provider: Used to mark the Git provider as read-only. Read-only Git providers can not be used to create new projects. Projects can not be exported to asset catalogs using read-only Git providers.

Edit Git Provider​

Admin users can edit the Git provider for any record in the application within the Admin settings. Here, the label can be edited and if the Git provider is read-only or not.

Delete Git Provider​

To delete a Git provider use the header or inline Delete capability. After confirming the action, the Git provider and all tokens related to it will be permanently deleted.

⚠warning

You are not allowed to delete a Git provider if there are still microservices in the Solution Designer associated to the specific provider.

Necessary Git Token Permissions​

The available capabilities in the Solution Designer depend on the permissions that are assigned to the user in the remote Git.

Grant General Permissions for Users on Repositories​

Repository or group administrators on the remote Git are responsible to grant access permissions on the repositories for the actual users.

GitLab:

  • To create new microservices: at least developer permissions on the group must be granted.
  • To edit the microservice content: at least developer permission (on the group or the repository) must be granted.
  • To view the microservice: at least guest or reporter permission (on the group or the repository) must be granted.
  • To delete a microservice: at least owner permission on the group must be granted.
⚠warning

The above described permissions are valid for a GitLab EE default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.

Bitbucket Server:

  • To create new microservices: administrator permission on project must be granted.
  • To edit the microservice content: at least write permission (on the project or the repository) must be granted.
  • To view the microservice: at least read permission (on the project or the repository) must be granted.
  • To delete a microservice: administrator permission on project or repository must be granted.
⚠warning

The above described permissions are valid for a Bitbucket default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.

GitHub Enterprise:

  • To create new microservices: The authenticated user must be at least a member of the GitHub organization.
  • To edit the microservice content: at least write permission in the GitHub organization must be granted.
  • To view the microservice: at least read permission in the GitHub organization must be granted.
  • To delete a microservice: admin access on the organization must be granted.
⚠warning

The above described permissions are valid for a GitHub Enterprise default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.

Define Specific Permissions on Tokens​

Usually, one could explicitly define the basic permissions for the token while creating the token in the remote Git provider.

Minimum permissions that need to be granted for the token:

GitLab:

  • Select scope api
  • Select scope read_repository
  • Select scope write_repository (for GitLab version 11.11 or higher)

Bitbucket Server:

  • Select permission "Read" for basic read access
  • Select permission "Write" to allow create, delete and edit capabilities, as well as committing to the repository
  • Select permission "Administrator" to allow create, import and delete microservices

GitHub Enterprise:

  • Select permission "public_repo" to access public repositories.
  • Select permission "write_org" to read and write organization and team membership, read and write organization projects.
  • Select permission "repo_status" to access commit status in a repository.
  • Select "delete_repo" to be able to delete organization repositories.
  • Select "admin_org" to get full access of organization and teams, read and write organization projects.

Asset Catalogs​

Asset Catalogs are containers that group multiple projects as assets so that they can be imported as starting points for other projects. To enable sharing of projects as an asset you have to set up at least one asset catalog within IBM Industry Solutions Workbench.

Adding an asset catalog​

To add an asset catalog:

  • Navigate to the admin settings page by clicking the gear icon in the navigation bar ⚙
  • Click "Admin Settings".
  • Navigate to the "Asset Catalogs" tab.
  • Click on the (+ Add Catalog) button.

Filling in the "Add Asset Catalog"

  • Catalog Alias: A unique alias for this asset catalog (required).

  • Tags: To group the asset catalogs (optional)

  • Git Provider: A list of all Git providers for which you have an access token (required)

  • Repository Group: All repository groups in the specified Git provider for which you have at least read rights, where repository group is the git group that logically contain the repositories inside it (required)

  • Repository Key: It is the name of the catalog that will end up in git repository (required)

  • Description: Some notes on the purpose of this asset catalog (optional)

    💡tip

    If the specified repository key doesn't exist, check the "Create a new Git repository for the asset catalog if it does not exist yet" checkbox in order to create a new repository key.

    💡tip

    Assets from a specific catalog can be included in the project creation to provide a set of pre-defined resources, configurations, or templates. Check 'Include assets from this catalog in the project creation' to see assets while creating a project.

    💡tip

    We recommend to structure your asset catalogs consciously and avoid to have more than 50 different assets in one asset catalog.

Editing an asset catalog​

To edit an asset catalog, please follow these steps:

  • Navigate to the admin settings page by clicking the gear icon in the navigation bar ⚙

  • Click "Admin Settings".

  • Navigate to the "Asset Catalogs" tab.

  • Use the search box to search for the asset catalog to be edited, you can search either by:

    • Catalog alias
    • Tags
    • Git provider
    • Repository group
    • Repository key

  • Once you locate the catalog, press the three dots on the right and click the (- Edit) button.

Filling in the "Edit Asset Catalog"

  • Tags: To group the asset catalogs (optional)
  • Description: Some notes on the purpose of this asset catalog (optional)

Deleting an asset catalog​

To delete an asset catalog, please follow these steps:

  • Navigate to the admin settings page by clicking the gear icon in the navigation bar ⚙

  • Click "Admin Settings".

  • Navigate to the "Asset Catalogs" tab.

  • Use the search box to search for the asset catalog to be removed, you can search either by:

    • Catalog alias
    • Tags
    • Git provider
    • Repository group
    • Repository key

  • Once you locate the catalog, press the three dots on the right and click the (- Delete) button.

  • Confirm the "Delete Asset Catalog" dialog.

Component Repositories​

The Component Repository is a combination of Helm Chart Repository and Image registry that needs to be configured.

All released components that are built via a new Release Pipeline will be pushed and saved into the Component Repository and can be used in application composite projects afterwards.

💡tip

Only dc_admin users can configure the component repositories

Adding a Component Repository​

To add a component repository:

  • Navigate to the admin settings page by clicking the gear icon in the navigation bar ⚙
  • Click "Admin Settings".
  • Navigate to the "Component Repositories" tab.
  • Click on the (+ Add Component Repository) button.

Filling in the "Add Component Repository"

  • Component Repository Acronym: A unique acronym for this component repository (required).

  • Tags: To group the component Repository (optional).

  • Helm Repository URL: The helm repository URL (required).

  • Helm Repository Username: The helm repository username (required).

  • Helm Repository Password: The helm repository password (required).

  • Image Registry URL: the URL of the image registry you want to connect to (required).

  • Image Registry Username: The image registry username (required).

  • Image Registry Password: The image registry password (required).

  • Description: Some notes on the purpose of this component repository (optional).

  • Repository Key: The repository key of the asset catalog (required).

  • Set as default component repository: Indicates the default component repository (optional).

    ℹ️note

    check "Set as default component repository" checkbox if you need this component repository to be used for all "Release" pipelines.

Editing a component repository​

To edit a component repository, please follow these steps:

  • Navigate to the admin settings page by clicking the gear icon in the navigation bar ⚙

  • Click "Admin Settings".

  • Navigate to the "Component Repositories" tab.

  • Use the search box to search for the component repository to be edited, you can search either by:

    • Repository acronym
    • Tags
    • Helm Repository URL
    • Image Registry URL

  • Once you locate the repository, press the three dots on the right and click the (- Edit) button.

Filling in the "Edit Component Repository"

  • Tags: To group the component Repository (optional).

  • Helm Repository URL: The helm repository URL (required).

  • Helm Repository Username: The helm repository username (required).

  • Helm Repository Password: The helm repository password (required).

  • Image Registry URL: the URL of the image registry you want to connect to (required).

  • Image Registry Username: The image registry username (required).

  • Image Registry Password: The image registry password (required).

  • Description: Some notes on the purpose of this component repository (optional).

  • Repository Key: The repository key of the asset catalog (required).

  • Set as default component repository: Indicates the default component repository (optional).

    ℹ️note

    check "Set as default component repository" checkbox if you need this component repository to be used for all "Release" pipelines.

Removing a component repository​

To delete a component repository, please follow these steps:

  • Navigate to the admin settings page by clicking the gear icon in the navigation bar ⚙

  • Click "Admin Settings".

  • Navigate to the "Component Repositories" tab.

  • Use the search box to search for the asset catalog to be removed, you can search either by:

    • Repository acronym
    • Tags
    • Helm Repository URL
    • Image Registry URL

  • Once you locate the component repository, press the three dots on the right and click the (- Remove) button.

  • Confirm the "Remove Component Repository" dialog.

Course Admin Settings