Git

Standard Authentication

Required Fields: 

• Location/Connection URL 
  • Example Format: http://github.com/tasktop/repository.git
  • This should be the URL that the Git repository can be cloned from
• Git Hosting Service
  • Select the hosting service (such as Bitbucket, GitHub, etc.) that you are utilizing
• Username
• Password

Optional Fields: 

• Git Hosting Web URL
  • The base URL for the service hosting the repository, (e.g., https://github.com or https://gitlab.com). This will be used to construct URLs for artifacts synchronized via Hub. If empty, Hub will attempt to determine the URL, but it may be incorrect.  
  • Note: If "Custom URL" is selected as the hosting service, this URL should contain a (commit) placeholder for the commit ID, (i.e., https://customhosting/commits/(commit))
• Connection Security: If checked, insecure connections to this repository will be allowed. See details here.

Note: Proxy configuration for the Git repository cannot be configured within the Hub UI. It must be manually configured for the Hub installation by adding the http proxy properties to the Catalina configuration. See more details here.

Learn more about how to set up your repository in Planview Hub here. 

SSH Public/Private Key

Required Fields: 

• Location/Connection URL 
  • Example Format: http://github.com/tasktop/repository.git
  • This should be the URL that the Git repository can be cloned from
• Git Hosting Service
  • Select the hosting service (such as Bitbucket, GitHub, etc.) that you are utilizing
• Private Key
• Private Key Passphrase

You can learn about this authentication method here.

Optional Fields: 

• Git Hosting Web URL
  • The base URL for the service hosting the repository, (e.g., https://github.com or https://gitlab.com). This will be used to construct URLs for artifacts synchronized via Hub. If empty, Hub will attempt to determine the URL, but it may be incorrect. If "Custom URL" is selected as the hosting service, this URL should contain a (commit) placeholder for the commit ID (i.e., https://customhosting/commits/(commit))
• Connection Security: If checked, insecure connections to this repository will be allowed. See details here.

Flowing Git Commits to Jama

Many organizations may need to gain visibility into the commits Developer's are making to their codebase. As a Hub user, you may consider flowing commits from Git to a Requirements Management tool. A large driver for this scenario is to reduce overhead for developers working in the SCM tool, by enabling an integration that flows commits and their relevant information to the Requirements Management tool.

The special use case details outlined below involve flowing Git commits to Jama. When configuring this use case, some important implications should be noted when setting up the Hub integration - This is due to Jama's underlying architecture:

To create new 'code' artifacts in Jama (or other custom artifact types) and have them correspond to 'commits' in Git, you must:

• Create a 'set' in Jama for "code" (or whichever artifact type the commit will flow to in Jama). This must be in the same project or 'component' as the artifacts the commits will be referencing.
  • If a 'set' does not exist, an error will occur instructing you to create a 'set' for the "code" to live in.
  • If there is no referenced artifact, the commit will be created in a "code" set in the parent project.
  • If the referenced 'requirement' artifact is in a 'component', there must also be a "code" set in the same 'component' or else an error will occur.
• Limitation: You cannot put the "code" artifacts into a 'folder' within a Jama 'set'. "Code" artifacts must be created directly under a 'set'.
• If there are multiple "code" sets in a component or project, the commit will be created in the first project based on how Jama orders them.