ansibleで繰り返し処理を実装する場合は with_XXX系ディレクティブをよく利用していた。 特によく利用するのが with_items で、単純な繰り返し処理には with_itemsで対応することが多かった。
ansible 2.5以降では新しく loopディレクティブが導入された。 loopを利用することで各種with_XXX系ディレクティブの使い分けを考えなくて済むようになる。
単に with_XXX系ディレクティブをloopディレクティブで置き換えるだけでは上手くいかないケースもあるが、基本的にはloopディレティブが推奨されているのでこちらを利用した方がよさそう。 一方でwith_XXX系ディレクティブが非推奨になったわけではない。 新規に実装する分はloopディレクティブを採用すればよさそう。
github actionsのinputにはrequiredというパラメータがある。 これにより、対象のinuptが必須なのかオプションなのかを区別することができる。
しかし、required: trueに指定したinputが指定されなかったからといってエラーになるわけではない。 上記ドキュメントにもエラーにならないことが記載されている。
注: ワークフローの実行を自動的にトリガーするイベントに入力が指定されていない場合、required: true を使用するワークフローでは自動的にエラーが返されません。
じゃあrequiredオプションにどのような意味があるのかというと、何の意味もないらしい。 開発者などが識別しやすいようにするドキュメンテーション的な意味しかない。
required: trueなinputが未指定の場合は自動でエラーにするか、バリデーション機能が提供されると助かるのだが。
GitHubの Fine-grained personal access tokenは personal access token(classic)に比べて細かく権限を制御できるだけでなく、対象のResource ownerを1つ指定する必要がある。
所属する組織をResource ownerに指定するには、対象組織がpersonal access tokenによるアクセスを許可していないといけない。 許可していない場合はResoruce ownerに対象組織を指定することができない。
Fine-grained personal access tokens は複数のユーザや組織のリソースに同時にアクセスできる権限を付与することはできない。 例えば個人のリポジトリと所属する組織(会社など)のリポジトリにアクセスする権限は設定できない。
Each token can only access resources owned by a single user or organization.
ユーザや組織など複数のリソースに同時に参照するためには、personal access token(classic)を利用する必要がある。
Step Functionsにはリビジョン・バージョン・エイリアスの概念がある。 単にStep Functionsを更新するとリビジョンが更新されるが、特定のリビジョンにバージョンやエイリアスを発行することもできる。
(公式ドキュメントより)
Step Functionsの実行に失敗した場合において新しく実行し直すと、入力は引き継ぎつつも最新のリビジョンで実行される。 これはマネコン上では「最新のリビジョンで実行を開始」という表記があることから判断できるが、公式ドキュメントにこの挙動に関する説明は見つからなかった。
2023年11月に、失敗したタスクから処理を再開するリドライブ機能がリリースされた。
リドライブを実行する場合は、失敗したワークフローと同じリビジョンで実行される。 例えばStep Functionsを実行して失敗し、Step Functionsを更新した後にリドライブをしても更新内容は適用されない。これはバージョンやエイリアスを発行していても変わらない。 これについては公式ドキュメントに説明がある。
Even if you update your alias to point to a different version, the redriven execution continues to use the version associated with the original execution attempt.
Pythonのビルドまわりの設定はpyproject.tomlに記述することが一般的である。 これはPEP518によって定められている。
一方で、すべてのツールがpyproject.tomlをサポートしているわけではなく、静的解析ツールである flake8 などは pyproject.tomlをサポートしていない。 このため、 .flake8 ファイルなどで別途設定を記述する必要がある。
pyproject.toml対応についても議論されているが、現時点では積極的に対応を進めている状況ではない。
どうしてもpyproject.tomlを利用したい場合はflake8のラッパーツールである pflake8 を使うとよい。
GitHub Actionsを手動で実行する workflow_dispatch にはさまざなま入力を指定できる。
input のcontextには string or number or boolean or choice とあり、例としてstring, number, booleanの場合が記載されている。
実は、 on.workflow_dispatch.inputs のドキュメントにはもう少し詳しい(正確？)なドキュメントがあり、上記には記載されていないchoiceの記述方法や紹介されていないenvironmentが利用可能なことが示されている。
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
print_tags:
description: 'True to print to STDOUT'
required: true
type: boolean
tags:
description: 'Test scenario tags'
required: true
type: string
environment:
description: 'Environment to run tests against'
type: environment
required: true
このように、type: choiceを指定した場合はoptionsの項目に選択肢を指定する。 type: environmentを指定した場合は各リポジトリに設定したenvironmentが選択できる。
docker build時にクレデンシャルを利用したい場合は --mount=type=secretを利用する。 これによりクレデンシャル情報がdockerイメージ内に保存されることを避けることができる。
# syntax=docker/dockerfile:1 FROM node:alpine RUN --mount=type=secret,id=SECRET_TOKEN \ SECRET_TOKEN=$(cat /run/secrets/SECRET_TOKEN) yarn run test
mount=type=secretで指定したidが /run/secrets/以下にファイルマウントされる。このため環境変数として利用したいのであれば変数に格納して利用しないといけない。
/run/secrest/ にマウントするのではなく直接環境変数に展開する方法はないかと思ったら、issueにはリクエストは挙がっているが実装される見込みは今のところなさそう。
