A customized fork from Zalando's awesome Zally. It enforces some automatically checkable rules from SBB's API Principles.
Zally is a quality assurance tool. It’s a linter for OpenAPI specifications, which:
Its standard configuration will check your APIs against the rules defined in Zalando’s RESTful Guidelines, but anyone can use it out-of-the-box.
Zally’s easy-to-use CLI uses the server in the background so that you can check your API on the spot. It also features an intuitive Web UI that shows implemented rules and lints external files and (with its online editor) API definitions.
x-zally-ignore
extension)Trying out Zally is easy. You can build and run the whole Zally stack (web-ui, server and database) by executing:
./build-and-run.sh
Web UI is accessible on http://localhost:8080
; Zally server on http://localhost:8000
Please consult the following documents for more information:
Zally welcomes contributions from the open source community. To get started, take a look at our contributing guidelines. Then check our Project Board and Issues Tracker for ideas.
For Zally version 1.5, we’re focusing on:
If you have ideas for these items, please let us know.
Feel free to join our Gitter room or contact one of the maintainers directly.
Zally is not the only linter for OpenAPI v2 and v3. There is an article comparing different OpenAPI linters.
So why should you choose Zally?
MIT license with an exception. See license file.
OSSRH_JIRA_USERNAME
and OSSRH_JIRA_PASSWORD
environment variables to access Maven Central Repo are
configuredrelease-<release-version>
.server/gradle.properties
from -SNAPSHOT
to a final version.cd server
./gradlew clean build publishAllPublicationsToMavenRepository
server/gradle.properties
with the release versionshell script
git tag v<release-version> -m "Version <release-version>"
Bump version in server/gradle.properties
to the next -SNAPSHOT
release
branch and tag
shell script
git push origin
git push origin <tag-name>