update wskdeploy docs to reflect it being a subcommand of wsk

[dgrove-oss]

http://openwhisk.apache.org/documentation.html#wskdeploy should be reworked to reflect wskdeploy now being bundled as a sub-command of wsk

[pritidesai]

thanks @dgrove-oss yup, agree, need to update the website as well

[Amndeep7]

Bump: apache/openwhisk-wskdeploy#1109

I can change that one paragraph, but I'm not sure what yall wanna do for the rest of that section considering that recent wskdeploy releases no longer have binaries attached so if one were dedicated to using wskdeploy as opposed to wsk project then they're going to have to build it themselves.

[dgrove-oss]

@mrutkows - opinions? coming up on two years now and the docs are still out of date.

[rabbah]

I think the references to wskdeploy can be replaced with references to the wsk CLI instead, including amending the command line example.

[mrutkows]

@dgrove-oss @rabbah It had been my intent to maintain a wskdeploy (standalone) binary as well as the "deploy" command within the CLI since one can create automation with just the wskdeploy executable and not install the CLI. I did not recall seeing anyone change that; releases never have official binaries; we did release "convenience" binaries. The website docs should reflect both the standalone instructions (as secondary) as well as the "deploy" command as part of CLI (primary).

[mrutkows]

@dgrove-oss @rabbah I no longer see the releases tab under the GitHub repo. did this get removed by Apache Infra.??? How do we get it back?

The website docs were updated: https://openwhisk.apache.org/documentation.html#wskdeploy
and apparently, they reference the (no hidden) releases link: https://github.com/apache/openwhisk-wskdeploy/releases

As I said, I do not recall (forgive if I truly forgot) no longer supplying binaries... assume this was some Apache decision to avoid legal issues around graduation time? If so, would love to add them back.

[Amndeep7]

@mrutkows The releases "tab" was moved by a UI update by Github a while back to instead be a section on the column on the right hand side.

[mrutkows]

@Amndeep7 I would like to revisit the decision to not produce wskdeploy binaries... as I truly do not recall agreeing to no longer do this but assume some discussion was had and this was required to allow us to graduate and/or simplify/streamline processes.

[dgrove-oss]

is there an active maintainer for wskdeploy? If so, their first step would be to get it passing travis builds again. been broken for months.

[mrutkows]

@dgrove-oss I saw that 2 weeks ago and assume your key changes work... trying to find time... would like to merge you travis/key PR and then see why those 2 integration tests are failing against golang runtime.

The last I had time/left it (PR merged) it built fine which was Sept. when I forced into an emergency assignment. The first indication it did no longer build was your Travis PR apache/openwhisk-wskdeploy#1108 which was Dec. 17th and did not see until under 2 weeks ago as I was not actively working. This is likely due to a change YE2020 in ICF support for golang or other images.

[mrutkows]

@dgrove-oss and Dave please know that resources have become rather scarce/tenuous and I have been trying to add new professionals as part of our Jumpstart program each of the last 3 quarters.

[dgrove-oss]

The reason why there are no connivence binarys with the 1.1.0 release of wskdeploy is that the wskdeploy build failed due to changes in golang runtime versions and no one had the bandwidth to fix it. If wskdeploy built and passed its own test suite, all of the machinery is still in place to publish images.

https://travis-ci.org/github/apache/openwhisk-wskdeploy/builds/732114326