Hi Carlos, Your option makes sense. Instead of changing Gradle config I would see if I can check for required environment variables to be set. If not set then test would be cancelled [1]. This way just by setting environment variables test execution can be controlled
Would give this a try with CosmosDB PR Chetan Mehrotra [1] http://www.scalatest.org/user_guide/using_assertions#assumptions On Fri, Apr 20, 2018 at 4:44 PM, Carlos Santana <[email protected]> wrote: > Hi Chetan > > I proposed a new option 3 :-) > > We can configure Travis to skip this tests when the build is on PR and run > the tests when build is on master branch. > > So creating a new gradle task for it testLeanPR > > The same for doing the decryption of the secret will be done only when is not > a PR build. > > We already do this and I can work with you to setup I know I have some repos > doing this for ibmfunctions and I think wskdeploy also has similar Travis > setup using credentials > > If you do this configuration your PR will be green and will be able to merge > it into master. > > In terms running the tests on your branch on your fork for the PR, you can > setup your fork to run the Travis tests and share the link as comment on the > PR pointing to the Travis build passing and running the tests. > > With that then I think we can feel confident and merge the PR and the tests > will run again in master branch in main repo. > > > - Carlos Santana > @csantanapr > >> On Apr 20, 2018, at 5:21 AM, Chetan Mehrotra <[email protected]> >> wrote: >> >> Hi Team, >> >> For some of the work I am doing (CosmosDB integration [1], S3 >> AttachmentStore) the test need to be run against a remote cloud >> service and thus requires access to access keys. >> >> For CosmosDB PR I tried to read them from environment variables [2] >> and have them configured in the Travis settings for the repo. However >> it appears that those environment variables are not exposed for PR >> runs (for good reason) and instead are only accessible to PR which >> originate from same origin repo [3]. Due to this the build failed [4] >> for PR but passed on the build from fork [5] >> >> So I see following options >> >> 1. Have a branch in incubator-openwhisk repo and then create a PR from that. >> 2. Keep working on a branch in fork and then reviewers can run the >> test on there setup by providing the credentials directly. >> >> So any thoughts on how to proceed on this work? I prefer #1 but that >> would require me to work on a branch in incubator-openwhisk repo and >> create PR from that >> >> Chetan Mehrotra >> [1] https://github.com/apache/incubator-openwhisk/pull/3562 >> [2] >> https://github.com/apache/incubator-openwhisk/pull/3562/files#diff-4193e72115f45d80db211b31c0eeffd8 >> [3] https://blog.travis-ci.com/2013-06-10-secure-env-in-pull-requests >> [4] >> https://scans.gradle.com/s/pg4t4okpmhrle/tests/ubbzynwftyf6i-6kwrh3kd4tzye >> [5] https://travis-ci.org/chetanmeh/incubator-openwhisk/branches (see >> status for artifact-store-cosmos)
