Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: automation and documentation update Add checklist to PRs, CODEOWNERS file, fix duplicates in GH Pages, an… #16

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
## Checklist
- [ ] I have read the [CONTRIBUTING.md](../CONTRIBUTING.md)
- [ ] I certify that my `preview` and `released` lists for Events/Metrics/Alerts are correct
- [ ] I certify that all Events/Metrics/Alerts in `released` are properly tested and ready for production
7 changes: 4 additions & 3 deletions .github/workflows/create_tag_on_main_merge.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,14 @@ name: Bump version
on:
push:
branches:
- master
- main

jobs:
build:
runs-on: ubuntu-latest
steps:

- uses: actions/checkout@master
- uses: actions/checkout@v4
with:
# Fetches entire history, so we can analyze commits since last tag
fetch-depth: 0
Expand All @@ -17,4 +18,4 @@ jobs:
id: tag_version
uses: mathieudutour/[email protected]
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
github_token: ${{ secrets.GITHUB_TOKEN }}
12 changes: 12 additions & 0 deletions .github/workflows/pr_checklist_completion.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
name: 'PR Tasks Completed Check'
on:
pull_request:
types: [opened, edited]

jobs:
task-check:
runs-on: ubuntu-latest
steps:
- uses: kentaro-m/[email protected]
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
8 changes: 8 additions & 0 deletions CODEOWNERS
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# See https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#example-of-a-codeowners-file
#

* @equinix/governor-digin-observability-architects
fabric* @equinix/governor-digin-fabric
resource_manager* @equinix/governor-qore-crh
access_manager* @equinix/governor-qore-crh
network_edge* @equinix/governor-ne-network-edge-engineering
34 changes: 28 additions & 6 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -76,6 +76,34 @@ Each contributed data schema requires the following attributes:
* "metricNames" - - Object with list attributes `released` and `preview` that mark which environment the data schema is ready to suppport the given metric in. Only place types in the `released` list if it is fully tested and ready for production. Place it into the `preview` list if it is under development and should only be available in UAT.
* "alertNames" - Object with list attributes `released` and `preview` that mark which environment the data schema is ready to suppport the given event type in. Only place types in the `released` list if it is fully tested and ready for production. Place it into the `preview` list if it is under development and should only be available in UAT.

## Process for Upgrading Event/Metric/Alert from Development to Production

When adding a new event/metric/alert to a data schema always start by
entering it into the `preview` list. This list identifies *in development*
items and is the starting point for new events/metrics/alerts being added
into the repo.

Once an event/metric/alert has been thoroughly tested in lower environments
you will remove that item from the `preview` list and move it to the
`released` list. This indicates that your item is not ready to be consumed
in production and the production Equinix Event Manager will pass these items
through to the consumers.

