GitHub Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 9: Line 9:


==Repository Name==
==Repository Name==
The repository name may not contain slashes.


=Webhooks=
=Webhooks=

Revision as of 04:40, 7 September 2022

Internal

Repository

https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories

The elements fully identifying a repository within GitHub are:

Owner

The owner can be an organization or an individual user.

Repository Name

The repository name may not contain slashes.

Webhooks

https://developer.github.com/webhooks/

A webhook is a mechanism that triggers a HTTP POST invocation into the webhook's external URL, every time a specific event occurs.

A webhook can be installed on an organization or on a specific repository. Once installed, it will be triggered each time one or more subscribed events happen in that organization/repository.

Can be set via UI: Repository -> Settings -> Options: Webhooks.

Webhook Secret

Used by OpenShift for its S2I build strategy.

Pull-Request

https://help.github.com/en/articles/creating-a-pull-request

Usually, a pull request is initiated from a feature branch and indicates the intent to merge with the develop branch. It is possible to initiate pull requests from a previously cloned repository as well.

The pull requests have to be reviewed, approved and explicitly applied by the owner of the parent repository.

A reviewer is a person you want to review your code. It is not necessarily a person responsible for the specific area the PR applies to, or responsible for merging the commit. However it is a good idea to co-opt as reviewer a person who worked with that code before. When assigning a "reviewer", make sure to click the "Request" link at the right of the reviewer's name.

An assignee is usually the PR opener, who normally is also the person responsible with merging the PR after consent from reviewer(s).

Also see Git cloning.

Also see:

Pull Request Procedures

Required Reviews for Pull Requests

Required Reviews for Pull Requests

Code Owners

https://help.github.com/en/articles/about-code-owners

Protected Branch

Security

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure

Authentication

An user accessing GitHub is in the position to authenticate in the following situations: when using a browser, when using the CLI, when using the API and when using GitHub Desktop.

Browser Authentication

CLI Authentication

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-authentication-to-github#authenticating-with-the-command-line
https://cli.github.com/manual/gh_auth_login

API Authentication

GitHub Desktop Authentication

Personal Access Token

https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line

A personal access token is a piece of information that more here... . GitHub grants access to whoever makes a HTTPS invocation and presents this token: it function like an ordinary OAuth access token. It also can be used instead of a password for Git over HTTPS, or can be used to authenticate to the API over Basic Authentication. Git API access is allowed in presence of the tocken. A personal access token is similar to a password, in that they should be protected carefully. They are usually though placed in scripts, when building automated CI/CD pipelines. The advantage of using a token instead of a password is that the tokens can be revoked, can be proactively rotated, and then a lot of them can be created.

The list of already generated tokens can be obtained at https://github.com/settings/tokens (account -> Settings -> Developer settings -> Personal access tokens.

Operations:

Create a Personal Access Token for Command Line

OAuth Support

https://developer.github.com/v3/oauth_authorizations

GitHub's OAuth implementation supports the standard authorization code grant type (https://tools.ietf.org/html/rfc6749#section-4.1).

OAuth Token

https://help.github.com/en/articles/git-automation-with-oauth-tokens

OAuth App

https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/

Query Language

https://help.github.com/en/github/searching-for-information-on-github/understanding-the-search-syntax
is:pr
author:ovidiuf

PRs merged between a certain date range:

is:pr author:ovidiuf merged:2020-03-16..2020-03-21

Organization

Actions

GitHub Actions

Images

The "natural" width for GitHub Markdown images seems to be 7.65 inches, while saved at 42 pixels/inch. This results in an image 833 pixels wide.

OpenOffice Save.png

Text Width

Text Width in Markdown Documents

The optimal code text width is 94.

        10|       20|       30|       40|       50|       60|       70|       80|       90|94|
1234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234

Text Width in Code

160

#       10|       20|       30|       40|       50|       60|       70|       80|       90|      100|      110|      120|      130|      140|      150|      160|
#234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|234567890|

GitHub Apps

https://docs.github.com/en/developers/apps/getting-started-with-apps