> For the complete documentation index, see [llms.txt](https://dailyjournal.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dailyjournal.gitbook.io/notes/tools/github.md).

# GitHub

**GitHub** is a cloud platform that uses Git as its core technology. It simplifies the process of collaborating on projects and provides a website, command-line tools, and overall flow that allows developers and users to work together. GitHub acts as the "remote repository" 

**Forking a Repository** - **Forking** a repository makes a copy of the repository in your GitHub account. The parent repository is referred to as the **upstream** while your forked copy is referred to as the **origin**.

## GitHub Actions

{% embed url="<https://youtu.be/cP0I9w2coGU>" %}

**GitHub actions** provide task automation and workflow functionality in a repository. Actions can be used to streamline processes in your software development lifecycle and implement continuous integration and continuous deployment (CI/CD).

GitHub Actions are composed of the following components:

* **Workflows**: Automated processes added to your repository.
* **Events**: An activity that triggers a workflow.
* **Jobs**: A set of steps that execute on a runner.
* **Steps**: A task that can run one or more commands (actions).
* **Actions**: Standalone commands that can be combined into steps. Multiple steps can be combined to create a job.
* **Runners**: Server that has the GitHub Actions runner application installed.

### Two types of GitHub actions <a href="#two-types-of-github-actions" id="two-types-of-github-actions"></a>

There are two types of GitHub actions: container actions and JavaScript actions.

With **container actions**, the environment is part of the action's code. These actions can only be run in a Linux environment that GitHub hosts. Container actions support many different languages.

**JavaScript actions** don't include the environment in the code. This means you'll have to specify the environment to execute these actions. You can run in a VM in the cloud or on-premises. JavaScript actions support Linux, macOS and Windows environments.

### The components of GitHub Actions <a href="#the-components-of-github-actions" id="the-components-of-github-actions"></a>

![](https://1151231797-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQAaqgCwmb83T8T0x2j%2F-Me6H7LJ6q3ZxAPCTTT-%2F-Me6Iwr2Co9I_XtGHGMA%2Fimage.png?alt=media\&token=894f1916-fd25-475a-87c0-cc0a882b2936)

## Continuous Integration (CI)

CI is the practice of using automation to build and test software every time a developer commits changes to version control.

&#x20;In addition to default environment variables, you can use defined variables as contexts. Contexts and default variables are similar in that they both provide access to environment information, but they have some important differences. While default environment variables can only be used within the runner, context variables can be used at any point within the workflow. For example, context variables enable you to run an `if` statement to evaluate an expression before the runner is executed.

```yaml
name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"
```

This example is using the `github.ref` context to check the branch that triggered the workflow. If the branch is `main`, the runner is executed and prints out "Deploying to production server on branch $GITHUB\_REF". The default environment variable `$GITHUB_REF` is used in the runner to refer to the branch.&#x20;

{% hint style="info" %}
Notice that default environment variables are all uppercase where context variables are all lowercase.
{% endhint %}

#### Custom Environment Variables

Similar to using default environment variables, you can use custom environment variables in your workflow file. To create a custom variable, you need to define it in your workflow file using the `env` context. If you want to use the value of an environment variable inside a runner, you can use the runner operating system's normal method for reading environment variables.

```yaml
name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        env:
          First_Name: Mona
```

### Scripts in your workflow <a href="#scripts-in-your-workflow" id="scripts-in-your-workflow"></a>

In the above workflow snippet examples, the `run` keyword is used to simply print a string of text. Since the `run` keyword tells the job to execute a command on the runner, you use the `run` keyword to run actions or scripts.

```yaml
jobs:
  example-job:
    steps:
      - run: npm install -g bats
```

In this example, you are using npm to install the bats software testing package by using the `run` keyword. You can also run a script as an action. You can store the script in your repository, often done in a `.github/scripts/` directory, and then supply the path and shell type using the `run` keyword.

```yaml
jobs:
  example-job:
    steps:
      - name: Run build script
        run: ./.github/scripts/build.sh
        shell: bash
```