feat: Add pages from code-cookbook

Author: MichaelCurrin

cheatsheets/ci-cd/github-actions/definitions.md

@@ -0,0 +1,21 @@
+# Definitions
+> Copied from Github UI or docs
+
+## Personal access tokens
+
+aka "PAT"
+
+> Tokens you have generated that can be used to access the GitHub API.
+>
+> Make sure to copy your new personal access token now. You won’t be able to see it again!
+
+If you have one token across repos, then if need to regenerate, then you'd have to go and update everywhere.
+
+So you might want to create a PAT for each application as a one to one mapping.
+
+
+## Secrets
+
+> Secrets are environment variables that are **encrypted** and only exposed to selected actions. Anyone with **collaborator** access to this repository can use these secrets in a workflow.
+>
+> Secrets are not passed to workflows that are triggered by a pull request from a fork

cheatsheets/ci-cd/github-actions/index.md

@@ -0,0 +1,26 @@
+---
+layout: listing
+logo: githubactions
+---
+# GitHub Actions
+> Guide to syntax for GitHub Actions workflows
+
+
+## Intro
+
+
+## About
+
+This section covers how to use GitHub Actions in a CI/CD flow such as you run automated tests, deploy and publish your repo. All running for free in the cloud whenever the workflow is triggered such as with a push or merged Pull Request.
+
+To use GH Actions, you must create a workflow YAML file with appropriate fields set including triggers and steps. You can write shell commands as _steps_ and you can use use actions from the GH Marketplace to help you setup your environment (install a language and packages) and perform test and deploy steps, without you having to write a lot of code.
+
+
+## Getting started
+
+Here are some other areas to start with:
+
+- Workflow syntax and samples / use-cases around them
+    - [Jobs](jobs.md)
+    - [Triggers](triggers.md)
+- [Resources](resources.md) for external links such as to docs, to help you get into how Actions work and the syntax

cheatsheets/ci-cd/github-actions/jobs.md

