Following the README, the "go get" command did automatically pull the go CLI, but did not get these new Cloud Foundry dependencies. This message is shown on command line building the development branch:

Currently when creating actions, the default location is the src folder under the manifest path, we need to support the source location is somewhere on the web, for example http://github.com/repo_name/path/action.js.

There is currently an experimental API for an API Gateway. We should investigate support for this API inside a manifest and/or deployment.

The experimental API currently runs in the CLI and we can derive the calls from running the CLI in verbose mode.

An example of possible syntax:

api-experimental:
    newbot:
      basepath: /whiskbot
      path: /newbot
      verb: get
      action: newbot

where the action is newbot, and the constructed API is a GET call with path /whiskbot/newbot

It would be useful to have a wskdeploy generate <package-name> or wskdeploy init <package-name> , which could prompt the user for basic information about a package and generate a starter manifest.yaml as well as a starter directory structure (e.g. a src directory). It could also generate a starter deployment.yaml-template file. That way, a developer can use wskdeploy almost exclusively from the start of development to deploy their OpenWhisk assets.

https://github.com/openwhisk/openwhisk-wskdeploy/branches/all

(see red X) on the PR on the link, although the "push" to development worked the "pull" did not.

With current codebase, when I try make build, the go will complain "fatal: repository 'https://github.com/openwhisk/go-whisk/' not found", because currently the repo doesn't exists.
So the import will fail.

If I change the package import source code to github.com/openwhisk/openwhisk/tools/cli/go-whisk/whisk, the go will complain that
" Installing dependencies
$GOPATH/src/github.com/openwhisk/openwhisk/tools/cli/go-whisk/whisk/client.go:31:5: local import "../wski18n" in non-local package"

Develop the first test case of Wsk Tool.
I recommend to use the "HelloWorld" use case.
I will submit the related files to "tests" folder.

Daisy

The i18n library:
"github.com/nicksnyder/go-i18n/i18n"

Has an ad-hoc license which may prevent us from exiting Apache incubator. Please find an alternative or attempt to remove. Otherwise we will need to submit it for legal review at the ASF.

Please add a section that shows how to run the command using "go" and also the known parameters using one of our test files.

We need to support the deployment of trigger & rule.
This function can be tested using tests/testcases/triggerrule

The third test case will support feed action. It uses the github hook as a sample. This use case will install a feed to fire a trigger when there is activity in a specified GitHub repository.

The package will deploy:
a feed action named as "webhook_feed"
a trigger named as "webhook_trigger"
a action named as "sendemail"

When the package is deployed successfully, it can be tested as following:
#Install package
$ wsktool deploy -p /tests/testcases/githubfeed
#When there is a "PUSH" event to the specified github, an email will be sent out.

Now the use cases contains sample ones, we need support real and more complex openwhisk packages use cases such as https://github.com/openwhisk/openwhisk-package-rss
Github feed advanced, polygen tracking etc mentioned in the specification.

I would like to create a new top-level file (which I intent to make a convention for all OpenWhisk family of projects) that lists all external libraries (e.g., imports) we rely upon to build (or run). The list should for convenience list the type of license and provide a hyperlink to that project/license for convenience when we need to provide reviews for Apache.

The goal is to become aware that in order to exit Apache incubator we must assure that all code dependencies have Apache 2.0 compatible licenses.

We deploy rule with the sample file, the rule deployment failed. With the error message:
Got error creating rule with error message: {{.msg}} (code {{.code}}) and error code: 144.

Other action, trigger, package creation failed, it seems related to this issue.
apache/openwhisk#1577

We need to investigate and fix this.

Need to check.

All openwhisk family projects should start with "openwhisk-".

Please note "master" and "development" or out of sync and should be have merges (from both sides) to sync them. Ideally, "master" should be "master" and reflect the working code for GA.

Add a travis file, so make sure all the tests(unitary, integration) are passed and build success, for a minimum gate before any merge of pr.

In my first build, I have to copy my local wsktool/utils folder and go-whisk to $GOPATH/src/github.com.
I think it should be resolved some time in the future.

We need to start supporting deployment file. According to the Specification, a Deployment file contains configuration information, e.g.

• input parameters
• authorization credentials
• namespaces

and so on.

There is a simple Deployment file in tests/testcases/triggerrule, with namespaces of application and packages, authorization credential of OW, and input parameters to rule. We can start the support of deployment file from this basic case.

Currently there are two yaml file to help deploy the wsk objects, one is deployment yaml and one is manifest yaml, if we need those 2 files, we'd better parse them in separate go modules, currently they are in one module. It's better to put them in 2 diff module.

wskdeploy --interactive-mode yes|no can toggle on and off any prompting. Default is no (or false), we should allow interactive mode.

With the new name, wskdeploy deploy is redundant. We should remove the deploy command and move its function into the wskdeploy root command

The current tool cannot reference other OpenWhisk packages as dependencies. At a minimum we should be able to pull in and reference entities in other packages w/o requiring the developer to copy the source code. This requires:

• create a module to parse dependency graph and validate it
• create feature to download/obtain dependencies into the current project path and be able to reference these from inside the manifest and deployment yaml files.

This is a large task and likely should be broken up into multiple issues.

