Re: Avatica CI test failures
Quick update: I was able to use docker hub's hooks to set the release version of the docker images during build time as suggested by Vladimir. In addition, I was also able to automate the publishing of the Avatica HSQLDB image (CALCITE1948 [1]). The trick to publishing the HSQLDB image is quite simple. Docker hub provides a post_push hook that is executed when a dockerfile is pushed to the registry. I simply use it to build the HSQLDB dockerfile and push it to a separate HSQLDB docker repository after the vanilla avatica image is built. I was able to push to multiple different repositories using the post_push hook, so it should come in handy if we need to publish other flavors of the Avatica image in the future. Note that due to docker hub's requirement of the Dockerfile location in the automated build configuration, I had to move the dockerfile for the HSQLDB image into the same folder as the vanilla avatica image, otherwise nothing will build. See my commit here: https://github.com/F21/calcite-avatica/commit/c772c978df5d74e8b4faec85d3a03a0bea89887f Docker hub repositories of the pushed test images are here: - https://hub.docker.com/r/f21global/calcite-avatica-test/ - https://hub.docker.com/r/f21global/calcite-avatica-hypersql-test2/ - https://hub.docker.com/r/f21global/calcite-avatica-hypersql-test1/ If this solution is acceptable, I propose that we close CALCITE-1948 and open a new issue encompassing the publication of the HSQLDB image and publication of the avatica image using docker hub hooks. I will then finalize the commit and we should be able to get it into 1.13.0-rc0, which I plan to make available tomorrow. I will then ask infra to create the apache/calcite-avatica-hsqldb repository on docker hub as a non-automated build, so we should have a HSQLDB avatica image published once 1.13.0 is release. Francis [1] https://issues.apache.org/jira/browse/CALCITE-1948 On 22/11/2018 5:41 am, Vladimir Sitnikov wrote: I'm not sure what combination of plugins would be best to do this Josh, you might have missed, yet there's an option to add DockerHub hook files to the repository, and DockerHub will execute them at build. Then no replacements would be required. What do you think? Vladimir
Re: Avatica CI test failures
I made an initial attempt at replacing the AVATICA_VERSION in the dockerfiles during a build using the maven-replacer-plugin and the scm plugin. Unfortunately, I was not able to get it to work correctly. The commit is here: https://github.com/F21/calcite-avatica/commit/d3f13910e6db1fbe536933c1c7c619bfdd5f5c93 I won't have any more time to look at it for the rest of the week. If someone wants to take a stab, please check out the commit. While researching how to implement this, I came across an answer on StackOverflow where the author outlined some issues with this approach: https://stackoverflow.com/a/47817363/624884 In summary, they used scm:checkin to commit the files. This meant that they will also be committed even when the -DdryRun=true argument is used. I tried scm:add in my own version, but couldn't get the files to update or change. I think using docker hooks per Vladimir's suggestion is probably the simplest way. The implementation is quite simple, we simply set ARG AVATICA_VERSION to empty in our dockerfiles. We then create files in the hooks folder for each build phase of the dockerfiles we want to intercept. The hook would just be a simple bash script where we can pass the tag being built to the docker build command. See an example of one I implemented for one of my projects here: https://github.com/Boostport/kubernetes-vault/blob/master/cmd/init/hooks/build If there is consensus on using docker hooks, I think it should be possible to get that included into the 1.13.0-rc0 release. On 22/11/2018 5:41 am, Vladimir Sitnikov wrote: I'm not sure what combination of plugins would be best to do this Josh, you might have missed, yet there's an option to add DockerHub hook files to the repository, and DockerHub will execute them at build. Then no replacements would be required. What do you think? Vladimir
Re: Avatica CI test failures
>I'm not sure what combination of plugins would be best to do this Josh, you might have missed, yet there's an option to add DockerHub hook files to the repository, and DockerHub will execute them at build. Then no replacements would be required. What do you think? Vladimir
Re: Avatica CI test failures
Actually, I think filtering in the version is a good idea. I should have thought of that one on my own :P. Thanks for the suggestion, Vladimir! Looks like the Dockerhub stuff is still WIP (at least, that issue is still open). I'm not sure what combination of plugins would be best to do this (maven-resources-plugin might be enough). I might have some time over the holiday weekend to look at this. On 11/21/18 6:29 AM, Francis Chuang wrote: I think using dockerhub's hooks is definitely, an option. Josh, what do you think? Then we can get rid of the stuff in the pom.xml to validate the version number in the dockerfiles. The downside is that anyone building the images on their own machine would have to pass in the AVATICA_VERSION environment variable manually, but these files are under the dockerhub folder, so it should be clear that they are used to publish images to dockerhub. There are other Dockerfiles under the dockerfolder for building a snapshot docker image on your own system and those can still be used without having to pass in the AVATICA_VERSION environment variable. On 21/11/2018 10:02 pm, Vladimir Sitnikov wrote: Francis>We do need the dockerfiles with the correct version numbers Francis>committed to git, because once we tag a release, docker hub will build Francis>the docker images from those dockerfiles and publish them to docker hub I see, then replacement the source file + commit might be a way to go here indeed. By the way, have you considered DockerHub's hooks/variables to perform the replacement on build? For instance: https://github.com/docker/hub-feedback/issues/508#issuecomment-243968310 What do you think? Vladimir
Re: Avatica CI test failures
I think using dockerhub's hooks is definitely, an option. Josh, what do you think? Then we can get rid of the stuff in the pom.xml to validate the version number in the dockerfiles. The downside is that anyone building the images on their own machine would have to pass in the AVATICA_VERSION environment variable manually, but these files are under the dockerhub folder, so it should be clear that they are used to publish images to dockerhub. There are other Dockerfiles under the dockerfolder for building a snapshot docker image on your own system and those can still be used without having to pass in the AVATICA_VERSION environment variable. On 21/11/2018 10:02 pm, Vladimir Sitnikov wrote: Francis>We do need the dockerfiles with the correct version numbers Francis>committed to git, because once we tag a release, docker hub will build Francis>the docker images from those dockerfiles and publish them to docker hub I see, then replacement the source file + commit might be a way to go here indeed. By the way, have you considered DockerHub's hooks/variables to perform the replacement on build? For instance: https://github.com/docker/hub-feedback/issues/508#issuecomment-243968310 What do you think? Vladimir
Re: Avatica CI test failures
Francis>We do need the dockerfiles with the correct version numbers Francis>committed to git, because once we tag a release, docker hub will build Francis>the docker images from those dockerfiles and publish them to docker hub I see, then replacement the source file + commit might be a way to go here indeed. By the way, have you considered DockerHub's hooks/variables to perform the replacement on build? For instance: https://github.com/docker/hub-feedback/issues/508#issuecomment-243968310 What do you think? Vladimir
Re: Avatica CI test failures
On 21/11/2018 8:04 pm, Vladimir Sitnikov wrote: I mean by direct replacement is that What is the purpose of those files? The files are used to build docker images. Do you mean end users should build docker files manually? The files should not be built manually. However, if the user wants to, he can build docker images from the dockerfiles. Do you intend to publish them as a part of Avatica release? They are part of the source distribution, but not part of any jars we publish. We do need the dockerfiles with the correct version numbers committed to git, because once we tag a release, docker hub will build the docker images from those dockerfiles and publish them to docker hub. Vladimir
Re: Avatica CI test failures
>I mean by direct replacement is that What is the purpose of those files? Do you mean end users should build docker files manually? Do you intend to publish them as a part of Avatica release? Vladimir
Re: Avatica CI test failures
There are currently 2 Dockerfiles where we need to update the version numbers: - https://github.com/apache/calcite-avatica/blob/master/docker/src/main/dockerhub/Dockerfile - https://github.com/apache/calcite-avatica/blob/master/docker/src/main/dockerhub-hypersql/Dockerfile What I mean by direct replacement is that the maven replacer plugin directly updates the version number in those 2 files (AVATICA_VERSION=...) and then use the maven scm plugin to commit them to the repository. On 21/11/2018 7:25 pm, Vladimir Sitnikov wrote: direct replacement in the target file acceptable What do you mean by that? Vladimir
Re: Avatica CI test failures
>direct replacement in the target file acceptable What do you mean by that? Vladimir
Re: Avatica CI test failures
That makes sense! In Java do people tend to use templates for these
cases or is direct replacement in the target file acceptable?
I am currently looking at the replacement plugin
(https://code.google.com/archive/p/maven-replacer-plugin/) to replace
the `AVATICA_VER` lines in the dockerfiles directly using regex for the
direct replacement case. However, if templates are how things are
generally used in Java, the resources plugin would work well.
Francis
On 21/11/2018 7:00 pm, Vladimir Sitnikov wrote:
Francis>I am not too familiar with maven and its plugins, but from my
understanding
Typical Maven convention is to place the "template" file to
src/main/resources, then maven-resources-plugin would "filter" (==replace)
properties in the file and place the result into target/classes/...
For instance, it would replace ${project.version} with relevant value.
Does that work for you?
Vladimir
Re: Avatica CI test failures
Francis>I am not too familiar with maven and its plugins, but from my
understanding
Typical Maven convention is to place the "template" file to
src/main/resources, then maven-resources-plugin would "filter" (==replace)
properties in the file and place the result into target/classes/...
For instance, it would replace ${project.version} with relevant value.
Does that work for you?
Vladimir
Re: Avatica CI test failures
This is excellent! This also means that we do not have to manually update the dockerfile during a release. I think we have 2 options here: - Keep the dockerfile in dockerfile.template and during release, replace placeholders inside the file and replace the dockerfile file in the repository using some maven automation - During release update the version number in the dockerfile using some maven automation. I am not too familiar with maven and its plugins, but from my understanding the maven-release plugin is able to update the version numbers in the various pom.xml files. Is the plugin able to do the same for arbitrary files in the repository (preferably using regex if we want it to update the dockerfile directly as in option 2) ? Francis On 21/11/2018 5:50 pm, Vladimir Sitnikov wrote: Francis, can you just generate the Dockerfile **during** the build? I guess you can generate the file with proper version, then "docker-check" would be obsolete. Am I missing something? Vladimir
Re: Avatica CI test failures
Francis, can you just generate the Dockerfile **during** the build? I guess you can generate the file with proper version, then "docker-check" would be obsolete. Am I missing something? Vladimir
Re: Avatica CI test failures
I think the original proposed approach of using `-DskipDockerCheck` is not possible to implement in maven. My original implementation is to implement profile activation using a property for the docker-check profile: !skipDockerCheck Unfortunately, properties work on a global basis, so, as long as the skipDockerCheck property is not present, the profile will be activated, hence all executions of maven will need `-DskipDockerCheck` to avoid the check. Options I considered, but do not work: - Can we peg the docker check profile to a goal? Unsupported in Maven: https://stackoverflow.com/questions/15964170/how-to-activate-profile-based-on-goal-being-executed - Can we set a property in the root pom.xml under the "apache-release" profile and read the property in the docker-check profile to activate it? No: https://stackoverflow.com/questions/46927776/maven-child-profile-activated-on-parent-profile-property Potential options for fixing this: - The profile was originally named "apache-release", so that it would be activated with -Papache-release (which is also the name of the release profile in the pom.xml in the root of the project). We can rename the profile for the docker check to "docker-check". Then, when making a real release, we use `-Papache-release,docker-check`. When making a dry-run release, we just use `-Papache-release`. - We use a property, but make it positive. So, when building a real release, we pass in `-DdockerCheck` to run the check. The downside of these 2 approaches are: - Disabling the docker check is not an exception, you will need to specifically request it to run the check. - It's possible to build releases with broken dockerfiles if the docker check is neglected. Please let me know your thoughts. Francis On 21/11/2018 9:12 am, Josh Elser wrote: Thanks. The first red build I saw was after your change had landed. I may be wrong, but I think that's how we got here :) On 11/20/18 4:37 PM, Francis Chuang wrote: Oh dear! I was under the impression that the builds were breaking before the fix for CALCITE-2385 was committed, but I was wrong! I'll try to get this fixed today. On 21/11/2018 3:57 am, Josh Elser wrote: Wait, back up a second? Francis -- did you break every other build just to try to fix CALCITE-2385? We should not have had to be making changes to CI just to make this work... On 11/19/18 4:04 PM, Francis Chuang wrote: Thanks for organizing that, Michael! Kevin: Currently, all builds will fail without -DskipDockerCheck in place. I was hoping there is some way to configure Maven to run the docker check when the goal is release:prepare and the -DdryRun argument is not present, however there doesn't seem to be a way to do this with the maven release plugin. The disadvantage of reversing the logic (so that the docker check is triggered on the specification of the argument) is that it's possible to create a broken release with the wrong version numbers in the Dockerfiles if -DcheckDocker is accidentally omitted. My original thought was to make the ability to skip the check an exception (similar to -DskipTests). Please let me know your thoughts Francis On 20/11/2018 4:27 am, Kevin Risden wrote: So is it possible to change the logic so this only gets triggered during a release? Seems weird to have to specify -DskipDockerCheck on a regular build. My local jenkins has been failing too and I'm hesitant to make the same change. I would guess builds from the command line will fail too? Kevin Risden On Mon, Nov 19, 2018 at 12:07 PM Michael Mior wrote: No problem. I also gave you access so you should be able to do this yourself in the future. Let me know if that doesn't seem to have worked. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 21:10, Francis Chuang a écrit : Thanks, Michael! On 19/11/2018 11:37 am, Michael Mior wrote: Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : This is the latest test failure for Avatica on Jenkins: https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console It looks like the failure is due to check-dockerhub-dockerfile-version. This check always fails during development or release:prepare -DdryRun, because it relies on tags and version numbers that are only available when we are making a release for real. I committed a fix for CALCITE-2385 [1] to fix this. I am not able to update the CI configuration for Jenkins, but can someone update it to include the -DskipDockerCheck argument to fix it? For Travis, the cause of the test failures is also the same and I updated the .travis.yml file to fix it. [1] https://issues.apache.org/jira/browse/CALCITE-2385
Re: Avatica CI test failures
Thanks. The first red build I saw was after your change had landed. I may be wrong, but I think that's how we got here :) On 11/20/18 4:37 PM, Francis Chuang wrote: Oh dear! I was under the impression that the builds were breaking before the fix for CALCITE-2385 was committed, but I was wrong! I'll try to get this fixed today. On 21/11/2018 3:57 am, Josh Elser wrote: Wait, back up a second? Francis -- did you break every other build just to try to fix CALCITE-2385? We should not have had to be making changes to CI just to make this work... On 11/19/18 4:04 PM, Francis Chuang wrote: Thanks for organizing that, Michael! Kevin: Currently, all builds will fail without -DskipDockerCheck in place. I was hoping there is some way to configure Maven to run the docker check when the goal is release:prepare and the -DdryRun argument is not present, however there doesn't seem to be a way to do this with the maven release plugin. The disadvantage of reversing the logic (so that the docker check is triggered on the specification of the argument) is that it's possible to create a broken release with the wrong version numbers in the Dockerfiles if -DcheckDocker is accidentally omitted. My original thought was to make the ability to skip the check an exception (similar to -DskipTests). Please let me know your thoughts Francis On 20/11/2018 4:27 am, Kevin Risden wrote: So is it possible to change the logic so this only gets triggered during a release? Seems weird to have to specify -DskipDockerCheck on a regular build. My local jenkins has been failing too and I'm hesitant to make the same change. I would guess builds from the command line will fail too? Kevin Risden On Mon, Nov 19, 2018 at 12:07 PM Michael Mior wrote: No problem. I also gave you access so you should be able to do this yourself in the future. Let me know if that doesn't seem to have worked. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 21:10, Francis Chuang a écrit : Thanks, Michael! On 19/11/2018 11:37 am, Michael Mior wrote: Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : This is the latest test failure for Avatica on Jenkins: https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console It looks like the failure is due to check-dockerhub-dockerfile-version. This check always fails during development or release:prepare -DdryRun, because it relies on tags and version numbers that are only available when we are making a release for real. I committed a fix for CALCITE-2385 [1] to fix this. I am not able to update the CI configuration for Jenkins, but can someone update it to include the -DskipDockerCheck argument to fix it? For Travis, the cause of the test failures is also the same and I updated the .travis.yml file to fix it. [1] https://issues.apache.org/jira/browse/CALCITE-2385
Re: Avatica CI test failures
Oh dear! I was under the impression that the builds were breaking before the fix for CALCITE-2385 was committed, but I was wrong! I'll try to get this fixed today. On 21/11/2018 3:57 am, Josh Elser wrote: Wait, back up a second? Francis -- did you break every other build just to try to fix CALCITE-2385? We should not have had to be making changes to CI just to make this work... On 11/19/18 4:04 PM, Francis Chuang wrote: Thanks for organizing that, Michael! Kevin: Currently, all builds will fail without -DskipDockerCheck in place. I was hoping there is some way to configure Maven to run the docker check when the goal is release:prepare and the -DdryRun argument is not present, however there doesn't seem to be a way to do this with the maven release plugin. The disadvantage of reversing the logic (so that the docker check is triggered on the specification of the argument) is that it's possible to create a broken release with the wrong version numbers in the Dockerfiles if -DcheckDocker is accidentally omitted. My original thought was to make the ability to skip the check an exception (similar to -DskipTests). Please let me know your thoughts Francis On 20/11/2018 4:27 am, Kevin Risden wrote: So is it possible to change the logic so this only gets triggered during a release? Seems weird to have to specify -DskipDockerCheck on a regular build. My local jenkins has been failing too and I'm hesitant to make the same change. I would guess builds from the command line will fail too? Kevin Risden On Mon, Nov 19, 2018 at 12:07 PM Michael Mior wrote: No problem. I also gave you access so you should be able to do this yourself in the future. Let me know if that doesn't seem to have worked. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 21:10, Francis Chuang a écrit : Thanks, Michael! On 19/11/2018 11:37 am, Michael Mior wrote: Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : This is the latest test failure for Avatica on Jenkins: https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console It looks like the failure is due to check-dockerhub-dockerfile-version. This check always fails during development or release:prepare -DdryRun, because it relies on tags and version numbers that are only available when we are making a release for real. I committed a fix for CALCITE-2385 [1] to fix this. I am not able to update the CI configuration for Jenkins, but can someone update it to include the -DskipDockerCheck argument to fix it? For Travis, the cause of the test failures is also the same and I updated the .travis.yml file to fix it. [1] https://issues.apache.org/jira/browse/CALCITE-2385
Re: Avatica CI test failures
Wait, back up a second? Francis -- did you break every other build just to try to fix CALCITE-2385? We should not have had to be making changes to CI just to make this work... On 11/19/18 4:04 PM, Francis Chuang wrote: Thanks for organizing that, Michael! Kevin: Currently, all builds will fail without -DskipDockerCheck in place. I was hoping there is some way to configure Maven to run the docker check when the goal is release:prepare and the -DdryRun argument is not present, however there doesn't seem to be a way to do this with the maven release plugin. The disadvantage of reversing the logic (so that the docker check is triggered on the specification of the argument) is that it's possible to create a broken release with the wrong version numbers in the Dockerfiles if -DcheckDocker is accidentally omitted. My original thought was to make the ability to skip the check an exception (similar to -DskipTests). Please let me know your thoughts Francis On 20/11/2018 4:27 am, Kevin Risden wrote: So is it possible to change the logic so this only gets triggered during a release? Seems weird to have to specify -DskipDockerCheck on a regular build. My local jenkins has been failing too and I'm hesitant to make the same change. I would guess builds from the command line will fail too? Kevin Risden On Mon, Nov 19, 2018 at 12:07 PM Michael Mior wrote: No problem. I also gave you access so you should be able to do this yourself in the future. Let me know if that doesn't seem to have worked. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 21:10, Francis Chuang a écrit : Thanks, Michael! On 19/11/2018 11:37 am, Michael Mior wrote: Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : This is the latest test failure for Avatica on Jenkins: https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console It looks like the failure is due to check-dockerhub-dockerfile-version. This check always fails during development or release:prepare -DdryRun, because it relies on tags and version numbers that are only available when we are making a release for real. I committed a fix for CALCITE-2385 [1] to fix this. I am not able to update the CI configuration for Jenkins, but can someone update it to include the -DskipDockerCheck argument to fix it? For Travis, the cause of the test failures is also the same and I updated the .travis.yml file to fix it. [1] https://issues.apache.org/jira/browse/CALCITE-2385
Re: Avatica CI test failures
I think a detail that was dropped here is that this only affects a `deploy`, not a normal dev build. Re-reading the context on CALCITE-2385 reminded me about what exactly Francis was trying to do. This shouldn't being affecting the average person, just those deploying SNAPSHOTs by hand. There may be some trickery done in Maven to work around this, but I don't have the time to look into that presently. On 11/19/18 12:27 PM, Kevin Risden wrote: So is it possible to change the logic so this only gets triggered during a release? Seems weird to have to specify -DskipDockerCheck on a regular build. My local jenkins has been failing too and I'm hesitant to make the same change. I would guess builds from the command line will fail too? Kevin Risden On Mon, Nov 19, 2018 at 12:07 PM Michael Mior wrote: No problem. I also gave you access so you should be able to do this yourself in the future. Let me know if that doesn't seem to have worked. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 21:10, Francis Chuang a écrit : Thanks, Michael! On 19/11/2018 11:37 am, Michael Mior wrote: Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : This is the latest test failure for Avatica on Jenkins: https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console It looks like the failure is due to check-dockerhub-dockerfile-version. This check always fails during development or release:prepare -DdryRun, because it relies on tags and version numbers that are only available when we are making a release for real. I committed a fix for CALCITE-2385 [1] to fix this. I am not able to update the CI configuration for Jenkins, but can someone update it to include the -DskipDockerCheck argument to fix it? For Travis, the cause of the test failures is also the same and I updated the .travis.yml file to fix it. [1] https://issues.apache.org/jira/browse/CALCITE-2385
Re: Avatica CI test failures
Thanks for organizing that, Michael! Kevin: Currently, all builds will fail without -DskipDockerCheck in place. I was hoping there is some way to configure Maven to run the docker check when the goal is release:prepare and the -DdryRun argument is not present, however there doesn't seem to be a way to do this with the maven release plugin. The disadvantage of reversing the logic (so that the docker check is triggered on the specification of the argument) is that it's possible to create a broken release with the wrong version numbers in the Dockerfiles if -DcheckDocker is accidentally omitted. My original thought was to make the ability to skip the check an exception (similar to -DskipTests). Please let me know your thoughts Francis On 20/11/2018 4:27 am, Kevin Risden wrote: So is it possible to change the logic so this only gets triggered during a release? Seems weird to have to specify -DskipDockerCheck on a regular build. My local jenkins has been failing too and I'm hesitant to make the same change. I would guess builds from the command line will fail too? Kevin Risden On Mon, Nov 19, 2018 at 12:07 PM Michael Mior wrote: No problem. I also gave you access so you should be able to do this yourself in the future. Let me know if that doesn't seem to have worked. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 21:10, Francis Chuang a écrit : Thanks, Michael! On 19/11/2018 11:37 am, Michael Mior wrote: Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : This is the latest test failure for Avatica on Jenkins: https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console It looks like the failure is due to check-dockerhub-dockerfile-version. This check always fails during development or release:prepare -DdryRun, because it relies on tags and version numbers that are only available when we are making a release for real. I committed a fix for CALCITE-2385 [1] to fix this. I am not able to update the CI configuration for Jenkins, but can someone update it to include the -DskipDockerCheck argument to fix it? For Travis, the cause of the test failures is also the same and I updated the .travis.yml file to fix it. [1] https://issues.apache.org/jira/browse/CALCITE-2385
Re: Avatica CI test failures
So is it possible to change the logic so this only gets triggered during a release? Seems weird to have to specify -DskipDockerCheck on a regular build. My local jenkins has been failing too and I'm hesitant to make the same change. I would guess builds from the command line will fail too? Kevin Risden On Mon, Nov 19, 2018 at 12:07 PM Michael Mior wrote: > No problem. I also gave you access so you should be able to do this > yourself in the future. Let me know if that doesn't seem to have worked. > > -- > Michael Mior > mm...@apache.org > > > Le dim. 18 nov. 2018 à 21:10, Francis Chuang a > écrit : > > > Thanks, Michael! > > > > On 19/11/2018 11:37 am, Michael Mior wrote: > > > Thanks Francis! I updated the configuration on Jenkins and triggered a > > > rebuild and looks like things pass now. > > > > > > -- > > > Michael Mior > > > mm...@apache.org > > > > > > > > > Le dim. 18 nov. 2018 à 17:20, Francis Chuang > > > a > > > écrit : > > > > > >> This is the latest test failure for Avatica on Jenkins: > > >> > > >> > > > https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console > > >> > > >> It looks like the failure is due to > check-dockerhub-dockerfile-version. > > >> This check always fails during development or release:prepare > -DdryRun, > > >> because it relies on tags and version numbers that are only available > > >> when we are making a release for real. I committed a fix for > > >> CALCITE-2385 [1] to fix this. I am not able to update the CI > > >> configuration for Jenkins, but can someone update it to include the > > >> -DskipDockerCheck argument to fix it? > > >> > > >> For Travis, the cause of the test failures is also the same and I > > >> updated the .travis.yml file to fix it. > > >> > > >> [1] https://issues.apache.org/jira/browse/CALCITE-2385 > > >> > > >> > > > > >
Re: Avatica CI test failures
No problem. I also gave you access so you should be able to do this yourself in the future. Let me know if that doesn't seem to have worked. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 21:10, Francis Chuang a écrit : > Thanks, Michael! > > On 19/11/2018 11:37 am, Michael Mior wrote: > > Thanks Francis! I updated the configuration on Jenkins and triggered a > > rebuild and looks like things pass now. > > > > -- > > Michael Mior > > mm...@apache.org > > > > > > Le dim. 18 nov. 2018 à 17:20, Francis Chuang > a > > écrit : > > > >> This is the latest test failure for Avatica on Jenkins: > >> > >> > https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console > >> > >> It looks like the failure is due to check-dockerhub-dockerfile-version. > >> This check always fails during development or release:prepare -DdryRun, > >> because it relies on tags and version numbers that are only available > >> when we are making a release for real. I committed a fix for > >> CALCITE-2385 [1] to fix this. I am not able to update the CI > >> configuration for Jenkins, but can someone update it to include the > >> -DskipDockerCheck argument to fix it? > >> > >> For Travis, the cause of the test failures is also the same and I > >> updated the .travis.yml file to fix it. > >> > >> [1] https://issues.apache.org/jira/browse/CALCITE-2385 > >> > >> > >
Re: Avatica CI test failures
Thanks, Michael! On 19/11/2018 11:37 am, Michael Mior wrote: Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : This is the latest test failure for Avatica on Jenkins: https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console It looks like the failure is due to check-dockerhub-dockerfile-version. This check always fails during development or release:prepare -DdryRun, because it relies on tags and version numbers that are only available when we are making a release for real. I committed a fix for CALCITE-2385 [1] to fix this. I am not able to update the CI configuration for Jenkins, but can someone update it to include the -DskipDockerCheck argument to fix it? For Travis, the cause of the test failures is also the same and I updated the .travis.yml file to fix it. [1] https://issues.apache.org/jira/browse/CALCITE-2385
Re: Avatica CI test failures
Thanks Francis! I updated the configuration on Jenkins and triggered a rebuild and looks like things pass now. -- Michael Mior mm...@apache.org Le dim. 18 nov. 2018 à 17:20, Francis Chuang a écrit : > This is the latest test failure for Avatica on Jenkins: > > https://builds.apache.org/job/Calcite-Avatica-Master/129/jdk=JDK%201.8%20(latest),label_exp=ubuntu&&!cloud-slave/console > > It looks like the failure is due to check-dockerhub-dockerfile-version. > This check always fails during development or release:prepare -DdryRun, > because it relies on tags and version numbers that are only available > when we are making a release for real. I committed a fix for > CALCITE-2385 [1] to fix this. I am not able to update the CI > configuration for Jenkins, but can someone update it to include the > -DskipDockerCheck argument to fix it? > > For Travis, the cause of the test failures is also the same and I > updated the .travis.yml file to fix it. > > [1] https://issues.apache.org/jira/browse/CALCITE-2385 > >
