Struct roctogen::endpoints::repos::Repos[−][src]

pub struct Repos<'api> { /* fields omitted */ }

Implementations

[src]

impl<'api> Repos<'api>

[src]

pub async fn accept_invitation_for_authenticated_user_async(
&self,
invitation_id: i32
) -> Result<(), ReposAcceptInvitationForAuthenticatedUserError>

Accept a repository invitation

GitHub API docs for accept_invitation_for_authenticated_user

[src]

pub fn accept_invitation_for_authenticated_user(
&self,
invitation_id: i32
) -> Result<(), ReposAcceptInvitationForAuthenticatedUserError>

Accept a repository invitation

GitHub API docs for accept_invitation_for_authenticated_user

[src]

pub async fn add_app_access_restrictions_async(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddAppAccessRestrictions
) -> Result<Vec<Integration>, ReposAddAppAccessRestrictionsError>

Add app access restrictions

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

Grants the specified apps push access for this branch. Only installed GitHub Apps with write access to the contents permission can be added as authorized actors on a protected branch.

Type	Description
`array`	The GitHub Apps that have push access to this branch. Use the app’s `slug`. Note: The list of users, apps, and teams in total is limited to 100 items.

GitHub API docs for add_app_access_restrictions

[src]

pub fn add_app_access_restrictions(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddAppAccessRestrictions
) -> Result<Vec<Integration>, ReposAddAppAccessRestrictionsError>

Add app access restrictions

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

Grants the specified apps push access for this branch. Only installed GitHub Apps with write access to the contents permission can be added as authorized actors on a protected branch.

Type	Description
`array`	The GitHub Apps that have push access to this branch. Use the app’s `slug`. Note: The list of users, apps, and teams in total is limited to 100 items.

GitHub API docs for add_app_access_restrictions

[src]

pub async fn add_collaborator_async(
 &self,
 owner: &str,
 repo: &str,
 username: &str,
 body: PutReposAddCollaborator
) -> Result<RepositoryInvitation, ReposAddCollaboratorError>

Add a repository collaborator

This endpoint triggers notifications. Creating content too quickly using this endpoint may result in secondary rate limiting. See “Secondary rate limits” and “Dealing with secondary rate limits” for details.

For more information on permission levels, see “Repository permission levels for an organization”. There are restrictions on which permissions can be granted to organization members when an organization base role is in place. In this case, the permission being given must be equal to or higher than the org base permission. Otherwise, the request will fail with:

Cannot assign {member} permission of {role name}

Note that, if you choose not to pass any parameters, you’ll need to set Content-Length to zero when calling out to this endpoint. For more information, see “HTTP verbs.”

The invitee will receive a notification that they have been invited to the repository, which they must accept or decline. They may do this via the notifications page, the email they receive, or by using the repository invitations API endpoints.

Rate limits

You are limited to sending 50 invitations to a repository per 24 hour period. Note there is no limit if you are inviting organization members to an organization repository.

GitHub API docs for add_collaborator

[src]

pub fn add_collaborator(
 &self,
 owner: &str,
 repo: &str,
 username: &str,
 body: PutReposAddCollaborator
) -> Result<RepositoryInvitation, ReposAddCollaboratorError>

Add a repository collaborator

This endpoint triggers notifications. Creating content too quickly using this endpoint may result in secondary rate limiting. See “Secondary rate limits” and “Dealing with secondary rate limits” for details.

For more information on permission levels, see “Repository permission levels for an organization”. There are restrictions on which permissions can be granted to organization members when an organization base role is in place. In this case, the permission being given must be equal to or higher than the org base permission. Otherwise, the request will fail with:

Cannot assign {member} permission of {role name}

Note that, if you choose not to pass any parameters, you’ll need to set Content-Length to zero when calling out to this endpoint. For more information, see “HTTP verbs.”

The invitee will receive a notification that they have been invited to the repository, which they must accept or decline. They may do this via the notifications page, the email they receive, or by using the repository invitations API endpoints.