As a starting step let's propose:

• support for getting a Github-based OpenWhisk package
• mange a semantic version applied to an entire deployment (as opposed to individual entities)

Add a makefile for wskdeploy, update README if necessary to tell customer how to use the tool.

It seems we need some conversion to get the detailed error message, as well as error code when there is error happened during deploying items onto openwhisk platform.

We need to:

• update parser to support feed
• update servicedeployer.go to support feed
• update the webhook test case.

We want a parser to support the elements in the manifest files of testcase1.
I'm going to make the following changes:

• utils/manifest.go will be added for manifest_full.yaml parser.
• tests/manifest_test.go will be added accordingly.
• remove deployment.go and test code according.
• Integrate manifest.go with deployerService.
• Add corresponding test cases for the integration.
• Refactor and change existing code if necessary.

wskdeploy --no-defaults yes | no (or true | false) should affect if we use file system conventions and allow default values for manifest file. Default is yes (we should not allow defaults)

Currently the manifest_full.yaml the action hello is hard coded, which makes parser a little bit confused, so the better action name would be action, and put the action name as a property?

Another issue, do we need to consider some web contents, I read the spec, it seems some action or whisk entities maybe on the web?

The OpenWhisk API has an existing Go package go-whisk that implements the OpenWhisk REST API. It is designed to be re-used by other applications. We should integrate our tool with this package to handle the network calls to an OpenWhisk instance.

go-whisk will provide us with:

• A REST API implementation
• A framework for adding i18n to our code

With the latest code change, the tool doesn't support solo -m or -d flags, it will prompt error messages, better keep backward compitable.

We need to conform to the convention established for all repos. under the OpenWhisk family. This is something we discussed among the initial committers for OpenWhisk under Apache as the established naming convention going forward. This will align us also with existing Apache project GitHub repos. conventions and ease any potential movement under a different org.

As we need to support more use cases and features, we added a lot of test cases datas to support more use cases, we also need to add test code and test cases to ensure the quality of the project.

Use case "Data Processing with MessageHub" needs an action sequence. We should support composition entity in wskdeploy.

Sample:

my_action_sequence:
    type: sequence
    sequence:
        - action_1
        - action_2
        - action_3
    inputs:
        simple_input_string: string
    outputs:
        annotated_output_string: string

This test case includes proposal for declaring sequence, use api-experimental, add annotations

We add a new "get" command to download information about the installed actions/trigger/rules.
The get should support get those information from different namespace etc.

testcase2 is based on testcase1 but it can be deployed and tested independently because the artifacts of testcase1 is included.

The testcase2 to deploy a basic trigger and rule based. The demo can be shown with following commands:

#deploy package, including
#Action "hello" is deployed
#Trigger "locationUpdate" is deployed
#Rule "myFirstRule" is deployed
$ wsktool deploy -p /tests/testcases/triggerrule
#Fire trigger "locationUpdate"
$ wsk trigger fire locationUpdate --param name Donald --param place "Washington, D.C."
#Verify "hello" is invoked
$ wsk activation list --limit 1 hello
$ wsk activation result ###############

Add a verify command which would read the manifest and deployment files, then check to see what is already installed in OpenWhisk.
This is a derivative of #93

Now if there is no default manifest/deployments yaml in current dir, the tool will panic with stack traces, which is not friendly to users, we need to improve this. We also need better description for basic commands currently already supported etc.

Example refactored manifest and deployment yaml. Also has example of properties based deployment file.

Currently the deploy were a default behavior under root command, and the manifest and deployment flag are global flags, we need to separate deploy/undeploy and corresponding
flags under each command. Add this issue to separate the refactor progress.

Of course we can always use "go get" flags to assure that the tool will automatically "pull" all dependent libs. that it finds; however, we should also make these library import (dependencies) explicit as well in our "godeps" file (i.e., https://github.com/openwhisk/wskdeploy/blob/master/Godeps/Godeps.json).

This SHOULD allow people to simply use "go get" with no flags as intended (for simplicity).

We need to think about how to integrate wskdeploy as a part of wsk cli. We may consider to use wsk deploy to invoke the real go program wskdeploy. Shall we integrate them at the source code level ? Or shall we integrate them at build level ?

We need to discuss how to support multiple packages deployment in a single command. There are two options:

• add multiple packages in a single manifest file
• use multiple manifest files, 1 package per a manifest

Let's discuss the solution here.

The goal would be to read a manifest file, then remove all entities currently deployed in OpenWhisk.

We could add a simple UI through web browser if user don't want to bother with Cli, it's perhaps more intuitive, we could wrap up go cli with a web server, and some basic HTML template.

Master branch tests failed, we need to fix it according to latest codes updates.

We also need to add a command to return the version of wskdeploy tool. As mentioned by apache/openwhisk#1677

We currently rely on .wskprops or the deployment.yaml file to specify the namespace and authkey. If these values are missing (because there is no .wskprops or its missing from the deployment.yaml), we should add prompts for the user to enter in the information during a deployment.

Currently the manifest and deployment yaml defined both some properties such as name space, package name etc, basically we deploy the entities by obey to the manifest file, but we need to add some check in the code level to make basic consistency, or hints to help user identify the errors.