gibo コマンドを使って .gitignore のテンプレートを簡単に作成する

ブログに載せるサンプルコードを管理したり，仕事でプロトタイプを実装することが多かったり，とにかく Git リポジトリを新しく作る機会が多くある．そのときに毎回似たような .gitignore を作ることになり，面倒だった．共通的な設定はホームディレクトリの ~/.gitignore を使っているけど，同僚とコードを共有することもあり，やはりリポジトリ単位に .gitignore を作成したかった．この運用を軽減するために使っているツールとして，今回は .gitignore のテンプレート（ボイラープレート）を簡単に作成できる「gibo」を紹介する．

gibo とは？

「gibo (short for .gitignore boilerplates)」 を使うと，例えば Python や Ruby など，プログラミング言語ごとに用意された .gitignore のテンプレートを簡単に作成できる．正確に表現すると，GitHub のリポジトリ github/gitignore に公開されているテンプレートを gibo コマンドを使って取得できる．よって，ラッパーコマンドのような立ち位置と言える．非常に便利でよく使っている．

github.com

github.com

gibo をインストールする

Mac なら brew コマンドを使えば，簡単にインストールできる．今回は最新版 v2.2.4 を前提にする．

$ brew install gibo

$ gibo version
gibo 2.2.4 by Simon Whitaker <sw@netcetera.org>
https://github.com/simonwhitaker/gibo

もし，ローカル環境にインストールしたくない場合は，Docker を使う案もある．

$ docker run --rm simonwhitaker/gibo version
gibo 2.2.4 by Simon Whitaker <sw@netcetera.org>
https://github.com/simonwhitaker/gibo

gibo を使う

基本的には gibo dump コマンドを使って，標準出力をリダイレクトする．以下のように gibo dump Python とすれば，Python 用の .gitignore を作成できるし，gibo dump Python macOS のようにスペース区切りで複数指定すれば，Python と Mac 用の .gitignore を作成できる．ほら .DS_Store を間違ってコミットしちゃった経験は誰にでもあるよね？笑

$ gibo dump Python >> .gitignore
$ gibo dump Python macOS >> .gitignore

Docker を使う場合は，以下のように docker run をすれば OK！

$ docker run --rm simonwhitaker/gibo dump Python >> .gitignore
$ docker run --rm simonwhitaker/gibo dump Python macOS >> .gitignore

タブ補完をする

gibo は「タブ補完」もサポートしている．README.md に bash / zsh / fish の設定が載っているけど，僕は oh-my-zsh を使っているため，Wiki を参考に oh-my-zsh の設定を紹介する．以下のように plugins/gibo ディレクトリを作成して，GitHub に公開されている gibo-completion.zsh にシンボリックリンクを貼るだけ！簡単！gibo-completion.zsh は任意のディレクトリに置いておけばよくて，僕は dotfiles の中に置いてある．設定が終わったら，zsh をリロードしておくのを忘れずに！

• Using gibo as an ohmyzsh plugin · simonwhitaker/gibo Wiki · GitHub

$ mkdir -p ${ZSH}/custom/plugins/gibo/
$ ln -s ~/dotfiles/gibo-completion.zsh ${ZSH}/custom/plugins/gibo/gibo.plugin.zsh

以下のように gibo [tab] と入力すれば，コマンドが表示されるし，gibo dump P [tab] と入力すれば，P にマッチするテンプレートを補完できる．便利だし，むしろ使えないと困る！

$ gibo [tab]
dump     -- Dump one or more boilerplates
help     -- Display this help text
list     -- List available boilerplates
root     -- Show the directory where gibo stores its boilerplates
search   -- Search for boilerplates
update   -- Update list of available boilerplates
version  -- Display current script version

$ gibo dump P [tab]
PSoCCreator    Perl           Pimcore        Prestashop     Puppet
Packer         Phalcon        PlayFramework  Processing     PureScript
Patch          Phoenix        Plone          PuTTY          Python

他にもコマンドはある

gibo dump コマンド以外だと，例えば gibo list コマンドを使うと，サポートしているテンプレートの一覧を確認できる．とは言え，さっき紹介した「タブ補完」を設定すれば gibo dump [tab] と入力すれば良く，個人的にはあまり使っていなかったりする．

