※当サイトの記事には、広告・プロモーションが含まれます。

GitHubのDependabotの機能を有効に、且つ、自動処理したい。GitHub Actionsの併用でOKらしいが...

gigazine.net

これまで観測誤差だと片付けられてきた、宇宙に関する理論と実際の観測記録の間にある食い違いが、ジェイムズ・ウェッブ宇宙望遠鏡といった最新鋭の観測技術により誤差ではなかったことが判明しつつあります。

宇宙論は転換点を迎えている、あと数年で「人類は新しい物理学に遭遇するかもしれない」と天体物理学者 - GIGAZINE

長年にわたり、世界中の天文学者の間で論争となってきたこの矛盾の全容が明らかになり、人類が既存の宇宙観の再考を余儀なくされる時が目前に迫っていると、専門家が提唱しました。

宇宙論は転換点を迎えている、あと数年で「人類は新しい物理学に遭遇するかもしれない」と天体物理学者 - GIGAZINE

現行の宇宙論の中で最も有力な標準モデルである「ΛCDMモデル」では、宇宙は68.3%のダークエネルギーと26.8%のダークマター、そして4.9%の通常の原子で成り立っているとされています。これは、ビッグバンの残光とも呼ばれている宇宙マイクロ波背景放射(CMB)の詳細な観測データから導き出された非常に正確な結果です。

宇宙論は転換点を迎えている、あと数年で「人類は新しい物理学に遭遇するかもしれない」と天体物理学者 - GIGAZINE

ところが、近年に入ってこのモデルと矛盾する観測結果が報告されるようになり、長い間かけて築き上げられてきた理論の妥当性が揺るがされる事態となっています。

宇宙論は転換点を迎えている、あと数年で「人類は新しい物理学に遭遇するかもしれない」と天体物理学者 - GIGAZINE

理論的には、ハッブル定数の値は67.4km/s/Mpc(キロメートル毎秒毎メガパーセク)ですが、ハッブル宇宙望遠鏡で宇宙の灯台とも呼ばれているセファイド変光星までの距離を測定して計算すると、値は73km/s/Mpcとなります。

宇宙論は転換点を迎えている、あと数年で「人類は新しい物理学に遭遇するかもしれない」と天体物理学者 - GIGAZINE

⇧ 8%って、1割に近い値を僅かとみなす感覚が理解できんのだけど...

学者の間で「緊張(テンション)」と呼ばれるこの矛盾した結果は、これまで「セファイドの光と他の星の光が合わさったことで観測結果に誤差が生じたのかもしれない」と説明されてきました。

宇宙論は転換点を迎えている、あと数年で「人類は新しい物理学に遭遇するかもしれない」と天体物理学者 - GIGAZINE

しかし、目的の天体とそれ以外の光を正確に見分けることができるジェイムズ・ウェッブ宇宙望遠鏡での観測により、ハッブル宇宙望遠鏡の観測結果は間違いではなかったことが確かめられました。

宇宙論は転換点を迎えている、あと数年で「人類は新しい物理学に遭遇するかもしれない」と天体物理学者 - GIGAZINE

⇧ 最早、観測が、事実ではなく思い込みが入り混じった推測でしか無かったことが証明されてしまったわけですな。

まさに、

An implicit bias or implicit stereotype is the pre-reflective attribution of particular qualities by an individual to a member of some social out group.

https://en.wikipedia.org/wiki/Implicit_stereotype

Implicit bias training (or unconscious bias training) programs are designed to help individuals become aware of their implicit biases and equip them with tools and strategies to act objectively, limiting the influence of their implicit biases.

https://en.wikipedia.org/wiki/Implicit_bias_training

Some researchers say implicit biases are learned stereotypes that are automatic, seemingly associative,unintentional, deeply ingrained, universal, and can influence behavior.

https://en.wikipedia.org/wiki/Implicit_bias_training

物理学会が 「無意識のバイアス」に陥っていたということですかね。

そもそも、観測というアプローチとして、