Rate limits

You are limited to sending 50 invitations to a repository per 24 hour period. Note there is no limit if you are inviting organization members to an organization repository.

GitHub API docs for add_collaborator

[src]

pub async fn add_status_check_contexts_async(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddStatusCheckContexts
) -> Result<Vec<String>, ReposAddStatusCheckContextsError>

Add status check contexts

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

GitHub API docs for add_status_check_contexts

[src]

pub fn add_status_check_contexts(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddStatusCheckContexts
) -> Result<Vec<String>, ReposAddStatusCheckContextsError>

Add status check contexts

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

GitHub API docs for add_status_check_contexts

[src]

pub async fn add_team_access_restrictions_async(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddTeamAccessRestrictions
) -> Result<Vec<Team>, ReposAddTeamAccessRestrictionsError>

Add team access restrictions

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

Grants the specified teams push access for this branch. You can also give push access to child teams.

Type	Description
`array`	The teams that can have push access. Use the team’s `slug`. Note: The list of users, apps, and teams in total is limited to 100 items.

GitHub API docs for add_team_access_restrictions

[src]

pub fn add_team_access_restrictions(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddTeamAccessRestrictions
) -> Result<Vec<Team>, ReposAddTeamAccessRestrictionsError>

Add team access restrictions

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

Grants the specified teams push access for this branch. You can also give push access to child teams.

Type	Description
`array`	The teams that can have push access. Use the team’s `slug`. Note: The list of users, apps, and teams in total is limited to 100 items.

GitHub API docs for add_team_access_restrictions

[src]

pub async fn add_user_access_restrictions_async(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddUserAccessRestrictions
) -> Result<Vec<SimpleUser>, ReposAddUserAccessRestrictionsError>

Add user access restrictions

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

Grants the specified people push access for this branch.

Type	Description
`array`	Usernames for people who can have push access. Note: The list of users, apps, and teams in total is limited to 100 items.

GitHub API docs for add_user_access_restrictions

[src]

pub fn add_user_access_restrictions(
 &self,
 owner: &str,
 repo: &str,
 branch: &str,
 body: PostReposAddUserAccessRestrictions
) -> Result<Vec<SimpleUser>, ReposAddUserAccessRestrictionsError>

Add user access restrictions

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

Grants the specified people push access for this branch.

Type	Description
`array`	Usernames for people who can have push access. Note: The list of users, apps, and teams in total is limited to 100 items.

GitHub API docs for add_user_access_restrictions

[src]

pub async fn check_collaborator_async(
 &self,
 owner: &str,
 repo: &str,
 username: &str
) -> Result<(), ReposCheckCollaboratorError>

Check if a user is a repository collaborator

For organization-owned repositories, the list of collaborators includes outside collaborators, organization members that are direct collaborators, organization members with access through team memberships, organization members with access through default organization permissions, and organization owners.

Team members will include the members of child teams.

GitHub API docs for check_collaborator

[src]

pub fn check_collaborator(
 &self,
 owner: &str,
 repo: &str,
 username: &str
) -> Result<(), ReposCheckCollaboratorError>

Check if a user is a repository collaborator

For organization-owned repositories, the list of collaborators includes outside collaborators, organization members that are direct collaborators, organization members with access through team memberships, organization members with access through default organization permissions, and organization owners.

Team members will include the members of child teams.

GitHub API docs for check_collaborator

[src]

pub async fn check_vulnerability_alerts_async(
 &self,
 owner: &str,
 repo: &str
) -> Result<(), ReposCheckVulnerabilityAlertsError>

Check if vulnerability alerts are enabled for a repository

Shows whether dependency alerts are enabled or disabled for a repository. The authenticated user must have admin access to the repository. For more information, see “About security alerts for vulnerable dependencies”.

GitHub API docs for check_vulnerability_alerts

[src]

pub fn check_vulnerability_alerts(
 &self,
 owner: &str,
 repo: &str
) -> Result<(), ReposCheckVulnerabilityAlertsError>

