[EP] CLI #432
[EP] CLI #432
Conversation
|
|
||
| ### Standalone | ||
|
|
||
| The standalone binary will be available via the usual means, final users will be able to simply |
There was a problem hiding this comment.
Some elaboration here would be good... minimally, point to the Releasing section for both short term and long term goals.
There was a problem hiding this comment.
Sure, I'm adding a pointer to "releasing".
docs/proposals/cli.md
Outdated
|
|
||
| Will be responsible for managing Build objects, using the verbs: `create`, `update`, list and | ||
| `delete`. End users will have the ability to bootstrap a repository container image build with a | ||
| single command, similarly to `shp init`, but with no assumptions about local project folder. |
There was a problem hiding this comment.
Granted, this is upstream and we don't want to necessarily proscribe an overly openshift slant to things, but we have resounding, positive, feedback with the oc new-app and oc new-build experience of pointing at a repo or local file system with constructing build related artifacts, that we need to at least consider it. Even if we at least initially rule it out, but consider for later.
It would certainly tie in with your associated local/remote EPs.
So minimally touching upon the correlation here seems prudent.
There was a problem hiding this comment.
The shp init should take place in a future EP, so I'm redacting that part from this EP, and mentioning the correlation with with other features, that's indeed prudent. Please consider latest commit.
docs/proposals/cli.md
Outdated
|
|
||
| ## Command | ||
|
|
||
| The project will use [cobra](https://github.com/spf13/cobra) for scaffolding the command-line |
There was a problem hiding this comment.
Might as well include Viper also https://github.com/spf13/viper for saving configuration files etc.
There was a problem hiding this comment.
Indeed. Viper comes handy for this type of command-line together with Cobra. Thanks.
|
is this blocked somehow? otherwise we should push on this one, CLI is pretty important for reaching wider adoption of Build. |
I will go through the comments and make sure it's up-to-speed for today's community meeting. |
docs/proposals/cli.md
Outdated
| ## Testing | ||
|
|
||
| The strategy to test the command-line application will be based on `go test` for the unit testing, | ||
| and for end-to-end testing we should adopt [bats](https://github.com/sstephenson/bats). Bats | ||
| framework gives us a structured way to run shell script commands and what we expect them to | ||
| return, the command-line client shp is no more than a shell command. | ||
|
|
||
| The testing structure will be composed of: | ||
|
|
||
| - **Unit**: written in Golang and using [Gomega](https://onsi.github.io/gomega/) for assertion; | ||
| - **End-to-End**: written in Golang and located at the traditional `test/e2e` directory; | ||
| - **System**: written using Bats framework (Bash); | ||
|
|
||
| Bats will also be helpful for a future `shp` container-image, we are able to mount the Bats files | ||
| in the container-image produced, and run our system testing against it. Therefore, Bats covers | ||
| testing of a local command-line binary, as well as it does a container-image. |
There was a problem hiding this comment.
Quick question regarding the proposed tools: I have worked with both bats and Ginkgo. Definitely good way to do it. However, I never really made friends with bats, especially when trying to debug an issue and I was missing some ad-hoc flexibility. For one of our tools, I adapted a style I saw in the open-source tool spruce. A helper function in the test suite works as a stand-in for the binary and you keep writing all your tests in Go while the test definition looks kind of like your command line would. Maybe you can have a look at the idea.
There was a problem hiding this comment.
Taking your experience in consideration I'm rewording to make Bats optional, we may decide for another tool depending on the group experience with it. I think it's fair to give it a try, follow buildah's example.
Thanks for sharing more options for this role.
There was a problem hiding this comment.
The buildah example looks nice. Something like that could be fun. Looking forward to see this in action.
|
/approve |
openshift-ci-robot
added
the
approved
docs/proposals/cli.md
Outdated
| $ kubectl shp ... | ||
| ``` | ||
|
|
||
| And the following global parameters are expected, to keep consistency with `kubectl`: |
| $ shp <resource> <verb> <name> [options] | ||
| ``` | ||
|
|
||
| For example: |
There was a problem hiding this comment.
The examples below do not follow the above mentioned shp <resource> <verb> syntax.
| $ shp logs nodejs-ex | ||
| ``` | ||
|
|
||
| During the review process of this enhancement proposal, we must decide which pattern suits better, |
There was a problem hiding this comment.
+1 for the shp <verb> <resource> pattern
|
|
||
| The testing structure will be composed of: | ||
|
|
||
| - **Unit**: written in Golang and using [Gomega](https://onsi.github.io/gomega/) for assertion; |
There was a problem hiding this comment.
Not sure if this belongs here, but I would prefer to forgo using Gomega and stick with pure go tests.
|
@otaviof We fixed an issue on CI, maybe you can rebase on top of master |
otaviof
dismissed
gabemontero’s stale review
Changes were applied accordingly.
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: HeavyWombat, qu1queee The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Enhancement proposal for creating a command-line interface for Shipwright's Build. A proof-of-concept implementation can be found on otaviof/shp.
Linked with issue #382, creates the foundation for #59.
Preview Videos