ヘンペルのカラス (Hempel's ravens) とは、ドイツカール・ヘンペルが1940年代に提出した、帰納法が抱える根本的な問題(「帰納法の問題英語版」)を喚起する問題である。「カラスのパラドックス」とも呼ばれるが、パラドックスとして扱うべきかどうかには異論もある

ヘンペルのカラス - Wikipedia

概要

「ヘンペルのカラス」は「全てのカラスは黒い」という命題を証明する以下のような対偶論法を指す。

ヘンペルのカラス - Wikipedia

「AならばBである」という命題の真偽は、その対偶「BでないものはAでない」の真偽と必ず同値となる

ヘンペルのカラス - Wikipedia

全称命題「全てのカラスは黒い」という命題はその対偶「全ての黒くないものはカラスでない」と同値であるので、これを証明すれば良い。

ヘンペルのカラス - Wikipedia

そして「全ての黒くないものはカラスでない」という命題は、世界中の黒くないものを順に調べ、それらの中に一つもカラスがないことをチェックすれば証明することができる。

ヘンペルのカラス - Wikipedia

そして「全ての黒くないものはカラスでない」という命題は、世界中の黒くないものを順に調べ、それらの中に一つもカラスがないことをチェックすれば証明することができる。

ヘンペルのカラス - Wikipedia

白いカラスの実在

余談であるが、「全てのカラスは黒い」という命題は反証されているというのも、アルビノもしくは白変種のカラス、すなわち「黒くない」カラスの実在が観測されているからである。

ヘンペルのカラス - Wikipedia

こうした事実は、科学の分野における命題には、実験や観察といった経験によって誤りであることが証明される可能性(反証可能性)があることを示している

ヘンペルのカラス - Wikipedia

⇧ 上記の問題が不可避となりそうな気もする。

ただ、

その奇妙さ

宇宙には無限に「黒くないもの」があるとすれば、実際にヘンペルの論法を証明に用いることはできなくなる。「黒くないものはカラスでない」ことを証明するために「黒くないもの」を順に調べようとしても、その作業は永遠に終わらないからである。

ヘンペルのカラス - Wikipedia

⇧ 作業が永遠に終わらないであろうと言われているであろうが、論争によると、

『これまでの宇宙観測方法が誤りであった可能性がある』

という新たな気付きを得ることができたという点では、「ヘンペルのカラス」的なアプローチが無意味では無いと言えるのかね?

まぁ、

tenbou.nies.go.jp

国連環境計画の世界自然保全モニタリングセンター、カナダのダルハウジー大学などの研究者らは、地球上の生物種数は約870万とする研究報告を発表した。

国連環境計画等、地球上の生物種数は約870万とする研究報告を発表|環境展望台:国立環境研究所 環境情報メディア

これまで、生物種総数の推定値には、300万~1億と大きな幅があった。現在の生物分類体系では、生物を下位から上位に向かって、種、属、科、目、綱、門、界の階層で分類し、約125万種がデータベースに登録されている。

国連環境計画等、地球上の生物種数は約870万とする研究報告を発表|環境展望台:国立環境研究所 環境情報メディア

今回の研究は、この登録された生物種を分析し、種と上位階層との間の数値的パターンを突き止めたことで、より正確な生物種数を算出できたという。

国連環境計画等、地球上の生物種数は約870万とする研究報告を発表|環境展望台:国立環境研究所 環境情報メディア

報告書によると、870万種のうち、動物が777万種、植物が29万8000種、菌類が61万1000種と推定。また、650万が陸上種で220万が海洋種だという。

国連環境計画等、地球上の生物種数は約870万とする研究報告を発表|環境展望台:国立環境研究所 環境情報メディア

陸上種の86%、海洋種の91%が未知種で、国際自然保護連合(IUCN)のレッドリストで生息状況を監視している種は全生物種の1%に満たないという結果となった。

国連環境計画等、地球上の生物種数は約870万とする研究報告を発表|環境展望台:国立環境研究所 環境情報メディア

⇧ 地球上ですら未知のことが多過ぎるからして、況や宇宙においてをや。

この推定方法も誤りである可能性はあると思われるが、他に代替できそうなアプローチが出て来ない以上は、突き進むしかないと。

アプローチの選定の影響が大きいのは、どの業界も変わらないってことですかね。

Gitリポジトリホスティングサービスと脆弱性診断サービス

ChatGPTに確認した感じでは、

No Gitリポジトリホスティングサービス 管理している組織 脆弱性診断サービス プランの内容
無償 有償
1 GitHub Microsoft Dependabot ※1 ※2
2 GitLab GitLab Inc. SAST, Dependency Scanning ※3 ※4
3 Bitbucket Atlassian Bitbucket Cloud's built-in security features ※3 ※4
4 Snyk Snyk Ltd. Snyk ※5 ※6
5 Renovate Community Renovate ※7 ※8
6 SourceForge Slashdot Media Custom integrations available ※7 ※8
7 Azure DevOps Microsoft Azure Security Center ※9 ※10
8 AWS CodeCommit Amazon AWS CodeGuru (for review) ※7 ※11
9 Google Cloud Source Repositories Google Cloud Build integration ※3 ※4
10 Oracle Cloud Infrastructure DevOps Oracle OCI DevOps integration ※9 ※10

※1 基本的な依存関係の脆弱性チェック

※2 特殊な機能はなし

※3 プライベートリポジトリ数に制限

※4 制限なし

※5 スキャン数に制限

※6 スキャン数無制限、追加機能

※7 無償で利用可能

※8 特に無し

※9 一部機能が無償

※10 フル機能使用

※11 追加の使用料が発生する場合がある

⇧ 上記のようなサービスが用意されている模様。

GitHubのDependabotとは

公式のドキュメントによると、

docs.github.com

Dependabot は、依存関係の管理に役立つ 3 つの異なる機能で構成されています。

  • Dependabot alerts — リポジトリで使っている依存関係に内在する脆弱性について通知します。
  • Dependabot security updates — 使っている依存関係のうち、既知のセキュリティ脆弱性があるものを更新するための pull request を自動的に生成します。
  • Dependabot version updates — 依存関係を最新に保つための pull request を自動的に発行します。

https://docs.github.com/ja/code-security/getting-started/dependabot-quickstart-guide

⇧ 3つの機能で構成されていますと。

GitHubのサービスにおける「Dependabot」の立ち位置はというと、

docs.github.com

GitHubのセキュリティ機能について

GitHubは、リポジトリ内及びOrganizationに渡ってコードとシークレットをセキュアに保つのに役立つ機能があります。 一部の機能は、すべてのプランのリポジトリに使用できます。 その他の機能は、GitHub Advanced Security を使うエンタープライズに使用できます。 GitHub Advanced Security の機能は、GitHub のすべてのパブリック リポジトリでも有効になります。詳しくは、「GitHub Advanced Security について」を参照してください。

https://docs.github.com/ja/code-security/getting-started/github-security-features

GitHubのセキュリティ機能の内の1つらしく、公式のドキュメントを読み進めていくと、

  • すべてのリポジトリで使用可能
    1. セキュリティ ポリシー
    2. Dependabot alerts およびセキュリティアップデート
    3. Dependabot version updates:
    4. 依存関係グラフ
    5. リポジトリのセキュリティの概要
  • 無料のパブリック リポジトリで使えます
    1. セキュリティ アドバイザリ
    2. ユーザーに対するシークレット スキャンニング アラート
    3. ユーザーのプッシュ保護
    4. パートナーに対するシークレット スキャンニング アラート
  • GitHub Advanced Security で使用可能
    1. Code scanning
    2. ユーザーに対するシークレット スキャンニング アラート
    3. カスタム自動トリアージ ルール
    4. 依存関係の確認

⇧ といった感じで、セキュリティ系の機能が盛り沢山過ぎるのだが、

『すべてのリポジトリで使用可能』

ということで、GitリポジトリとしてGitHubを利用しているのであれば、活用していきたい機能ということになるかと。

GitHubを利用していない場合は、利用できませんと。

GitHubのDependabotの機能を有効にしてみる

というわけで、まずは、GitHubでDependabotの機能を有効にする必要がありますと。

docs.github.com

⇧ 上記の手順の通りに進めます。

ブラウザでGitHubにログイン後、画面右上のアイコンを押下。

「Settings」を選択。

左サイドバーで「Security」>「Code security」を選択。

手順の選択肢の設定項目と、実際のGithub上の設定項目が噛み合わないが、以下と想定して、3つ選択。

No 手順 GitHub上の設定項目
1 Dependabot alerts Dependabot alerts
2 Dependabot security updates Dependabot security updates
3 Dependabot version updates Grouped security updates

チェックマークが付けば有効化されたということらしい。

GitHubのDependabotの機能を利用してみるが、自動で処理されるようにしたい。GitHub Actionsも併用すればOKだが...

GitHub上で「Dependabot」の設定が完了後に、リポジトリを確認しに行くと、

リポジトリの「Security」タブ

リポジトリの「Pull requests」タブ

⇧ 各タブのページに、「Dependabot」が情報を生成してくれており、

といった内容になっているらしい。

ただ、脆弱性の対応についてのpull requestも自動でマージして欲しいと思うのが人情、と言うか、提案された脆弱性の対応が適切かどうかの意思決定も任せたいというAIに責任転嫁させたいのが多忙過ぎる現代社会に生きる我々人類が採用したいアプローチだと言っても過言ではないのではなかろうか?

要するに、面倒なことはAIにお任せしたいのである。

だって、現代人は忙しいんだもの。

GitHubの公式のドキュメントによると、

docs.github.com

GitHub Actionsを利用すれば可能らしい。

ただ、実際の業務においては、

moneyforward-dev.jp

dev.classmethod.jp

⇧ 上記サイト様にありますように、GitHub Actionsで実行条件を精緻に検討する必要はありますと。

つまり、AIの提案は信用ならん、という立場に立たざるを得ないと。

ちなみに、ChatGPTに確認したところ、「Gitリポジトリホスティングサービス」と「利用可能なCI/CDツール」の対応については、

No Gitリポジトリホスティングサービス 管理している組織 利用可能なCI/CDツール
1 GitHub Microsoft GitHub Actions, Travis CI, CircleCI, Jenkins
2 GitLab GitLab Inc. GitLab CI/CD
3 Bitbucket Atlassian Bitbucket Pipelines, Jenkins
4 Snyk Snyk Ltd. GitHub Actions, Jenkins
5 Renovate Community GitHub Actions
6 SourceForge Slashdot Media GitHub Actions, Jenkins
7 Azure DevOps Microsoft Azure Pipelines, Jenkins, GitHub Actions
8 AWS CodeCommit Amazon AWS CodePipeline, Jenkins, CircleCI
9 Google Cloud Source Repositories Google Google Cloud Build, Jenkins, GitHub Actions
10 Oracle Cloud Infrastructure DevOps Oracle Jenkins, GitHub Actions

⇧ 上記のような表になるらしいが、適当なんだろうなぁ...

と言うわけで、個人的なGitHub上のリポジトリで試してみます。

GitHub上で適当なリポジトリを選択し、「Add file」のアイコンを押下し、「Create new file」を選択。

ファイル名を入力します。今回は「.github/workflows/dependabot-auto-merge.yml」のようなファイル名にしました。

GitHub Actionsで実行したい内容をymlファイルに入力し、「Comment change...」ボタンを押下。

■[リポジトリのルートディレクトリ].github/workflows/dependabot-auto-merge.yml

name: Dependabot auto-merge
on: # トリガー(GitHub Actionsのフローを実行する手段)
  pull_request:
  workflow_dispatch:  # 手動実行を有効にする
  schedule:
    - cron: '0 0 * * 0'  # 毎週日曜日の00:00 UTCに実行

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'ts0818/Hello'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Enable auto-merge for Dependabot PRs
        if: steps.metadata.outputs.update-type == 'version-update:semver-patch'
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{secrets.GITHUB_TOKEN}}    

