1 Executive Summary

Many of the Assets on the DX are open source. Open source projects are very often managed in Git. In fact, the DX Integration team often uses GitHub, an instance of Git, to manage Artifacts associated with an Asset.

The goal of this project is to facilitate the management of DX Asset projects that are held in a Git repository by providing an integration between Git and the DX. In particular, this will be achieved by creating a new button on the Asset Submission form that would automatically populate the Asset Submission form using the contents of the Git Repo if the information is there. If the information is not in the selected branch of the Git Repo, then the user will need to provide the information. Thus, the user would input the Git URL and branch and the DX Asset submission form would populate any missing elements of the form by "pulling" the Asset artifacts from the Git repository when the "Populate from Git" button is hit.

2 Business Objective

Today, some Asset owners that use Git repos to manage their open-source projects. They provide links to the Asset artifacts to provide the download, but the way that Git works, these artifacts are not easily downloaded into Blue Prism. Instead, they need to be fetched from the Git and sideloaded.

The objective of this project is to better support the Asset creation lifecycle by recognizing that the artifacts are stored in Git and using the Git API to extract the artifacts. Thus, it becomes easy to leverage Git as a Revision Control System for Assets on the DX, and publishing a Git Asset on the DX is streamlined. We want to achieve this with a Git integration in which the Asset is not dynamically updated when the Git is updated but rather the Asset information is "fetched" from the Git Repo upon the submit action.

3 Project Scope

3.1 In Scope

• This Integration should apply to any Git Repo using the standard Git API

• Special focus and testing should be applied for GitHub and BitBucket

• If users want to use private Gits, they will need to deal with security firewalls themselves.

3.1.1 Git Asset Submission Fields

Below are the fields for an Asset submission. In red is how the information should be pre-populated from the Git Repo.

• Asset Information

  • Is this asset private?

  • Asset Name / Title* - What you call the integration to customers. - from the readme.md section "#Title"

  • Primary Contact First Last Name* - Name of the Git Repo Owner

  • Primary Contact Email* - email of the Git Owner

  • Support Contact First Last Name* - Name of the Git Owner

  • Support Contact Email* - email of the Git Owner

  • Provider Name to Reflect in the Digital Exchange* - NONE

• Upload Technical Assets

  • Technical Asset Upload*UPLOAD TECHNICAL ASSET UPLOAD - the file in the git with the name technialAsset.* such as technicalAsset.bprelease or technicalAsset.

  • Licensing Selection

  • Please attach source code here - URL for the Git Repo with the branch information

• • Supported Versions - from readme.md section "#Supported Versions"

  • Support URL * - from the readme.md section "#Support URL"

  • Release Notes - from the readme.md section "#Release Notes"

  • Dependencies - from the readme.md section "#Dependencies"

  • Setup and Install Requirements - from the readme.md section "#Setup and Install Requirements"

  • Hardware Requirements - from the readme.md section "#Hardware Requirements"

• Add Export Control - must be filled out on the DX

• Marketing Content

  • Asset Pitch * - from the readme.md section "#Asset Pitch"

  • About the Asset * - from the readme.md section "#About the Asset"

  • Benefits of the Asset * - from the readme.md section "#Benefits of the Asset"

  • Images and Videos

    • Company Logo * - from the logo.png, logo.gif, logo.eps in the Git

    • Additional Images - from the images in the Git with filenames image1, image2, image3, image4, or image5

    • Demo Video One - from readme.md section "#Video One"

    • Demo Video Two - from readme.md section "#Video Two"

    • Demo Video Three from readme.md section "#Video Three"

  • Marketing Assets

    • Resource One Title * - from readme.md section "#Resource One Title"

    • Resource One Upload - from the file resourceOne.md

    • Resource Two Title - from readme.md section "#Resource Two Title"

    • Resource Two Upload - from the file resourceTwo.md

    • Resource Three Title - from readme.md section "#Resource Three Title"

    • Resource Three Upload - from the file resourceThree.md

    • Business Value Client Experiences with Asset (Bullet 1) - from readme.md section "#Business Benefit 1"

    • Business Value Client Experiences with Asset (Bullet 2) - from readme.md section "#Business Benefit 2"

    • Business Value Client Experiences with Asset (Bullet 3) - from readme.md section "#Business Benefit 3"

• eCommerce - User to complete

• Filter Categories - User to complete

3.1.2 Readme.md supplies the rest

The convention for Git repos is to have a readme.md file that contains markdown that is used to provide information about the software that is held in the Git Repo.

The bulk of the information used to pre-populate the Asset Submission form will be from the readme.md file which will be markdown with the following sections:

#Title
#Supported Versions
#Support URL
#Release Notes  
#Dependencies 
#Setup and Install Requirements   
#Hardware Requirements
#Video One
#Video Two
#Video Three
#Resource One Title  
#Resource Two Title   
#Resource Three Title   
#Business Benefit 1   
#Business Benefit 2
#Business Benefit 3   

Each section of the readme.md file is allowed to have markdown in it that should be translated into HTML upon input. If a section is missing it should be ignored. If a section is blank, it should be ignored. If a section has been added that is not needed, then it should be ignored.

3.2 Out of Scope

There will be no dynamic integration with the Git Repo. Rather when the "Git Fetch" button is pressed with an Asset submission, the submission will be populated from a single set of Git API calls.

4 Business Drivers

The business driver for this is two-fold:

1. Make it easier to submit Assets that are managed in GitHub

2. Make it easier to download and install Assets that are held in GitHub.

5 Current Process

Today, the Git Repo owner must manually copy materials from the Git Rep into the target fields and then format them.

6 Testing

1. Create a new asset

2. Pre-populate the form from a GitHub Repo

3. Verify that all of the fields and uploads are populated correctly

4. Verify that as the user you can edit or delete the text that was pre-populated

5. Verify that pressing the Pre-populate from the Git Repo does not override any fields that are not blank

6. Repeat the test with a Bitbucket Repo