admin: migrate to centralized linting workflows

[hdamker-bot]

CAMARA Project Admin Update - Linting Migration

This pull request migrates this repository from local linting configuration to centralized linting workflows managed by the CAMARA project.

🔄 Migration Summary

Removed local linting artifacts:

• megalinter.yml
• spectral_oas_lint.yml
• .spectral.yml
• .yamllint.yaml
• Lint function scripts in /lint_function/

Added centralized workflows:

• spectral-oas-caller.yml - Spectral linting with CAMARA ruleset
• pr_validation_caller.yml - Comprehensive PR validation

✨ Benefits of Centralized Linting

1. Always Up-to-Date: Linting rules and workflows are automatically updated across all repositories
2. Consistent Standards: Ensures uniform code quality checks across all CAMARA APIs
3. Reduced Maintenance: No need to maintain linting configurations locally
4. Enhanced Features: Access to latest tooling improvements without manual updates
5. Simplified Configuration: Workflows reference the centralized tooling repository

📋 What This Means for You

• No action required for basic operation - workflows will run automatically
• All existing checks continue with improved reliability
• Custom configurations can be discussed with the Release Management team if needed

🔧 Technical Details

The new workflows reference reusable workflows from:
camaraproject/tooling/.github/workflows/

This ensures all repositories benefit from:

• Latest Spectral rules for OpenAPI validation
• Consistent PR validation checks
• Centralized rule management
• Automated tooling updates

👥 Next Steps for Codeowners

⚠️ Important: This PR introduces linting workflows that will validate repository content.

Note on Linting Checks: The linting workflows are currently not blocking - they will not prevent this PR (or future PRs) from being merged. However, it is highly recommended to:

• Fix all linting errors before merging
• Establish a practice of only merging PRs that pass linting checks successfully
• All linting errors must be addressed before creating a release

This approach maintains code quality while allowing flexibility during the transition period.

Before Merging This PR:

1. Review linting results in PR checks:

   • Check the "Checks" tab for workflow results
   • Note any linting errors or warnings reported

2. Fix linting errors (strongly recommended):

   • Address all OpenAPI specification issues (Spectral and yamllint errors)
   • Address all test definitions issues (gherkin-lint errors)
   • Push fixes to this PR branch to re-trigger validation
   • While not required for merge, fixing issues now prevents accumulation of technical debt

3. Approve and merge this PR 🚀

After Merge:

1. Establish linting best practices:

   • Although checks are not blocking, treat linting errors as issues to fix
   • Aim to merge only PRs where linting checks pass successfully
   • This maintains code quality standards and prevents regression
   • Remember: Linting errors must be fixed before any release can be created

2. Test with additional rules (optional):

   • Verify OpenAPI specification with lower severity rules (warnings, hints, info)
   • Go to Actions tab → "Caller for Spectral linting with CAMARA ruleset" → Run workflow
   • Check workflow logs - if needed create an issue to improve your API specification

3. Monitor future PRs:

   • Provide guidance to contributors on fixing linting issues
   • First PRs after this may reveal new edge cases
   • The Release Management team can assist with complex issues

💡Pro tip: Running the Spectral workflow manually NOW is highly recommended. This allows you to identify and fix issues proactively rather than discovering them when submitting your next feature PR!

---

🤖 Generated via project-admin workflow
Triggered by hdamker, executed via hdamker-bot

➡️ Next Steps: This PR should be reviewed, fixed as needed, approved, and merged by repository codeowners following standard review processes.

---

This is a manually triggered automated administrative update.

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.01s
✅ API	spectral	1		0	1.45s
✅ GHERKIN	gherkin-lint	1		0	0.32s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.66s
✅ YAML	yamllint	1		0	0.32s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[hdamker]

@camaraproject/home-devices-qod_codeowners: the error/issues within test definition file are only whitespace changes. Nevertheless would it be good to make a plan when this API will be updated towards the latest Commonalities. My expectation is that this happens latest within the Fall26 meta-release cycle, as the API wasn't updated since its release in Fall24.

[jpengar]

Fixed indentation errors. LGTM

[hdamker]

As this isn't anymore the "0.4.0" version I suggest to set version within API and Test definition to "wip" before merging the changes.

[jpengar]

As this isn't anymore the "0.4.0" version I suggest to set version within API and Test definition to "wip" before merging the changes.

@hdamker I can address that, but there are no plans to evolve this API and it is a candidate for archiving

[hdamker]

@jpengar Good to know ... in this case it is also an option "to do nothing" and keep the main branch untouched until there is a decision. The PR was created together with the ones for all Sandbox repositories, independent of their status beyond the fact that they hadn't yet the centralized linting.

[jpengar]

@jpengar Good to know ... in this case it is also an option "to do nothing" and keep the main branch untouched until there is a decision. The PR was created together with the ones for all Sandbox repositories, independent of their status beyond the fact that they hadn't yet the centralized linting.

@hdamker I think we can merge this PR as it is and leave the 'WIP' version change aside for the time being, until the process of archiving this API has been confirmed. This doesn't need to be a dependency, so we can close this topic.

[hdamker]

@hdamker I think we can merge this PR as it is and leave the 'WIP' version change aside for the time being, until the process of archiving this API has been confirmed. This doesn't need to be a dependency, so we can close this topic.

@jpengar +1 ... especially as the API definition isn't touched.

@hdamker agrees to merge the PR as is in #75 (comment)