quiet_quality 1.0.2 → 1.0.3

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 637f00e52eae2e4b0cee2cf1e4c76b17595e7ac4a59aa2568ae0eee17b4a7d4c
4
- data.tar.gz: a45040a9379e05a86e87d01f274ea044084c0af13e65c6d00b7c664dde33afc6
3
+ metadata.gz: d7372d3c4b395adb2890c54270426bf92b9a2a9e2669ef27d5145eda776d1072
4
+ data.tar.gz: 5877277009b82e9685e62f8f8a1f17aec823faaad93c3c8e40dcb7f2640d0e7c
5
5
  SHA512:
6
- metadata.gz: f0666d43b98ea76f55b8dab0d3d38cc786f8c9a750b14dee1eff2c4a13ee7da94f94a83757fe643efa1d448197583864c02c34c0e49b7adda5d790d51eaad0ef
7
- data.tar.gz: 3cd316700e1abda994248dbd5959d242ccec0551d2f516212671fee07df1cfa5d36a9b53137ea299cce03b6bbbab9e328ba38132be6148d8626a7e4b1d71e346
6
+ metadata.gz: 4c860d24410fd6a03390e726fdc699113f3d0c21b722e12ccf564c666b5708690d8ed90a092448f3942496a47331e10b3d3bb7580ba2e0feeafbf74ea60bdb03
7
+ data.tar.gz: 67b89da10e8fc43370d586d9282776c2f1f23a0fa4fcfbea5bfd596ab6520cca7c9319731fd960c63dc04e36ab7021b83e27497d52f2e10b8cdd9ef8a39ad394
@@ -29,3 +29,6 @@ jobs:
29
29
 
30
30
  - name: Run rubocop (complexity checks)
31
31
  run: bundle exec rubocop --parallel
32
+
33
+ - name: Run markdownlint
34
+ run: bundle exec mdl .
data/.mdl_rules.rb ADDED
@@ -0,0 +1,2 @@
1
+ all
2
+ rule "MD013", ignore_code_blocks: true
data/.mdlrc ADDED
@@ -0,0 +1,2 @@
1
+ style File.expand_path("../.mdl_rules.rb", __FILE__)
2
+ git_recurse true
data/README.md CHANGED
@@ -1,34 +1,155 @@
1
1
  # QuietQuality
2
2
 
3
- Work in Progress
3
+ There are a lot of different tools that you need to run as you work - possibly
4
+ before you commit, or before you make a pull request, or after you make changes
5
+ to a class.. style checkers, tests, complexity metrics, static analyzers, etc.
6
+ QuietQuality can make that simpler and faster!
4
7
 
5
- But essentially, QuietQuality is intended for two purposes:
8
+ Or you may have a huge existing project, that's not _fully_ in compliance with
9
+ your style guides, but you want to avoid introducing _new_ issues, without
10
+ having to first resolve all of the existing ones. QuietQuality can help with
11
+ that too.
6
12
 
7
- 1. Let you conveniently run tools like rubocop, rspec, and standard against the _relevant_
8
- files locally (the files that have changed locally relative to the default branch)
9
- 2. Let you run those tools in CI (probably github actions) and annotate any issues found
10
- with _new or modified_ code, without bothering you about existing issues that you didn't
11
- touch.
13
+ ## Tool Support
12
14
 
15
+ So far, we have support for the following tools:
13
16
 
