Policies

University Policies and Regulations

As a service provided by the university, all official university policies and regulations apply to the NC State GitHub service. In particular please note the following:
– https://policies.ncsu.edu/policy/pol-10-00-01/
– https://policies.ncsu.edu/regulation/reg-08-00-02/
– https://policies.ncsu.edu/regulation/reg-08-00-03/

Data Sensitivity

Please consider the type of data that you are placing into this system. Remember, every time you store or share sensitive data, it’s your responsibility to fully comply with the NC State Data Management Framework (DMF).

If you have questions or need more information, contact the NC State Help Desk via the NC State IT Service Portal or call 919.515.4357 (HELP).

Thank you in advance for your help in safeguarding university data.

User Accounts

Access and Usage

Use of the NC State GitHub service is free to use for all currently enrolled students, student facing faculty, and non-faculty staff employees of NC State University for the duration of their time at the university.

No-Pay and Workshop accounts are permitted access to GitHub for anyone performing academic, not-for-profit research on behalf of or in collaboration with the university for as long as their account remains active.

Service accounts are available to faculty and staff for purposes of automation. Contact us for more information.

All usage of the NC State GitHub API is subject to Rate Limiting, and requests that break the limit will be denied.

Access to the NC State GitHub instance outside the aforementioned usage is not permitted.

Any usage of the service which intentionally attempts to compromise or disable the service will result in a user account ban from the service.

Account Provisioning

Accounts for qualified users are created upon their first successful authentication to the service. Users accounts will not be created before this time, and will be unavailable for the purposes of assigning permissions, transferring ownership of repositories, etc.

Account Decommissioning

Once a user has become separated* from the university, their GitHub account will be scheduled for decommission. All content owned by the user on GitHub will be archived and sent to the user via Google Drive, and the user’s GitHub account will be deleted soon after.

Note that only content directly owned by the user will be included in the archive. Any other content the user may have access to, but does not own, will not be included in the archive. This includes (but is not limited to) the following:

  • Other users’ forks of a repository owned by the user
  • Repositories owned by another user which the user is a collaborator on
  • Repositories owned by organizations the user is a member of

Users who wish to include repositories from organizations or other users in their archive should fork the repository prior to separation.

The NC State GitHub Service Team does not supply copies of data outside what was directly owned by the user’s account. Any user who wishes to obtain a copy of a repository not owned by their account after separation will need to contact the repository owner directly to request a copy.

If a decomissioned user was the last owner of an organization, the organization will be re-owned to a service account controlled by the NC State GitHub Service Team. A member of the organization may contact the service team to request ownership of the organization. See “Orphaned Organizations” for more details.

Workshop accounts are decommissioned regularly the day before the start of Spring, Summer, and Fall semester. This removes all repositories and permissions for the account. Archives are NOT created when Workshop accounts are decommissioned. We highly recommend Workshop account users backup and remove their data from GitHub before they lose access to the account. This prevents data from being lost when the account is wiped, and prevents other people from accessing data if the account changes hands before the scheduled wipe.

*Separated: A user is classified as “separated” if and only if they do not have an active employee record, are not currently registered for classes, and do not have an active academic plan for the current semester.

Account Names

All user accounts should be named after their Unity ID. Service accounts should match their name in Active Directory.

Any user accounts that renamed themselves will be corrected to their proper username according to their account type.

Organizations

General Use and Naming Conventions

Any user may create a new organization at any time. A user may create any number of organizations.

Organizations should be named after the purpose they serve, and it is highly recommended to avoid common names such as “homework”, or “project”. If an official unit on campus wishes to create an organization and the logical name for the organization has been taken, the existing organization will be renamed and the owners will be notified of the change. Please contact the NC State GitHub Service Team if your unit’s organization name has already been taken.

Organizations share a namespace with user accounts, and so organizations that have a naming conflict with a UnityID will be renamed and the owners will be notified of the change. We highly recommend choosing an organization name with a minimum of 12 characters in order to ensure the organization name will not conflict with a UnityID.

Organization names that are deemed offensive will be renamed and the owners will be notified of the change.

Orphaned Organizations

