[DO NOT MERGE]: Testing PR infrastructure.

[av8ramit]

No description provided.

[seanpmorgan]

@av8ramit @karmel I was wondering if we could get an update on the CI testing? Does it seem like there's a long-term issue or will it be resolved somewhat soon?

If it is long term then maybe we consider removing the git hook? It's tough to manage PRs with failing build markers throughout the repo

[av8ramit]

@seanpmorgan Trying to get this resolved as fast as possible.

[karmel]

@av8ramit Should @seanpmorgan be able to click through to see Py2 results now? @seanpmorgan , can you see them?

[seanpmorgan]

Py2 yes, Py3 no. Seems like its close 😄

[av8ramit]

I've only set up python2 for now. @karmel is currently reviewing python3 and I should hopefully have that up and running later today.

[av8ramit]

So unfortunately I cannot invoke a separate script (internal infrastructure reasons). I can only invoke bazel targets. I've mirrored your script for now and invoke the bazel targets after running configure.

@karmel @seanpmorgan can you confirm you can see the latest logs for both python2/3?

[seanpmorgan]

Can confirm py2 and py3 has publicly view-able results. So that I understand the process going forward, you'll need to mirror our CI script anytime its been updated... is that correct?

[av8ramit]

So here is what the internal script essentially does:

virtualenv -p python tf
source tf/bin/activate

pip install --upgrade pip

export CC_OPT_FLAGS='-mavx'
export TF_NEED_CUDA=0 # TODO: Verify this is used in GPU custom-op

export PYTHON_BIN_PATH=$(which python)

N_JOBS=$(grep -c ^processor /proc/cpuinfo)

./configure.sh

INTERNAL_BAZEL_COMMAND \
  test \
  -c opt -k \
  --jobs=${N_JOBS} --test_timeout 300,450,1200,3600 \
  --test_output=errors --local_test_jobs=8 \
  -- \
  //tensorflow_addons/...

So we will try and get to a point where we can just run a script, but like you said until then we may need to coordinate any large differences in your CI script to be mirrored.

[facaiy]

Hi, Amit. How can we trigger CI for contributor's PR? I try to apply kokoro:force-run label to #53, it fails unfortunately. Did I do something wrong?

[av8ramit]

I'm not sure. I'll need to debug why that is happening. Is there any way I can be temporarily given permissions to apply this label? Thanks for your patience as I set this up.

[karmel]

Ah, sorry, I responded in the offending issue-- there was a merge conflict, which was blocking tests.

[facaiy]

Could you check #53 ? I take a try again, and it still fails. It seems related with #70, we changed the location of the script.

logs:

Requirement already up-to-date: pip in ./tf/lib/python3.4/site-packages (19.0.3)

• /bin/bash ci_testing/addons_cpu.sh
  /bin/bash: ci_testing/addons_cpu.sh: No such file or directory

[facaiy]

I was a little wondering if we could use make unit-test (or bazel target?). If that, google might not need to care about the location of script any more?

[karmel]

Did we merge the move of the testing script? It looks like the attempt to call it in #53 is not finding the script-- /bin/bash: ci_testing/addons_cpu.sh: No such file or directory CC @av8ramit . We are all in a time crunch today, so if we don't get a chance to fix, you can trust the local runs for now.

[seanpmorgan]

Thanks for the follow-up, yes the script has been moved. This can wait until time allows because we've cut a release branch already for 0.1 and local tests are passing.

[av8ramit]

I've submitted a change internally to fix this. I've also changed the internal script to just invoke the addons_cpu.sh script.