Check if vulnerability alerts are enabled for a repository

Shows whether dependency alerts are enabled or disabled for a repository. The authenticated user must have admin access to the repository. For more information, see “About security alerts for vulnerable dependencies”.

GitHub API docs for check_vulnerability_alerts

[src]

pub async fn compare_commits_async(
 &self,
 owner: &str,
 repo: &str,
 basehead: &str,
 query_params: Option<impl Into<ReposCompareCommitsParams>>
) -> Result<CommitComparison, ReposCompareCommitsError>

Compare two commits

The basehead param is comprised of two parts: base and head. Both must be branch names in repo. To compare branches across other repositories in the same network as repo, use the format <USERNAME>:branch.

The response from the API is equivalent to running the git log base..head command; however, commits are returned in chronological order. Pass the appropriate media type to fetch diff and patch formats.

The response also includes details on the files that were changed between the two commits. This includes the status of the change (for example, if a file was added, removed, modified, or renamed), and details of the change itself. For example, files with a renamed status have a previous_filename field showing the previous filename of the file, and files with a modified status have a patch field showing the changes made to the file.

Working with large comparisons

To process a response with a large number of commits, you can use (per_page or page) to paginate the results. When using paging, the list of changed files is only returned with page 1, but includes all changed files for the entire comparison. For more information on working with pagination, see “Traversing with pagination.”

When calling this API without any paging parameters (per_page or page), the returned list is limited to 250 commits and the last commit in the list is the most recent of the entire comparison. When a paging parameter is specified, the first commit in the returned list of each page is the earliest.

Signature verification object

The response will include a verification object that describes the result of verifying the commit’s signature. The following fields are included in the verification object:

Name	Type	Description
`verified`	`boolean`	Indicates whether GitHub considers the signature in this commit to be verified.
`reason`	`string`	The reason for verified value. Possible values and their meanings are enumerated in table below.
`signature`	`string`	The signature that was extracted from the commit.
`payload`	`string`	The value that was signed.

These are the possible values for reason in the verification object:

Value	Description
`expired_key`	The key that made the signature is expired.
`not_signing_key`	The “signing” flag is not among the usage flags in the GPG key that made the signature.
`gpgverify_error`	There was an error communicating with the signature verification service.
`gpgverify_unavailable`	The signature verification service is currently unavailable.
`unsigned`	The object does not include a signature.
`unknown_signature_type`	A non-PGP signature was found in the commit.
`no_user`	No user was associated with the `committer` email address in the commit.
`unverified_email`	The `committer` email address in the commit was associated with a user, but the email address is not verified on her/his account.
`bad_email`	The `committer` email address in the commit is not included in the identities of the PGP key that made the signature.
`unknown_key`	The key that made the signature has not been registered with any user’s account.
`malformed_signature`	There was an error parsing the signature.
`invalid`	The signature could not be cryptographically verified using the key whose key-id was found in the signature.
`valid`	None of the above errors applied, so the signature is considered to be verified.

GitHub API docs for compare_commits

[src]

pub fn compare_commits(
 &self,
 owner: &str,
 repo: &str,
 basehead: &str,
 query_params: Option<impl Into<ReposCompareCommitsParams>>
) -> Result<CommitComparison, ReposCompareCommitsError>

Compare two commits

The basehead param is comprised of two parts: base and head. Both must be branch names in repo. To compare branches across other repositories in the same network as repo, use the format <USERNAME>:branch.

The response from the API is equivalent to running the git log base..head command; however, commits are returned in chronological order. Pass the appropriate media type to fetch diff and patch formats.

The response also includes details on the files that were changed between the two commits. This includes the status of the change (for example, if a file was added, removed, modified, or renamed), and details of the change itself. For example, files with a renamed status have a previous_filename field showing the previous filename of the file, and files with a modified status have a patch field showing the changes made to the file.

Working with large comparisons

