Splitting out -api was a very early step where we thought it would be useful to split out api and models - #748 for details
I like your idea more:
Having API as a separate
To implement a separate RuleSet user will need some implementation to test with.
zally-rules.jar = Rule APIs, annotations and core rule framework.Having API as a separate
jar make sense in cases when something may have many different implementations. For example Java Servlet API is the separate API jar because web servers may have different implementations. Or Java Persistence API which has Hibernate, Toplink or JEE implementation (do not remember it’s name).To implement a separate RuleSet user will need some implementation to test with.
I've used build-and-run.sh to setup zally
but my server container is in un-healthy state
could you please help
[root@localhost zally]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5a7cb77af1eb zally_web-ui "node server.js" 13 minutes ago Up 2 minutes 0.0.0.0:8080->3000/tcp zally_web-ui_1
2718bf554728 zally_server "/bin/sh -c 'java $(…" 13 minutes ago Up 2 minutes (unhealthy) 0.0.0.0:8000->8000/tcp, 8080/tcp zally_server_1
0c15a58683a0 postgres:9.6 "docker-entrypoint.s…" 13 minutes ago Up 2 minutes 0.0.0.0:54321->5432/tcp zally_postgres_1
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5a7cb77af1eb zally_web-ui "node server.js" 13 minutes ago Up 2 minutes 0.0.0.0:8080->3000/tcp zally_web-ui_1
2718bf554728 zally_server "/bin/sh -c 'java $(…" 13 minutes ago Up 2 minutes (unhealthy) 0.0.0.0:8000->8000/tcp, 8080/tcp zally_server_1
0c15a58683a0 postgres:9.6 "docker-entrypoint.s…" 13 minutes ago Up 2 minutes 0.0.0.0:54321->5432/tcp zally_postgres_1
[root@localhost zally]# go build
app.go:4:2: cannot find package "github.com/urfave/cli" in any of:
/usr/lib/golang/src/github.com/urfave/cli (from $GOROOT)
/root/go/src/github.com/urfave/cli (from $GOPATH)
app.go:5:2: cannot find package "github.com/zalando/zally/cli/zally/commands" in any of:
/usr/lib/golang/src/github.com/zalando/zally/cli/zally/commands (from $GOROOT)
/root/go/src/github.com/zalando/zally/cli/zally/commands (from $GOPATH)
main.go:7:2: cannot find package "github.com/zalando/zally/cli/zally/domain" in any of:
/usr/lib/golang/src/github.com/zalando/zally/cli/zally/domain (from $GOROOT)
/root/go/src/github.com/zalando/zally/cli/zally/domain (from $GOPATH)
app.go:4:2: cannot find package "github.com/urfave/cli" in any of:
/usr/lib/golang/src/github.com/urfave/cli (from $GOROOT)
/root/go/src/github.com/urfave/cli (from $GOPATH)
app.go:5:2: cannot find package "github.com/zalando/zally/cli/zally/commands" in any of:
/usr/lib/golang/src/github.com/zalando/zally/cli/zally/commands (from $GOROOT)
/root/go/src/github.com/zalando/zally/cli/zally/commands (from $GOPATH)
main.go:7:2: cannot find package "github.com/zalando/zally/cli/zally/domain" in any of:
/usr/lib/golang/src/github.com/zalando/zally/cli/zally/domain (from $GOROOT)
/root/go/src/github.com/zalando/zally/cli/zally/domain (from $GOPATH)
unable to install go CLI
FWIW you can definitely ignore the "unhealthy" indicator - it's badly configured and can never report healthy - zalando/zally#1133
Hi All, have done the zally setup on windows machine and successfully able to run web ui on localhost:3000. As part of minor text changes on UI hav modified the bundle.js file located at \zally-webui\node_modules\zally-web-ui\src\client\public\assets, the changes are reflected fine.
The setup on AWS linux EC2 instance is also working fine however i am not able to do similar UI changes on ec2 after modifying the bundle.js file. After modifying the file i restarted both docker container and ec2 instance too but the changes are not reflected.
Please help to mitigate issue with bundle.js file, changes are not reflected on zally web ui. Is there any other file which can be modified under docker to modify the text.
Hi @roxspring on the UI page the text says "Check if your SWAGGER Schema conforms to Zalando's REST API Guidelines" this we want to modify as "Check below your Open API specs to conforms with REST API Guidelines" . Also the hyperlink for 'Rest API guidelines' we want to provide an internal link.
Hello!
I got a question concerning the swagger-zalando-extension. I have https://plugins.jetbrains.com/plugin/8347-swagger and https://plugins.jetbrains.com/plugin/11115-swagger-zalando-extensions- installed in IntelliJ (2019.3.3), furthermore running zally locally which I can curl on localhost:8000/api-violations and get proper violations with a wrong openapi spec. However, when I point the zalando intellij extension to my local zally, "nothing happens", i.e. the linter doesn't work from within Intellij. Any pointers what to check? Thank you!
I got a question concerning the swagger-zalando-extension. I have https://plugins.jetbrains.com/plugin/8347-swagger and https://plugins.jetbrains.com/plugin/11115-swagger-zalando-extensions- installed in IntelliJ (2019.3.3), furthermore running zally locally which I can curl on localhost:8000/api-violations and get proper violations with a wrong openapi spec. However, when I point the zalando intellij extension to my local zally, "nothing happens", i.e. the linter doesn't work from within Intellij. Any pointers what to check? Thank you!
Hi, I was going through the documentation and the source and couldn't find a rule for "MUST use HTTP methods correctly [148]" https://opensource.zalando.com/restful-api-guidelines/#148. Wasn't a rule implemented for that one and if so it is because it is too broad to implement from a rule?
Great tool!
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?