$ gibo list
Actionscript        Dart            NetBeans        Node
Ada         Delphi          Ninja           Objective-C
Agda            DM          NotepadPP       OCaml
（省略）

gibo root コマンドを使うと，GitHub のリポジトリ github/gitignore を clone したディレクトリを確認できる．ようするに，テンプレートはローカルにコピーされている．すると，今度はテンプレート自体の更新をどのようにするのか？という点が気になると思う．gibo update コマンドを使えば，簡単に最新に追随できる．

$ gibo root
/Users/kakakakakku/.gitignore-boilerplates

$ ls -1 /Users/kakakakakku/.gitignore-boilerplates | wc -l
     132

$ gibo update
From github.com:github/gitignore
 * branch            master     -> FETCH_HEAD
Already up to date.

まとめ

もし GitHub のリポジトリ github/gitignore からコピーして .gitignore を作成している場合は，gibo を使ってシュッと .gitignore を作成すると便利！使うときは「タブ補完」も忘れずに設定しておくと良いぞ！

github.com

2020年6月にリリースされた「Redash v9.0.0-beta」の新機能と機能改善を「計10点」紹介

2020年6月に Redash の最新バージョン「Redash v9.0.0-beta」がリリースされた．正式リリースまでに変更される可能性はあるけど，Change Log を読むと新機能と機能改善が多くあった．今回は実際に試しながら「 Redash v9.0.0-beta の新機能と機能改善」を「計10点」厳選して紹介する．Change Log は以下の CHANGELOG.md で確認できる．

• redash/CHANGELOG.md at master · getredash/redash · GitHub

目次

1. データソースが追加された
2. クエリ画面がリニューアルされた
3. Date Range パラメータで直近n日を指定できるようになった
4. グラフ上で使える Plotly Mode Bar を非表示にできるようになった
5. クエリ結果を TSV 形式でダウンロードできるようになった
6. アラート画面がリニューアルされた
7. アラートのカスタムテンプレート機能が正式にリリースされた
8. アラートをミュートできるようになった
9. Celery を廃止して RQ に移行した
10. Python 3 を正式にサポートした

1. データソースが追加された

Redash はバージョンアップごとにデータソースが増えている．Redash v9.0.0-beta では「4種類」が追加されて「計55種類」になった．また今回は多くのデータソースに修正が入っているため，今まで困っていた挙動があれば，Change Log を見ておくと良いと思う．

• Amazon CloudWatch
• Amazon CloudWatch Logs Insights
• Azure Kusto
• Exasol

2. クエリ画面がリニューアルされた

クエリ画面のデザインがリニューアルされた．Change Log にも easier to read for non-technical Redash users と書かれている通り，直感的になったと思う．例えば「クエリ結果」と「グラフ」をタブから選べるようになった．

3. Date Range パラメータで直近n日を指定できるようになった

今まで Date Range パラメータを使う場合は，カレンダーから正確な日付を指定する必要があった．ようするに「直近n日」という毎日変化する日付は指定できなかった．今回追加された機能を使うと「This week」や「Last 30 days」など「計11種類」の選択肢から選べる．ダッシュボードを継続的にモニタリングしている場合などに特に便利な機能では！

• This week
• This month
• This year
• Last week
• Last month
• Last year
• Last 7 days
• Last 14 days
• Last 30 days
• Last 60 days
• Last 90 days

4. グラフ上で使える Plotly Mode Bar を非表示にできるようになった

個人的に特に不満なく使っていたけど，グラフ上にマウスを乗せると表示される Plotly Mode Bar を非表示にできるようになった．

設定は Organization Settings の中にあるため，勝手に設定変更はせず，チームで決めておくと良さそう．

5. クエリ結果を TSV 形式でダウンロードできるようになった

今までは「CSV 形式」と「Excel 形式」でダウンロードできたクエリ結果を「TSV 形式」でもダウンロードできるようになった．残るは「JSON 形式」と「YAML 形式」あたり？選択肢が増えるのは良いと思う．

6. アラート画面がリニューアルされた

アラート画面のデザインがリニューアルされた．今までの設定項目だった Op や Rearm seconds など，わかりにくかった表現もなくなり，直感的に設定できるようになった．

7. アラートのカスタムテンプレート機能が正式にリリースされた