To process a response with a large number of commits, you can use (per_page or page) to paginate the results. When using paging, the list of changed files is only returned with page 1, but includes all changed files for the entire comparison. For more information on working with pagination, see “Traversing with pagination.”

When calling this API without any paging parameters (per_page or page), the returned list is limited to 250 commits and the last commit in the list is the most recent of the entire comparison. When a paging parameter is specified, the first commit in the returned list of each page is the earliest.

Signature verification object

The response will include a verification object that describes the result of verifying the commit’s signature. The following fields are included in the verification object:

Name	Type	Description
`verified`	`boolean`	Indicates whether GitHub considers the signature in this commit to be verified.
`reason`	`string`	The reason for verified value. Possible values and their meanings are enumerated in table below.
`signature`	`string`	The signature that was extracted from the commit.
`payload`	`string`	The value that was signed.

These are the possible values for reason in the verification object:

Value	Description
`expired_key`	The key that made the signature is expired.
`not_signing_key`	The “signing” flag is not among the usage flags in the GPG key that made the signature.
`gpgverify_error`	There was an error communicating with the signature verification service.
`gpgverify_unavailable`	The signature verification service is currently unavailable.
`unsigned`	The object does not include a signature.
`unknown_signature_type`	A non-PGP signature was found in the commit.
`no_user`	No user was associated with the `committer` email address in the commit.
`unverified_email`	The `committer` email address in the commit was associated with a user, but the email address is not verified on her/his account.
`bad_email`	The `committer` email address in the commit is not included in the identities of the PGP key that made the signature.
`unknown_key`	The key that made the signature has not been registered with any user’s account.
`malformed_signature`	There was an error parsing the signature.
`invalid`	The signature could not be cryptographically verified using the key whose key-id was found in the signature.
`valid`	None of the above errors applied, so the signature is considered to be verified.

GitHub API docs for compare_commits

[src]

pub async fn create_autolink_async(
 &self,
 owner: &str,
 repo: &str,
 body: PostReposCreateAutolink
) -> Result<Autolink, ReposCreateAutolinkError>

Create an autolink reference for a repository

Users with admin access to the repository can create an autolink.

GitHub API docs for create_autolink

[src]

pub fn create_autolink(
 &self,
 owner: &str,
 repo: &str,
 body: PostReposCreateAutolink
) -> Result<Autolink, ReposCreateAutolinkError>

Create an autolink reference for a repository

Users with admin access to the repository can create an autolink.

GitHub API docs for create_autolink

[src]

pub async fn create_commit_comment_async(
 &self,
 owner: &str,
 repo: &str,
 commit_sha: &str,
 body: PostReposCreateCommitComment
) -> Result<CommitComment, ReposCreateCommitCommentError>

Create a commit comment

Create a comment for a commit using its :commit_sha.

This endpoint triggers notifications. Creating content too quickly using this endpoint may result in secondary rate limiting. See “Secondary rate limits” and “Dealing with secondary rate limits” for details.

GitHub API docs for create_commit_comment

[src]

pub fn create_commit_comment(
 &self,
 owner: &str,
 repo: &str,
 commit_sha: &str,
 body: PostReposCreateCommitComment
) -> Result<CommitComment, ReposCreateCommitCommentError>

Create a commit comment

Create a comment for a commit using its :commit_sha.

This endpoint triggers notifications. Creating content too quickly using this endpoint may result in secondary rate limiting. See “Secondary rate limits” and “Dealing with secondary rate limits” for details.

GitHub API docs for create_commit_comment

[src]

pub async fn create_commit_signature_protection_async(
 &self,
 owner: &str,
 repo: &str,
 branch: &str
) -> Result<ProtectedBranchAdminEnforced, ReposCreateCommitSignatureProtectionError>

Create commit signature protection

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

When authenticated with admin or owner permissions to the repository, you can use this endpoint to require signed commits on a branch. You must enable branch protection to require signed commits.

GitHub API docs for create_commit_signature_protection

[src]

