Do not worry. It seems next to impossible to stumble upon this issue if
tests developed on 'prepared' machine. This seems to be a side effect of a
used library which seems difficult to expect.
Thanks for looking into that. FWIW I opened an issue and assigned it to you
[1]. Feel free to reach out t
Hi Michael,
I wrote that test and much of that code. I'm quite sorry about the trouble.
The test should use mocks and not hang when it's missing GCP dependencies.
That sounds like a bug in the test. We can deactivate it while I figure out
what's going wrong..
Best
-P.
On Sat, Mar 30, 2019, 2:55 PM
After digging a bit deeper, I was able to verify, that those tests block on
authorization to GCP.
Seems that, as I do not have any credentials set, and underlying oauth2
falls back to some local mode. This seems to start a webserver on port 8080
and waiting there forever. Accessing that port forwa
Again very valid concerns! I wouldn't take that step lightly (eg. testing
every single go using gradle task we have, if not testing that explicit
case).
A happier path would be that gogradle "just works" with go modules, and we
can avoid the whole awkward double lockfile state, and version mismatc
Exactly. What you have said is what we should move towards IMO.
On Tue, Mar 26, 2019 at 4:02 PM Michael Luckey wrote:
>
>
> On Tue, Mar 26, 2019 at 11:40 PM Kenneth Knowles wrote:
>
>> +1 to separating integration tests from "build". It should be able to
>> succeed without internet access (if d
On Tue, Mar 26, 2019 at 11:40 PM Kenneth Knowles wrote:
> +1 to separating integration tests from "build". It should be able to
> succeed without internet access (if deps are cached).
>
Big +1 here.
I d even suggest the following:
- ./gradlew build must succeed 'offline' (if deps cached)
- no f
On Tue, Mar 26, 2019 at 11:18 PM Mikhail Gryzykhin
wrote:
> I believe what happens is that testPy2Gcp actually runs integration tests
> that try to connect to GCP.
>
Actually I was hoping for an explanation like this. Any suggestion how I
could confirm that on my behalf?
> Without having GCP c
+1 to separating integration tests from "build". It should be able to
succeed without internet access (if deps are cached).
On Tue, Mar 26, 2019 at 3:18 PM Michael Luckey wrote:
> Of course, we could implement something here. But I am worried about the
> consequences. As gogradle writes into (us
Of course, we could implement something here. But I am worried about the
consequences. As gogradle writes into (user) global state this would have
unexpected side effects.
Consider a developer running Project A - which happens to also use gogradle
- and during build of that project issues an innoc
I believe what happens is that testPy2Gcp actually runs integration tests
that try to connect to GCP. Without having GCP cluster and configuration on
your machine I'd expect these tests to fail.
I'd say we should remove testPy2Gcp task from "build" task and explicitly
keep it as integration test.
On Tue, Mar 26, 2019 at 10:29 PM Udi Meiri wrote:
> Luckey, I couldn't recreate your issue, but I still haven't done a full
> build.
> I created a new GCE VM with using the ubuntu-1804-bionic-v20190212a image
> (n1-standard-4 machine type).
>
> Ran the following:
> sudo apt-get update
> sudo apt-
On Tue, Mar 26, 2019 at 9:35 PM Robert Burke wrote:
> Michael, your concern is reasonable, especially with the experience with
> python, though that does help me bootstrap this work. :)
>
> The go tools provide caching and avoid redoing work if the source files
> haven't changed.
>
Of course, th
Luckey, I couldn't recreate your issue, but I still haven't done a full
build.
I created a new GCE VM with using the ubuntu-1804-bionic-v20190212a image
(n1-standard-4 machine type).
Ran the following:
sudo apt-get update
sudo apt-get install python-pip
sudo apt-get install python-virtualenv
git c
Michael, your concern is reasonable, especially with the experience with
python, though that does help me bootstrap this work. :)
The go tools provide caching and avoid redoing work if the source files
haven't changed. This applies most particularly for `go build` and `go
test`. As long as the go
"rm -r ~/.gradle/go/repo/" worked for me (there was more than one package
with issues).
My ~/.bashrc has
export GOPATH=$HOME/go
so maybe that's making the difference in my setup.
On Tue, Mar 26, 2019 at 11:28 AM Thomas Weise wrote:
> Can this be addressed by having "clean" remove all state tha
Can this be addressed by having "clean" remove all state that gogradle
leaves behind? This staleness issue has bitten me a few times also and it
would be good to have a reliable way to deal with it, even if it involves
an extra clean.
On Tue, Mar 26, 2019 at 11:14 AM Michael Luckey wrote:
> @Ud
@Udi
Did you try to just delete the
'/usr/local/google/home/ehudm/.gradle/go/repo/cloud.google.com' folder?
@Robert
As said before, I am a bit scared about the implications. Shelling out is
done by python, and from build perspective, this does not work very well,
unfortunately. I.e. no caching, up
Reading the error from the gradle scan, it largely looks like some part of
the GCP dependencies for the build depends on a package, where the commit
version is no longer around. The main issue with gogradle is that it's
entirely distinct from the usual Go workflow, which means deps users use
are li
Robert, from what I recall it's not flaky for me - it consistently fails.
Let me know if there's a way to get more logging about this error.
On Mon, Mar 25, 2019, 19:50 Robert Burke wrote:
> It's concerning to me that 1) the Go dependency resolution via gogradle is
> flaky, and 2) that it can bl
It's concerning to me that 1) the Go dependency resolution via gogradle is
flaky, and 2) that it can block other languages.
I suppose 2) makes sense since it's part of the container bootstrapping
code, but that makes 1) a serious problem, of which I wasn't aware.
I should have time to investigate
Just for the record,
using a vm here, because did not yet get all task running on my mac, and
did not want to mess with my setup.
So installed vanilla ubuntu-18.04 LTS on virtual box, 26GB ram, 6 cores and
further
sudo apt update
sudo apt install gcc
sudo apt install make
sudo apt install per
Thanks Udi for trying that!
In fact, the go dependency resolution is flaky. Did not look into that, but
just rerunning usually works. Of course, less than optimal, but, well...
Running build target is of course just an aggregation of task to run. And
unfortunately just running that
./gradlew :b
It shouldn't stall. That's a bug.
OTOH, I never use the `build` target.
I'll try running that myself.
On Mon, Mar 25, 2019, 07:24 Michael Luckey wrote:
> Hi,
>
> trying to run './gradlew build' on vanilla setup, my build consistently
> stalls during execution of python gcp tests, e.g. on both of
Okay, `./gradlew build` failed pretty quickly for me:
> Task :beam-sdks-go:resolveBuildDependencies FAILED
cloud.google.com/go: commit='4f6c921ec566a33844f4e7879b31cd8575a6982d',
urls=[https://code.googlesource.com/gocloud] does not exist in
/usr/local/google/home/ehudm/.gradle/go/repo/
cloud.goog
Hi,
trying to run './gradlew build' on vanilla setup, my build consistently
stalls during execution of python gcp tests, e.g. on both of
- > :beam-sdks-python:testPy2Gcp
- > :beam-sdks-python-test-suites-tox-py35:testPy35Gcp
Console output:
snip
test_big_query_standard_sql
(apache_beam.
25 matches
Mail list logo