Redash v8 でサイレントリリースされていたアラートの「カスタムテンプレート機能」が正式にリリースされた．今までは Feature Toggle の環境変数 REDASH_FEATURE_EXTENDED_ALERT_OPTIONS を有効化しないと使えなかった．なお，Redash v8 とはテンプレートの構文が変わっているので，ドキュメントを見ながら試すと良いと思う．現時点では「計10種類」の組み込み変数をサポートしている．

• ALERT_STATUS
• ALERT_CONDITION
• ALERT_THRESHOLD
• ALERT_NAME
• ALERT_URL
• QUERY_NAME
• QUERY_URL
• QUERY_RESULT_VALUE
• QUERY_RESULT_ROWS
• QUERY_RESULT_COLS

redash.io

実際に以下の「カスタムテンプレート」を用意した．

Subject

🛑 Redash アラート : {{ALERT_NAME}}

Body

アラート状態が "{{ALERT_STATUS}}" になりました 👀
値 "{{QUERY_RESULT_VALUE}}" は閾値 "{{ALERT_THRESHOLD}}" を超えました 📈

設定してから「Preview」を使うと，実際に組み込み変数を展開した値を確認することもできる．便利！

Slack にアラートを投稿してみた．情報量を増やすことができて便利！「カスタムテンプレート機能」は必須機能の1つになりそう！

8. アラートをミュートできるようになった

今まではアラートをミュートすることはできず，Destinations のエントリーを一時的に削除する運用などをしていた．Redash v9.0.0-beta から「Mute Notifications」と「Unmute Notifications」を使って切り替えられる．運用目線で便利なのでは！

9. Celery を廃止して RQ に移行した

Redash v8 までワーカー処理などに使われていた非同期処理フレームワーク Celery を廃止し，Redash v9.0.0-beta からは RQ (Redis Queue) に移行した．Redash を使うときは何も影響はないけど，Redash 環境を運用するエンジニアは，知っておくと良さそう．

python-rq.org

10. Python 3 を正式にサポートした

Redash v9.0.0-beta から Python 3 を正式にサポートし，Python 2 はサポートされなくなった．RQ と同じく Redash を使うときは何も影響はないけど，知っておくと良さそう．プルリクエストを読むと Python 3 をサポートするために必要だった差分を確認できる．u'' を書かなくて良かったり，読みやすくなった気もする．

github.com

まとめ

2020年6月にリリースされた「Redash v9.0.0-beta」を試しながら「 Redash v9.0.0-beta の新機能と機能改善」を「計10点」厳選して紹介した．個人的には「アラート画面」のリニューアルは嬉しかった．「Redash v9」が正式にリリースされたら kakakakakku/redash-hands-on にも対応させる予定！お楽しみに！

github.com

過去の Redash 紹介記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Mac の「画面共有」を使って「配信用 Mac」と「デモ用 Mac」を使い分ける

「リモート研修」を配信する場合「配信アプリ / 配信機材 / Chrome / PowerPoint / Visual Studio Code / iTerm2」など，必要最低限なアプリに限定したとしても，Mac の負荷（特に CPU と Network）が高くなってしまう．なお，環境としては MacBook Pro 2017 (2.3 GHz Intel Core i5) を使っていて，MacBook Pro を新しくする選択肢もある．

少し重めのデモを紹介する場合

Mac の負荷が高いとは言え，配信自体は遅延も少なく実施できる．しかし，最近悩んでいるのは「配信中に少し重めのデモを紹介する場合」で，例えば Docker Desktop for Mac を使ってコンテナイメージをビルドをしたり，実装したコードをコンパイルしたり，ローカル環境に API サーバを起動したり．通常なら問題なくても，配信中だと顕著に遅くなってしまう．Amazon EC2 など，クラウド上にデモ環境を構築して SSH をしたり VS Code Remote Development を使う案もあるし，実際に使っているけど，やはり「ローカル環境で動かしたい場合」もある！

Mac の「画面共有」を使う

そこで今回は Mac の「画面共有」を使う案を考えた．特にアプリをインストールする必要はなく，Mac を複数台持っていればすぐに使える．簡単に言えば Windows で使える「リモートデスクトップ」と同じ．今回はドキュメントを参照しながら試していく．なお「画面共有」を使った構成図も載せておく．