It is imperative that you understand the responsibility involved for managing
your team's domain with regards to the `preview` and `released` lists in your
data schema files. The [CODEOWNERS](#codeowners) section describes how
responsibility is managed within the repo. Please review it thoroughly.

## CODEOWNERS

CODEOWNERS file will be in place to establish a Github team (Synced with Equinix IAM) responsible for the files along the domain path they are contributing to. This ensures that 1 member from each domain team and 1 architect will always be necessary to approve a Pull Request before it can be merged.
thogarty marked this conversation as resolved.
Show resolved Hide resolved

This is critical because the responsibility of maintaining the `released` and `preview` lists outlined in the [Gating](#data-schema-gating-through-equinix-event-manager) section lies with the Domain owners and not the architects. Should any production defect be found the Domain owner is responsible for resolution

When adding a new domain to the `jsonschema/equinix` directory, add an entry
to the CODEOWNERS file signifying which Github Team is responsible for
reviewing/approving PRs that modify the domain directory being added

## Data Schema Versioning

Versioning for data schemas is only based on major versions; there are no minor or patch versions. The major versions
Expand All @@ -91,9 +119,3 @@ Not all data_schemas need to be moved to v2. Just the ones that have breaking ch

The self service contribution model is setup to ensure the repo is always in a stable state that can be released to either UAT or production. Each time a Pull Request is merged into main a new version tag will be created based on SemVar for the commit names
present in the change. This tag will always be available to the Equinix Event Manager for releases. This setup is possible because of our CODEOWNERSHIP model.

## CODEOWNERS

CODEOWNERS file will be in place to establish a Github team (Synced with Equinix IAM) responsible for the files along the domain path they are contributing to. This ensures that 1 member from each domain team and 1 architect will always be necessary to approve a Pull Request before it can be merged.

This is critical because the responsibility of maintaining the `released` and `preview` lists outlined in the [Gating](#data-schema-gating-through-equinix-event-manager) section lies with the Domain owners and not the architects. Should any production defect be found the Domain owner is responsible for resolution
2 changes: 0 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,8 +43,6 @@ The following data payloads are the supported events and formats for Equinix Int
`equinix.fabric.connection.bgpipv4_session_status.established` <br>
`equinix.fabric.connection.bgpipv4_session_status.idle` <br>
`equinix.fabric.connection.bgpipv4_session_status.open_confirm` <br>
`equinix.fabric.connection.bgpipv4_session_status.open_confirm` <br>
`equinix.fabric.connection.bgpipv4_session_status.open_sent` <br>
`equinix.fabric.connection.bgpipv4_session_status.open_sent` <br>
`equinix.fabric.connection.bgpipv6_session_status.connect` <br>
`equinix.fabric.connection.bgpipv6_session_status.established` <br>
Expand Down
2 changes: 0 additions & 2 deletions jsonschema/catalog.json
Original file line number Diff line number Diff line change
Expand Up @@ -53,8 +53,6 @@
"equinix.fabric.connection.bgpipv4_session_status.established",
"equinix.fabric.connection.bgpipv4_session_status.idle",
"equinix.fabric.connection.bgpipv4_session_status.open_confirm",
"equinix.fabric.connection.bgpipv4_session_status.open_confirm",
"equinix.fabric.connection.bgpipv4_session_status.open_sent",
"equinix.fabric.connection.bgpipv4_session_status.open_sent",
"equinix.fabric.connection.bgpipv6_session_status.connect",
"equinix.fabric.connection.bgpipv6_session_status.established",
Expand Down
14 changes: 7 additions & 7 deletions scripts/generate_json_catalog.py
Original file line number Diff line number Diff line change
Expand Up @@ -11,16 +11,16 @@ def retrieve_json_schemas():
with open(root + "/" + file, "r") as eventFile:
data = json.load(eventFile)
events = {
sc.RELEASED: sorted(data[sc.EVENTS][sc.RELEASED]),
sc.PREVIEW: sorted(data[sc.EVENTS][sc.PREVIEW])
sc.RELEASED: sorted(set(data[sc.EVENTS][sc.RELEASED])),
sc.PREVIEW: sorted(set(data[sc.EVENTS][sc.PREVIEW]))
}
metrics = {
sc.RELEASED: sorted(data[sc.METRICS][sc.RELEASED]),
sc.PREVIEW: sorted(data[sc.METRICS][sc.PREVIEW])
sc.RELEASED: sorted(set(data[sc.METRICS][sc.RELEASED])),
sc.PREVIEW: sorted(set(data[sc.METRICS][sc.PREVIEW]))
}
alerts = {
sc.RELEASED: sorted(data[sc.ALERTS][sc.RELEASED]),
sc.PREVIEW: sorted(data[sc.ALERTS][sc.PREVIEW])
sc.RELEASED: sorted(set(data[sc.ALERTS][sc.RELEASED])),
sc.PREVIEW: sorted(set(data[sc.ALERTS][sc.PREVIEW]))
}
newItem = {
"url": data["$id"],
Expand Down Expand Up @@ -49,4 +49,4 @@ def write_json_schemas_to_catalog_file(json_schemas):

if __name__ == "__main__":
json_schemas = retrieve_json_schemas()
write_json_schemas_to_catalog_file(json_schemas)
write_json_schemas_to_catalog_file(json_schemas)
2 changes: 1 addition & 1 deletion scripts/generate_readme_event_catalog.py
Original file line number Diff line number Diff line change
Expand Up @@ -55,4 +55,4 @@ def replace_readme_catalog():


if __name__ == "__main__":
replace_readme_catalog()
replace_readme_catalog()