実際、ロボット全体は単なる機能の集まりです。
変更ログの検索と処理は、いくつかの段階で構成されています。
- URLのデータを取得する方法を理解する必要があります。
- 選択した方法を使用して、データをディスクにダウンロードします。
- ダウンロードしたファイルを調べて、バージョン番号と説明が含まれている部分を抽出します。
- どの部分が本当に変更ログの一部であり、どの部分が単なるごみであるかを理解します。
- 見つかった商品をベースに追加します。
パーツ1、2、および5は完全に機械的であり、ロボットからの特別な知能を必要としません。
データ検索
前の記事で、 AllMyChangesがいくつかの異なるデータソースをサポートしていることを述べました。 第一に、GitとMercurialからポンプアウトできます。 次に、HTMLページを一度に1つずつダウンロードし、サイト全体を再帰的にバイパスできます。 3番目に、ロボットはApp StoreとGoogle Playから情報をダウンロードできます。
最初の段階では、特定のヒューリスティックルールに従って、段階2で呼び出す関数を決定します。 成功した場合、この選択はデータベースに保存されるため、毎回行う必要はありません。
ダウンロード中、ロボットは単にファイルをディスクに追加するか、追加の処理を実行します。 そのため、GitHubリリースAPIを介してデータを取得し、それらからMarkdown形式でファイルを形成します。 履歴またはVCS履歴から取得したデータでも、ほぼ同じことが起こります。
抽出
データマイニングは簡単ではありません。 特に、大量のファイルがある大規模なリポジトリの場合。 結局のところ、それらのそれぞれを回避する必要があり、適切なパーサーがある場合は、リリースノートに関連する部分を解析して探します。
現在、このサービスは3つの主要なファイル形式をサポートしています。
- マークダウン;
- 再構築されたテキスト。
- HTML
ただし、処理ステップは互いに独立しているため、データをダウンロードするための新しい機能とサポートされている形式のリストを拡張する両方の機能を簡単に追加できます。
ロボットを簡単にするために、追加の設定を使用してファイルシステムの適切な場所にロボットを送信できます。 これを行うには、新しいパッケージをサービスに追加するときに、変更ログを検索するディレクトリとファイルのリスト、または回避するのが最適なディレクトリのリストを指定できます。
たとえば、プロジェクトにはドキュメントのあるサブディレクトリがあることがわかっているので、そこで変更ログを探す必要があります。 この場合、「検索リスト」フィールドに
docs/
と入力すると、ロボットはそこでのみ検索します。 正確にどこを見るべきかわからないが、
src/
リリースノートフォルダーに間違いがないことがわかっている場合は、このディレクトリを「無視リスト」フィールドに追加する必要があります。
後処理
最も興味深い部分は、データの一部が受信されたときに始まります。これは変更ログである可能性があります。 これが主な魔法の始まりです。 難しいのは、あなたがいつも確実に言うことができないということです
抽出されたテキストが変更ログに関連しているかどうか。 もちろん、メタデータで
ChangeLog.md
というファイルから抽出されたと言っていれば、これは難しくありません。 しかし、残念ながら、これは常にそうではありません。
したがって、バージョン番号と説明が変更ログの一部であるかどうか、またはデータの一部が誤って抽出されたかどうかを判断するために、AllMyChangesロボットはいくつかのヒューリスティックルールを使用します。
まず、抽出されたすべてのピースは、抽出元のファイルごとにグループ化され、次にディレクトリなどによってグループ化されます。 各グループについて、変更ログになる可能性の評価が行われます。 ファイルとディレクトリの名前、およびそれらに含まれるピースの合計数が評価されます。
これは、異なるファイルに散らばるリリースノートを正しく処理するために必要です。 たとえば、Djangoの場合： ... tree / master / docs / release
さらに、さまざまな理由で発生する可能性のある重複は削除されます。 最も一般的な理由は、ドキュメント内の複雑な構造であり、異なるバージョンの見出しに同じバージョンが記載されています。
また、後処理段階では、もちろんファイルに示されていない限り、リリース日が計算されます。 ここでは、特定のヒューリスティックルールも適用されます。ファイルにすべてのバージョンにリリース日が含まれていて、いずれかのバージョンに含まれていない場合、まだリリースされていないと見なす必要があります。 このバージョンには「未リリース」というラベルが付いています。
日付といえば。 AllMyChangesは、ライブラリのバージョンごとに、リリース日と発見日という2つの日付を保持しています。 多くの場合、通知文字はこれらの日付の両方を示し、それらは異なります。 「リリース日」は、常に元のソースに示されている日付です。 時々そうでないかもしれないし、時には未来にさえあるかもしれません。奇跡があるかもしれません。 ただし、「発見日」は、ロボットがこのバージョンを最初に発見した時間に対応しています。 検出日は常に存在し、元のソースで「リリース日」が示されていない場合は、代わりに「検出日」が使用されます。
2つの日付は何ですか？ 1つ目は、ドキュメントに記載されている内容を修正し、2つ目は、新しいバージョンのリリースをユーザーに通知する必要があるかどうかを確認するために使用します。
この状況を想像してください。 あるライブラリのロシアの開発者は、新しい年に間に合うように美しい数字の
1.2.3
持つ新しいバージョンを見送りました。 私は彼女にリリース日
2015-01-01
を与え、GitHubでローンチすることなく、bainkiに行きました。 1月7日に目を覚まして落ち着いて、彼は
git push
を行うことにしました。
AllMyChangesがリポジトリでバージョン
1.2.3
を検出するとどうなりますか？ そう！ 彼は彼女のリリース日が
2015-01-01
であることを修正し
2015-01-07
が、発見日として
2015-01-07
を設定します。 これは、翌日ダイジェストを作成するときに、このバージョン
1.2.3
がダイジェストに入るようにするために必要です。 そして、彼女は古いリリース日を持っているという事実にもかかわらず、ダイジェストに入るべきです。 したがって、すべてにかかわらず、すべての可能性に対して、更新に関する通知を受け取ります:)
このすべてにより、AllMyChangesは、到達が困難なすべての場所でリリース情報の検索に完全に対応し、時間内に受信トレイに配信できます。
ご質問は？
まだ質問がある場合は、ホールで質問することをsupportしないでください 、またはsupport@allmychanges.comに書いてください 。 喜んでお答えします。