[ci] use external repo for check-labels (#1985)

* [ci] use external repo for check-labels

* remove ruled_labels specs, docs

* remove repo checkout

* remove checkout action

* remove old gha

.github/workflows/check-D-labels.yml

@@ -10,13 +10,6 @@ jobs:
   check-labels:
     runs-on: ubuntu-latest
     steps:
-      - name: Checkout sources
-        uses: actions/checkout@v3
-        with:
-          fetch-depth: 0
-          ref: ${{ github.event.pull_request.head.ref }}
-          repository: ${{ github.event.pull_request.head.repo.full_name }}
-
       - name: Pull image
         env:
           IMAGE: paritytech/ruled_labels:0.3.2
@@ -30,12 +23,13 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           API_BASE: https://api.github.com/repos
           REPO: ${{ github.repository }}
-          RULES_PATH: scripts/ci/ruled_labels
-          CHECK_SPECS: specs.yaml
+          RULES_PATH: labels/ruled_labels
+          CHECK_SPECS: specs_cumulus.yaml
         run: |
           echo "REPO: ${REPO}"
           echo "GITHUB_PR: ${GITHUB_PR}"
-
+          # Clone repo with labels specs
+          git clone https://github.com/paritytech/labels
           # Fetch the labels for the PR under test
           labels=$( curl -H "Authorization: token ${GITHUB_TOKEN}" -s "$API_BASE/${REPO}/pulls/${GITHUB_PR}" | jq '.labels | .[] | .name' | tr "\n" ",")
 

.github/workflows/check-labels.yml

@@ -8,13 +8,6 @@ jobs:
   check-labels:
     runs-on: ubuntu-latest
     steps:
-      - name: Checkout sources
-        uses: actions/checkout@v3
-        with:
-          fetch-depth: 0
-          ref: ${{ github.event.pull_request.head.ref }}
-          repository: ${{ github.event.pull_request.head.repo.full_name }}
-
       - name: Pull image
         env:
           IMAGE: paritytech/ruled_labels:0.3.2
@@ -28,12 +21,13 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           API_BASE: https://api.github.com/repos
           REPO: ${{ github.repository }}
-          RULES_PATH: scripts/ci/ruled_labels
-          CHECK_SPECS: specs.yaml
+          RULES_PATH: labels/ruled_labels
+          CHECK_SPECS: specs_cumulus.yaml
         run: |
           echo "REPO: ${REPO}"
           echo "GITHUB_PR: ${GITHUB_PR}"
-
+          # Clone repo with labels specs
+          git clone https://github.com/paritytech/labels
           # Fetch the labels for the PR under test
           labels=$( curl -H "Authorization: token ${GITHUB_TOKEN}" -s "$API_BASE/${REPO}/pulls/${GITHUB_PR}" | jq '.labels | .[] | .name' | tr "\n" ",")
 

CODEOWNERS

@@ -17,7 +17,7 @@
 # - The latest matching rule, if multiple, takes precedence.
 
 # CI
-/.github/ @paritytech/ci @chevdor
+/.github/ @paritytech/ci @paritytech/release-engineering
 /.gitlab-ci.yml @paritytech/ci
-/scripts/ci/ @paritytech/ci @chevdor
+/scripts/ci/ @paritytech/ci @paritytech/release-engineering
 

docs/documentation.md

@@ -1,92 +1 @@
-
-
-This is the documentation for the repo `paritytech/cumulus`.
-
-It contains 65 labels:
-
-### A Labels: Action labels, used with GHA and trigger a certain process
-- `A0-please_review`: *Pull request needs code review.*
-- `A1-needs_burnin`: *Pull request needs to be tested on a live validator node before merge. DevOps is notified via matrix*
-- `A2-insubstantial`: *Pull request requires no code review (e.g., a sub-repository hash update).*
-- `A3-in_progress`: *Pull request is in progress. No review needed at this stage.*
-- `A4-companion`: *A PR that should be considered alongside another (usually more comprehensive and detailed) PR.*
-- `A5-stale`: *Pull request did not receive any updates in a long time. No review needed at this stage. Close it.*
-- `A6-backport`: *Pull request is already reviewed well in another branch.*
-
-### B labels: Release note labels, to be used in combination with a T* label
-- `B0-silent`: *Changes should not be mentioned in any release notes*
-- `B1-note_worthy`: *Changes should be noted in the release notes*
-
-### C labels: Criticality - how critical is this change? Which impact does it have on the builders? To be used in combination with a T* label
-- `C1-low`: *PR touches the given topic and has a low impact on builders.*
-- `C3-medium`: *PR touches the given topic and has a medium impact on builders.*
-- `C5-high`: *PR touches the given topic and has a high impact on builders.*
-- `C7-critical`: *PR touches the given topic and has a critical impact on builders.*
-
-### D labels: Auditing labels, optional for cumulus
-- `D1-audited 👍`: *PR contains changes to fund-managing logic that has been properly reviewed and externally audited.*
-- `D2-notlive 💤`: *PR contains changes in a runtime directory that is not deployed to a chain that requires an audit.*
-- `D3-trivial 🧸`: *PR contains trivial changes in a runtime directory that do not require an audit*
-- `D5-nicetohaveaudit ⚠️`: *PR contains trivial changes to logic that should be properly reviewed.*
-- `D9-needsaudit 👮`: *PR contains changes to fund-managing logic that should be properly reviewed and externally audited*
-
-### E labels: Upgrade dependencies
-- `E0-runtime_migration`: *PR introduces code that might require downstream chains to run a runtime upgrade.*
-- `E1-database_migration`: *PR introduces code that does a one-way migration of the database.*
-- `E2-dependencies`: *Pull requests that update a dependency file.*
-- `E3-host_functions`: *PR adds new host functions which requires a node release before a runtime upgrade.*
-- `E4-node_first_update`: *This is a runtime change that will require all nodes to be update BEFORE the runtime upgrade.*
-
-### F labels: Fail - change breaks some part of the code
-- `F0-breaks_everything`: *This change breaks the underlying networking, sync or related and thus will cause a fork.*
-- `F1-breaks_authoring`: *This change breaks authorities or authoring code.*
-- `F2-breaks_consensus`: *This change breaks consensus or consensus code.*
-- `F3-breaks_API`: *This PR changes public API; next release should be major.*
-
-### I labels: Issue related labels
-- `I0-consensus`: *Issue can lead to a consensus failure.*
-- `I1-panic`: *The node panics and exits without proper error handling.*
-- `I2-security`: *The node fails to follow expected, security-sensitive, behaviour.*
-- `I3-bug`: *The node fails to follow expected behavior.*
-- `I4-annoyance`: *The node behaves within expectations, however this “expected behaviour” itself is at issue.*
-- `I5-tests`: *Tests need fixing, improving or augmenting.*
-- `I6-documentation`: *Documentation needs fixing, improving or augmenting.*
-- `I7-refactor`: *Code needs refactoring.*
-- `I8-footprint`: *An enhancement to provide a smaller (system load, memory, network or disk) footprint.*
-- `I9-optimisation`: *An enhancement to provide better overall performance in terms of time-to-completion for a task.*
-
-### J labels: Just a continuation of the issue related labels
-- `J0-enhancement`: *An additional feature request.*
-- `J1-meta`: *A specific issue for grouping tasks or bugs of a specific category.*
-- `J2-unconfirmed`: *Issue might be valid, but it's not yet known.*
-- `J3-intended`: *Issue describes a behavior which turns out to work as intended. Closer should explain why.*
-- `J4-duplicate`: *Issue is a duplicate. Closer should comment with a link to the duplicate.*
-- `J5-wont_fix`: *Issue is in principle valid, but this project will not address it. Closer should explain why.*
-- `J6-invalid`: *Issue is invalid. Closer should comment why.*
-
-### S labels: Status of an issue
-- `S0-design`: *Issue is in the design stage.*
-- `S1-implement`: *Issue is in the implementation stage.*
-- `S2-test/monitor`: *Issue is in the testing stage.*
-- `S3-deploy`: *Issue is in the deployment stage*
-- `S4-blocked`: *Issue is blocked, see comments for further information.*
-
-### T labels: Topics - to be used in combination with other labels
-- `T0-node`: *This PR/Issue is related to the topic “node”.*
-- `T1-runtime`: *This PR/Issue is related to the topic “runtime”.*
-- `T10-release`: *This PR/Issue is related to topics touching the release notes.*
-- `T2-API`: *This PR/Issue is related to APIs.*
-- `T3-relay_chain`: *This PR/Issue is related to the relay chain.*
-- `T4-smart_contracts`: *This PR/Issue is related to smart contracts.*
-- `T5-parachains`: *This PR/Issue is related to Parachains.*
-- `T6-XCM`: *This PR/Issue is related to XCM.*
-- `T7-statemint`: *This PR/Issue is related to Statemint*
-- `T7-substrate`: *This is an issue that needs to be implemented upstream in Substrate.*
-- `T8-CGP`: *This PR/Issue is related to Common Good Parachains.*
-
-### U labels: Urgency - in what time manner does this issue need to be resolved?
-- `U0-drop_everything`: *Everyone should address the issue now.*
-- `U1-asap`: *No need to stop dead in your tracks, however issue should be addressed as soon as possible.*
-- `U2-some_time_soon`: *Issue is worth doing soon.*
-- `U3-nice_to_have`: *Issue is worth doing eventually.*
-- `U4-some_day_maybe`: *Issue might be worth doing eventually.*
+Was moved [here](https://github.com/paritytech/labels/blob/main/docs/doc_cumulus.md)