support.apple.com

1. デモ用 Mac（サブ）

まず「デモ用 Mac（サブ）」で「画面共有」を有効化する．「システム環境設定 ➔ 共有」と選んだら「画面共有」にチェックを入れる．「アクセス許可」など，制限は適切に設定しておく．簡単！使わなくなったら無効化するのも忘れずに！

2. 配信用 Mac（メイン）

Mac を同じネットワーク (WiFi) に接続しておくと「配信用 Mac（メイン）」の Finder から「ネットワーク ➔ ${コンピュータ名} ➔ 画面を共有」と選べるようになっている．

もしくは Mac の「画面共有アプリ」を使って ${コンピュータ名}.local と入力しても同じ．

接続すると，以下のように Mac から Mac を操作できるようになる．まさに「リモートデスクトップ」と同じ！クリップボードも共有できるし，ショートカットも使えるし，レイテンシーも問題なく使える．今後は「少し重めの処理」を「デモ用 Mac（サブ）」で実施してみようと思う．検証環境で配信をしながら試したら「画面共有」自体の負荷は高くなく，問題なく使えていた．

まとめ

「リモート研修」を配信する場合に限らず，Mac の「画面共有」は知っておくと便利に使える場面もありそう！実際に使うと「解像度」を合わせておかないと，ウィンドウサイズを最大化できなかったり，気になるところはあるけど，使いながら模索しようと思う．

関連記事

• 仮想オーディオデバイス「BlackHole」を使って Mac から音楽を配信する - kakakakakku blog
• 便利すぎる！Mac のメニューバーでサウンド設定を変更するときは「Option キー」を使う - kakakakakku blog
• Mac で「なめらかに」デモを見せるために必須なアプリと機能 - kakakakakku blog

GitHub Actions と hadolint を組み合わせて Dockerfile の静的解析を自動化しよう！

GitHub Actions と hadolint (Haskell Dockerfile Linter) を組み合わせて，今まで雑に実装してきた Dockerfile の静的解析を自動化する環境を作った．できる限り Dockerfile Best Practices を意識していることもあり，警告はあまり多く出なかったけど，やはり CI (Continuous Integration) で気付ける安心感はある！

www.docker.com

hadolint (Haskell Dockerfile Linter)

hadolint を使うと Dockerfile に警告を出してくれる．また Dockerfile の RUN は，シェルスクリプトの Linter として有名な ShellCheck を使って警告を出してくれる．例えば FROM centos:latest のように FROM に :latest を使うと，バージョンを指定して！と警告が出る．意識していても漏れることもあり hadolint 便利！

$ hadolint Dockerfile
Dockerfile:1 DL3007 Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag

github.com

なお，hadolint の Wiki に現時点でサポートされているルール一覧と詳細が載っている．

• Home · hadolint/hadolint Wiki · GitHub

DL~ は hadolint のルールで，SC~ は ShellCheck のルールとなる．ShellCheck は他にもルールがある．

• DL3000 : Use absolute WORKDIR.
• DL3001 : Command does not make sense in a container.
• DL3002 : Last user should not be root.
• DL3003 : Use WORKDIR to switch to a directory.
• DL3004 : Do not use sudo.
• DL3005 : Do not use apt-get upgrade or dist-upgrade.
• DL3006 : Always tag the version of an image explicitly.
• DL3007 : Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag.
• DL3008 : Pin versions in apt get install.
• DL3009 : Delete the apt-get lists after installing something.
• DL3010 : Use ADD for extracting archives into an image.
• DL3011 : Valid UNIX ports range from 0 to 65535.
• DL3012 : Provide an email adress or URL as maintainer. 🚫DEPRECATED
• DL3013 : Pin versions in pip.
• DL3014 : Use the -y switch.
• DL3015 : Avoid additional packages by specifying --no-install-recommends.
• DL3016 : Pin versions in npm.
• DL3017 : Do not use apk upgrade
• DL3018 : Pin versions in apk add
• DL3019 : Use the --no-cache switch
• DL3020 : Use COPY instead of ADD for files and folders
• DL3021 : COPY with more than 2 arguments requires the last argument to end with /
• DL3022 : COPY --from should reference a previously defined FROM alias
• DL3023 : COPY --from cannot reference its own FROM alias
• DL3024 : FROM aliases (stage names) must be unique
• DL3025 : Use arguments JSON notation for CMD and ENTRYPOINT arguments
• DL3026 : Use only an allowed registry in the FROM image
• DL3027 : Do not use apt as it is meant to be an end-user tool, use apt-get or apt-cache instead.
• DL3028 : Pin versions in gem install
• DL3029 : Do not use --platform= with FROM.
• DL4000 : MAINTAINER is deprecated
• DL4001 : Either use Wget or Curl but not both.
• DL4003 : Multiple CMD instructions found. If you list more than one CMD then only the last CMD will take effect.
• DL4004 : Multiple ENTRYPOINT instructions found. If you list more than one ENTRYPOINT then only the last ENTRYPOINT will take effect.
• DL4005 : Use SHELL to change the default shell
• DL4006 : Set the SHELL option -o pipefail before RUN with a pipe in
• SC2046 : Quote this to prevent word splitting
  • SC2046 · koalaman/shellcheck Wiki · GitHub
