Integrating with Github

Github offers the facility to configure a webhook that you can use to trigger an automated and secure continuous integration and continuous delivery (CI/CD) pipeline hosted in your preferred CI/CD tool. When a new version of your workflow project is created, you can trigger the Github webhook by pushing a file descriptor of the project (in JSON format) to a configured Git repository, which in turn triggers the CI/CD pipeline.

Before you begin

Ensure that your environment can access the configured Github endpoint by using a network policy to open the external access.

Procedure

Complete the following configuration to push the project descriptor file of your workflow version to Github.

For Workflow authoring:

Create a custom.xml configuration file for the authentication alias, which has your Git user name and access token.

<?xml version="1.0" encoding="UTF-8"?>
<server>
   <authData id="Git-J2C-Auth-Alias-Name" user="your_user_name" password="your_access_token"/>
</server>

Create a secret using your custom.xml:

kubectl create secret generic your-custom-secret-name --from-file=sensitiveCustom.xml=./custom.xml

Add the following configuration to your custom resource (CR) file:

bastudio_configuration:
    bastudio_custom_xml: |+
      <properties>
              <server>
                <git-configuration  merge="replace">
                  <git-endpoint-url>https://api.github.com/repos/user1/bawgitrepo</git-endpoint-url>
                  <git-auth-alias-name>Git-J2C-Auth-Alias-Name</git-auth-alias-name>
                </git-configuration>
              </server>
      </properties>
    custom_secret_name: your-custom-secret-name

where <git-endpoint-url> is the REST API URL for your Git repository. The value should be "api.github.com" instead of "github.com".

If SSL is enabled for Git, import the Git TLS certificate into Business Automation Workflow, and update your CR file.
```
kubectl create secret generic git-ssl-secret --from-file=tls.crt=/root/gitSSL.cert
```
```
bastudio_configuration:
    tls:
      tlsTrustList: [git-ssl-secret]
```
This step is not needed if the Git website is signed with a well-known certificate authority (CA).
If you have applied network policies to your deployment to have restricted internet access, you must create a network policy to ensure that the workflow authoring server can access the external Git server. Create a network policy to allow the workflow authoring server to connect to the Git server by using the Git port. Apply the network policy as follows:
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: "bas-allow-git"
spec:
  podSelector:
    matchLabels:
      com.ibm.cp4a.networking/egress-external-app-component: 'BAS'
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr:  # IP address your git server. 
  - ports:
    - protocol: TCP
      port: # Port of your git server.
```
Wait for the operator to finish reconciling.
Verify the configuration:
1. In the bastudio pod, check /opt/ibm/wlp/usr/servers/defaultServer/TeamWorksConfiguration.running.xml to see that <git-endpoint-url> and <git-auth-alias-name> are merged into the file.
2. Also, check that the /opt/ibm/wlp/usr/shared/resources/sensitive-custom/sensitiveCustom1.xml file exists and has the <authData> of your Git user and token.
You can now push the project descriptor file to the configured Git repository by using the Push to Git action that is available on the version.