Azure / Azure/azure-openapi-validator

Ability to build ARM summary report

オープン
#421 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
TypeScript
スター
53
フォーク
57
平均マージ
1日 23時間
マージ済み PR(30日)
2

説明

To build confidence in the linter automation we need a summary report in the following format that can be the starting place for API reviewers to review the PRs.

For each RT

RPC category | #rules | #applicable | #success | #fail
-- | -- | -- | -- | --
RPC-V1-PUT | 22 | 22 | 20 | 2
RPC-V1-PATCH | 11 | 0 | 0 | 0
  |   |   |   |  

we need to investigate how to fix below issues:
1. the linter output message should include the RT and/or Namespace field , so we may need to update some rules implementation to relate the swagger paths with the rule
3. Linter should output message for each passed linter rule execution (currently there is no message for passed rules)
then we can generate a result base on the linter output message
4. some rules are implemented as only finding the violations of swagger greedily, so they don't have chance to visit all the swagger paths/operations and these rules need to be re-implemented

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

まず linter の出力とルールの実装をたどり、次に Swagger のパスとオペレーションがどのように訪問されるかを調べます。完了条件は、ルール数を含む要求された RT ごとの概要を作成し、API レビューを支えるのに十分な RT または namespace のコンテキストと、通過したルールのメッセージを追加することです。

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

評価

技術スタック
typescript
領域
api, tooling
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

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

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