GitHub Actions

Workflow file

• on
  • A (event)
  • B (event)
  • ...
• jobs
  • jobA
    • steps
      • stepA (uses | run)
      • stepB (uses | run)
      • ...
  • jobB
  • ...

Stepsでの実行

• jobs.<job_id>.steps.uses
  • Local
    • ./path/to/dir
      • ./.github/actions/my-action
  • GitHub
    • {owner}/{repo}[/{path}]@{ref}
      • actions/aws@v2.0.1
      • actions/aws/ec2@master
  • Docker
    • docker://[{host}/]{image}:{tag}
      • docker://alpine:3.8
      • docker://gcr.io/cloud-builders/gradle
• jobs.<job_id>.steps.run

runは1stepで1つだけ宣言できる (実行して確かめた).
run内でコマンドpipeできるので実行の幅はそんなかわらない.

steps

Not all steps run actions, but all actions run as a step.
...
Because steps run in their own process, changes to environment variables are not preserved between steps.
Workflow syntax for GitHub Actions - GitHub Help

自動化にどうやって認証/認可機能を持たせるか

GitHub Actionsはevent drivenな自動処理.
毎回コンテナを建てて廃棄するので、認証情報をコンテナ内に保持できない.
eventごとにユーザーへ認可をとるのは意味がない.
どうにかしてコンテナ起動時にコンテナへ認証/認可情報を自動で渡す必要がある.
ユーザーから得た認可情報を外部で保存しておいてコンテナへinjection、machineが認可が必要な際にそれを使う.
オープンソースの場合、credentialsをハードコードできない.
暗号化してハードコードするか、コンテナサービスへ渡しておくか.
コンテナサービスがほかのサービスをやっていれば、そこに関してはimplicit credential injectionが可能.
GitHub (Gitホスティング) とGitHub Actions (CI/CD) ならこの連携が可能

別のサービスでも、返ってくるタイプの動作ならevent signalにcredentials持たせればいいのでは？
ホスティングがeventに応じてflowとcredentialsを送信。CI/CDサービスはflowにcredentialsをいれつつ処理。結果をホスティングに反映させる処理でcredentialsを利用.
いくつか問題がある。
CI/CDサービスが信頼できるという前提（渡したcredentialsで別のflowを実行する可能性）~ credentialsの目的外利用。

GitHub ActionsはGITHUB_TOKENっていうGitHub App initialization token（寿命が1時間くらい）を暗示的に (contextで) 渡してる.
GITHUB_TOKENのセキュリティ要件で現段階ではgh-pagesへの自動デプロイには使えないのが悲しみポイント.でもすごい便利.

link1
link2

現段階ではGitHubのcredentialsをGitHub Actionsへ事前に登録しておく形式.
Userレベルのcredentials (Personal Access Token) を発行して、レポジトリのsecretsへ登録しておく。これが各レポジトリのworkflowへのsecrets contextになる。

Secrets: encrypted environment variables created in a repository and can only be used by GitHub Actions