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
• .gherkin-lintrc
• 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: ❌ ERROR

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.01s
✅ API	spectral	1		0	2.14s
❌ GHERKIN	gherkin-lint	2		1	0.7s
✅ JSON	jsonlint	1		0	0.16s
⚠️ JSON	prettier	1		1	0.38s
✅ JSON	v8r	1		0	2.72s
✅ REPOSITORY	git_diff	yes		no	0.39s
✅ REPOSITORY	secretlint	yes		no	3.74s
✅ YAML	yamllint	1		0	0.54s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[hdamker]

@camaraproject/edge-cloud_codeowners The centralized linting includes also the test definition files, hence the failed check.

It might make sense to do the clean-up and proper naming of the API and test definition files first, or even better to move the remaining API definitions with their test definition also in into own dedicated repositories.

[JoseMConde]

Thanks @hdamker , we are already trying to clean up the repository, removing and reordering the different files, we have some PRs open related with this topic.
We would like to present Edge Application Management for Spring26, is the only API that is still on the general repository, Do you think, for the release will be needed to create a dedicated repository for this API??

[hdamker]

We would like to present Edge Application Management for Spring26, is the only API that is still on the general repository, Do you think, for the release will be needed to create a dedicated repository for this API??

@JoseMConde My view is that it was the much cleaner solution to split also the last API out into a new repository and keep the EdgeCloud repository either only for documentation across the EdgeCloud related APIs or even archive it completely at some point of time.