GitHub Enterprise

Any Application Development Organization (ADO) employee that is part of their enterprise software development team.

GitHub Enterprise is available to all QualityNet Application Development Organizations (ADOs).

There are four GitHub Organization User Roles. Most users will request the GitHub-Developer User role, but a description of all roles is provided below:

• GitHub-SO: Designated for Security Officials responsible for approvals of each GitHub Organization. Request this role only if you have been designated as a Security Official.
• Read Only (I don’t work for this organization): Provides Ready Only access to another ADO’s GitHub Organization.
• GitHub-Admin: Designated for Admins (Organization Owners) responsible for GitHub Organization administration and assisting GitHub Organization users.
• GitHub-Developer: Most common GitHub Organization role as GitHub supports the ADO development community.

Yes, to obtain access to both ADO GitHub Organizations, you are required to submit HARP GitHub User requests for each.

To successfully authenticate in GitHub with your HARP credentials, the Security Official must approve your GitHub Role request. The 403 error occurs when a GitHub user request has not been approved.

Yes, but you are required to select the contract you are currently supporting, enter a reason for your request to access the ADO GitHub Organization and your request will need to be approved by the ADO Security Official.

The maximum size of Git objects that can be pushed to repositories on this appliance is 100MB per file (25MB if adding a file via a web browser). Allowing large objects to be pushed into Git can degrade performance. Consider other options such as using Nexus Repository Manager to store dependencies, artifacts and other large objects.

Only members with owner privileges for an organization or admin privileges for a repository can manage webhooks for an organization. For more information, see "Permission levels for an organization."

Chances are the account that you used to create the webhook token does not have Org Owner privileges in GitHub. Ensure that the account with which the token was created has these privileges. Use these credentials in the Jenkins Master Global configuration → GitHub Webhooks section and re-register the webhooks. Now, go to your repository and re-deliver the payload. This should fix the issue.

For help on configuring webhooks see About Webhooks in the GitHub Help documentation.

For help on building a webhook, including a full list of actions you can associate with, see "Webhooks" in the GitHub Developer documentation.

Users are not able to delete GitHub repositories. 

If you are absolutely certain that a repository belonging to you or your organization needs to be deleted, please submit a ServiceNow RITM and assign it to ESSII Build-DEVOPS.  After the ticket is created, please send an email to ESS_Devsecops_Team@ventera.com with the ticket number and a confirmation from you to delete the specified repository.

Once a repository is deleted from GitHub, it cannot be restored. 

Repositories containing tags/releases that have been deployed should be archived rather than be deleted.

A branch is a separate line of development that is “branched” from the Master branch.

A tag represents a version of a particular branch at a moment in time.

• While branches can be updated, a tag cannot
• A tag may not necessarily include all of the changes made in a branch
• From the GitHub web interface perspective, a tag is the same as a release
• Tags can also be created from the Git command line and then pushed to GHE