For the main repo, the sources from which the zips are made should also be in the repo. We can create a build.sh script to generate the zipped artifacts for the tests (and avoid changing the tests). I can do that if there are no takers. Maybe create a similar issue for the main repo with help wanted/good first issue tags.
-r On Tue, Sep 17, 2019 at 9:17 AM David P Grove <gro...@us.ibm.com> wrote: > > > > Carlos Santana <csantan...@gmail.com> wrote on 09/15/2019 06:22:19 PM: > > > > Even if want to we should not include in the release tgz anything > > that is not simple source code files (ie jar,zip,binaryexec) > > > > The released tgz can contain files and scripts (also files) that > > could generate those artifacts (jar, zip, binaryexec) > > > > This is my understanding > > > > As a receiver of the released tgz to use in a comercial product I > > would not trust those type of files (jar, zip, binaryexec), but I > > would be ok to run some commands using the content of the tgz to > > generate the test features artifacts (jar,zip, binaryexec) that > > allow me to run the tests. > > > > Makes sense. > > To make progress on getting a cli 1.0.0 out, I am going to make a src > release that simply excludes wskdeploy's integration tests. I don't have > the bandwidth to actually fix the underlying problem in wskdeploy test > suite. I opened [1] if someone wants to pick it up. > > We're going to have the exact same problem with the tests/dat tree of the > core repo. Would be great if someone wants to look at dealing with that so > we can progress on getting a core release out to let us publicize > standalone. > > --dave > > [1] https://github.com/apache/openwhisk-wskdeploy/issues/1073 >