pub fn create_commit_signature_protection(
 &self,
 owner: &str,
 repo: &str,
 branch: &str
) -> Result<ProtectedBranchAdminEnforced, ReposCreateCommitSignatureProtectionError>

Create commit signature protection

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub’s products in the GitHub Help documentation.

When authenticated with admin or owner permissions to the repository, you can use this endpoint to require signed commits on a branch. You must enable branch protection to require signed commits.

GitHub API docs for create_commit_signature_protection

[src]

pub async fn create_commit_status_async(
 &self,
 owner: &str,
 repo: &str,
 sha: &str,
 body: PostReposCreateCommitStatus
) -> Result<Status, ReposCreateCommitStatusError>

Create a commit status

Users with push access in a repository can create commit statuses for a given SHA.

Note: there is a limit of 1000 statuses per sha and context within a repository. Attempts to create more than 1000 statuses will result in a validation error.

GitHub API docs for create_commit_status

[src]

pub fn create_commit_status(
 &self,
 owner: &str,
 repo: &str,
 sha: &str,
 body: PostReposCreateCommitStatus
) -> Result<Status, ReposCreateCommitStatusError>

Create a commit status

Users with push access in a repository can create commit statuses for a given SHA.

Note: there is a limit of 1000 statuses per sha and context within a repository. Attempts to create more than 1000 statuses will result in a validation error.

GitHub API docs for create_commit_status

[src]

pub async fn create_deploy_key_async(
 &self,
 owner: &str,
 repo: &str,
 body: PostReposCreateDeployKey
) -> Result<DeployKey, ReposCreateDeployKeyError>

Create a deploy key

You can create a read-only deploy key.

GitHub API docs for create_deploy_key

[src]

pub fn create_deploy_key(
 &self,
 owner: &str,
 repo: &str,
 body: PostReposCreateDeployKey
) -> Result<DeployKey, ReposCreateDeployKeyError>

Create a deploy key

You can create a read-only deploy key.

GitHub API docs for create_deploy_key

[src]

pub async fn create_deployment_async(
 &self,
 owner: &str,
 repo: &str,
 body: PostReposCreateDeployment
) -> Result<Deployment, ReposCreateDeploymentError>

Create a deployment

Deployments offer a few configurable parameters with certain defaults.

The ref parameter can be any named branch, tag, or SHA. At GitHub we often deploy branches and verify them before we merge a pull request.

The environment parameter allows deployments to be issued to different runtime environments. Teams often have multiple environments for verifying their applications, such as production, staging, and qa. This parameter makes it easier to track which environments have requested deployments. The default environment is production.

The auto_merge parameter is used to ensure that the requested ref is not behind the repository’s default branch. If the ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds, the API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will return a failure response.

By default, commit statuses for every submitted context must be in a success state. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to specify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do not require any contexts or create any commit statuses, the deployment will always succeed.

The payload parameter is available for any extra information that a deployment system might need. It is a JSON text field that will be passed on when a deployment event is dispatched.

The task parameter is used by the deployment system to allow different execution paths. In the web world this might be deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an application with debugging enabled.

Users with repo or repo_deployment scopes can create a deployment for a given ref.

Merged branch response

You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating a deployment. This auto-merge happens when:

Auto-merge option is enabled in the repository
Topic branch does not include the latest changes on the base branch, which is master in the response example
There are no merge conflicts

If there are no new commits in the base branch, a new request to create a deployment should give a successful response.

Merge conflict response

This error happens when the auto_merge option is enabled and when the default branch (in this case master), can’t be merged into the branch that’s being deployed (in this case topic-branch), due to merge conflicts.

Failed commit status checks

This error happens when the required_contexts parameter indicates that one or more contexts need to have a success status for the commit to be deployed, but one or more of the required contexts do not have a state of success.

GitHub API docs for create_deployment

[src]

pub fn create_deployment(
 &self,
 owner: &str,
 repo: &str,
 body: PostReposCreateDeployment
) -> Result<Deployment, ReposCreateDeploymentError>