In the event an organization has a single owner, and that owner’s account has been decommissioned, the organization is considered “orphaned”. Ownership of the organization is transferred to a service account controlled by the NC State GitHub Service Team. Repositories and membership of the organization are left as they are at the time of transfer.

A member of an orphaned organization may contact the service team and request ownership of the organization. Ownership will be transferred to that user, and the organization will no longer be considered “orphaned”. If multiple members request ownership, all will be granted ownership.

Orphaned organizations with no additional members will be decommissioned after one year, and all repositories will be deleted.

Repositories

Ownership and Permissions

User repositories are owned by their creator, and the owner has sole discretion for assigning other users permissions to access the repository.

Organization repositories are owned by the organization, and permissions are assigned as configured by the organization settings.

Any additional access requests should go though the repository owner, or a user with delegated permissions.

The contents of a repository are pursuant to University Policy 10.00.01 and generally content in repositories owned by a student is property of the student, while content in repositories owned by an employee is property of the university.

In cases where the owner is unable or unwilling to grant access, and the contents of the repository are university property, users may reach out to the NC State GitHub Service Team, and ownership of the repository will be transferred to an appropriate party.

General Use and Naming Conventions

Any user may create a new repository at any time. A user may create any number of repositories.

Repositories may be named anything. Repositories are always scoped to a user account or organization, so there is no risk of naming conflicts with other users.

Repositories with names that are deemed offensive will be renamed and the owner will be notified of the change.

Size and File Type Limits

There are no restrictions on what types of files may be included in a git repository. It is recommended to keep binary files out of repositories because they are not handled well by git, but it is allowed if desired.

There is a hard file size limit of 100MB. Commits containing files larger than 100MB in size will be rejected when pushing the commits to GitHub. You will need to drop the commits containing the large files before you will be able to push. Attempting to work around this limit by breaking up larger files into 100MB chunks is generally not recommended, as you will quickly expand the overall size of the repository.

There is no hard limit on overall repository size; however, we do enforce soft limits. Users that use an abnormally large amount of disk space will be given a warning and asked to reduce their repository size if possible. In the event a repository size causes performance issues for the service, the repository will be removed and the owner will be notified. Generally, repositories should be no larger than 1GB at most.

GitHub Actions

GitHub Actions are automation workflows which can be added to a repository to facilitate tasks such as automated testing and deployment. This feature is available to all users and organizations in the NC State GitHub service. The NC State GitHub Service Team does not provide general support for implementing Actions, but can assist with configuring Runners and give general advice to users.

The NC State GitHub Service Team maintains a pool of Actions Runners (Global Actions Runners) which are available for use by any user or organization in the service. These Runners are configured with a suite of useful software, and users may request additional software be added. Docker containers are usable from within the Runners, so users are able to utilize their own software via containers if desired. The Global Actions Runners are a shared service, and workflows are processed in the order in which they arrive. There may be a queue for workflows to be processed. If a workflow is found to be negatively impacting the health of the Global Actions Runners, the workflow may be disabled by the service team and the owner will be notified.

Any user or organization is free to set up and configure their own Actions Runners for their own use (Self-Hosted Actions Runners). The NC State GitHub Service Team is not responsible in any way for the maintenance, security, or support of Self-Hosted Actions Runners, and users who opt to set up and use a Self-Hosted Actions Runner do so at their own risk.

Users and organizations may utilize Actions from the GitHub Marketplace, with the restriction that only Actions from Verified Creators are available for use. This includes Actions created by GitHub themselves, and from vendors which have been approved by GitHub.

Artifacts and Logs from workflow execution are kept for a period of 30 days, after which they are deleted and are inaccessible.

Disaster Recovery

The GitHub Enterprise server is a VM in the OIT VMware infrastructure running in the data center. The GitHub Enterprise server is backed up nightly to another server which is then backed up into the standard OIT backup environment with backups retained for 30 days for the purposes of Disaster Recovery. Implementing the Disaster Recovery plan consists of building a new VM from the image provided by GitHub and restoring the backup. The same process has been used multiple times for server migrations successfully.

For recovering individual repositories, the GitHub Enterprise server soft deletes the content for 90 days, allowing the service team to recover it without having to go to backup.