Repository Organization
Repository Organization
The repository and profile are organized into two primary branches: main and TBD. The repository has a set of tags representing iterative releases of the STIG from one Benchmark major version to the next. It also has a set of releases for fixes and updates to the profile between STIG Benchmark Releases.
Branches
main branch
The main branch contains the most recent code for the profile. It may include bugs and is typically aligned with the latest patch release for the profile. This branch is primarily used for development and testing workflows for the various testing targets. For production validation, use the latest stable patch release.
v{x}r{xx} branches
The v{x}r{xx} branches represent the changes between releases of the benchmark. They align with the STIG releases for the Benchmark found at the DISA STIG Document Library.
Releases
Releases use Semantic Versioning (SemVer), aligning with the STIG Benchmark versioning system of Major Version and Release. The SemVer patch number is used for updates, bug fixes, and code changes between STIG Benchmark Releases for the given product. STIG Benchmarks use a Version and Release tagging pattern v{x}r{xx} - like V1R12 - and we mirror that pattern in our SemVer releases.
Tags
Current Tag
We don't use a specific current or latest tag. The current/latest tag for the profile and repository will always be the latest major tag of the benchmark. For example, if v1.12.3 is the latest Benchmark release from the STIG author, then the tag v1.12 will point to the v1.12.3 release of the code.
To use the current main, point directly to the GitHub repo.
Major Tags
Major tags point to the latest patch release of the benchmark. For example, v1.3 and v1.3.0 represent the first release of the Red Hat Enterprise Linux 8 STIG V1R3 Benchmark. The v1.12.xx tag(s) would represent the V1R12 Benchmark releases as we find bugs, fixes, or general improvements to the testing profile. This tag will point to its v{x}r{xx} counterpart.
Patch Releases
The latest patch release always points to the major release for the profile.
For example, after releasing v1.12.0, we will point v1.12 to that patch release: v1.12.0. When an issue is found, we will fix, tag, and release v1.12.1. We will then 'move' the v1.12 tag so that it points to tag v1.12.1. This way, your pipelines can choose if they want to pin on a specific release of the InSpec profile or always run 'current'.