@@ -0,0 +1,150 @@
+# Jobs cheatsheet
+> Syntax for jobs in GH actions workflow file
+
+{% raw %}
+
+See [Workflow syntax for Github Actions](https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions) in Github docs.
+
+> A workflow run is made up of one or more jobs. Jobs run in **parallel** by default.
+>
+> To run jobs sequentially, you can define dependencies on other jobs using the `jobs.<job_id>.needs` keyword.
+>
+> Each job runs in an environment specified by runs-on.
+
+
+## Job IDs
+
+Each job must have a unique ID as below. This must start with a letter or `_` and contain only alphanumeric characters, `-`, or `_`.
+
+```yaml
+jobs:
+  my_first_job:
+    name: My first job
+
+  my_second_job:
+    name: My second job
+```
+
+Using `runs-on`.
+
+```yaml
+jobs:
+  my_first_job:
+    runs-on: ubuntu-latest
+    name: My first job
+
+  my_second_job:
+    runs-on: ubuntu-latest
+    name: My second job
+```
+
+
+## Needs
+
+By default jobs run in parallel.
+
+Here we setup a sequence of jobs that only run if the previous one passed.
+
+[Job Needs](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds) docs.
+
+> Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional statement that causes the job to continue.
+
+- `main.yml`
+    ```yaml
+    jobs:
+      job1:
+
+      job2:
+        needs: job1
+
+      job3:
+        needs: [job1, job2]
+    ```
+
+See [job output](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjobs_idoutputs) in the docs for how to persist or [upload and download artifications](https://docs.github.com/en/actions/guides/storing-workflow-data-as-artifacts#passing-data-between-jobs-in-a-workflow). If you don't do this, then a `build` directory from one job can't be used by the other job.
+
+Using job output in a dependent job:
+
+- `main.yml`
+    ```yaml
+    jobs:
+      job1:
+        runs-on: ubuntu-latest
+
+        # Map a step output to a job output
+        outputs:
+          output1: ${{ steps.step1.outputs.test }}
+          output2: ${{ steps.step2.outputs.test }}
+
+        steps:
+        - id: step1
+          run: echo "::set-output name=test::hello"
+        - id: step2
+          run: echo "::set-output name=test::world"
+
+      job2:
+        runs-on: ubuntu-latest
+
+        needs: job1
+
+        steps:
+        - run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}
+    ```
+
+
+## If statement
+
+This step only runs when the event type is a pull_request and the event action is unassigned.
+
+- `main.yml`
+    ```yaml
+    steps:
+     - name: My first step
+       if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
+       run: echo This event is a pull request that had an assignee removed.
+    ```
+- `main.yml`
+    ```yaml
+    steps:
+    - name: Print a greeting
+      env:
+        MY_VAR: Hi there! My name is
+        FIRST_NAME: Mona
+        MIDDLE_NAME: The
+        LAST_NAME: Octocat
+      run: |
+        echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.
+    ```
+
+This can be useful if you want just one workflow file and one job but want to skip a deploy steps at the end.
+
+Read more
+
+- [Context and Expression Syntax](https://help.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions)
+- [If steps](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps).
+
+
+## Related
+
+### Env
+
+```yaml
+env:
+  SERVER: production
+```
+
+### Defaults
+
+```yaml
+defaults:
+  foo: bar
+```
+
+```yaml
+defaults:
+  run:
+    shell: bash
+    working-directory: scripts
+```
+
+{% endraw %}

cheatsheets/ci-cd/github-actions/resources.md

@@ -0,0 +1,40 @@
+# Resources
+> External links around GH Actions, from basic to advanced usage
+
+If you are new to GitHub Actions, I recommend going over my blog posts on dev.to - [Intro to GitHub Actions series](https://dev.to/michaelcurrin/series/9032)
+
+
+## Overview
+
+- [GitHub Actions Marketplace](https://github.com/marketplace)
+- [GitHub Actions](https://github.com/actions) org on Github
+- [GitHub Actions](https://github.community/c/github-actions) community forums
+
+
+## Documentation
+
+- [GitHub Actions Documentation](https://docs.github.com/en/actions)
+- [Configuring and managing workflows](https://docs.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow)
+    - A good step-by-step tutorial for setting up GH Actions
+- [Environment variables](https://docs.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables)
+- _Getting Started_ section
+    - [Core concepts](https://docs.github.com/en/actions/getting-started-with-github-actions/core-concepts-for-github-actions)
+- _Reference_ section
+    - [Workflow syntax](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions)
+    - [Events that trigger workflows](https://docs.github.com/en/actions/reference/events-that-trigger-workflows)
+    - [Context and expression syntax](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions)
+    - [Workflow commands](https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions)
+        - e.g. Setting color to green or showing a warning message.
+            ```yaml
+            - name: Set selected color
+              run: echo '::set-env name=SELECTED_COLOR::green'
+            ```
+        - This can be useful in workflows and when writing commands in the shell file for an action.
+
+
+## Limitations
+
+- [Intro to GitHub Actions blog post](https://gabrieltanner.org/blog/an-introduction-to-github-actions)
+    > Actions are completely free for every open-source repository and include **2000 free build minutes per month** for all your private repositories which is comparable with most CI/CD free plans. If that is not enough for your needs you can pick another plan or go the self-hosted route.
+- [Usage limits](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#usage-limits)
+    > On the free tier you can have _20 concurrent jobs_. I guess 20 on one repo or 20 repos with one each.

cheatsheets/ci-cd/github-actions/skip.md

@@ -0,0 +1,68 @@
+# Skip
+> How to skip some or all of the build steps
+
+{% raw %}
+
+## Ignore paths
+
+Don't run the workflow if changes were only made to certain paths, such as the `docs` directory.
+
+Remember to use quotes so stop YAML evaluation of the `**` glob.
+
+### Paths ignore attribute
+
+Use `paths-ignore` attribute.
+
+From [example ignoring paths](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#example-ignoring-paths) in the docs.
+
+```yaml
+on:
+  push:
+    paths-ignore:
+      - "docs/**"
+```
+
+If your docs directory has a lot of files in it that you edit often, then it is worth skipping that at least.
+
+You don't have to be thorough. Like I wouldn't put your `LICENSE` file in there as that hardly changes.
+
+### Paths attribute
+
+This will only build `.js` files and ignore others.
+
+```yaml
+on:
+  push:
+    paths:
+    - "**.js"
+```
+
+This is dangerous because you might leave your workflow file, `Makefile`, package files, etc. So can avoid being too restrictive accidentally by using the exclusion in the previous section instead.
+
+### Positive and negative paths
+
+Or using a `!` symbol in the `paths` attribute. The order matters. Here we include a directory and then exclude a subdirectory.
+
+```yaml
+on:
+  push:
+    paths:
+      - "sub-project/**"
+      - "!sub-project/docs/**"
+```
+
+
+## Skip step
+
+Add a condition to skip if the commit message containts the phrase `[ci skip]`.
+
+```yaml
+jobs:
+  deploy_docs:
+    if: "!contains(github.event.commits[0].message, '[ci skip]')"
+
+    steps:
+      # ...
+```
+
+{% endraw %}