⇧ 上記のような内容にしました。

コミットのメッセージを入力し、「Commit changes」ボタンを押下。

リポジトリに追加されました。

「Actions」タブの左サイドバーに、ymlファイルで追加したフローが表示されており選択できるようになっていればOK。

ymlファイルで、「on:」の設定で「workflow_dispatch:」を追加していると、GitHub上から手動実行できるようになる模様。

一応、手動実行してみたところ、「1 workflow run」と表示されているので、GitHub Actionsのフローが実行できた模様。

ただ、「Pull requests」タブの件数が減っていないところを見ると、

『全てのpatchレベルの更新を自動マージする』

という条件に一致しない「Pull request」ということらしい。

とりあえず、「Dependabot」の脆弱性の自動対応はできてませんが、「GitHub Actions」デビューは果たせたということで。

GitHub Actions」について、リポジトリ横断的に共通のフローを適用させたい場合、どうすれば良いんだろうか?

もし、GitHub Actionsのフローを定義するのが、リポジトリ毎にしかできないとすると、仮に100個のリポジトリがあった場合に、100個すべてにymlファイルを配置、且つ、「DRYの原則」に違反する重複する記述をせざるを得なくなり地獄だなと...

今のところ、

kakakakakku.hatenablog.com

⇧ 上記サイト様にありますように、共通のフローを定義したymlファイルを配置する用のリポジトリを1つ用意する必要がありますと。

このあたりが限界といった感じですかね...

全てのリポジトリに対して「Dependabot」向けの共通的なフローを実行させたい場合は、「Dependabot」用の無意味な空レポジトリを作成する感じになってしまうのは致し方ないということですかね...

とりあえず、「GitHub Actions」の設定が分かり辛い...

毎度モヤモヤ感が半端ない…

今回はこのへんで。