Skip to Main Content
Status Shipped
Workspace DX Platform
Created by Paul Nerger
Created on Nov 6, 2020
Merged idea
This idea has been merged into another idea. To comment or vote on this idea, please visit DXP-I-1 A Blue Prism Package Manager that works with the DX.

Auto-populate Asset Form from Git Repo Merged

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 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 section "#Supported Versions"

    • Support URL * - from the section "#Support URL"

    • Release Notes - from the section "#Release Notes"

    • Dependencies - from the section "#Dependencies"

    • Setup and Install Requirements - from the section "#Setup and Install Requirements"

    • Hardware Requirements - from the section "#Hardware Requirements"

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

  • Marketing Content

    • Asset Pitch * - from the section "#Asset Pitch"

    • About the Asset * - from the section "#About the Asset"

    • Benefits of the Asset * - from the 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 section "#Video One"

      • Demo Video Two - from section "#Video Two"

      • Demo Video Three from section "#Video Three"

    • Marketing Assets

      • Resource One Title * - from section "#Resource One Title"

      • Resource One Upload - from the file

      • Resource Two Title - from section "#Resource Two Title"

      • Resource Two Upload - from the file

      • Resource Three Title - from section "#Resource Three Title"

      • Resource Three Upload - from the file

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

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

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

  • eCommerce - User to complete

  • Filter Categories - User to complete

3.1.2 supplies the rest

The convention for Git repos is to have a 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 file which will be markdown with the following sections:

#Supported Versions
#Support URL
#Release Notes
#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 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

  • +4