Was something changed in build? Do I need some additional changes to build locally?

master build is passing https://github.com/airbytehq/airbyte/runs/1190634625 are you up to date on master?

yep. Just pulled it before running locally and cleaned all old images

can you prepend

clean

to whatever gradle command you are running?

e.g if you are running

./gradlew build

then run

./gradlew clean build

ok let me try to clean it.

Now works. Thank you a lot. Totally forgot to clean..

No problem! This Shouldn’t be happening really. If this ever happens again can you post the contents of build/ in here so we can find which files were causing the issue?

Sure. If I face it again - I will try to provide as much info as possible.

hmm, actually I have 1 more problem. On another PC I have next error for build ( even for clean one )

DockerProcessBuilderFactoryTest > testImageExists() FAILED
    org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
        at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39)
        at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40)
        at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:35)
        at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:162)
        at io.airbyte.workers.process.DockerProcessBuilderFactoryTest.testImageExists(DockerProcessBuilderFactoryTest.java:43)

ah i know the issue here. PR going up right now

https://airbytehq.slack.com/archives/C019WEENQRM/p1601564803046200 this happens when there are multiple java artifacts in the build folder. the COPY directive realizes there are multiple items that match the splay operator and tried to copy both, but can’t because our use of COPY assumes that only one thing will match that operator. the only reason you should have multiple artifacts match the splat operator is because the version of something has changed but the old artifact is not removed from the build dir. running clean gets rid of the old artifact which fixes this issue.

https://airbytehq.slack.com/archives/C019WEENQRM/p1601568188049900?thread_ts=1601564803.046200&cid=C019WEENQRM actually this issue shouldn’t happen if you have connectivity to dockerhub — does your other PC have connectivity to dockerhub?

all the test does is verify that it can download the image

airbyte/scheduler:dev

from docker, and the image exists here: https://hub.docker.com/layers/airbyte/scheduler/dev/images/sha256-8b066d0c797e56567e94282f644d12c9e6a874abd2c451cf42e53e59d9797fe9?context=explore, and the build passes CI on github which means it’s able to pull it from dockerhub

or it could happen with slow internet

he he. That may sound a bit insane but actually its just another PC at home. So it is in the same network and

docker-compose up

works fine on it.