From 03dd6198b1f8bca19ff27a20cf912c720599b405 Mon Sep 17 00:00:00 2001 From: Ryan Merolle Date: Fri, 8 Nov 2024 12:01:08 -0500 Subject: [PATCH] Lint fixes (#2485) * update markdown * lint updates * markdown lint updates * markdown code block fixes * read add test tube to markdown --- .github/dependabot.yml | 48 +++--- .github/workflows/stale.yml | 2 +- .github/workflows/update-generated-schema.yml | 8 +- .github/workflows/validation.yml | 2 +- .markdownlint.yaml | 4 + .pre-commit-config.yaml | 23 +-- README.md | 148 +++++++++++------- scripts/align-filenames-models.py | 14 +- scripts/fix-filename-underscores.py | 4 +- scripts/fix-slugs.py | 2 +- scripts/update-schema.py | 2 +- 11 files changed, 148 insertions(+), 109 deletions(-) create mode 100644 .markdownlint.yaml diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 17246f0dc..88b1da441 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -1,36 +1,36 @@ --- version: 2 updates: - - package-ecosystem: "pip" - directory: "/" + - package-ecosystem: pip + directory: / schedule: - interval: "monthly" - time: "02:00" - timezone: "America/New_York" + interval: monthly + time: 02:00 + timezone: America/New_York labels: - - "dependencies" - target-branch: "master" + - dependencies + target-branch: master assignees: - - "danner26" - - package-ecosystem: "github-actions" - directory: "/" + - danner26 + - package-ecosystem: github-actions + directory: / schedule: - interval: "monthly" - time: "02:00" - timezone: "America/New_York" + interval: monthly + time: 02:00 + timezone: America/New_York labels: - - "dependencies" - target-branch: "master" + - dependencies + target-branch: master assignees: - - "danner26" - - package-ecosystem: "devcontainers" - directory: "/" + - danner26 + - package-ecosystem: devcontainers + directory: / schedule: - interval: "monthly" - time: "02:00" - timezone: "America/New_York" + interval: monthly + time: 02:00 + timezone: America/New_York labels: - - "dependencies" - target-branch: "master" + - dependencies + target-branch: master assignees: - - "danner26" + - danner26 diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index 38f8dbed9..b260b418a 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -3,7 +3,7 @@ name: Close stale PRs on: schedule: - - cron: '0 4 * * *' + - cron: 0 4 * * * jobs: stale: runs-on: ubuntu-latest diff --git a/.github/workflows/update-generated-schema.yml b/.github/workflows/update-generated-schema.yml index d7e64d359..c171a6267 100644 --- a/.github/workflows/update-generated-schema.yml +++ b/.github/workflows/update-generated-schema.yml @@ -2,7 +2,7 @@ name: Gather New NetBox Generated Schema JSON on: schedule: - - cron: '0 */12 * * *' + - cron: 0 */12 * * * jobs: schema-update: runs-on: ubuntu-latest @@ -48,9 +48,9 @@ jobs: - name: Create Pull Request uses: peter-evans/create-pull-request@v7 with: - commit-message: "Regenerate master slug list after successful PR merge" - committer: "NetBox-Bot " - author: "NetBox-Bot " + commit-message: Regenerate master slug list after successful PR merge + committer: NetBox-Bot + author: NetBox-Bot branch: ${{ steps.netbox-release.outputs.release }} delete-branch: true base: master diff --git a/.github/workflows/validation.yml b/.github/workflows/validation.yml index b7f2f19d4..f17670764 100644 --- a/.github/workflows/validation.yml +++ b/.github/workflows/validation.yml @@ -99,7 +99,7 @@ jobs: id: pickle-change uses: tj-actions/changed-files@v45 with: - files: 'tests/known-slugs.pickle' + files: tests/known-slugs.pickle - name: Add PR Comment if pickle file is modified uses: mshick/add-pr-comment@v2 if: steps.pickle-change.outputs.any_changed == 'true' diff --git a/.markdownlint.yaml b/.markdownlint.yaml new file mode 100644 index 000000000..a076d9193 --- /dev/null +++ b/.markdownlint.yaml @@ -0,0 +1,4 @@ +--- +default: true + +MD013: false diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index fddef05d5..c351e4a6e 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -1,8 +1,7 @@ --- -files: ^(device-types|module-types)/ repos: - repo: https://github.com/pre-commit/pre-commit-hooks - rev: v4.6.0 + rev: v5.0.0 hooks: - id: trailing-whitespace - id: end-of-file-fixer @@ -19,12 +18,16 @@ repos: - id: yamllint name: Lint YAML files args: [--format, parsable, --strict] - - repo: local + - repo: https://github.com/DavidAnson/markdownlint-cli2 + rev: v0.14.0 hooks: - - id: pytest - name: Run PyTest Case Checks - entry: pytest - language: system - args: [--tb=short, -v] - pass_filenames: false - always_run: true + - id: markdownlint-cli2 + #- repo: local + # hooks: + # - id: pytest + # name: Run PyTest Case Checks + # entry: pytest + # language: system + # args: [--tb=short, -v] + # pass_filenames: false + # always_run: true diff --git a/README.md b/README.md index 897affed6..1353ccb91 100644 --- a/README.md +++ b/README.md @@ -27,24 +27,25 @@ Each definition **must** include at minimum the following fields: - Type: String - Pattern: `"^[-a-zA-Z0-9_]+$"`. Must match the following characters: `-`, `_`, Uppercase or Lowercase `a` to `z`, Numbers `0` to `9`. ->:test_tube: **Valid Example**: ->``` ->manufacturer: Dell ->model: PowerEdge R6515 ->slug: dell-poweredge-r6515 ->``` +:test_tube: Example: + + ```yaml + manufacturer: Dell + model: PowerEdge R6515 + slug: dell-poweredge-r6515 + ``` The following fields may **optionally** be declared: - `part_number`: An alternative representation of the model number (e.g. a SKU). (**Default: None**) - Type: String -> :test_tube: **Example**: `part_number: D109-C3` + - :test_tube: Example: `part_number: D109-C3` - `u_height`: The height of the device type in rack units. Increments of 0.5U are supported. (**Default: 1**) - Type: number (minimum of `0`, multiple of `0.5`) -> :test_tube: **Example**: `u_height: 12.5` + - :test_tube: Example: `u_height: 12.5` - `is_full_depth`: A boolean which indicates whether the device type consumes both the front and rear rack faces. (**Default: true**) - Type: Boolean -> :test_tube: **Example**: `is_full_depth: false` + - :test_tube: Example: `is_full_depth: false` - `airflow`: A declaration of the airflow pattern for the device. (**Default: None**) - Type: String - Options: @@ -54,27 +55,30 @@ The following fields may **optionally** be declared: - `right-to-left` - `side-to-rear` - `passive` -> :test_tube: **Example**: `airflow: side-to-rear` + - :test_tube: Example: `airflow: side-to-rear` - `front_image`: Indicates that this device has a front elevation image within the [elevation-images](elevation-images/) folder. (**Default: None**) - NOTE: The elevation images folder requires the same folder name as this device. The file name must also adhere to .front. - Type: Boolean -> :test_tube: **Example**: `front_image: True` + - :test_tube: Example: `front_image: True` - `rear_image`: Indicates that this device has a rear elevation image within the [elevation-images](elevation-images/) folder. (**Default: None**) - NOTE: The elevation images folder requires the same folder name as this device. The file name must also adhere to .rear. - Type: Boolean -> :test_tube: **Example**: `rear_image: True` + - :test_tube: Example: `rear_image: True` - `subdevice_role`: Indicates that this is a `parent` or `child` device. (**Default: None**) - Type: String - Options: - `parent` - `child` -> :test_tube: **Example**: `subdevice_role: parent` + - :test_tube: Example: `subdevice_role: parent` - `comments`: A string field which allows for comments to be added to the device. (**Default: None**) - Type: String -> :test_tube: **Example**: `comments: This is a comment that will appear on all NetBox devices of this type` + - :test_tube: Example: `comments: This is a comment that will appear on all NetBox devices of this type` +- `is_powered`: A boolean which indicates whether the device type does not take power. This is mainly used as a workaround for validation testing on non-devices (i.e. rackmount kits for mounting desktop devices) (**Default: True**) + - Type: Boolean + - :test_tube: Example: `is_powered: false` - `weight`: A number representing the numeric weight value. Must be a multiple of 0.01 (2 decimal places). (**Default: None**) - - Type: Number - - Value: must be a multiple of 0.01 + - Type: Number + - Value: must be a multiple of 0.01 - `weight_unit`: A string defining the unit of measurement. It must be one of the supported values. (**Default: None**) - Type: String - Value: Enumerated Options @@ -82,14 +86,12 @@ The following fields may **optionally** be declared: - g - lb - oz ->:test_tube: **Example**: ->``` ->weight: 12.21 ->weight_unit: lb ->``` -- `is_powered`: A boolean which indicates whether the device type does not take power. This is mainly used as a workaround for validation testing on non-devices (i.e. rackmount kits for mounting desktop devices) (**Default: True**) - - Type: Boolean -> :test_tube: **Example**: `is_powered: false` + - :test_tube: Example: + + ```yaml + weight: 12.21 + weight_unit: lb + ``` For further detail on these attributes and those listed below, please reference the [schema definitions](schema/) and the [Component Definitions](#component-definitions) below. @@ -99,36 +101,45 @@ For further detail on these attributes and those listed below, please reference Valid component types are listed below. Each type of component must declare a list of the individual component templates to be added. -- [`console-ports`](#console-ports "Availible in NetBox 2 and later") -- [`console-server-ports`](#console-server-ports "Availible in NetBox 2.2 and later") -- [`power-ports`](#power-ports "Availible in NetBox 1.7 and later") -- [`power-outlets`](#power-outlets "Availible in NetBox 2 and later") -- [`interfaces`](#interfaces "Availible in all versions of NetBox") -- [`front-ports`](#front-ports "Availible in NetBox 2.5 and later") -- [`rear-ports`](#rear-ports "Availible in NetBox 2.5 and later") -- [`module-bays`](#module-bays "Availible in NetBox 3.2 and later") -- [`device-bays`](#device-bays "Availible in all versions of NetBox") -- [`inventory-items`](#inventory-items "Availible in NetBox 3.2 and later") +- [console-ports](#console-ports "Availible in NetBox 2 and later") +- [console-server-ports](#console-server-ports "Availible in NetBox 2.2 and later") +- [power-ports](#power-ports "Availible in NetBox 1.7 and later") +- [power-outlets](#power-outlets "Availible in NetBox 2 and later") +- [interfaces](#interfaces "Availible in all versions of NetBox") +- [front-ports](#front-ports "Availible in NetBox 2.5 and later") +- [rear-ports](#rear-ports "Availible in NetBox 2.5 and later") +- [module-bays](#module-bays "Availible in NetBox 3.2 and later") +- [device-bays](#device-bays "Availible in all versions of NetBox") +- [inventory-items](#inventory-items "Availible in NetBox 3.2 and later") The available fields for each type of component are listed below. -#### Console Ports ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/consoleport/)) -> A console port provides connectivity to the physical console of a device. These are typically used for temporary access by someone who is physically near the device, or for remote out-of-band access provided via a networked console server. +#### Console Ports + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/consoleport/)** + +A console port provides connectivity to the physical console of a device. These are typically used for temporary access by someone who is physically near the device, or for remote out-of-band access provided via a networked console server. - `name`: Name - `label`: Label - `type`: Port type slug (Array) - `poe`: Does this port access/provide POE? (Boolean) -#### Console Server Ports ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/consoleserverport/)) -> A console server is a device which provides remote access to the local consoles of connected devices. They are typically used to provide remote out-of-band access to network devices, and generally connect to console ports. +#### Console Server Ports + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/consoleserverport/)** + +A console server is a device which provides remote access to the local consoles of connected devices. They are typically used to provide remote out-of-band access to network devices, and generally connect to console ports. - `name`: Name - `label`: Label - `type`: Port type slug (Array) -#### Power Ports ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/powerport/)) -> A power port is a device component which draws power from some external source (e.g. an upstream power outlet), and generally represents a power supply internal to a device. +#### Power Ports + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/powerport/)** + +A power port is a device component which draws power from some external source (e.g. an upstream power outlet), and generally represents a power supply internal to a device. - `name`: Name - `label`: Label @@ -136,8 +147,11 @@ The available fields for each type of component are listed below. - `maximum_draw`: The port's maximum power draw, in watts (optional) - `allocated_draw`: The port's allocated power draw, in watts (optional) -#### Power Outlets ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/poweroutlet/)) -> Power outlets represent the outlets on a power distribution unit (PDU) or other device that supplies power to dependent devices. Each power port may be assigned a physical type, and may be associated with a specific feed leg (where three-phase power is used) and/or a specific upstream power port. This association can be used to model the distribution of power within a device. +#### Power Outlets + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/poweroutlet/)** + +Power outlets represent the outlets on a power distribution unit (PDU) or other device that supplies power to dependent devices. Each power port may be assigned a physical type, and may be associated with a specific feed leg (where three-phase power is used) and/or a specific upstream power port. This association can be used to model the distribution of power within a device. - `name`: Name - `label`: Label @@ -145,16 +159,22 @@ The available fields for each type of component are listed below. - `power_port`: The name of the power port on the device which powers this outlet (optional) - `feed_leg`: The phase (leg) of power to which this outlet is mapped; A, B, or C (optional) -#### Interfaces ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/interface/)) -> Interfaces in NetBox represent network interfaces used to exchange data with connected devices. On modern networks, these are most commonly Ethernet, but other types are supported as well. IP addresses and VLANs can be assigned to interfaces. +#### Interfaces + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/interface/)** + +Interfaces in NetBox represent network interfaces used to exchange data with connected devices. On modern networks, these are most commonly Ethernet, but other types are supported as well. IP addresses and VLANs can be assigned to interfaces. - `name`: Name - `label`: Label - `type`: Interface type slug (Array) - `mgmt_only`: A boolean which indicates whether this interface is used for management purposes only (default: false) -#### Front Ports ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/frontport/)) -> Front ports are pass-through ports which represent physical cable connections that comprise part of a longer path. For example, the ports on the front face of a UTP patch panel would be modeled in NetBox as front ports. Each port is assigned a physical type, and must be mapped to a specific rear port on the same device. A single rear port may be mapped to multiple front ports, using numeric positions to annotate the specific alignment of each. +#### Front Ports + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/frontport/)** + +Front ports are pass-through ports which represent physical cable connections that comprise part of a longer path. For example, the ports on the front face of a UTP patch panel would be modeled in NetBox as front ports. Each port is assigned a physical type, and must be mapped to a specific rear port on the same device. A single rear port may be mapped to multiple front ports, using numeric positions to annotate the specific alignment of each. - `name`: Name - `label`: Label @@ -162,8 +182,11 @@ The available fields for each type of component are listed below. - `rear_port`: The name of the rear port on this device to which the front port maps - `rear_port_position`: The corresponding position on the mapped rear port (default: 1) -#### Rear Ports ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/rearport/)) -> Like front ports, rear ports are pass-through ports which represent the continuation of a path from one cable to the next. Each rear port is defined with its physical type and a number of positions: Rear ports with more than one position can be mapped to multiple front ports. This can be useful for modeling instances where multiple paths share a common cable (for example, six discrete two-strand fiber connections sharing a 12-strand MPO cable). +#### Rear Ports + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/rearport/)** + +Like front ports, rear ports are pass-through ports which represent the continuation of a path from one cable to the next. Each rear port is defined with its physical type and a number of positions: Rear ports with more than one position can be mapped to multiple front ports. This can be useful for modeling instances where multiple paths share a common cable (for example, six discrete two-strand fiber connections sharing a 12-strand MPO cable). - `name`: Name - `label`: Label @@ -171,25 +194,34 @@ The available fields for each type of component are listed below. - `positions`: The number of front ports that can map to this rear port (default: 1) - `poe`: Does this port access/provide POE? (Boolean) -#### Module Bays ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/modulebay/)) -> Module bays represent a space or slot within a device in which a field-replaceable module may be installed. A common example is that of a chassis-based switch such as the Cisco Nexus 9000 or Juniper EX9200. Modules in turn hold additional components that become available to the parent device. +#### Module Bays + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/modulebay/)** + +Module bays represent a space or slot within a device in which a field-replaceable module may be installed. A common example is that of a chassis-based switch such as the Cisco Nexus 9000 or Juniper EX9200. Modules in turn hold additional components that become available to the parent device. - `name`: Name - `label`: Label - `position`: The alphanumeric position in which this module bay is situated within the parent device. When creating module components, the string `{module}` in the component name will be replaced with the module bay's `position`. See the [NetBox Documentation](https://docs.netbox.dev/en/stable/models/dcim/moduletype/#automatic-component-renaming) for more details. -#### Device Bays ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/devicebay/)) ->Device bays represent a space or slot within a parent device in which a child device may be installed. For example, a 2U parent chassis might house four individual blade servers. The chassis would appear in the rack elevation as a 2U device with four device bays, and each server within it would be defined as a 0U device installed in one of the device bays. Child devices do not appear within rack elevations or count as consuming rack units. -> -> Child devices are first-class Devices in their own right: That is, they are fully independent managed entities which don't share any control plane with the parent. Just like normal devices, child devices have their own platform (OS), role, tags, and components. LAG interfaces may not group interfaces belonging to different child devices. +#### Device Bays + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/devicebay/)** + +Device bays represent a space or slot within a parent device in which a child device may be installed. For example, a 2U parent chassis might house four individual blade servers. The chassis would appear in the rack elevation as a 2U device with four device bays, and each server within it would be defined as a 0U device installed in one of the device bays. Child devices do not appear within rack elevations or count as consuming rack units. + +Child devices are first-class Devices in their own right: That is, they are fully independent managed entities which don't share any control plane with the parent. Just like normal devices, child devices have their own platform (OS), role, tags, and components. LAG interfaces may not group interfaces belonging to different child devices. - `name`: Name - `label`: Label -#### Inventory Items ([Documentation](https://docs.netbox.dev/en/stable/models/dcim/inventoryitem/)) -> Inventory items represent hardware components installed within a device, such as a power supply or CPU or line card. They are intended to be used primarily for inventory purposes. -> -> Inventory items are hierarchical in nature, such that any individual item may be designated as the parent for other items. For example, an inventory item might be created to represent a line card which houses several SFP optics, each of which exists as a child item within the device. An inventory item may also be associated with a specific component within the same device. For example, you may wish to associate a transceiver with an interface. +#### Inventory Items + +**[Documentation](https://docs.netbox.dev/en/stable/models/dcim/inventoryitem/)** + +Inventory items represent hardware components installed within a device, such as a power supply or CPU or line card. They are intended to be used primarily for inventory purposes. + +Inventory items are hierarchical in nature, such that any individual item may be designated as the parent for other items. For example, an inventory item might be created to represent a line card which houses several SFP optics, each of which exists as a child item within the device. An inventory item may also be associated with a specific component within the same device. For example, you may wish to associate a transceiver with an interface. - `name`: Name - `label`: Label diff --git a/scripts/align-filenames-models.py b/scripts/align-filenames-models.py index e86a5d592..2c38b3c38 100644 --- a/scripts/align-filenames-models.py +++ b/scripts/align-filenames-models.py @@ -13,21 +13,21 @@ for root, dirs, files in walk(root_dir): if file.split(".")[0].count("_") > 0: newname = file.replace("_", "-") rename(f"{root}/{file}", f"{root}/{newname}") - + data = [] with open(path.join(root, file), 'r') as stream: try: data = stream.readlines() - + model = "" partNumber = "" - + for idx, line in enumerate(data): if "model: " in line: model = line.split(": ")[1].strip().replace(" ", "-") if "part_number: " in line: partNumber = line.split(": ")[1].strip() - + fileName = file.split('.')[0].casefold() regModel = model.replace("sfp+", "sfpp").replace("poe+", "poep").replace("!", "").replace("/", "-").replace("SFP+", "SFPP").replace("POE+", "POEP").replace("!", "").replace("/", "-").replace("PoE+", "PoEP") modModel = regModel.casefold().replace("'", "").replace("+", "-plus").replace("*", "-") @@ -38,9 +38,9 @@ for root, dirs, files in walk(root_dir): print(file.casefold()) print("------------") total = total + 1 - + except yaml.YAMLError as exc: print(exc) stream.close() - -print(f"Total Left: {total}") \ No newline at end of file + +print(f"Total Left: {total}") diff --git a/scripts/fix-filename-underscores.py b/scripts/fix-filename-underscores.py index 75cf541cc..0ef06b345 100644 --- a/scripts/fix-filename-underscores.py +++ b/scripts/fix-filename-underscores.py @@ -13,5 +13,5 @@ for root, dirs, files in walk(root_dir): if file.split(".")[0].count("_") > 0: newname = file.replace("_", "-") rename(f"{root}/{file}", f"{root}/{newname}") - -print(f"Total Left: {total}") \ No newline at end of file + +print(f"Total Left: {total}") diff --git a/scripts/fix-slugs.py b/scripts/fix-slugs.py index f620fdeb2..f8c4d04ca 100644 --- a/scripts/fix-slugs.py +++ b/scripts/fix-slugs.py @@ -78,4 +78,4 @@ for root, dirs, files in walk(root_dir): file.writelines(data) file.close() -print(f"Total Left: {total}") \ No newline at end of file +print(f"Total Left: {total}") diff --git a/scripts/update-schema.py b/scripts/update-schema.py index 66ab9d9c5..ce0f6b758 100644 --- a/scripts/update-schema.py +++ b/scripts/update-schema.py @@ -56,4 +56,4 @@ def __init__(): print("Completed data extract.") -__init__() \ No newline at end of file +__init__()