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. Linting errors will block this PR from merging until resolved.

Before This PR Can Be Merged:

1. Review linting results in PR checks:

   • Check the "Checks" tab for workflow results
   • All linting errors must be resolved before merge is possible

2. Fix linting errors directly in this PR:

   • 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
   • Repeat until all checks pass successfully

Approve and merge this PR 🚀

After Successful Merge:

1. Monitor the new linting system:

   • All future PRs will be subject to the same linting requirements
   • Contributors will need to fix linting issues before their PRs can merge
   • This ensures code quality standards are maintained going forward

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:

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

💡Pro tip: Running the Spectral workflow manually NOW is highly recommended. This allows you to 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.68s
✅ GHERKIN	gherkin-lint	1		0	0.35s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.68s
✅ YAML	yamllint	1		0	0.54s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[albertoramosmonagas]

Hi @hdamker ,

We’ve managed to reduce all validation errors down to the following:

/github/workspace/code/Test_definitions/predictive-connectivity-data.feature  
  51     Element Scenario too long: actual 16, expected 15                               scenario-size  
  64     Step name is too long. Length of 224 is longer than the maximum allowed: 190    name-length  
  84     Element Scenario too long: actual 18, expected 15                               scenario-size  
 106     Element Scenario too long: actual 21, expected 15                               scenario-size  
 173     Element Scenario too long: actual 16, expected 15                               scenario-size  
 189     Step name is too long. Length of 197 is longer than the maximum allowed: 190    name-length  
 467     Step name is too long. Length of 191 is longer than the maximum allowed: 190    name-length  

We’ve already shortened or refactored wherever possible, but in these remaining cases, reducing either the step names or the scenario length would compromise test coverage or clarity. I’ve tried several approaches and couldn’t find a clean way to simplify further.

Would it be reasonable to suggest in the PR that these two rules (name-length and scenario-size) could be treated as warnings instead?

Let me know what you think!

Best,
Alberto

[hdamker]

We’ve already shortened or refactored wherever possible, but in these remaining cases, reducing either the step names or the scenario length would compromise test coverage or clarity. I’ve tried several approaches and couldn’t find a clean way to simplify further.

Would it be reasonable to suggest in the PR that these two rules (name-length and scenario-size) could be treated as warnings instead?

@albertoramosmonagas I'm not an expert for Gherkin files, therefore I don't know how important the checks are (maybe as tools using the code have similar restrictions). I would propose that you ask the question within a discussion or issue in Commonalities where the rules are defined.

Short-term you might just ignore the errors, the check is not blocking the PR merge.

Here some hints how to handle the points:

1. Scenario too long (scenario-size)

• Split long scenarios into smaller, more focused scenarios. If a scenario tests multiple things, break it into separate scenarios for each aspect.
• Move repeated setup steps to the Background section if possible.
• Use scenario outlines with examples for similar steps that only differ by input values.

2. Step name too long (name-length)

• Shorten step descriptions by removing unnecessary details or splitting complex steps into multiple, simpler steps.
• Use variables or references (e.g., refer to a schema or property by a short name instead of a full path).
• Move explanations to comments above the step, keeping the step itself concise.

For example: @predictive_connectivity_data_05_async_operation_not_completed_scenario could be split into two: one for the initial async request and one for the callback validation.
For using a scenario outline is here an example from QualityOnDemand: camaraproject/QualityOnDemand@2109425

[albertoramosmonagas]

We have reduced the errors and now there are only a few remaining related to scenario size and name length, which we consider almost impossible to reduce without compromising part of the tests. For my part, it is approved because the check is not blocking the PR merge.

I am awaiting your approval, @eric-murray, to merge and move on to the public version.

[hdamker]

We have reduced the errors and now there are only a few remaining related to scenario size and name length, which we consider almost impossible to reduce without compromising part of the tests. For my part, it is approved because the check is not blocking the PR merge.

I am awaiting your approval, @eric-murray, to merge and move on to the public version.

If you merge this PR, you should then still fix the issues in a separate issue and PR. The issues will show up in in every PR, including the release PR - where the ReleaseManagement will insist either to fix them or to get a decision from Commonalities to relax the rules. On a personal note I don't agree that the issues can't be resolved without compromising part of the tests, it needs just some refactoring of the scenarios.