• SC2086 : Double quote to prevent globbing and word splitting.
  • SC2086 · koalaman/shellcheck Wiki · GitHub

GitHub Actions + hadolint

GitHub Actions と hadolint を組み合わせる場合，Docker Hub に公開された hadolint の Docker イメージを使うこともできるけど，今回は GitHub Actions ですぐに使える Hadolint Action を使うことにした．

github.com

さっそく .github/workflows/workflow.yml に以下を設定する．GitHub に push をしたら，Hadolint Action を使って Dockerfile に対して hadolint を実行する単純なワークフローにした．

name: Workflow
on: push
jobs:
  build:
    name: Hadolint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Hadolint
        uses: brpaz/hadolint-action@master

今回サンプルとして，以下のヒドイ Dockerfile を実装し，GitHub に push をする．

FROM centos:latest

RUN vim hello.txt

RUN sudo pwd

ADD README.md /app/

EXPOSE 80000

GitHub Actions で実行結果を確認すると，以下のように「計5種類」の警告が出た．

• ❌ DL3007 : FROM で :latest を使っている
• ❌ DL3001 : vim コマンドを使っている
• ❌ DL3004 : sudo コマンドを使っている
• ❌ DL3020 : COPY ではなく ADD を使っている
• ❌ DL3011 : 0 ~ 65535 以外のポートを使っている

Dockerfile:1 DL3007 Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag
Dockerfile:3 DL3001 For some bash commands it makes no sense running them in a Docker container like `ssh`, `vim`, `shutdown`, `service`, `ps`, `free`, `top`, `kill`, `mount`, `ifconfig`
Dockerfile:5 DL3004 Do not use sudo as it leads to unpredictable behavior. Use a tool like gosu to enforce root
Dockerfile:7 DL3020 Use COPY instead of ADD for files and folders
Dockerfile:9 DL3011 Valid UNIX ports range from 0 to 65535

まとめ

最近 GitHub Actions を使う機会があり，使えば使うほど楽しくなって，今回は hadolint と組み合わせてみた．Dockerfile を GitHub に push すると，自動的に静的解析をしてくれるのは便利！オススメ！

関連記事

GitHub Actions に入門するなら「GitHub Learning Lab」を使うと便利！という記事を書いた．

kakakakakku.hatenablog.com

シェルスクリプトを実装するときは ShellCheck をよく使っている．2017年に CircleCI と組み合わせた記事を書いた．

kakakakakku.hatenablog.com

GitHub Actions に入門するなら GitHub Learning Lab の Hello World コースを受講しよう

GitHub を学ぶときに「GitHub Learning Lab」を使うと便利！という紹介記事を6月に書いた．最近 GitHub Actions を使う機会があり，入門するために「GitHub Learning Lab」の「GitHub Actions: Hello World」コースを受講した．今回も非常に良かった！

kakakakakku.hatenablog.com

GitHub Actions: Hello World

「GitHub Actions: Hello World」は GitHub Actions を学ぶ入門コースとなる．現在はまだ日本語に翻訳されてなく，英語を選択する必要はあるけど，Bot / Issue / Pull Request を活用したインタラクティブな構成になっていて，楽しく学べる．以下のステップを進めていくことになり，最終的には GitHub Actions を使って，Docker イメージをビルドして実行できるようになる．

