vtk 0.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.editorconfig +11 -0
- data/.github/workflows/main.yml +13 -0
- data/.gitignore +19 -0
- data/.rspec +3 -0
- data/.rubocop.yml +5 -0
- data/.tool-versions +1 -0
- data/CHANGELOG.md +35 -0
- data/Gemfile +6 -0
- data/LICENSE.txt +20 -0
- data/README.md +19 -0
- data/Rakefile +12 -0
- data/bin/console +15 -0
- data/bin/setup +12 -0
- data/docs/design-doc.md +143 -0
- data/exe/vtk +18 -0
- data/lib/vtk.rb +8 -0
- data/lib/vtk/cli.rb +24 -0
- data/lib/vtk/command.rb +122 -0
- data/lib/vtk/commands/.gitkeep +1 -0
- data/lib/vtk/commands/module.rb +24 -0
- data/lib/vtk/commands/module/add.rb +31 -0
- data/lib/vtk/templates/.gitkeep +1 -0
- data/lib/vtk/templates/module/add/.gitkeep +1 -0
- data/lib/vtk/version.rb +5 -0
- data/vtk.gemspec +40 -0
- metadata +160 -0
checksums.yaml
ADDED
@@ -0,0 +1,7 @@
|
|
1
|
+
---
|
2
|
+
SHA256:
|
3
|
+
metadata.gz: 548575ce6bef53e2e3e617e8151e056879c569821d24cdcb0c9ab1ded7cde684
|
4
|
+
data.tar.gz: 1a087c94d0c2f30076cbd312c020a59dcc995185a4cf5a658a9fe3fd35adde45
|
5
|
+
SHA512:
|
6
|
+
metadata.gz: 9772f4461e30d1fb40da791790c851aada39362d18dff6d9b903ad45a2b35017201066c724397a99175d923f2aa4940563b6af65c360f86920e826fdcd51944d
|
7
|
+
data.tar.gz: 63a40c81a3f42214db2a46cc9ccd68a562ce570c5b1557a5d9937f156ad850ea7ec98774c481ed18f759e05b71d29da9396ac9b581e9267437405537096a6674
|
data/.editorconfig
ADDED
data/.gitignore
ADDED
@@ -0,0 +1,19 @@
|
|
1
|
+
/.bundle/
|
2
|
+
/.yardoc
|
3
|
+
/_yardoc/
|
4
|
+
/coverage/
|
5
|
+
/doc/
|
6
|
+
/pkg/
|
7
|
+
/spec/reports/
|
8
|
+
/tmp/
|
9
|
+
*.bundle
|
10
|
+
*.so
|
11
|
+
*.o
|
12
|
+
*.a
|
13
|
+
mkmf.log
|
14
|
+
|
15
|
+
# rspec failure tracking
|
16
|
+
.rspec_status
|
17
|
+
|
18
|
+
# Don't check in lock file for this app (gem)
|
19
|
+
Gemfile.lock
|
data/.rspec
ADDED
data/.rubocop.yml
ADDED
data/.tool-versions
ADDED
@@ -0,0 +1 @@
|
|
1
|
+
ruby 2.7.2
|
data/CHANGELOG.md
ADDED
@@ -0,0 +1,35 @@
|
|
1
|
+
commit 27fe3ef674a283686b7cff164386ec9d913208ef (HEAD -> start-afresh-with-tty, origin/start-afresh-with-tty)
|
2
|
+
Author: Lindsey Hattamer <lindsey.hattamer@oddball.io>
|
3
|
+
Date: Mon Jan 4 11:13:11 2021 -0500
|
4
|
+
|
5
|
+
add docs
|
6
|
+
|
7
|
+
commit 3a7d97c35ca9f084a0f27d1a2ff522dd8e9b2abc
|
8
|
+
Author: Eric Boehs <eric@boehs.com>
|
9
|
+
Date: Mon Jan 4 10:11:38 2021 -0600
|
10
|
+
|
11
|
+
Looks like rake runs rubocop already
|
12
|
+
|
13
|
+
commit 9f7df0e213edaa57420a1bd14501aea6fc4ffd5a
|
14
|
+
Author: Eric Boehs <eric@boehs.com>
|
15
|
+
Date: Mon Jan 4 10:10:33 2021 -0600
|
16
|
+
|
17
|
+
GH Actions: Pin Ubuntu to 20.04 (avoids warning)
|
18
|
+
|
19
|
+
commit 3343941e76b506ed00d3fbd1a7ecd163873597fc
|
20
|
+
Author: Eric Boehs <eric@boehs.com>
|
21
|
+
Date: Mon Jan 4 10:06:42 2021 -0600
|
22
|
+
|
23
|
+
Add tool-versions and rubocop to GitHub Actions
|
24
|
+
|
25
|
+
commit 99560d5ad44c9889bdd4884104c993aa86749a40
|
26
|
+
Author: Lindsey Hattamer <lindsey.hattamer@oddball.io>
|
27
|
+
Date: Mon Jan 4 11:03:58 2021 -0500
|
28
|
+
|
29
|
+
Remove adding to gemfile
|
30
|
+
|
31
|
+
commit b6394523b7eafbde3276a9f990dd7e4179e124e4
|
32
|
+
Author: Lindsey Hattamer <lindsey.hattamer@oddball.io>
|
33
|
+
Date: Mon Jan 4 11:02:55 2021 -0500
|
34
|
+
|
35
|
+
Update .github/workflows/main.yml
|
data/Gemfile
ADDED
data/LICENSE.txt
ADDED
@@ -0,0 +1,20 @@
|
|
1
|
+
The MIT License (MIT)
|
2
|
+
|
3
|
+
Copyright (c) 2020 Eric Boehs
|
4
|
+
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
6
|
+
this software and associated documentation files (the "Software"), to deal in
|
7
|
+
the Software without restriction, including without limitation the rights to
|
8
|
+
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
|
9
|
+
the Software, and to permit persons to whom the Software is furnished to do so,
|
10
|
+
subject to the following conditions:
|
11
|
+
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
13
|
+
copies or substantial portions of the Software.
|
14
|
+
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
|
17
|
+
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
|
18
|
+
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
|
19
|
+
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
20
|
+
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
data/README.md
ADDED
@@ -0,0 +1,19 @@
|
|
1
|
+
# VSP Toolkit (`vtk`)
|
2
|
+
|
3
|
+
The purpose of this gem is to allow VFS engineers to quickly begin developing on the platform. It does this by providing a command line interface that allows the use of simple commands and parameters to do everything from setting up a development environment to building out a directory structure and creating necessary files for separating code into its own module.
|
4
|
+
|
5
|
+
*The following assumes you have Ruby 2.6.6 or higher installed.*
|
6
|
+
|
7
|
+
## Installation
|
8
|
+
|
9
|
+
Install it yourself as:
|
10
|
+
|
11
|
+
$ gem install vtk
|
12
|
+
|
13
|
+
## Usage
|
14
|
+
|
15
|
+
### Modules
|
16
|
+
|
17
|
+
Teams developing for vets-api should create their code as a module. This allows for the separation and easy identification of different projects. To scaffold a directory structure for your module, first cd into the vets-api directory, then enter the command below, substituting the name of your module for *<module name>*. This will build out a directory structure and create necessary files in the `modules/` directory.
|
18
|
+
|
19
|
+
$ vtk module add <module name>
|
data/Rakefile
ADDED
data/bin/console
ADDED
@@ -0,0 +1,15 @@
|
|
1
|
+
#!/usr/bin/env ruby
|
2
|
+
# frozen_string_literal: true
|
3
|
+
|
4
|
+
require 'bundler/setup'
|
5
|
+
require 'vtk'
|
6
|
+
|
7
|
+
# You can add fixtures and/or initialization code here to make experimenting
|
8
|
+
# with your gem easier. You can also use a different console, if you like.
|
9
|
+
|
10
|
+
# (If you use this, don't forget to add pry to your Gemfile!)
|
11
|
+
# require "pry"
|
12
|
+
# Pry.start
|
13
|
+
|
14
|
+
require 'irb'
|
15
|
+
IRB.start(__FILE__)
|
data/bin/setup
ADDED
@@ -0,0 +1,12 @@
|
|
1
|
+
#!/usr/bin/env bash
|
2
|
+
set -euo pipefail
|
3
|
+
IFS=$'\n\t'
|
4
|
+
set -vx
|
5
|
+
|
6
|
+
gem install bundler --conservative
|
7
|
+
bundle config set --local path '.bundle/bundle'
|
8
|
+
bundle install
|
9
|
+
bundle binstubs --all
|
10
|
+
gem install tty --conservative
|
11
|
+
|
12
|
+
# Do any other automated setup that you need to do here
|
data/docs/design-doc.md
ADDED
@@ -0,0 +1,143 @@
|
|
1
|
+
# VSP Toolkit/Command-Line Interface (CLI) Design Doc
|
2
|
+
|
3
|
+
> This document is in draft status and subject to change or removal.
|
4
|
+
|
5
|
+
- **Author(s):** Keifer Furzland
|
6
|
+
- **Last Updated:** June 25, 2020
|
7
|
+
- **Status:** **Draft** | In Review | Approved
|
8
|
+
- **Approvers:** John Paul Ashenfelter [ ], Michael Fleet \[ \], Andrew Gunsch \[ \], Alex Pappas \[ \],
|
9
|
+
|
10
|
+
## Overview
|
11
|
+
### Objective
|
12
|
+
|
13
|
+
We want to answer the following questions:
|
14
|
+
|
15
|
+
Why do we want a command-line interface (CLI)?
|
16
|
+
How do we build & deploy features into a CLI?
|
17
|
+
What infrastructure resources do we use?
|
18
|
+
How is the CLI installed & configured?
|
19
|
+
How could VFS users use the CLI to make development easier?
|
20
|
+
|
21
|
+
Only VSP engineers should be releasing "officially supported" code, though it can be an open source tool, of course
|
22
|
+
|
23
|
+
The intended audience is VSP software engineers, particularly those on the Operations, FE Tools, and BE Tools teams.
|
24
|
+
|
25
|
+
- Build a cohesive set of command line tools used by VFS teams to make development easier.
|
26
|
+
- Solving and preventing problems with self-service,
|
27
|
+
- Primary product user is VFS engineer, though VSP team(s) will dogfood while building
|
28
|
+
|
29
|
+
|
30
|
+
### Background
|
31
|
+
|
32
|
+
VSP engineers utilize a wide variety of tools, processes, concepts, and utilities that are scattered about various documents, brains, and
|
33
|
+
machines.
|
34
|
+
|
35
|
+
For as much as we can, we should aim to build a single source of truth. This will be best for managing/updating code,
|
36
|
+
reducing "works on my machine" problems, and provide automatic configuration/support.
|
37
|
+
|
38
|
+
### High Level Design - WIP
|
39
|
+
|
40
|
+
These are mostly ideas until the first research spike is complete.
|
41
|
+
|
42
|
+
- VSP can use to do internal tasks (to dogfood) but goal is to improve VFS teams productivity
|
43
|
+
- Configuration file to manage local user configuration
|
44
|
+
- Configuration management (write to ~/.vsp/config.yml) for portability and extensibility
|
45
|
+
- Single binary install, package management, install from source (make it *easy* and *fool-proof* to install & update &
|
46
|
+
use)
|
47
|
+
- Built-in tools for portability (`pkg`, `nodejs`) can reduce headache for cross-platform users, and "just work," though
|
48
|
+
- Adds value by allowing us to codify important business practices (running reports, updating config, etc).
|
49
|
+
- Integrates w/ other tools across the VSP world
|
50
|
+
- Provides a modular design (VFS teams can modify it)
|
51
|
+
- Future-proof and scale-friendly - the shell isn't going away, React might, SOCKS config may change (instead of
|
52
|
+
everyone updating `/etc/*` or equiv, they can run `vsp upgrade` and `vsp socks` and be done w/ it)
|
53
|
+
- Could provide a webservice for the VFS team to use to query status/outages (is this just /v0/backend_status?)
|
54
|
+
- Test user data may be accessible here too, like `vsp service mvi --users --out=mvi-test-users.json`
|
55
|
+
- `vsp product:config forms --all --hide-sensitive` would show global VSP and api/site (product) specific configuration
|
56
|
+
- `vsp config` - should this be showing config for a specific thing? like "aws configuration" or "vets-api settings.yml"
|
57
|
+
- `vsp toolkit:plugin {init, config, install} PLUGIN_NAME` - for building, configuring, installing a new toolkit plugin (with oclif)
|
58
|
+
- Indicate somehow that a command is a native plugin or an "extension" i.e. not supported directly by VSP?
|
59
|
+
- We can build a process around adding/publishing modules for inclusion in the supported code, maybe
|
60
|
+
- We envision this can be leveraged into a web UI by wrapping a common API pattern
|
61
|
+
- The RPCs between commands should be consistent schema so we can do standard extensions
|
62
|
+
|
63
|
+
|
64
|
+
## Specifics
|
65
|
+
|
66
|
+
### Detailed Design - WIP
|
67
|
+
|
68
|
+
#### Prototype Plan
|
69
|
+
|
70
|
+
- Use [`oclif`](https://oclif.io/docs) to rapidly generate CLI framework
|
71
|
+
- One pattern would be to to map the CLI commands to the command pattern in code architecture
|
72
|
+
- Prototyping first 'thin layer' proving out the tooling:
|
73
|
+
- `vsp doctor:socks` # manage VA SOCKS state/connection - wraps `devops/utils/va.sh`
|
74
|
+
- `vsp services:status` # see backend service status, planned outages, etc. by hitting the `vets-api` endpoint
|
75
|
+
- `vsp products:site --build-version` # show the `build.txt` info
|
76
|
+
|
77
|
+
After the spike we'll have a prototype usable in further user testing.
|
78
|
+
|
79
|
+
### Code Location
|
80
|
+
|
81
|
+
- We could either host the `vsp-toolkit` as the core/main library and host git submodules for plugins
|
82
|
+
- Plugins *should* contain any dependencies, and this may "inspire rewrites" - which would add tech debt to squeeze a
|
83
|
+
- - We could reference dependencies and explicit check for them at runtime/command runtime/vsp doctor, like "does
|
84
|
+
`$VSP_DEVOPS_REPO` exist? good, use` $VSP_DEVOPS_REPO_PATH/scripts/script.sh` or is `va.sh` in `$PATH`, then redirect VSP
|
85
|
+
utils `$CMD` to `va.sh $_`
|
86
|
+
|
87
|
+
### Testing Plan
|
88
|
+
|
89
|
+
- `oclif` generates tests but we should ensure we're writing unit & integration tests across platforms
|
90
|
+
|
91
|
+
### Logging
|
92
|
+
|
93
|
+
- N/a
|
94
|
+
|
95
|
+
### Debugging
|
96
|
+
|
97
|
+
- Include a utility command `--debug` for debug output include system architecture, dependencies versions, etc.
|
98
|
+
|
99
|
+
### Caveats
|
100
|
+
|
101
|
+
- TBD
|
102
|
+
|
103
|
+
### Security Concerns
|
104
|
+
|
105
|
+
- Ensure we are properly handling files, permissions, data, memory, performance details
|
106
|
+
|
107
|
+
### Privacy Concerns
|
108
|
+
|
109
|
+
- This tool shouldn't allow anyone to do anything they inherently wouldn't be able to otherwise. In order to maintain
|
110
|
+
this state, we should consider how platform-wide privacy concerns are addressed. I.e. authorization, authentication,
|
111
|
+
audit-trail. Does the user have least privilege?
|
112
|
+
|
113
|
+
### Open Questions and Risks
|
114
|
+
|
115
|
+
- Will the majority of our audience be comfortable with this tool?
|
116
|
+
- Should we use OCLIF? Or Thor?
|
117
|
+
- How can we build a web UI on top of it? SDK-style
|
118
|
+
- Allow for multiple languages driving the CLI? Is this possible?
|
119
|
+
- Can we wrap application generators/wizards/form builders?
|
120
|
+
- We have basically millions of NPM scripts, can we improve discoverability w/o rewriting them all?
|
121
|
+
- Wrapping over porting - investigate how we can leverage existing scripts
|
122
|
+
- Shelling out (safely) is a not-necessarily bad idea
|
123
|
+
- Structure a script folder with endpoints as folders/script filenames?
|
124
|
+
|
125
|
+
### Work Estimates
|
126
|
+
- June 25 2020: Product Outline & Design Document drafted and out for review
|
127
|
+
- June 26 2020: Spike on prototype to explore potential painpoints and flesh out outline/doc
|
128
|
+
- July ? : Plan & start work pending stakeholder approval
|
129
|
+
- July- Aug: Dogfood and build out uses for internal, existing tools (doctor, utils, metadata, logs, aws connections,
|
130
|
+
etc). (Wrap existing scripts, update where necesessary)
|
131
|
+
- August : Have 3-5 useful tools prototyped and ready for a design sprint w/ VFS & VSP engineers
|
132
|
+
|
133
|
+
### Alternatives - WIP
|
134
|
+
_This section contains alternative solutions to the stated objective, as well as explanations for why they weren't used. In the planning stage, this section is useful for understanding the value added by the proposed solution and why particular solutions were discarded. Once the system has been implemented, this section will inform readers of alternative solutions so they can find the best system to address their needs._
|
135
|
+
|
136
|
+
### Future Work - WIP
|
137
|
+
_Features you'd like to (or will need to) add but aren't required for the current release. This is a great place to speculate on potential features and performance improvements._
|
138
|
+
|
139
|
+
### Revision History
|
140
|
+
|
141
|
+
Date | Revisions Made | Author
|
142
|
+
-----|----------------|--------
|
143
|
+
June 25, 2020 | Added initial draft of design document. | Keifer Furzland
|
data/exe/vtk
ADDED
@@ -0,0 +1,18 @@
|
|
1
|
+
#!/usr/bin/env ruby
|
2
|
+
# frozen_string_literal: true
|
3
|
+
|
4
|
+
lib_path = File.expand_path('../lib', __dir__)
|
5
|
+
$LOAD_PATH.unshift(lib_path) unless $LOAD_PATH.include?(lib_path)
|
6
|
+
require 'vtk/cli'
|
7
|
+
|
8
|
+
Signal.trap('INT') do
|
9
|
+
warn("\n#{caller.join("\n")}: interrupted")
|
10
|
+
exit(1)
|
11
|
+
end
|
12
|
+
|
13
|
+
begin
|
14
|
+
Vtk::CLI.start
|
15
|
+
rescue Vtk::CLI::Error => e
|
16
|
+
puts "ERROR: #{e.message}"
|
17
|
+
exit 1
|
18
|
+
end
|
data/lib/vtk.rb
ADDED
data/lib/vtk/cli.rb
ADDED
@@ -0,0 +1,24 @@
|
|
1
|
+
# frozen_string_literal: true
|
2
|
+
|
3
|
+
require 'thor'
|
4
|
+
|
5
|
+
module Vtk
|
6
|
+
# Handle the application command line parsing
|
7
|
+
# and the dispatch to various command objects
|
8
|
+
#
|
9
|
+
# @api public
|
10
|
+
class CLI < Thor
|
11
|
+
# Error raised by this runner
|
12
|
+
Error = Class.new(StandardError)
|
13
|
+
|
14
|
+
desc 'version', 'vtk version'
|
15
|
+
def version
|
16
|
+
require_relative 'version'
|
17
|
+
puts "v#{Vtk::VERSION}"
|
18
|
+
end
|
19
|
+
map %w[--version -v] => :version
|
20
|
+
|
21
|
+
require_relative 'commands/module'
|
22
|
+
register Vtk::Commands::Module, 'module', 'module [SUBCOMMAND]', 'Command description...'
|
23
|
+
end
|
24
|
+
end
|
data/lib/vtk/command.rb
ADDED
@@ -0,0 +1,122 @@
|
|
1
|
+
# frozen_string_literal: true
|
2
|
+
|
3
|
+
require 'forwardable'
|
4
|
+
|
5
|
+
module Vtk
|
6
|
+
# Command class that all command inherit from
|
7
|
+
class Command
|
8
|
+
extend Forwardable
|
9
|
+
|
10
|
+
def_delegators :command, :run
|
11
|
+
|
12
|
+
# Execute this command
|
13
|
+
#
|
14
|
+
# @api public
|
15
|
+
def execute(*)
|
16
|
+
raise(
|
17
|
+
NotImplementedError,
|
18
|
+
"#{self.class}##{__method__} must be implemented"
|
19
|
+
)
|
20
|
+
end
|
21
|
+
|
22
|
+
# The external commands runner
|
23
|
+
#
|
24
|
+
# @see http://www.rubydoc.info/gems/tty-command
|
25
|
+
#
|
26
|
+
# @api public
|
27
|
+
def command(**options)
|
28
|
+
require 'tty-command'
|
29
|
+
TTY::Command.new(options)
|
30
|
+
end
|
31
|
+
|
32
|
+
# The cursor movement
|
33
|
+
#
|
34
|
+
# @see http://www.rubydoc.info/gems/tty-cursor
|
35
|
+
#
|
36
|
+
# @api public
|
37
|
+
def cursor
|
38
|
+
require 'tty-cursor'
|
39
|
+
TTY::Cursor
|
40
|
+
end
|
41
|
+
|
42
|
+
# Open a file or text in the user's preferred editor
|
43
|
+
#
|
44
|
+
# @see http://www.rubydoc.info/gems/tty-editor
|
45
|
+
#
|
46
|
+
# @api public
|
47
|
+
def editor
|
48
|
+
require 'tty-editor'
|
49
|
+
TTY::Editor
|
50
|
+
end
|
51
|
+
|
52
|
+
# File manipulation utility methods
|
53
|
+
#
|
54
|
+
# @see http://www.rubydoc.info/gems/tty-file
|
55
|
+
#
|
56
|
+
# @api public
|
57
|
+
def generator
|
58
|
+
require 'tty-file'
|
59
|
+
TTY::File
|
60
|
+
end
|
61
|
+
|
62
|
+
# Terminal output paging
|
63
|
+
#
|
64
|
+
# @see http://www.rubydoc.info/gems/tty-pager
|
65
|
+
#
|
66
|
+
# @api public
|
67
|
+
def pager(**options)
|
68
|
+
require 'tty-pager'
|
69
|
+
TTY::Pager.new(options)
|
70
|
+
end
|
71
|
+
|
72
|
+
# Terminal platform and OS properties
|
73
|
+
#
|
74
|
+
# @see http://www.rubydoc.info/gems/tty-pager
|
75
|
+
#
|
76
|
+
# @api public
|
77
|
+
def platform
|
78
|
+
require 'tty-platform'
|
79
|
+
TTY::Platform.new
|
80
|
+
end
|
81
|
+
|
82
|
+
# The interactive prompt
|
83
|
+
#
|
84
|
+
# @see http://www.rubydoc.info/gems/tty-prompt
|
85
|
+
#
|
86
|
+
# @api public
|
87
|
+
def prompt(**options)
|
88
|
+
require 'tty-prompt'
|
89
|
+
TTY::Prompt.new(options)
|
90
|
+
end
|
91
|
+
|
92
|
+
# Get terminal screen properties
|
93
|
+
#
|
94
|
+
# @see http://www.rubydoc.info/gems/tty-screen
|
95
|
+
#
|
96
|
+
# @api public
|
97
|
+
def screen
|
98
|
+
require 'tty-screen'
|
99
|
+
TTY::Screen
|
100
|
+
end
|
101
|
+
|
102
|
+
# The unix which utility
|
103
|
+
#
|
104
|
+
# @see http://www.rubydoc.info/gems/tty-which
|
105
|
+
#
|
106
|
+
# @api public
|
107
|
+
def which(*args)
|
108
|
+
require 'tty-which'
|
109
|
+
TTY::Which.which(*args)
|
110
|
+
end
|
111
|
+
|
112
|
+
# Check if executable exists
|
113
|
+
#
|
114
|
+
# @see http://www.rubydoc.info/gems/tty-which
|
115
|
+
#
|
116
|
+
# @api public
|
117
|
+
def exec_exist?(*args)
|
118
|
+
require 'tty-which'
|
119
|
+
TTY::Which.exist?(*args)
|
120
|
+
end
|
121
|
+
end
|
122
|
+
end
|
@@ -0,0 +1 @@
|
|
1
|
+
#
|
@@ -0,0 +1,24 @@
|
|
1
|
+
# frozen_string_literal: true
|
2
|
+
|
3
|
+
require 'thor'
|
4
|
+
|
5
|
+
module Vtk
|
6
|
+
module Commands
|
7
|
+
# Interfaces with vets-api modules
|
8
|
+
class Module < Thor
|
9
|
+
namespace :module
|
10
|
+
|
11
|
+
desc 'add <module name>', 'Add a new module to vets-api'
|
12
|
+
method_option :help, aliases: '-h', type: :boolean,
|
13
|
+
desc: 'Display usage information'
|
14
|
+
def add(name)
|
15
|
+
if options[:help]
|
16
|
+
invoke :help, ['add']
|
17
|
+
else
|
18
|
+
require_relative 'module/add'
|
19
|
+
Vtk::Commands::Module::Add.new(name, options).execute
|
20
|
+
end
|
21
|
+
end
|
22
|
+
end
|
23
|
+
end
|
24
|
+
end
|
@@ -0,0 +1,31 @@
|
|
1
|
+
# frozen_string_literal: true
|
2
|
+
|
3
|
+
require_relative '../../command'
|
4
|
+
|
5
|
+
module Vtk
|
6
|
+
module Commands
|
7
|
+
class Module
|
8
|
+
# Adds a new module to vets-api
|
9
|
+
class Add < Vtk::Command
|
10
|
+
attr_accessor :name, :options
|
11
|
+
|
12
|
+
def initialize(name, options)
|
13
|
+
@name = name
|
14
|
+
@options = options
|
15
|
+
|
16
|
+
super()
|
17
|
+
end
|
18
|
+
|
19
|
+
def execute(_input: $stdin, _output: $stdout)
|
20
|
+
create_module name
|
21
|
+
end
|
22
|
+
|
23
|
+
private
|
24
|
+
|
25
|
+
def create_module(name)
|
26
|
+
`rails g module #{name}`
|
27
|
+
end
|
28
|
+
end
|
29
|
+
end
|
30
|
+
end
|
31
|
+
end
|
@@ -0,0 +1 @@
|
|
1
|
+
#
|
@@ -0,0 +1 @@
|
|
1
|
+
#
|
data/lib/vtk/version.rb
ADDED
data/vtk.gemspec
ADDED
@@ -0,0 +1,40 @@
|
|
1
|
+
# frozen_string_literal: true
|
2
|
+
|
3
|
+
require_relative 'lib/vtk/version'
|
4
|
+
|
5
|
+
Gem::Specification.new do |spec|
|
6
|
+
spec.name = 'vtk'
|
7
|
+
spec.license = 'MIT'
|
8
|
+
spec.version = Vtk::VERSION
|
9
|
+
spec.authors = ['Eric Boehs', 'Lindsey Hattamer', 'Travis Hilton']
|
10
|
+
spec.email = ['eric.boehs@oddball.io', 'lindsey.hattamer@oddball.io', 'travis.hilton@oddball.io']
|
11
|
+
|
12
|
+
spec.summary = 'A CLI for the VSP platform'
|
13
|
+
spec.description = 'This is a CLI tool for the VSP platform for developer usage'
|
14
|
+
spec.homepage = 'https://github.com/department-of-veterans-affairs/vsp-toolkit'
|
15
|
+
spec.required_ruby_version = Gem::Requirement.new('>= 2.4.0')
|
16
|
+
|
17
|
+
spec.metadata['homepage_uri'] = spec.homepage
|
18
|
+
spec.metadata['source_code_uri'] = spec.homepage
|
19
|
+
spec.metadata['changelog_uri'] = 'https://github.com/department-of-veterans-affairs/vsp-toolkit/blob/master/CHANGELOG.md'
|
20
|
+
|
21
|
+
# Specify which files should be added to the gem when it is released.
|
22
|
+
# The `git ls-files -z` loads the files in the RubyGem that have been added into git.
|
23
|
+
spec.files = Dir.chdir(File.expand_path(__dir__)) do
|
24
|
+
`git ls-files -z`.split("\x0").reject { |f| f.match(%r{\A(?:test|spec|features)/}) }
|
25
|
+
end
|
26
|
+
spec.bindir = 'exe'
|
27
|
+
spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
|
28
|
+
spec.require_paths = ['lib']
|
29
|
+
|
30
|
+
spec.add_dependency 'thor', '> 0.20.3'
|
31
|
+
|
32
|
+
spec.add_development_dependency 'rake', '~> 13.0.0'
|
33
|
+
spec.add_development_dependency 'rspec', '~> 3.10.0'
|
34
|
+
spec.add_development_dependency 'rubocop', '~> 1.6.0'
|
35
|
+
spec.add_development_dependency 'rubocop-rake', '~> 0.5.0'
|
36
|
+
spec.add_development_dependency 'rubocop-rspec', '~> 2.0.0'
|
37
|
+
|
38
|
+
# For more information and examples about making a new gem, checkout our
|
39
|
+
# guide at: https://bundler.io/guides/creating_gem.html
|
40
|
+
end
|
metadata
ADDED
@@ -0,0 +1,160 @@
|
|
1
|
+
--- !ruby/object:Gem::Specification
|
2
|
+
name: vtk
|
3
|
+
version: !ruby/object:Gem::Version
|
4
|
+
version: 0.1.0
|
5
|
+
platform: ruby
|
6
|
+
authors:
|
7
|
+
- Eric Boehs
|
8
|
+
- Lindsey Hattamer
|
9
|
+
- Travis Hilton
|
10
|
+
autorequire:
|
11
|
+
bindir: exe
|
12
|
+
cert_chain: []
|
13
|
+
date: 2021-01-05 00:00:00.000000000 Z
|
14
|
+
dependencies:
|
15
|
+
- !ruby/object:Gem::Dependency
|
16
|
+
name: thor
|
17
|
+
requirement: !ruby/object:Gem::Requirement
|
18
|
+
requirements:
|
19
|
+
- - ">"
|
20
|
+
- !ruby/object:Gem::Version
|
21
|
+
version: 0.20.3
|
22
|
+
type: :runtime
|
23
|
+
prerelease: false
|
24
|
+
version_requirements: !ruby/object:Gem::Requirement
|
25
|
+
requirements:
|
26
|
+
- - ">"
|
27
|
+
- !ruby/object:Gem::Version
|
28
|
+
version: 0.20.3
|
29
|
+
- !ruby/object:Gem::Dependency
|
30
|
+
name: rake
|
31
|
+
requirement: !ruby/object:Gem::Requirement
|
32
|
+
requirements:
|
33
|
+
- - "~>"
|
34
|
+
- !ruby/object:Gem::Version
|
35
|
+
version: 13.0.0
|
36
|
+
type: :development
|
37
|
+
prerelease: false
|
38
|
+
version_requirements: !ruby/object:Gem::Requirement
|
39
|
+
requirements:
|
40
|
+
- - "~>"
|
41
|
+
- !ruby/object:Gem::Version
|
42
|
+
version: 13.0.0
|
43
|
+
- !ruby/object:Gem::Dependency
|
44
|
+
name: rspec
|
45
|
+
requirement: !ruby/object:Gem::Requirement
|
46
|
+
requirements:
|
47
|
+
- - "~>"
|
48
|
+
- !ruby/object:Gem::Version
|
49
|
+
version: 3.10.0
|
50
|
+
type: :development
|
51
|
+
prerelease: false
|
52
|
+
version_requirements: !ruby/object:Gem::Requirement
|
53
|
+
requirements:
|
54
|
+
- - "~>"
|
55
|
+
- !ruby/object:Gem::Version
|
56
|
+
version: 3.10.0
|
57
|
+
- !ruby/object:Gem::Dependency
|
58
|
+
name: rubocop
|
59
|
+
requirement: !ruby/object:Gem::Requirement
|
60
|
+
requirements:
|
61
|
+
- - "~>"
|
62
|
+
- !ruby/object:Gem::Version
|
63
|
+
version: 1.6.0
|
64
|
+
type: :development
|
65
|
+
prerelease: false
|
66
|
+
version_requirements: !ruby/object:Gem::Requirement
|
67
|
+
requirements:
|
68
|
+
- - "~>"
|
69
|
+
- !ruby/object:Gem::Version
|
70
|
+
version: 1.6.0
|
71
|
+
- !ruby/object:Gem::Dependency
|
72
|
+
name: rubocop-rake
|
73
|
+
requirement: !ruby/object:Gem::Requirement
|
74
|
+
requirements:
|
75
|
+
- - "~>"
|
76
|
+
- !ruby/object:Gem::Version
|
77
|
+
version: 0.5.0
|
78
|
+
type: :development
|
79
|
+
prerelease: false
|
80
|
+
version_requirements: !ruby/object:Gem::Requirement
|
81
|
+
requirements:
|
82
|
+
- - "~>"
|
83
|
+
- !ruby/object:Gem::Version
|
84
|
+
version: 0.5.0
|
85
|
+
- !ruby/object:Gem::Dependency
|
86
|
+
name: rubocop-rspec
|
87
|
+
requirement: !ruby/object:Gem::Requirement
|
88
|
+
requirements:
|
89
|
+
- - "~>"
|
90
|
+
- !ruby/object:Gem::Version
|
91
|
+
version: 2.0.0
|
92
|
+
type: :development
|
93
|
+
prerelease: false
|
94
|
+
version_requirements: !ruby/object:Gem::Requirement
|
95
|
+
requirements:
|
96
|
+
- - "~>"
|
97
|
+
- !ruby/object:Gem::Version
|
98
|
+
version: 2.0.0
|
99
|
+
description: This is a CLI tool for the VSP platform for developer usage
|
100
|
+
email:
|
101
|
+
- eric.boehs@oddball.io
|
102
|
+
- lindsey.hattamer@oddball.io
|
103
|
+
- travis.hilton@oddball.io
|
104
|
+
executables:
|
105
|
+
- vtk
|
106
|
+
extensions: []
|
107
|
+
extra_rdoc_files: []
|
108
|
+
files:
|
109
|
+
- ".editorconfig"
|
110
|
+
- ".github/workflows/main.yml"
|
111
|
+
- ".gitignore"
|
112
|
+
- ".rspec"
|
113
|
+
- ".rubocop.yml"
|
114
|
+
- ".tool-versions"
|
115
|
+
- CHANGELOG.md
|
116
|
+
- Gemfile
|
117
|
+
- LICENSE.txt
|
118
|
+
- README.md
|
119
|
+
- Rakefile
|
120
|
+
- bin/console
|
121
|
+
- bin/setup
|
122
|
+
- docs/design-doc.md
|
123
|
+
- exe/vtk
|
124
|
+
- lib/vtk.rb
|
125
|
+
- lib/vtk/cli.rb
|
126
|
+
- lib/vtk/command.rb
|
127
|
+
- lib/vtk/commands/.gitkeep
|
128
|
+
- lib/vtk/commands/module.rb
|
129
|
+
- lib/vtk/commands/module/add.rb
|
130
|
+
- lib/vtk/templates/.gitkeep
|
131
|
+
- lib/vtk/templates/module/add/.gitkeep
|
132
|
+
- lib/vtk/version.rb
|
133
|
+
- vtk.gemspec
|
134
|
+
homepage: https://github.com/department-of-veterans-affairs/vsp-toolkit
|
135
|
+
licenses:
|
136
|
+
- MIT
|
137
|
+
metadata:
|
138
|
+
homepage_uri: https://github.com/department-of-veterans-affairs/vsp-toolkit
|
139
|
+
source_code_uri: https://github.com/department-of-veterans-affairs/vsp-toolkit
|
140
|
+
changelog_uri: https://github.com/department-of-veterans-affairs/vsp-toolkit/blob/master/CHANGELOG.md
|
141
|
+
post_install_message:
|
142
|
+
rdoc_options: []
|
143
|
+
require_paths:
|
144
|
+
- lib
|
145
|
+
required_ruby_version: !ruby/object:Gem::Requirement
|
146
|
+
requirements:
|
147
|
+
- - ">="
|
148
|
+
- !ruby/object:Gem::Version
|
149
|
+
version: 2.4.0
|
150
|
+
required_rubygems_version: !ruby/object:Gem::Requirement
|
151
|
+
requirements:
|
152
|
+
- - ">="
|
153
|
+
- !ruby/object:Gem::Version
|
154
|
+
version: '0'
|
155
|
+
requirements: []
|
156
|
+
rubygems_version: 3.0.8
|
157
|
+
signing_key:
|
158
|
+
specification_version: 4
|
159
|
+
summary: A CLI for the VSP platform
|
160
|
+
test_files: []
|