14
- Basic usage examples:
17
+ * rubocop
18
+ * standardrb
19
+ * rspec
20
+ * haml-lint
21
+ * brakeman (though there's no way to run this against only changed files)
15
22
 
23
+ Supporting more tools is relatively straightforward - they're implemented by
24
+ wrapping cli invocations and parsing output files (which overall seem to be much
25
+ more stable interfaces than the code interfaces to the various tools), and each
26
+ tool's support is built orthogonally to the others, in a
27
+ `QuietQuality::Tools::[Something]` namespace, with a `Runner` and a `Parser`.
28
+
29
+ ## Local Usage Examples
30
+
31
+ Working locally, you'll generally want to commit a `.quiet_quality.yml`
32
+ configuration file into the root of your repository - it'll specify which tools
33
+ to run by default, and how to run them (whether you want to only run each tool
34
+ against the _changed files_, whether to _filter_ the resulting _messages_ down
35
+ to only those targeting lines that have been changed), and allows you to specify
36
+ the _comparison branch_, so you don't have to make a request to your origin
37
+ server every time you run the tool to see whether you're comparing against
38
+ `master` or `main` in this project.
39
+
40
+ If you have a configuration set up like that, you might have details specified
41
+ for `rubocop`, `rspec`, `standardrb`, and `brakeman`, but have only `rubocop`,
42
+ `standardrb`, and `rspec` set to run by default. That configuration file would
43
+ look like this (you can copy it from [here](docs/example-config.yml)):
44
+
45
+ ```yaml
46
+ ---
47
+ default_tools: ["standardrb", "rubocop", "rspec"]
48
+ executor: concurrent
49
+ comparison_branch: main
50
+ changed_files: true
51
+ filter_messages: true
52
+ brakeman:
53
+ changed_files: false
54
+ filter_messages: true
16
55
  ```
17
- # you have five commits in your feature branch and 3 more files changes but not committed.
18
- # this will run rubocop against all of those files.
19
- qq rubocop
20
-
21
- # run rspec against the changed specs, and annotate any failing specs (well, the first 10
22
- # of them) against the commit using github's inline output-based annotation approach. Which
23
- # will of course only produce actual annotations if this happens to have been run in a
24
- # github action.
25
- qq rspec --annotate=github_stdout
26
-
27
- # run standardrb against all of the files (not just the changed ones). Still only print out
28
- # problems to lines that have changed, so not particularly useful :-)
29
- qq standard --all --incremental
30
-
31
- # run all of the tools against the entire repository, and print the first three messages
32
- # out for each tool.
33
- qq all --all --full --limit-per-tool=3
56
+
57
+ Then if you invoke `qq`, you'll see output like this:
58
+
59
+ ```bash
60
+ qq
61
+ --- Passed: standardrb
62
+ --- Passed: rubocop
63
+ --- Passed: rspec
64
+ ```
65
+
66
+ But if you want to run brakeman, you could call `qq brakeman`:
67
+
68
+ ```bash
69
+ ❯ qq brakeman
70
+ --- Failed: brakeman
71
+
72
+
73
+ 2 messages:
74
+ app/controllers/articles_controller.rb:3 [SQL Injection] Possible SQL injection
75
+ app/controllers/articles_controller.rb:11 [Remote Code Execution] `YAML.load` called with parameter value
76
+
34
77
  ```
78
+
79
+ ## CI Usage Examples
80
+
81
+ Currently, QuietQuality is most useful from GitHub Actions - in that context, it's
82
+ possible to generate nice annotations for the analyzed commit (using Workflow
83
+ Actions). But it can be used from other CI systems as well, you just won't get
84
+ nice annotations out of it (yet).
85
+
86
+ For CI systems, you can either configure your execution entirely through
87
+ command-line arguments, or you can create additional configuration files and
88
+ specify them on the command-line.
89
+
90
+ Here is an invocation that executes rubocop and standardrb, expecting the full
91
+ repository to pass the latter, but not the former:
92
+
93
+ ```bash
94
+ qq rubocop standardrb \
95
+ --all-files --changed-files rubocop \
96
+ --unfiltered --filter-messages rubocop \
97
+ --comparison-branch main \
98
+ --no-config \
99
+ --executor serial \
100
+ --annotate-github-stdout
101
+ ```
102
+
103
+ Note the use of `--no-config`, to cause it to _not_ automatically load the
104
+ `.quiet_quality.yml` config included in the repository.
105
+
106
+ Alternatively, we could have put all of that configuration into a config file
107
+ like this:
108
+
109
+ ```yaml
110
+ # config/quiet_quality/linters_workflow.yml
111
+ ---
112
+ default_tools: ["standardrb", "rubocop"]
113
+ executor: serial
114
+ comparison_branch: main
115
+ changed_files: false
116
+ filter_messages: false
117
+
118
+ rubocop:
119
+ changed_files: true
120
+ filter_messages: true
121
+ ```
122
+
123
+ And then run `qq -C config/quiet_quality/linters_workflow.yml`
124
+
125
+ ## Available Options
126
+
127
+ The configuration file supports the following _global_ options (top-level keys):
128
+
129
+ * `executor`: 'serial' or 'concurrent' (the latter is the default)
130
+ * `annotator`: none set by default, and `github_stdout` is the only supported
131
+ value so far.
132
+ * `comparison_branch`: by default, this will be _fetched_ from git, but that
133
+ does require a remote request. You should set this, it saves about half a
134
+ second. This is normally 'main' or 'master', but it could be 'trunk', or
135
+ 'develop' - it is the branch that PR diffs are _against_.
136
+ * `changed_files`: defaults to false - should tools be run against only the
137
+ files that have changed, or against the entire repository? This is the global
138
+ setting, but it is also settable per tool.
139
+ * `filter_messages`: defaults to false - should the resulting messages that do
140
+ not refer to lines that were changed or added relative to the comparison
141
+ branch be skipped? Also possible to set for each tool.
142
+
143
+ And then each tool can have an entry, within which `changed_files` and
144
+ `filter_messages` can be specified - the tool-specific settings override the
145
+ global ones.
146
+
147
+ ### CLI Options
148
+
149
+ The same options are all available on the CLI, plus some additional ones - run
150
+ `qq --help` for a detailed list of the options, but the notable additions are:
151
+
152
+ * `--help/-H`: See a list of the options
153
+ * `--no-config/-N`: Do _not_ load a config file, even if present.
154
+ * `--config/-C` load the supplied config file (instead of the detected one, if
155
+ found)
@@ -0,0 +1,9 @@
1
+ ---
2
+ default_tools: ["standardrb", "rubocop", "rspec"]
3
+ executor: concurrent
4
+ comparison_branch: main
5
+ changed_files: true
6
+ filter_messages: true
7
+ brakeman:
8
+ changed_files: false
9
+ filter_messages: true
@@ -11,11 +11,16 @@ module QuietQuality
11
11
  end
12
12
 
13
13
  def outcome
14
- @_outcome ||= runner.invoke!
14
+ @_outcome ||= Tools::Outcome.new(
15
+ tool: runner_outcome.tool,
16
+ output: runner_outcome.output,
17
+ logging: runner_outcome.logging,
18
+ failure: messages.any?
19
+ )
15
20
  end
16
21
 
17
22
  def failure?
18
- messages.any?
23
+ outcome.failure?
19
24
  end
20
25
 
21
26
  def messages
@@ -30,6 +35,10 @@ module QuietQuality
30
35
 
31
36
  attr_reader :changed_files, :tool_options
32
37
 
38
+ def runner_outcome
39
+ @_runner_outcome ||= runner.invoke!
40
+ end
41
+
33
42
  def limit_targets?
34
43
  tool_options.limit_targets?
35
44
  end
@@ -44,7 +53,7 @@ module QuietQuality
44
53
  end
45
54
 
46
55
  def parser
47
- @_parser ||= tool_options.parser_class.new(outcome.output)
56
+ @_parser ||= tool_options.parser_class.new(runner_outcome.output)
48
57
  end
49
58
 
50
59
  def relevance_filter
@@ -1,3 +1,3 @@
1
1
  module QuietQuality
2
- VERSION = "1.0.2"
2
+ VERSION = "1.0.3"
3
3
  end
@@ -41,4 +41,5 @@ Gem::Specification.new do |spec|
41
41
  spec.add_development_dependency "standard", "~> 1.28"
42
42
  spec.add_development_dependency "rubocop", "~> 1.50"
43
43
  spec.add_development_dependency "debug"
44
+ spec.add_development_dependency "mdl", "~> 0.12"
44
45
  end
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: quiet_quality
3
3
  version: !ruby/object:Gem::Version
4
- version: 1.0.2
4
+ version: 1.0.3
5
5
  platform: ruby
6
6
  authors:
7
7
  - Eric Mueller
@@ -136,6 +136,20 @@ dependencies:
136
136
  - - ">="
137
137
  - !ruby/object:Gem::Version
138
138
  version: '0'
139
+ - !ruby/object:Gem::Dependency
140
+ name: mdl
141
+ requirement: !ruby/object:Gem::Requirement
142
+ requirements:
143
+ - - "~>"
144
+ - !ruby/object:Gem::Version
145
+ version: '0.12'
146
+ type: :development
147
+ prerelease: false
148
+ version_requirements: !ruby/object:Gem::Requirement
149
+ requirements:
150
+ - - "~>"
151
+ - !ruby/object:Gem::Version
152
+ version: '0.12'
139
153
  description: |
140
154
  Allow your CI to notice and/or annotate new quality issues, despite the presences of
141
155
  many pre-existing issues in your codebase.
@@ -150,6 +164,8 @@ files:
150
164
  - ".github/workflows/linters.yml"
151
165
  - ".github/workflows/rspec.yml"
152
166
  - ".gitignore"
167
+ - ".mdl_rules.rb"
168
+ - ".mdlrc"
153
169
  - ".quiet_quality.yml"
154
170
  - ".rspec"
155
171
  - ".rubocop.yml"
@@ -157,6 +173,7 @@ files:
157
173
  - LICENSE
158
174
  - README.md
159
175
  - bin/qq
176
+ - docs/example-config.yml
160
177
  - lib/quiet_quality.rb
161
178
  - lib/quiet_quality/annotation_locator.rb
162
179
  - lib/quiet_quality/annotators.rb