• Step 1 : Add a Dockerfile
• Step 2 : Add an entrypoint script
• Step 3 : Add an action.yml file
• Step 4 : Start your workflow file
• Step 5 : Run an action from your workflow file
• Step 6 : Trigger the workflow
• Step 7 : Incorporate the workflow

lab.github.com

セットアップ

まず「Start free course」ボタンを押してセットアップをする．今回はリポジトリ公開設定として Private を選ぶ．すると，自動的にコースで使うリポジトリ hello-github-actions が作られる．

さっそく Issue に Bot から Step 1 の手順がコメントされる．進めていくぞ！

Step 1 : Add a Dockerfile

最初に Issue を読みながら GitHub Actions の概要を学んでいく．「アクション」には「Docker Container (Linux)」と「JavaScript (Linux, MacOS, Windows)」の2種類があり，今回は「Docker Container」を使っていく．

help.github.com

まず，first-action ブランチを作り，以下のように action-a/Dockerfile を実装したら Pull Request を作る．GitHub の基本的な操作は書いてなく，慣れていない場合は前提コース「Introduction to GitHub」コースを受講しておく必要がありそう．

FROM debian:9.5-slim

ADD entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Step 2 : Add an entrypoint script

次に ENTRYPOINT に指定したスクリプト action-a/entrypoint.sh を実装する．単純に echo するだけではなく，GitHub Actions の inputs シンタックスを試すため，環境変数も含めておく．

#!/bin/sh -l

sh -c "echo Hello world my name is $INPUT_MY_NAME"

Step 3 : Add an action.yml file

今度は GitHub Actions のアクションを定義していくため action.yml を作る．ポイントは runs シンタックスを使って Dockerfile を指定している点と，inputs シンタックスを使って環境変数のデフォルト値を設定している点になる．branding シンタックスはアクションを GitHub Marketplace に公開するときに使えるアイコン設定（Feather から選べる）となり，今回は関係なさそう．

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
  MY_NAME:
    description: "Who to greet"
    required: true
    default: "World"

runs:
  using: "docker"
  image: "Dockerfile"

branding:
  icon: "mic"
  color: "purple"

help.github.com

Step 4 : Start your workflow file

アクションを定義したため，次にワークフローを定義していく．設定ファイルは .github/workflows/main.yml に置く．

• name : ワークフロー名
• on : ワークフローを実行するトリガー設定
• jobs : アクション設定
  • uses: actions/checkout@v1 : リポジトリをチェックアウトする（現在は既に v2 もリリースされている）

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: ./action-a
        with:
          MY_NAME: "Mona"

docs.github.com

github.com

Step 5 : Run an action from your workflow file

実際にワークフローを確認すると，正常に実行されていた．

Step 6 : Trigger the workflow

標準出力に Hello world my name is Mona と表示されていた．

Step 7 : Incorporate the workflow

最後は Pull Request を master ブランチに Merge する．

最終的に Issue / Pull Request は以下のようになっていた．今回も非常に良かった！楽しかった！

まとめ

「GitHub Learning Lab」の「GitHub Actions: Hello World」コースを受講して，GitHub Actions に入門した．一歩一歩インタラクティブに進めることで理解度を高められる点は，やはり「GitHub Learning Lab」の最大のメリットだと思う．実は「GitHub Learning Lab」には，コースとドキュメントをまとめた「Learning Path」という仕組みもあり，例えば「DevOps with GitHub Actions」という Learning Path もある．「Publish to GitHub Packages」コースは特に気になる！

1. GitHub Actions: Hello World
2. GitHub Actions: Continuous Integration
3. GitHub Actions: Publish to GitHub Packages
4. GitHub Actions: Continuous Delivery with Azure
5. GitHub Actions: Continuous Delivery with AWS
6. GitHub Actions: Writing JavaScript Actions
7. GitHub Actions: Write Docker container actions
8. GitHub Actions: Using GitHub Script
9. Migrating from Azure Pipelines to GitHub Actions
10. Migrating from Jenkins to GitHub Actions
11. Migrating from CircleCI to GitHub Actions

lab.github.com