ci: add workflow to validate specs against Swagger Validator

[ChiragAgg5k]

Summary

• Adds .github/workflows/ci.yml that runs on push and PR to main
• Finds all JSON spec files under specs/ and POSTs each to https://validator.swagger.io/validator/debug
• Parses the response for schemaValidationMessages with level == "error" and fails the job if any are found
• Reports a per-file pass/fail summary and a final count

Test plan

• Verify the workflow triggers on PR
• Confirm all current specs pass validation
• Confirm the job fails if a broken spec is introduced

Summary by CodeRabbit

• Chores
  • Added an automated CI workflow that validates JSON specifications on every push and pull request to main, reports per-spec and aggregate results, and fails builds if validation errors are found.
• Documentation
  • Updated the README badge from Twitter to X.

[coderabbitai]

Warning

Rate limit exceeded

@ChiragAgg5k has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 23 minutes and 48 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Walkthrough

A new GitHub Actions workflow (.github/workflows/ci.yml) is added to validate JSON specifications. It triggers on push and pull requests to the main branch, checks out the repository, posts each JSON file in the specs/ directory to the Swagger Validator debug endpoint, parses responses with jq to count schema validation errors, prints per-spec PASS/FAIL results and aggregate totals, and fails the workflow if any spec fails. Additionally, the README badge referencing Twitter was replaced with an X badge.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and specifically describes the main change: adding a CI workflow to validate specs against Swagger Validator.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch add-ci-workflow

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

.github/workflows/ci.yml (1)

21-21: External service dependency with no retry logic

The entire workflow is gated on validator.swagger.io being reachable. A single transient failure on any spec file fails (or silently passes, before the fix above) the CI run with no recourse.

Consider adding --retry 3 --retry-delay 5 --retry-all-errors to the curl invocation. This handles transient network hiccups without changing the failure semantics:

-            response=$(curl -s --fail-with-body --max-time 30 -X POST \
+            response=$(curl -s --fail-with-body --max-time 30 --retry 3 --retry-delay 5 --retry-all-errors -X POST \

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml at line 21, The workflow currently depends on
VALIDATOR_URL and calls curl against validator.swagger.io with no retry, so
transient network failures can break CI; update the curl invocation that uses
the VALIDATOR_URL variable to add retry logic (e.g., append the flags --retry 3
--retry-delay 5 --retry-all-errors) so curl will retry transient errors while
preserving failure semantics if the service is truly unreachable.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/ci.yml:
- Line 41: The workflow currently feeds find results into the while loop (done <
<(find specs -name "*.json" | sort)) and can silently succeed when no spec files
are found; modify the script to capture the find output into a variable or array
first, check if it's empty (e.g., after running find into SPECS or an array),
and if empty emit an error/notice and exit non‑zero (or set FAILED>0) before
entering the while loop so PASSED/FAILED cannot both be zero and produce a
false-positive CI pass; update the code paths that reference PASSED and FAILED
to respect this early exit.
- Around line 26-40: The validation step silently marks specs as PASSED on HTTP
4xx/5xx or network errors; update the curl invocation that sets response to
include the --fail-with-body flag and add an inline per-file failure handler on
the curl command (the || { ...; continue; } pattern) so that when curl exits
non-zero you log the HTTP/network error, increment FAILED, and continue to the
next spec without terminating the whole script under set -e; ensure you
reference the existing variables response, spec_file, VALIDATOR_URL and the
counters PASSED/FAILED and keep the subsequent jq-based error parsing of
schemaValidationMessages unchanged.

---

Nitpick comments:
In @.github/workflows/ci.yml:
- Line 21: The workflow currently depends on VALIDATOR_URL and calls curl
against validator.swagger.io with no retry, so transient network failures can
break CI; update the curl invocation that uses the VALIDATOR_URL variable to add
retry logic (e.g., append the flags --retry 3 --retry-delay 5
--retry-all-errors) so curl will retry transient errors while preserving failure
semantics if the service is truly unreachable.