how_is 12.0.0 → 13.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.travis.yml +1 -3
- data/CHANGELOG.md +21 -2
- data/ISSUES.md +86 -0
- data/README.md +3 -3
- data/design/01-functionality.md +155 -0
- data/design/02-implementation.md +18 -0
- data/exe/how_is +17 -8
- data/how_is.gemspec +1 -6
- data/lib/how_is/analyzer.rb +1 -1
- data/lib/how_is/cli.rb +0 -86
- data/lib/how_is/fetcher.rb +3 -0
- data/lib/how_is/pulse.rb +1 -1
- data/lib/how_is/report/base_report.rb +1 -1
- data/lib/how_is/report/html.rb +1 -1
- data/lib/how_is/report/json.rb +1 -1
- data/lib/how_is/report.rb +1 -1
- data/lib/how_is/version.rb +2 -2
- data/lib/how_is.rb +91 -4
- metadata +8 -33
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 7e016f1b7f3e89bf467f6ecedf72a5381ddb1efa
|
4
|
+
data.tar.gz: b5a681c62fac3083352a7b998d8dc37e74edd3bd
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 0a99668e69ed19eacd4e430be5571600fdf55589a5a7261120ae03d8d3af43aa95b445f7385f7f3a4be443df3f3173ec79b639ab9c798944e8a1671d67595150
|
7
|
+
data.tar.gz: 37c55d12b41138e5fd73aa6e8fb0070de3a8999805a096836575140d70548cc73861cbe35847681aced55c34af0c4e86c384256f89fe6fe67381a90d363e2483
|
data/.travis.yml
CHANGED
data/CHANGELOG.md
CHANGED
@@ -9,10 +9,26 @@ this project adheres to [Semantic Versioning](http://semver.org).
|
|
9
9
|
|
10
10
|
(Nothing so far.)
|
11
11
|
|
12
|
+
## [v13.0.0]
|
13
|
+
|
14
|
+
This release ([snapshot](https://github.com/how-is/how_is/tree/v13.0.0))
|
15
|
+
largely focused on an API redesign.
|
16
|
+
|
17
|
+
Pull requests for this release can be [viewe on
|
18
|
+
GitHub](https://github.com/how-is/how_is/pulls?utf8=&q=is%3Apr%20created%3A2016-12-12..2017-02-09).
|
19
|
+
|
20
|
+
### Changed
|
21
|
+
|
22
|
+
* API overhaul. ([#115](https://github.com/how-is/how_is/issues/115), [#117](https://github.com/how-is/how_is/pull/117))
|
23
|
+
* Raise an exception/show a CLI warning if the provided repository name
|
24
|
+
isn't in the "user/repo" format.
|
25
|
+
([#98](https://github.com/how-is/how_is/pull/98))
|
26
|
+
|
12
27
|
## [v12.0.0]
|
13
28
|
|
14
|
-
This release
|
15
|
-
|
29
|
+
This release ([snapshot](https://github.com/how-is/how_is/tree/v12.0.0))
|
30
|
+
largely focused on refactoring and developer experience improvements
|
31
|
+
(e.g. adding Rake tasks and improving the generated JSON and HTML).
|
16
32
|
|
17
33
|
Pull Requests for this release can be [viewed on
|
18
34
|
GitHub](https://github.com/how-is/how_is/pulls?utf8=&q=is%3Apr%20created%3A2016-11-11..2016-12-11).
|
@@ -35,6 +51,9 @@ GitHub](https://github.com/how-is/how_is/pulls?utf8=&q=is%3Apr%20created%3A2016-
|
|
35
51
|
|
36
52
|
## [11.0.0]
|
37
53
|
|
54
|
+
This release ([snapshot](https://github.com/how-is/how_is/tree/v11.0.0))
|
55
|
+
removed PDF reports, handles more edge cases, and improves tests.
|
56
|
+
|
38
57
|
### Added
|
39
58
|
|
40
59
|
- Document Ruby API
|
data/ISSUES.md
ADDED
@@ -0,0 +1,86 @@
|
|
1
|
+
# Issue Management
|
2
|
+
|
3
|
+
The goal of issue management is to organize the work that needs to be
|
4
|
+
done when working on a project, by allowing users to report bugs,
|
5
|
+
request features or documentation, and start discussions.
|
6
|
+
|
7
|
+
To simplify that task, issues have _labels_. The purpose of labels is to
|
8
|
+
group issues in ways developers find useful. The obvious examples being
|
9
|
+
bug reports and feature requests.
|
10
|
+
|
11
|
+
This document is intended as a guide to help you understand what labels
|
12
|
+
on a given issue mean, or to help you choose labels for a new issue.
|
13
|
+
|
14
|
+
Labels on this repository are grouped, using the section before the
|
15
|
+
first colon in an issue name.
|
16
|
+
|
17
|
+
Issue groups:
|
18
|
+
|
19
|
+
* [(ungrouped)](#ungrouped)
|
20
|
+
* [category](#categories)
|
21
|
+
* [closed](#closed)
|
22
|
+
* [size](#size)
|
23
|
+
* [status](#status)
|
24
|
+
* [type](#type)
|
25
|
+
|
26
|
+
---
|
27
|
+
|
28
|
+
## (ungrouped)
|
29
|
+
|
30
|
+
### blocked
|
31
|
+
|
32
|
+
An issue which can't be worked on until some other work is finished.
|
33
|
+
If an issue has this label, it _should_ (but, unfortunately, may not)
|
34
|
+
have an explanation of what other work needs to be done before it can be
|
35
|
+
worked on.
|
36
|
+
|
37
|
+
### duplicate
|
38
|
+
|
39
|
+
A duplicate issue.
|
40
|
+
|
41
|
+
### in progress
|
42
|
+
|
43
|
+
An issue which is currently being worked on. This should be added when
|
44
|
+
someone begins work on an issue.
|
45
|
+
|
46
|
+
### ready
|
47
|
+
|
48
|
+
An issue which is ready to be worked on. This should be removed when
|
49
|
+
someone begins work on an issue.
|
50
|
+
|
51
|
+
## categories
|
52
|
+
|
53
|
+
### category: export
|
54
|
+
|
55
|
+
Issues relating to exporting reports.
|
56
|
+
|
57
|
+
## size
|
58
|
+
|
59
|
+
### size: small
|
60
|
+
|
61
|
+
An issue which should, at least in theory, be relatively simple to
|
62
|
+
resolve.
|
63
|
+
|
64
|
+
### size: large
|
65
|
+
|
66
|
+
An issue which is expected to take a large amount of effort to resolve.
|
67
|
+
|
68
|
+
### size: here be dragons
|
69
|
+
|
70
|
+
An issue which is extremely difficult, possibly impossible, to determine
|
71
|
+
the actual difficulty of. It could be resolved quickly, or it could grow
|
72
|
+
significantly.
|
73
|
+
|
74
|
+
## type
|
75
|
+
|
76
|
+
### type: bug report
|
77
|
+
|
78
|
+
A bug report.
|
79
|
+
|
80
|
+
### type: feature request
|
81
|
+
|
82
|
+
A request for a new feature to be added.
|
83
|
+
|
84
|
+
### type: question
|
85
|
+
|
86
|
+
An issue which is a question or discussion.
|
data/README.md
CHANGED
@@ -1,5 +1,5 @@
|
|
1
|
-
[](https://waffle.io/how-is/how_is)
|
2
|
+
[](https://travis-ci.org/how-is/how_is)
|
3
3
|
|
4
4
|
# How is [your repo]?
|
5
5
|
|
@@ -121,7 +121,7 @@ To install this gem onto your local machine, run `bundle exec rake install`. To
|
|
121
121
|
|
122
122
|
## Contributing
|
123
123
|
|
124
|
-
Bug reports and pull requests are welcome on GitHub at https://github.com/
|
124
|
+
Bug reports and pull requests are welcome on GitHub at https://github.com/how-is/how_is. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
|
125
125
|
|
126
126
|
|
127
127
|
## License
|
@@ -0,0 +1,155 @@
|
|
1
|
+
# how_is functional specification
|
2
|
+
|
3
|
+
By [Ellen Marie Dash](https://twitter.com/duckinator)
|
4
|
+
Last Updated: 2017-01-03
|
5
|
+
|
6
|
+
This document is a _functional specification_ (in other words, it documents
|
7
|
+
how the program works from an end-user perspective).
|
8
|
+
See [02-implementation.md](02-implementation.md) for a technical
|
9
|
+
specification (that is, how it is implemented).
|
10
|
+
|
11
|
+
*This document is incomplete.* It will take significant revisions before
|
12
|
+
this document can be considered complete.
|
13
|
+
|
14
|
+
## Overview
|
15
|
+
|
16
|
+
how_is is a command-line tool to quantify the state of a GitHub
|
17
|
+
repository, and suggest actionable tasks to improve maintenance. It uses
|
18
|
+
information from the issue tracker, the codebase itself, and third-party
|
19
|
+
APIs to accomplish this. The expected audience is project managers, or
|
20
|
+
people in similar roles, and software developers.
|
21
|
+
|
22
|
+
## Scenarios
|
23
|
+
|
24
|
+
When designing products, it helps to imagine a few real life stories of
|
25
|
+
how actual (stereotypical) people would use them. Let's look at some
|
26
|
+
scenarios.
|
27
|
+
|
28
|
+
### Scenario 1: Jill (Project Manager)
|
29
|
+
|
30
|
+
Jill is a project manager for a large software project, which is hosted
|
31
|
+
on GitHub. She recently realized the project is falling behind on
|
32
|
+
managing issues and pull requests, and would like to get more detailed
|
33
|
+
information about this.
|
34
|
+
|
35
|
+
She runs `how_is some_org/some_project` to generate a report, which
|
36
|
+
contains information about the oldest and newest issues/PRs, the rate at
|
37
|
+
which issues/PRs are being opened and closed, and what issues fall under
|
38
|
+
whiat label. It also includes suggestions for improving management of
|
39
|
+
the project — such as possible approaches to keep on top of new
|
40
|
+
pull requests.
|
41
|
+
|
42
|
+
### Scenario 2: Jesse (Developer)
|
43
|
+
|
44
|
+
Jesse is a developer who works on the same project as Jill.
|
45
|
+
??? Why do people use a config file? It feels like it may actually
|
46
|
+
be redundant after the dashboard is implemented? Maybe we should discuss
|
47
|
+
the Ruby API instead? ???
|
48
|
+
|
49
|
+
## Nongoals
|
50
|
+
|
51
|
+
This project is not:
|
52
|
+
|
53
|
+
* A dashboard. It generates a static report. However, a dashboard is
|
54
|
+
going to be implemented _using_ how\_is. See:
|
55
|
+
[how-is/dashboard](https://github.com/how-is/dashboard).
|
56
|
+
* Magic. It can at best give suggestions based on data. It can't know
|
57
|
+
the context or nuance to provide tailored advice. It needs human
|
58
|
+
interpretation and understanding in order to be useful.
|
59
|
+
|
60
|
+
## Contents of a Report
|
61
|
+
|
62
|
+
Reports will contain the following:
|
63
|
+
|
64
|
+
* Number of open issues/PRs (+ links to listing of open issues/PRs).
|
65
|
+
* Links to newest and oldest issues/PRs + dates they were opened.
|
66
|
+
* Average issue/PR age.
|
67
|
+
* Number of issues closed in the past month (+ link to GitHub page listing
|
68
|
+
them).\*
|
69
|
+
* Number of PRs merged in the past month (+ link to GitHub page listing
|
70
|
+
them).\*
|
71
|
+
* Number of issues/PRs not updated in the past month (+ link to GitHub
|
72
|
+
page listing them, if possible).\*
|
73
|
+
* A graph showing the number of issues with each label (grouped by
|
74
|
+
category — explained later), as well as with no label (+ links
|
75
|
+
to lists of issues with each label).\*\*
|
76
|
+
* Clicking a label will pull information about issue labels from
|
77
|
+
various files, if they exist. Assuming one of those files exists,
|
78
|
+
clicking on a label will show the description of that label if it is
|
79
|
+
defined. If it is not defined, it will show a message explaining
|
80
|
+
that. The description will include a link to the file it was pulled
|
81
|
+
from.\*
|
82
|
+
* Code churn (via Code Climate) — TODO: determine presentation
|
83
|
+
details.\*
|
84
|
+
* Average length of time it takes for any team member to respond to a
|
85
|
+
new issue/PR.\*
|
86
|
+
* If a directory containing previous reports is specified, generate a
|
87
|
+
graph of this response time per week.\*
|
88
|
+
|
89
|
+
Items with an asterisk (\*) have yet to be implemented.
|
90
|
+
Items with two asterisks (\*\*) have been partially implemented.
|
91
|
+
|
92
|
+
## UI Specification
|
93
|
+
|
94
|
+
## Infmation about how_is
|
95
|
+
|
96
|
+
`how_is --help` prints help text and exits.
|
97
|
+
|
98
|
+
`how_is --version` prints the version and exits.
|
99
|
+
|
100
|
+
### Generating a report
|
101
|
+
|
102
|
+
How\_is can generate HTML reports for https://github.com/rubygems/rubygems.
|
103
|
+
By default, it generates reports at `./report.html`.
|
104
|
+
To view an HTML report, open it in aweb browser.
|
105
|
+
|
106
|
+
There is no output when it succeeds.
|
107
|
+
|
108
|
+
```
|
109
|
+
$ how_is rubygems/rubygems
|
110
|
+
$
|
111
|
+
```
|
112
|
+
|
113
|
+
### Generate a report, specifying the filename
|
114
|
+
|
115
|
+
You can generate reports with other filenames, as well as different
|
116
|
+
report formats, using the `--report FILENAME` parameter.
|
117
|
+
|
118
|
+
The FILENAME can be any filename that ends with a lowercase
|
119
|
+
extension specifying a supported format (currently `.html` and `.json`).
|
120
|
+
|
121
|
+
If the filename ends with `.html` it'll generate an HTML report,
|
122
|
+
if it ends with `.json` it'll generate a JSON report.
|
123
|
+
|
124
|
+
There is no output when it succeeds.
|
125
|
+
|
126
|
+
```
|
127
|
+
$ how_is --report report.json rubygems/rubygems
|
128
|
+
$
|
129
|
+
```
|
130
|
+
|
131
|
+
### Generate a report, using data from a JSON report
|
132
|
+
|
133
|
+
If you have a JSON report (see above), you can use that to generate
|
134
|
+
another report (probably HTML) using that data.
|
135
|
+
|
136
|
+
E.g.,
|
137
|
+
|
138
|
+
```
|
139
|
+
$ how_is --from report.json --report report.html
|
140
|
+
$
|
141
|
+
```
|
142
|
+
|
143
|
+
This generates an HTML report just like `how_is --report report.html
|
144
|
+
REPOSITORY`, except it uses the data from `report.json` instead of
|
145
|
+
fetching it again.
|
146
|
+
|
147
|
+
tl;dr: you're using the JSON file as a cache.
|
148
|
+
|
149
|
+
### Generating a report using a config file
|
150
|
+
|
151
|
+
See [the README](https://github.com/how-is/how_is/blob/master/README.md#generating-reports-from-a-config-file).
|
152
|
+
|
153
|
+
### Ruby API
|
154
|
+
|
155
|
+
See [the README](https://github.com/how-is/how_is/blob/master/README.md#ruby-api).
|
@@ -0,0 +1,18 @@
|
|
1
|
+
# how_is technical specification
|
2
|
+
|
3
|
+
By [Ellen Marie Dash](https://twitter.com/duckinator)
|
4
|
+
Last Updated: 2017-01-??
|
5
|
+
|
6
|
+
This document is a _technical specification_ (in other words, how the
|
7
|
+
program is implemented).
|
8
|
+
See [01-functionality.md](01-functionality.md) for a functional
|
9
|
+
specification (that is, how it works from an end-user perspective).
|
10
|
+
|
11
|
+
*This document is incomplete.* It will take significant revisions before
|
12
|
+
this document can be considered complete.
|
13
|
+
|
14
|
+
## Overview
|
15
|
+
|
16
|
+
TODO (high-level overview of architecture)
|
17
|
+
|
18
|
+
##
|
data/exe/how_is
CHANGED
@@ -19,12 +19,21 @@ opts = result[:opts]
|
|
19
19
|
options = result[:options]
|
20
20
|
arguments = result[:arguments]
|
21
21
|
|
22
|
-
|
23
|
-
|
24
|
-
|
25
|
-
|
26
|
-
|
27
|
-
|
28
|
-
|
29
|
-
|
22
|
+
begin
|
23
|
+
if options[:help]
|
24
|
+
puts result[:opts]
|
25
|
+
elsif options[:version]
|
26
|
+
puts HowIs::VERSION
|
27
|
+
elsif options[:config]
|
28
|
+
HowIs.from_config_file(YAML.load_file(options[:config]))
|
29
|
+
else
|
30
|
+
HowIs.generate_report_file(options)
|
31
|
+
end
|
32
|
+
rescue => e
|
33
|
+
if ENV['SHOW_TRACE']
|
34
|
+
raise
|
35
|
+
else
|
36
|
+
abort "Error: #{e.message}"
|
37
|
+
end
|
30
38
|
end
|
39
|
+
|
data/how_is.gemspec
CHANGED
@@ -21,13 +21,8 @@ Gem::Specification.new do |spec|
|
|
21
21
|
spec.add_runtime_dependency "github_api", "~> 0.14.5"
|
22
22
|
spec.add_runtime_dependency "contracts", "~> 0.14.0"
|
23
23
|
spec.add_runtime_dependency "slop", "~> 4.4.1"
|
24
|
-
spec.add_runtime_dependency "prawn", "~> 2.1.0"
|
25
24
|
|
26
|
-
spec.add_runtime_dependency "
|
27
|
-
|
28
|
-
# Travis CI only supports up to Ruby 2.2.0, but Rack 2.0+ requires Ruby 2.2.2+,
|
29
|
-
# so this pegs Rack to the latest version that works with Ruby 2.2.0.
|
30
|
-
spec.add_runtime_dependency "rack", "< 2.0"
|
25
|
+
spec.add_runtime_dependency "rack", "~> 2.0"
|
31
26
|
|
32
27
|
spec.add_runtime_dependency "tessellator-fetcher", "~> 5.0.0"
|
33
28
|
|
data/lib/how_is/analyzer.rb
CHANGED
data/lib/how_is/cli.rb
CHANGED
@@ -6,91 +6,5 @@ require 'stringio'
|
|
6
6
|
class HowIs::CLI
|
7
7
|
include Contracts::Core
|
8
8
|
|
9
|
-
DEFAULT_CONFIG_FILE = 'how_is.yml'
|
10
9
|
|
11
|
-
# Generates YAML frontmatter, as is used in Jekyll and other blog engines.
|
12
|
-
#
|
13
|
-
# E.g.,
|
14
|
-
# generate_frontmatter({'foo' => "bar %{baz}"}, {'baz' => "asdf"})
|
15
|
-
# => "---\nfoo: bar asdf\n"
|
16
|
-
Contract C::HashOf[C::Or[String, Symbol] => String],
|
17
|
-
C::HashOf[C::Or[String, Symbol] => C::Any] => String
|
18
|
-
def generate_frontmatter(frontmatter, report_data)
|
19
|
-
frontmatter = convert_keys(frontmatter, :to_s)
|
20
|
-
report_data = convert_keys(report_data, :to_sym)
|
21
|
-
|
22
|
-
frontmatter = frontmatter.map { |k, v|
|
23
|
-
v = v % report_data
|
24
|
-
|
25
|
-
[k, v]
|
26
|
-
}.to_h
|
27
|
-
|
28
|
-
YAML.dump(frontmatter)
|
29
|
-
end
|
30
|
-
|
31
|
-
##
|
32
|
-
# Generates a series of report files based on a YAML config file.
|
33
|
-
def from_config_file(config_file = nil, **kwargs)
|
34
|
-
config_file ||= DEFAULT_CONFIG_FILE
|
35
|
-
|
36
|
-
from_config(YAML.load_file(config_file), **kwargs)
|
37
|
-
end
|
38
|
-
|
39
|
-
##
|
40
|
-
# Generates a series of report files based on a config Hash.
|
41
|
-
def from_config(config,
|
42
|
-
github: nil,
|
43
|
-
report_class: nil)
|
44
|
-
report_class ||= HowIs::Report
|
45
|
-
|
46
|
-
date = Date.strptime(Time.now.to_i.to_s, '%s')
|
47
|
-
date_string = date.strftime('%Y-%m-%d')
|
48
|
-
friendly_date = date.strftime('%B %d, %y')
|
49
|
-
|
50
|
-
analysis = HowIs.generate_analysis(repository: config['repository'], github: github)
|
51
|
-
|
52
|
-
report_data = {
|
53
|
-
repository: config['repository'],
|
54
|
-
date: date,
|
55
|
-
friendly_date: friendly_date,
|
56
|
-
}
|
57
|
-
|
58
|
-
config['reports'].map do |format, report_config|
|
59
|
-
filename = report_config['filename'] % report_data
|
60
|
-
file = File.join(report_config['directory'], filename)
|
61
|
-
|
62
|
-
report = report_class.export(analysis, format)
|
63
|
-
|
64
|
-
result = build_report(report_config['frontmatter'], report_data, report)
|
65
|
-
|
66
|
-
File.open(file, 'w') do |f|
|
67
|
-
f.puts result
|
68
|
-
end
|
69
|
-
|
70
|
-
result
|
71
|
-
end
|
72
|
-
end
|
73
|
-
|
74
|
-
# Combine the frontmatter, report data, and raw report into a report with
|
75
|
-
# frontmatter.
|
76
|
-
def build_report(frontmatter, report_data, report)
|
77
|
-
str = StringIO.new
|
78
|
-
|
79
|
-
if frontmatter
|
80
|
-
str.puts generate_frontmatter(frontmatter, report_data)
|
81
|
-
str.puts "---"
|
82
|
-
str.puts
|
83
|
-
end
|
84
|
-
|
85
|
-
str.puts report
|
86
|
-
|
87
|
-
str.string
|
88
|
-
end
|
89
|
-
|
90
|
-
private
|
91
|
-
# convert_keys({'foo' => 'bar'}, :to_sym)
|
92
|
-
# => {:foo => 'bar'}
|
93
|
-
def convert_keys(data, method_name)
|
94
|
-
data.map {|k, v| [k.send(method_name), v]}.to_h
|
95
|
-
end
|
96
10
|
end
|
data/lib/how_is/fetcher.rb
CHANGED
@@ -31,6 +31,9 @@ class HowIs::Fetcher
|
|
31
31
|
github = nil)
|
32
32
|
github ||= Github.new(auto_pagination: true)
|
33
33
|
user, repo = repository.split('/', 2)
|
34
|
+
raise HowIs::CLI::OptionsError, 'To generate a report from GitHub, ' \
|
35
|
+
'provide the repository username/project. ' \
|
36
|
+
'Quitting!' unless user && repo
|
34
37
|
issues = github.issues.list user: user, repo: repo
|
35
38
|
pulls = github.pulls.list user: user, repo: repo
|
36
39
|
|
data/lib/how_is/pulse.rb
CHANGED
data/lib/how_is/report/html.rb
CHANGED
data/lib/how_is/report/json.rb
CHANGED
data/lib/how_is/report.rb
CHANGED
data/lib/how_is/version.rb
CHANGED
@@ -1,3 +1,3 @@
|
|
1
|
-
|
2
|
-
VERSION = "
|
1
|
+
class HowIs
|
2
|
+
VERSION = "13.0.0"
|
3
3
|
end
|
data/lib/how_is.rb
CHANGED
@@ -6,7 +6,7 @@ Cacert.set_in_env
|
|
6
6
|
|
7
7
|
C = Contracts
|
8
8
|
|
9
|
-
|
9
|
+
class HowIs
|
10
10
|
include Contracts::Core
|
11
11
|
|
12
12
|
require 'how_is/fetcher'
|
@@ -25,10 +25,16 @@ module HowIs
|
|
25
25
|
|
26
26
|
##
|
27
27
|
# Generates and returns a report as a String.
|
28
|
-
def
|
29
|
-
analysis =
|
28
|
+
def initialize(repository, **kw_args)
|
29
|
+
@analysis = HowIs.generate_analysis(repository: repository, **kw_args)
|
30
|
+
end
|
31
|
+
|
32
|
+
def to_html
|
33
|
+
Report.export(@analysis, :html)
|
34
|
+
end
|
30
35
|
|
31
|
-
|
36
|
+
def to_json
|
37
|
+
Report.export(@analysis, :json)
|
32
38
|
end
|
33
39
|
|
34
40
|
##
|
@@ -65,4 +71,85 @@ module HowIs
|
|
65
71
|
|
66
72
|
analysis
|
67
73
|
end
|
74
|
+
|
75
|
+
# Generates YAML frontmatter, as is used in Jekyll and other blog engines.
|
76
|
+
#
|
77
|
+
# E.g.,
|
78
|
+
# generate_frontmatter({'foo' => "bar %{baz}"}, {'baz' => "asdf"})
|
79
|
+
# => "---\nfoo: bar asdf\n"
|
80
|
+
Contract C::HashOf[C::Or[String, Symbol] => String],
|
81
|
+
C::HashOf[C::Or[String, Symbol] => C::Any] => String
|
82
|
+
def self.generate_frontmatter(frontmatter, report_data)
|
83
|
+
frontmatter = convert_keys(frontmatter, :to_s)
|
84
|
+
report_data = convert_keys(report_data, :to_sym)
|
85
|
+
|
86
|
+
frontmatter = frontmatter.map { |k, v|
|
87
|
+
v = v % report_data
|
88
|
+
|
89
|
+
[k, v]
|
90
|
+
}.to_h
|
91
|
+
|
92
|
+
YAML.dump(frontmatter)
|
93
|
+
end
|
94
|
+
|
95
|
+
##
|
96
|
+
# Generates a series of report files based on a config Hash.
|
97
|
+
def self.from_config(config,
|
98
|
+
github: nil,
|
99
|
+
report_class: nil)
|
100
|
+
report_class ||= HowIs::Report
|
101
|
+
|
102
|
+
date = Date.strptime(Time.now.to_i.to_s, '%s')
|
103
|
+
date_string = date.strftime('%Y-%m-%d')
|
104
|
+
friendly_date = date.strftime('%B %d, %y')
|
105
|
+
|
106
|
+
analysis = HowIs.generate_analysis(repository: config['repository'], github: github)
|
107
|
+
|
108
|
+
report_data = {
|
109
|
+
repository: config['repository'],
|
110
|
+
date: date,
|
111
|
+
friendly_date: friendly_date,
|
112
|
+
}
|
113
|
+
|
114
|
+
generated_reports = {}
|
115
|
+
|
116
|
+
config['reports'].map do |format, report_config|
|
117
|
+
filename = report_config['filename'] % report_data
|
118
|
+
file = File.join(report_config['directory'], filename)
|
119
|
+
|
120
|
+
report = report_class.export(analysis, format)
|
121
|
+
|
122
|
+
result = build_report(report_config['frontmatter'], report_data, report)
|
123
|
+
|
124
|
+
generated_reports[file] = result
|
125
|
+
|
126
|
+
result
|
127
|
+
end
|
128
|
+
|
129
|
+
generated_reports
|
130
|
+
end
|
131
|
+
|
132
|
+
# Combine the frontmatter, report data, and raw report into a report with
|
133
|
+
# frontmatter.
|
134
|
+
def self.build_report(frontmatter, report_data, report)
|
135
|
+
str = StringIO.new
|
136
|
+
|
137
|
+
if frontmatter
|
138
|
+
str.puts generate_frontmatter(frontmatter, report_data)
|
139
|
+
str.puts "---"
|
140
|
+
str.puts
|
141
|
+
end
|
142
|
+
|
143
|
+
str.puts report
|
144
|
+
|
145
|
+
str.string
|
146
|
+
end
|
147
|
+
|
148
|
+
private
|
149
|
+
# convert_keys({'foo' => 'bar'}, :to_sym)
|
150
|
+
# => {:foo => 'bar'}
|
151
|
+
def self.convert_keys(data, method_name)
|
152
|
+
data.map {|k, v| [k.send(method_name), v]}.to_h
|
153
|
+
end
|
154
|
+
|
68
155
|
end
|
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: how_is
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version:
|
4
|
+
version: 13.0.0
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Ellen Marie Dash
|
8
8
|
autorequire:
|
9
9
|
bindir: exe
|
10
10
|
cert_chain: []
|
11
|
-
date:
|
11
|
+
date: 2017-02-09 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: github_api
|
@@ -52,46 +52,18 @@ dependencies:
|
|
52
52
|
- - "~>"
|
53
53
|
- !ruby/object:Gem::Version
|
54
54
|
version: 4.4.1
|
55
|
-
- !ruby/object:Gem::Dependency
|
56
|
-
name: prawn
|
57
|
-
requirement: !ruby/object:Gem::Requirement
|
58
|
-
requirements:
|
59
|
-
- - "~>"
|
60
|
-
- !ruby/object:Gem::Version
|
61
|
-
version: 2.1.0
|
62
|
-
type: :runtime
|
63
|
-
prerelease: false
|
64
|
-
version_requirements: !ruby/object:Gem::Requirement
|
65
|
-
requirements:
|
66
|
-
- - "~>"
|
67
|
-
- !ruby/object:Gem::Version
|
68
|
-
version: 2.1.0
|
69
|
-
- !ruby/object:Gem::Dependency
|
70
|
-
name: mini_magick
|
71
|
-
requirement: !ruby/object:Gem::Requirement
|
72
|
-
requirements:
|
73
|
-
- - "~>"
|
74
|
-
- !ruby/object:Gem::Version
|
75
|
-
version: 4.5.1
|
76
|
-
type: :runtime
|
77
|
-
prerelease: false
|
78
|
-
version_requirements: !ruby/object:Gem::Requirement
|
79
|
-
requirements:
|
80
|
-
- - "~>"
|
81
|
-
- !ruby/object:Gem::Version
|
82
|
-
version: 4.5.1
|
83
55
|
- !ruby/object:Gem::Dependency
|
84
56
|
name: rack
|
85
57
|
requirement: !ruby/object:Gem::Requirement
|
86
58
|
requirements:
|
87
|
-
- - "
|
59
|
+
- - "~>"
|
88
60
|
- !ruby/object:Gem::Version
|
89
61
|
version: '2.0'
|
90
62
|
type: :runtime
|
91
63
|
prerelease: false
|
92
64
|
version_requirements: !ruby/object:Gem::Requirement
|
93
65
|
requirements:
|
94
|
-
- - "
|
66
|
+
- - "~>"
|
95
67
|
- !ruby/object:Gem::Version
|
96
68
|
version: '2.0'
|
97
69
|
- !ruby/object:Gem::Dependency
|
@@ -206,11 +178,14 @@ files:
|
|
206
178
|
- CHANGELOG.md
|
207
179
|
- CODE_OF_CONDUCT.md
|
208
180
|
- Gemfile
|
181
|
+
- ISSUES.md
|
209
182
|
- LICENSE.txt
|
210
183
|
- README.md
|
211
184
|
- Rakefile
|
212
185
|
- bin/console
|
213
186
|
- bin/setup
|
187
|
+
- design/01-functionality.md
|
188
|
+
- design/02-implementation.md
|
214
189
|
- exe/how_is
|
215
190
|
- fixtures/vcr_cassettes/how-is-example-empty-repository.yml
|
216
191
|
- fixtures/vcr_cassettes/how-is-example-repository.yml
|
@@ -248,7 +223,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
248
223
|
version: '0'
|
249
224
|
requirements: []
|
250
225
|
rubyforge_project:
|
251
|
-
rubygems_version: 2.
|
226
|
+
rubygems_version: 2.5.2
|
252
227
|
signing_key:
|
253
228
|
specification_version: 4
|
254
229
|
summary: Quantify the health of a GitHub repository is.
|