Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

research(platform): approvals when using Tirith

オープン
#359 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
github, gitlab, terraform
領域
ci-cd, devops, security

調査の方向性

まず GitHub environments と required reviewers を GitLab manual jobs と比較し、次に GitHub App を使う代替の status-sync 形式を検討します。plan attestation によって、適用された plan が承認済みのものだとどのように証明されるかを解決します。1 つの approval design が選択され、その workflow と失敗時の動作が文書化され、downgrade-to-warn の曖昧さが解消されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

research

A policy failure that should pause for a human rather than hard-fail. Today's honest answer is
downgrade-to-warn, because blocking would leave the platform workflow stuck. Two candidate shapes,
both unproven: (1) lean on each CI system's own approval gates (GitHub environments/required
reviewers, GitLab manual jobs) with Tirith exiting the right code and a documented recipe per
platform; (2) sync run status through a GitHub App so an approval on the platform side updates the
PR check. Decide the shape before building; this intersects plan attestation — an approval is only
meaningful if the applied plan is provably the approved one.

主要言語
Python
スター
167
フォーク
47
平均マージ
1日 21時間
マージ済み PR(30日)
7

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

StackGuardian/tirith のほかの issue

StackGuardian/tirith の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。