Githubアクション環境変数と文脈についての4つのチップス

私は最近GitHubアクションで少し遊びました、そして、私が何度も何が起こっているかについて理解するために何度も何度も私のワークフローを実行していたので、私はそれが私が環境変数と文脈に関して特に学んだものを共有するのがおもしろいと思いました.

🗨 Disclaimer: Although I have some experience with Azure Pipelines, I am still learning GitHub Actions so I do not pretend to know everything about them nor do I never make mistakes when writing about them. Feel free to correct me in the comments if you think I am wrong about something or if something that I show can be done more effectively.

ヒントN°1 :環境変数の構文は、あなたの仕事で使用しているシェルに依存します
Githubアクションのワークフローを知っているように、それぞれのジョブが同じランナーで実行される一連のステップである別のジョブで構成されています.ランナーがUbuntu、Windows、MacOS、または別のオペレーティングシステム(あなた自身のランナーをホストする場合)をホストすることができますように、あなたのコマンドを実行するシェルは、選択したランナーに応じてデフォルトで同じではありません.例えば、あなたがUbuntu Github Hostsランナーの上にいるならば、デフォルトでシェルはbashです、しかし、Windows Githubが走らせたランナーで、それはPowerShellですpwsh もちろん古いWindows PowerShellではありません.
使用するシェルによっては、スクリプト内の環境変数を使用する構文は以下のドキュメント画面で見ることができます.

🗨 When I am talking about environment variables here I am referring to GitHub default environment variables (for instance GITHUB_EVENT_NAME which the name of the webhook event that triggered the workflow) and to custom variables you set in a workflow. The syntax for environment variables you just create and use in a shell script does not change of course.

このドキュメントではシェルによって使用する構文を簡単に説明しますhere しかし、私は簡単にそれを欠場することができます.実際、あなたが見つけることができるGithubアクションの例のほとんどはbashにあるので、あなたが使用しているシェルに注意を払わずにそれらを使うならば、あなたはおそらくそれを間違っているでしょう.私は、私のスクリプトがWindowsランナーで働いていなかった理由を理解しようとする多くの時間を失いました.

ヒントN°2 :リポジトリを使用しないでくださいGITHUB_TOKEN 別のワークフローをトリガする必要があるタスクで.
The GITHUB_TOKEN あなたのワークフローであなたのgithubリポジトリにいくつかのアクションを行うには、タグを押すように、新しいリリースを作成し、問題を作成することができます秘密です.それはあなたのワークフローで自動化することができますので、非常に便利ですので、組み込みのアクションやGithubの残りのAPIを使用してgithubリポジトリの多くのこと.

🗨 Be aware that internally GitHub Actions is a GitHub App that is installed on your repository when you start creating GitHub Actions workflows for this repository. That means the token represented by GITHUB_TOKEN in your workflow is a GitHub App installation token that will only work on your repository workflow and that will have a limited set of permissions (but your can grant more permissions directly in your workflow if you want).

ワークフローの認証について知りたい場合はpage Githubドキュメントのトピックについてしかし、すぐに読んで重要な情報を欠場することがあります:

"events triggered by the GITHUB_TOKEN will not create a new workflow run"

これはどういう意味ですか.あなたが2つのワークフローを持っていて、最初のものがGITHUB_TOKEN 第2のものを引き起こすべきである行動のために、2番目のワークフローは決して引き起こされません.目的は、ワークフローの無限ループを行うことからあなたを防ぐためには、お互いをトリガ実行されます.
つまり、新しいタグがリポジトリにプッシュされたときにリリースを発行するワークフローを実装したいと思います.あなたはcreate a GitHub Personal Access Token , それをあなたの倉庫の秘密として加えて、あなたの最初のワークフローであなたのリリースをつくるために、それを使ってください.この方法では、リリースが発行されると、2番目のワークフローが実行されます.

ヒントn°3 : genthub actionワークフローをpowershell変数にトリガーしたイベントから情報を割り当てます.
場合によっては、ワークフローを引き起こしたイベントからの情報に応じて特定のアクションを行うためにいくつかのPowerShellを実行します.したがって、このデータによるPowerShell変数を持つことは本当に役に立つかもしれません.たとえば、リリースの発行によって引き起こされるワークフローがあれば、このリリースのバイナリのURLを取得する必要があります.
ワークフローを引き起こしたイベントに対応するWebhookペイロードは、github コンテキスト.

🗨 If you are not familiar with contexts in GitHub Actions, they are objects that contain information about the current workflow, job, runner or things like that. Contexts are often used in expressions to determine whether or not a step of the workflow should be executed or to set some variables as you can see in the sample below.

あなたが読むことができるようにdocumentation , EventプロパティはObject型のオブジェクトで、クエリを実行するのが難しくなり、PowerShell変数に代入できます.幸いにも、GitHubイベントデータがランナーファイルシステム上のJSONファイルに保持されているという事実に基づいた方法があります.
最初のツールを使用することです jq これは既にGithubのランナーにインストールされており、JSONデータを処理することができます.エドワードThomsonはブログ記事を持っています. GitHub Actions Day 12: Information about your Workflow .
つ目は、以下のようにGithubコンテキストをつかむために直接PowerShellを使うことです:$github = Get-Content '${{ github.event_path }}' | ConvertFrom-Json . おかげで、多くのエドワードトムソンは、この先端を手伝ってくれた😀.

エドワードトムソン
エソソソン

ワークフローを回転させると、GITHUBイベントデータをディスク上のJSONファイルに置きます.私たちはファイル名をgithubコンテキスト自身に保存します.それで` ConvertFrom JSON `を使うことができます.
午後15時39分- 20月20日
これを説明するために、これらの2つの方法を使用して、リリースによって発行されたバイナリのURLをPowerShell変数に割り当てますgithub コンテキスト

JQの使用

 $installerUrl = $(jq --raw-output '.release.assets[].browser_download_url | select(contains(\"windows.msi\"))' "${{ github.event_path }}")

PowerShellでのConvertfrom JSONメソッドの使用

$github = Get-Content '${{ github.event_path }}' | ConvertFrom-Json
$installerUrl = $github.release.assets | Where-Object -Property name -match 'windows.msi' | Select -ExpandProperty browser_download_url -First 1

私はJQについて知りませんでした、しかし、私はそれが本当に良いツールであるとわかります.しかし、私はJSON文字列の代わりに直接オブジェクトを操作することができるので、PowerShell方法を好みます.それは私がアップグレードを自動化するためにしたものですNushell 新しいリリースが発行されるとき、GitHubアクションを使用するWingetパッケージarticle ).

ヒントN°4 :あなたのワークフローで何が間違っているかを理解するためにデバッグログを有効にする
多くのCI/CDプラットフォームとして、GitHubアクションは、何かが正しく動作していないときに、ワークフローをデバッグするのを難しくします.また、デフォルトでは、ワークフローを実行するときに、いくつかの式/コンテキストが評価される方法が表示されません.そのため、ワークフローの定義が間違っているかを把握できません.
うまくいけば、あなたのリポジトリ内のすべてのパイプラインのデバッグログを有効にすることができますACTIONS_STEP_DEBUG あなたの倉庫で真実に.あなたはそれについての詳細を読むことができますdocumentation しかし、ここではワークフローの中で好きになっているものを実行します.

私はこれらの4つのヒントは素晴らしいGithubアクションのワークフローを構築するのに役立ちます願っています.