A code generator for QingCloud & QingStor SDKs.
Snips generates various code for QingCloud and QingStor SDKs with API specifications in OpenAPI Specification (Swagger) v2.0 format.
Run snips --help
to get to help messages of snips.
$ snips --help
A code generator for QingCloud & QingStor SDKs.
It is used to generate code from our public APIs currently.
For example:
$ snips -m QingStor -n latest \
-s ./specs -t ./templates/qingstor/go \
-o ./publish/qingstor-sdk-go/service
$ ...
$ snips --service=QingStor \
--service-api-version=latest \
--spec=./specs \
--template=./templates/qingstor/ruby \
--output=./publish/qingstor-sdk-ruby/lib/qingstor/sdk/service
$ ...
Copyright (C) 2016 Yunify, Inc.
Usage:
snips [flags]
Flags:
-o, --output string Specify the output directory.
-m, --service string Choose the service to use.
-n, --service-api-version string Choose the service API version to use. (default "latest")
-s, --spec string Specify spec files directory.
--spec-format string Specify the format of spec file. (default "Swagger-v2.0")
-t, --template string Specify template files directory.
-v, --version Show version.
Snips is a command line tool, and it's easy to have it installed. You can build it from source code or download the precompiled binary directly.
Snips requires Go 1.6 or later's vendor feature, the dependencies the project
used are included in the vendor
directory. And we use [govendor]
govender link to manage project dependence.
go get -u github.com/yunify/snips
Notice: You can also use Go 1.5 with the GO15VENDOREXPERIMENT=1
.
- Go to releases tab and download the binary for your operating
system, for example
snips-v0.0.7-darwin_amd64.tar.gz
. - Unarchive the downloaded file, and put the executable file
snips
into a directory that in the$PATH
environment variable, for example/usr/local/bin
. - Run
snips --help
to get started.
Snips takes API specifications and template to generate lots of code for APIs, then these generated code plus the handcrafted code makes up the SDK. Next, we use scenario based test to make sure our SDKs are working properly, and ensure their functional consistency.
+---------------------------------------------+--------------------+
| | Workflow Diagram |
| API Specifications +--------------------|
| + |
| | Scenario |
| Templates | +-------------> Based |
| + | +------>SDKs Testing |
| | | | ^ + |
| | v | | | |
| +-----> Snips+---+ | | |
| | | |
| | v |
| Handcraft+------------------+ Publish |
| |
+------------------------------------------------------------------+
- Create handcraft files of SDK, to handle configuration, network request and etc.
- Writing templates for API code.
- Generate code using snips.
- Running tests.
- Publish.
- Change handcraft files (if needed) and update the API specs.
- Regenerate code.
- Running tests.
- Publish.
Let's take Go SDK for QingStor (qingstor-sdk-go
) for
example.
./specs/qingstor
: Refer to the QingStor API specifications./test/features
: Refer to the QingStor SDK test scenarios
Tips: Include these files as git submodule.
-
Create template files which will be used to generate API code in
./template
. -
Generate code using snips, and format the generated code.
$ snips --service=qingstor \ --service-api-version=latest \ --spec="./specs" \ --template="./template" \ --output="./service" Loaded templates from ./template 4 template(s) detected. Loaded service QingStor (2016-01-06) from ./specs Generating to: ./service/qingstor.go Generating to: ./service/object.go Generating to: ./service/bucket.go Generating to: ./service/types.go Everything looks fine. $ gofmt -w .
-
Implement test scenarios in
./test
.$ ls ./test bucket.go config.yaml.example test_config.yaml bucket_acl.go features test_config.yaml.example bucket_cors.go main.go utils.go bucket_external_mirror.go object.go vendor bucket_policy.go object_multipart.go config.yaml service.go
-
Running scenarios test, and pass all tests.
$ pushd ./test $ go run *.go ... 38 scenarios (38 passed) 84 steps (84 passed) 1m2.408357076s $ popd
-
Every time the QingStor API changes, just update the
specs/qingstor
and./test/features
submodule and regenerate code. Then add/change test for this API change, and rerun the online test to make sure the SDK is working properly.
Please see Contributing Guidelines
of this project
before submitting patches.
The Apache License (Version 2.0, January 2004).