jslint-like test for javascript files
Details
Details
- Reviewers
vanmeeuwen
Run this script in drydocker after each commit. On errors, the script terminates with exit code 1, on success with 0
Diff Detail
Diff Detail
- Repository
- rQA stick
- Branch
- master
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
The used closure compiler is hosted here: https://github.com/google/closure-compiler
License is Apache 2.0 and it requires a JVM to run.
Comment Actions
As our groupware plugins still need to run on legacy browsers like FF 3.6, the language is set to ECMASCRIPT3. Once that requirement is dropped, this can be changed to ECMASCRIPT5.
Comment Actions
What value does using this compiler represent specifically? Is it exactly the same code as would otherwise be run in, say, a Chrome or Chromium browser? Is it by far the best? The only one? The only one that can verify compatibility with browsers?
The routine to iterate over files and execute a java command with options is probably one that is generic across a variety of software development projects and should be considered for a function in (a new file) drydocker/generic_jslint.sh.
The linting of JavaScript is supposed to occur as part of test_build.sh, where also the PHP linting is executed.
This should have been outlined before the work would have been started, such that T95 (the epic) results in sizable work items T96, T97, T98 and possibly more later.
| drydocker/roundcubemail-plugins-kolab/test_jslint.sh | ||
|---|---|---|
| 5 | This zip file should be added to the Docker images individually, or tests might fail because of conditions that have little to do with code issues (and mark the repository as not-releasable). | |
| 12 | Redirecting the output to /dev/null is not helping the consumer of the build result pages appreciate the messages emitted by this compiler. Consider not redirecting the output at all. | |
| 13 | Please just add $? to $retval. | |
| 15 | This is not the standard output format used elsewhere. | |
| 17 | This is not the standard output format used elsewhere. | |
Comment Actions
It's the only one I know :-)
The routine to iterate over files and execute a java command with options is probably one that is generic across a variety of software development projects and should be considered for a function in (a new file) drydocker/generic_jslint.sh.
There's some additional filtering (grep -v viewer) in there. But sure, this could be packed into a generic function.
| drydocker/roundcubemail-plugins-kolab/test_jslint.sh | ||
|---|---|---|
| 5 | I'm not familiar with the ways docker works or how such tests should be constructed. Please advise! | |
| 12 | This would print the entire content of the compiled script to stdout. Not what we want if just checking for compilation errors. | |
| 15 | Sorry, I'm not aware of any standard output formats... | |
Comment Actions
| drydocker/roundcubemail-plugins-kolab/test_jslint.sh | ||
|---|---|---|
| 5 | The trick is to resolve as many external dependencies while building the image from which containers are ran, rather than to continue to depend on them within each container spawned from the image. The repository for that is a different one though: rDO. | |
| 12 | Indeed, it does not do that on my workstation. Redirect to /dev/null it is. | |
| 15 | A function provided by the entry point of the Docker images ensures that a command being run outputs its stdout to a copy of the shell stdout, and return an exit code in proper form. It also calls a function to echo to stdout and save to a report file, the status message including a commit id. One might call this the more standard output format. | |