Skip to content

Conversation

@AmberArcadia
Copy link
Member

Summary

Implements GitHub issue #9313 - adds a pre-commit hook that ensures packages using go-fips also have corresponding go-fips tests.

  • Detects any go-fips variant (go-fips, go-fips-md5, etc.) in environment packages or go-package declarations
  • Validates each package/subpackage independently - every go-fips usage must have its own test/go-fips-check
  • Handles complex scenarios: main package + subpackages, multiple subpackages, mixed configurations
  • Provides detailed error messages specifying exactly which component is missing tests
  • Supports subpackage test sections properly

Test plan

  • Test on packages that use go-fips and have tests (should pass)
  • Test on packages that don't use go-fips (should skip)
  • Test on packages with subpackage go-fips usage (should validate subpackage tests)
  • Test comprehensive detection of go-fips variants
  • Validate error messages are specific and actionable

🤖 Generated with Claude Code

Implements GitHub issue requirements:
- Detects packages using go-fips in environment or pipeline
- Verifies they have corresponding go-fips test (uses: test/go-fips-check)
- Reports failures for packages missing the required test
- Detect any go-fips variant (go-fips, go-fips-md5, etc.) using startswith()
- Check each package/subpackage independently for compliance
- Require matching tests for each go-fips usage (not just any test)
- Provide detailed error messages specifying which component lacks tests
- Handle subpackage test sections properly

Fixes comprehensive validation of go-fips test requirements.
Copy link
Contributor

@dannf dannf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test looks good to me, a few comments about optimizations inside. Would you mind raising this in #eng-os? I'd like to give other people a chance to chime in, since this is establishing a de facto policy (and I'm not really a go-fips expert). @murraybd might be interested in it as well, as a test proliferater himself :)

One note: this test is looking at the YAML file in a pre-compiled state, so it will miss things such as packages with names like ${{vars.expands-to-go-fips}}-foo. If we implemented it as a melange linter or melange compiled it, it wouldn't have that problem. I wonder if there's a way to have one hook do the compilation such that all follow-on tests could consume it w/o recompiling?

[^/]+\.ya?ml # matches .yaml or .yml files at the top level only
)$
- id: check-for-go-fips-test
files: '^[^.][^/]*\.yaml$' # matches non-hidden .yaml files at the top level only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be more efficient to use this to identify the go-fips packages that need to be parsed. If we can filter out packages at this level, we needn't spawn another python interpreter to run the check. Of course, if it might be the case that only a subpackage will match, then that won't work.

# Check if main package uses go-fips
main_uses_fips = False
main_has_test = False

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we shouldn't need to duplicate the code between main package parsing and subpkg parsing. See the shellcheck test, where it puts the main package and any sub package in a list, and just iterates through them all the same way. We should probably consider creating a library class that just does stuff like this for us so we can share it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants