Question: What are best practices to adapt a ruleset?
In terms of adapting zally rules we took a few approaches, depending on requirements, which may work for you too:
- Submit patches to Zally to make existing rules more configurable, and run with your own config. The Zalando team are generally pretty receptive to this sort of thing, but can lead to odd situations where an "X must have Y format" rule becomes reconfigured to require "Z" format and the Zalando folks don't want to change their rule's wording.
- Where rules didn't really make sense to be public then I maintained some internal rules in my fork. This is a little painful when refactoring are performed upstream and need to be accounted for in the fork - but mostly the refactoring were mine so I had a head start and didn't suffer too badly :).
That last approach was my default at first, but I wish I'd submitted more of them upstream from the start. There was talk of creating a third ruleset in the master branch for my in-house, and I got clearance from work but didn't get time to do it and have since moved to a different company (not even doing any REST APIs).
If the Zalando folk are up for it then I'd be very tempted to recommend this approach and create a "SBB" ruleset in the zally master codebase, with your fork just changing the config. I think it'd be good for cross pollination of ideas, but it's also potentially painful if fixes for in-house rules are gated by PR reviews from Zalando.
The only point of confusion I had was when trying to change the snake-case to camelCase rule. The rule suggests that it's handle there, actually it's in the 'reference.conf' in zally-core. I resolved it by copying the CaseChecker config to the 'reference.conf' of my ruleset, so that I didn't to change the anything in zally-core.
Thus, it might be a slight improvement to document this dependency by documenting that in the rules dealing with cases and/or to add the CaseChecker config to the zalando-ruleset directory.
If this is the way to go, I can propose a patch.
Hi Zally team, I just cloned latest zally from master. And got compileKotlinTest failure as above screenshot.
Could you please help me figure out why de.zalando.zally.statistic.ReviewStatistics cannot be resolved?
Hii Pasan, can you be more specific about which components in Zally you are referring to? If you talk about the server and web-ui: we are currently running these as Docker images in Kubernetes. The server is running with 1.5GB since we are to lazy to monitor, however 756MB should be enough when I have a second look at the actual usage data. The web-ui is running with 128MB sufficiently stable since a long time.
Hi Tronje, thanks for getting back soon. The Zally components were the web-ui and the server. And yeah I can confirm those are ranges when I monitor the existing setup we have. I wanted to confirm the numbers before setting out the resource allocation. Again thanks a lot!
I will update
config4k:0.4.1 to config4k:0.4.2 anyways.
Just wanted to send a large thanks for the Zally project and a small notification that I created a stand-alone Maven plugin for Zally available here: https://github.com/ethlo/zally-maven-plugin
Hi all,
I was trying to build the docker image for web UI and run it for production. But since Dockerfile doesn't contain explicit webpack build steps, when running a container from the built image, front-end throws a
I was wondering if the explicit webpack build isn't added as a step in the WEB UI Dockerfile for a specific reason?
I was trying to build the docker image for web UI and run it for production. But since Dockerfile doesn't contain explicit webpack build steps, when running a container from the built image, front-end throws a
Uncaught SyntaxError: Unexpected token '<'. I think this is because it can't locate the bundle.jsI was wondering if the explicit webpack build isn't added as a step in the WEB UI Dockerfile for a specific reason?
@AnjaniParameswari hi, if you build the project with Maven, you can use plugin written by @ethlo for failing build in case of rule violations
https://github.com/ethlo/zally-maven-plugin#usage
https://github.com/ethlo/zally-maven-plugin#usage
@ethlo hi, excellent, thank you. I also wrote a Maven plugin zalando/zally#1300, but didn't release it. Great that you finished and published your version
Hi - I'm trying to curl for validations of an open api spec... but it errors with "400 An api definition is missing in api_definition field". Here's a snippet showing what I'm doing:
curl -X POST \
-H "Content-Type: application/x-yaml" \
--data "$(cat ~/restful-apis/abc/v1/api-spec.yml)" \
http://localhost:8000/api-violations/
does the server not support v3 specs in yaml? I guess it do .. and I probably need to hint it somehow :).... Any ideas? (sorry for the nOOb question)
Hi Nicky, you need to send a linting request with an encapsulating object - not just a specification. See https://github.com/zalando/zally/blob/master/server/zally-server/src/main/resources/api/zally-api.yaml
Hello Guys, how can i use rules ignore functionality with zally-client? I see source *.go code in github, but i didn't find anything like "x-zally-ignore". I know that i can send direct request to zally-server with ignoreRules param in body and this work. But i hope to do this with zally-client
Hi Zally team, I am working on deploying Zally on zallydemo.com so that developers can use this free tool for hitting the endpoint with any API client and get the violations. I created an EC2 instance and I am running into issues. I am getting: This generated password is for development use only. Your security configuration must be updated before running your application in production message. Can you point me to the right resource to resolve this issue?
