[Searchlight][Zuul] tox failed tests at zuul check only
Hello, Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI? [1] https://review.openstack.org/#/c/619162/ Thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote:
Hello,
Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI?
Reading the exceptions [2] and the test setup code [3] it appears that elasticsearch isn't responding on its http port and is thus treated as having not started. With the info we currently have it is hard to say why. Instead of redirecting exec logs to /dev/null [4] maybe we can capture that data? Also probably worth grabbing the elasticsearch daemon log as well. Without that information it is hard to say why this happened. I am not aware of any changes in the CI system that would cause this, but we do rebuild our test node images daily. [2] http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-o... [3] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/... [4] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/... Clark
Hi Clark, Thanks for the update. I will try doing what you suggested. Bests, On Tue, Dec 4, 2018 at 1:39 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote:
Hello,
Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI?
Reading the exceptions [2] and the test setup code [3] it appears that elasticsearch isn't responding on its http port and is thus treated as having not started. With the info we currently have it is hard to say why. Instead of redirecting exec logs to /dev/null [4] maybe we can capture that data? Also probably worth grabbing the elasticsearch daemon log as well.
Without that information it is hard to say why this happened. I am not aware of any changes in the CI system that would cause this, but we do rebuild our test node images daily.
[2] http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-o... [3] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/... [4] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/...
Clark
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
Hi Clark, Outputting the exec logs does help. And, I found the problem for the functional tests to fail, it because ES cannot be started because of the way the functional sets up the new version of ES server (5.x). I'm working on updating it. Many thanks, On Tue, Dec 4, 2018 at 1:39 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote:
Hello,
Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI?
Reading the exceptions [2] and the test setup code [3] it appears that elasticsearch isn't responding on its http port and is thus treated as having not started. With the info we currently have it is hard to say why. Instead of redirecting exec logs to /dev/null [4] maybe we can capture that data? Also probably worth grabbing the elasticsearch daemon log as well.
Without that information it is hard to say why this happened. I am not aware of any changes in the CI system that would cause this, but we do rebuild our test node images daily.
[2] http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-o... [3] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/... [4] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/...
Clark
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
Hi again, Just wonder how the image for searchlight test was set up? Which user is used for running ElasticSearch? Is there any way to indicate the user that will run the test? Can I do it with [1]? Based on the output of [2] I can see there are some permission issue of JDK if I run the functional tests with the stack user on my dev environment. [1] https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.s... [2] https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__ini... Thanks, On Fri, Dec 7, 2018 at 4:30 PM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Hi Clark,
Outputting the exec logs does help. And, I found the problem for the functional tests to fail, it because ES cannot be started because of the way the functional sets up the new version of ES server (5.x). I'm working on updating it.
Many thanks,
On Tue, Dec 4, 2018 at 1:39 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote:
Hello,
Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI?
Reading the exceptions [2] and the test setup code [3] it appears that elasticsearch isn't responding on its http port and is thus treated as having not started. With the info we currently have it is hard to say why. Instead of redirecting exec logs to /dev/null [4] maybe we can capture that data? Also probably worth grabbing the elasticsearch daemon log as well.
Without that information it is hard to say why this happened. I am not aware of any changes in the CI system that would cause this, but we do rebuild our test node images daily.
[2] http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-o... [3] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/... [4] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/...
Clark
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
On Fri, Dec 7, 2018, at 8:17 AM, Trinh Nguyen wrote:
Hi again, Just wonder how the image for searchlight test was set up? Which user is used for running ElasticSearch? Is there any way to indicate the user that will run the test? Can I do it with [1]? Based on the output of [2] I can see there are some permission issue of JDK if I run the functional tests with the stack user on my dev environment.
[1] https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.s... [2] https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__ini...
The unittest jobs run as the Zuul user. This user has sudo access when test-setup.sh runs, but then we remove sudo access when tox is run. This is important as we are trying to help ensure that you can run tox locally without it making system level changes. When your test setup script runs `dpkg -i` this package install may start running an elasticsearch instance. It depends on how the package is set up. This daemon would run under the user the package has configured for that service. When you run an elasticsearch process from your test suite this will run as the zuul user. Hope this helps. I also left a couple of comments on change 622871. Clark
Thanks, Clark. On Sat, Dec 8, 2018 at 3:16 AM Clark Boylan <cboylan@sapwetik.org> wrote:
Hi again, Just wonder how the image for searchlight test was set up? Which user is used for running ElasticSearch? Is there any way to indicate the user
On Fri, Dec 7, 2018, at 8:17 AM, Trinh Nguyen wrote: that
will run the test? Can I do it with [1]? Based on the output of [2] I can see there are some permission issue of JDK if I run the functional tests with the stack user on my dev environment.
[1]
https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.s...
[2]
https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__ini...
The unittest jobs run as the Zuul user. This user has sudo access when test-setup.sh runs, but then we remove sudo access when tox is run. This is important as we are trying to help ensure that you can run tox locally without it making system level changes.
When your test setup script runs `dpkg -i` this package install may start running an elasticsearch instance. It depends on how the package is set up. This daemon would run under the user the package has configured for that service. When you run an elasticsearch process from your test suite this will run as the zuul user.
Hope this helps. I also left a couple of comments on change 622871.
Clark
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
Hi Clark, I'm trying to figure out how Zuul processes the test-setup.sh [1] file to adopt new dependencies. [1] https://github.com/openstack/searchlight/blob/master/tools/test-setup.sh Thanks, On Sat, Dec 8, 2018 at 9:10 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Thanks, Clark.
On Sat, Dec 8, 2018 at 3:16 AM Clark Boylan <cboylan@sapwetik.org> wrote:
Hi again, Just wonder how the image for searchlight test was set up? Which user is used for running ElasticSearch? Is there any way to indicate the user
On Fri, Dec 7, 2018, at 8:17 AM, Trinh Nguyen wrote: that
will run the test? Can I do it with [1]? Based on the output of [2] I can see there are some permission issue of JDK if I run the functional tests with the stack user on my dev environment.
[1]
https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.s...
[2]
https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__ini...
The unittest jobs run as the Zuul user. This user has sudo access when test-setup.sh runs, but then we remove sudo access when tox is run. This is important as we are trying to help ensure that you can run tox locally without it making system level changes.
When your test setup script runs `dpkg -i` this package install may start running an elasticsearch instance. It depends on how the package is set up. This daemon would run under the user the package has configured for that service. When you run an elasticsearch process from your test suite this will run as the zuul user.
Hope this helps. I also left a couple of comments on change 622871.
Clark
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote:
I'm trying to figure out how Zuul processes the test-setup.sh [1] file to adopt new dependencies. [...]
Looking at what you've put in there for your JRE packages, those would be better handled in a bindep.txt file in your repository. Running tools/test-setup.sh in jobs is really to catch other sorts of setup steps like precreating a database or formatting and mounting a particular filesystem your tests are going to rely on. For system package dependencies of your jobs, we have a declarative mechanism already which doesn't require complex conditional handling: we install whatever bindep says is missing. I see you're also leveraging tools/test-setup.sh to obtain packages of elasticsearch which are not available in the distributions on which your jobs run, which I guess is a suitable workaround though it seems odd to test on platforms which don't package the software on which your project relies. -- Jeremy Stanley
Thank Jeremy. I will look into bindep. On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote:
I'm trying to figure out how Zuul processes the test-setup.sh [1] file to adopt new dependencies. [...]
Looking at what you've put in there for your JRE packages, those would be better handled in a bindep.txt file in your repository. Running tools/test-setup.sh in jobs is really to catch other sorts of setup steps like precreating a database or formatting and mounting a particular filesystem your tests are going to rely on. For system package dependencies of your jobs, we have a declarative mechanism already which doesn't require complex conditional handling: we install whatever bindep says is missing.
I see you're also leveraging tools/test-setup.sh to obtain packages of elasticsearch which are not available in the distributions on which your jobs run, which I guess is a suitable workaround though it seems odd to test on platforms which don't package the software on which your project relies. -- Jeremy Stanley
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
Trying to look through the logs of the last merged patch set [1] but nothing there. Is there any other places that I can look into? [1] https://review.openstack.org/#/c/616056/ Thanks, On Wed, Dec 12, 2018 at 9:47 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Thank Jeremy. I will look into bindep.
On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote:
I'm trying to figure out how Zuul processes the test-setup.sh [1] file to adopt new dependencies. [...]
Looking at what you've put in there for your JRE packages, those would be better handled in a bindep.txt file in your repository. Running tools/test-setup.sh in jobs is really to catch other sorts of setup steps like precreating a database or formatting and mounting a particular filesystem your tests are going to rely on. For system package dependencies of your jobs, we have a declarative mechanism already which doesn't require complex conditional handling: we install whatever bindep says is missing.
I see you're also leveraging tools/test-setup.sh to obtain packages of elasticsearch which are not available in the distributions on which your jobs run, which I guess is a suitable workaround though it seems odd to test on platforms which don't package the software on which your project relies. -- Jeremy Stanley
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
Hi all, Finally, found the problem. For some reason, py27 has to wait a little bit longer for the elasticsearch instance to be up. I just let the functional setup code wait a little while. Problem solved. Amazing! :) Many thanks :) On Wed, Dec 12, 2018 at 11:37 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Trying to look through the logs of the last merged patch set [1] but nothing there. Is there any other places that I can look into?
[1] https://review.openstack.org/#/c/616056/
Thanks,
On Wed, Dec 12, 2018 at 9:47 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Thank Jeremy. I will look into bindep.
On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote:
I'm trying to figure out how Zuul processes the test-setup.sh [1] file to adopt new dependencies. [...]
Looking at what you've put in there for your JRE packages, those would be better handled in a bindep.txt file in your repository. Running tools/test-setup.sh in jobs is really to catch other sorts of setup steps like precreating a database or formatting and mounting a particular filesystem your tests are going to rely on. For system package dependencies of your jobs, we have a declarative mechanism already which doesn't require complex conditional handling: we install whatever bindep says is missing.
I see you're also leveraging tools/test-setup.sh to obtain packages of elasticsearch which are not available in the distributions on which your jobs run, which I guess is a suitable workaround though it seems odd to test on platforms which don't package the software on which your project relies. -- Jeremy Stanley
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
BTW, I switched to use the bindep.txt and make the test script much simpler. Thanks :) On Wed, Dec 12, 2018 at 5:35 PM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Hi all,
Finally, found the problem. For some reason, py27 has to wait a little bit longer for the elasticsearch instance to be up. I just let the functional setup code wait a little while.
Problem solved. Amazing! :)
Many thanks :)
On Wed, Dec 12, 2018 at 11:37 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Trying to look through the logs of the last merged patch set [1] but nothing there. Is there any other places that I can look into?
[1] https://review.openstack.org/#/c/616056/
Thanks,
On Wed, Dec 12, 2018 at 9:47 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Thank Jeremy. I will look into bindep.
On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote:
I'm trying to figure out how Zuul processes the test-setup.sh [1] file to adopt new dependencies. [...]
Looking at what you've put in there for your JRE packages, those would be better handled in a bindep.txt file in your repository. Running tools/test-setup.sh in jobs is really to catch other sorts of setup steps like precreating a database or formatting and mounting a particular filesystem your tests are going to rely on. For system package dependencies of your jobs, we have a declarative mechanism already which doesn't require complex conditional handling: we install whatever bindep says is missing.
I see you're also leveraging tools/test-setup.sh to obtain packages of elasticsearch which are not available in the distributions on which your jobs run, which I guess is a suitable workaround though it seems odd to test on platforms which don't package the software on which your project relies. -- Jeremy Stanley
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
On 2018-12-04 00:28:30 +0900 (+0900), Trinh Nguyen wrote:
Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI?
I don't know of any recent changes which would result in the indicated test failures. According to the log it looks like it's a functional testsuite and the tests are failing to connect to the search API. I don't see your job collecting any service logs however, so it's unclear whether the API service is failing to start, or spontaneously crashes, or something else is going on. My first guess would be that one of your dependencies has released and brought some sort of regression. According to http://zuul.openstack.org/builds?job_name=openstack-tox-py27&project=openstack%2Fsearchlight&branch=master the last time that job passed for your repo was 2018-11-07 with the installed package versions listed in the http://logs.openstack.org/56/616056/1/gate/openstack-tox-py27/e413441/tox/py... file, and the first failure I see matching the errors in yours ran with the versions in http://logs.openstack.org/62/619162/1/check/openstack-tox-py27/809a281/tox/p... on 2018-11-21 (it wasn't run for the intervening 2 weeks so we have a fairly large window of potential external breakage there). A diff of those suggests the following dependencies updated between them: coverage: 4.5.1 -> 4.5.2 cryptography: 2.3.1 -> 2.4.1 httplib2: 0.11.3 -> 0.12.0 oslo.cache: 1.31.1 -> 1.31.0 (downgraded) oslo.service: 1.32.0 -> 1.33.0 python-neutronclient: 6.10.0 -> 6.11.0 requests: 2.20.0 -> 2.20.1 WebOb: 1.8.3 -> 1.8.4 Make sure with your local attempts at reproduction you're running with these newer versions of dependencies, for example by clearing any existing tox envs with the -r flag or `git clean -dfx` so that stale versions aren't used instead. -- Jeremy Stanley
Thank Jeremy for the clear instructions. On Tue, Dec 4, 2018 at 2:05 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-12-04 00:28:30 +0900 (+0900), Trinh Nguyen wrote:
Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI?
I don't know of any recent changes which would result in the indicated test failures. According to the log it looks like it's a functional testsuite and the tests are failing to connect to the search API. I don't see your job collecting any service logs however, so it's unclear whether the API service is failing to start, or spontaneously crashes, or something else is going on. My first guess would be that one of your dependencies has released and brought some sort of regression.
According to
http://zuul.openstack.org/builds?job_name=openstack-tox-py27&project=openstack%2Fsearchlight&branch=master the last time that job passed for your repo was 2018-11-07 with the installed package versions listed in the
http://logs.openstack.org/56/616056/1/gate/openstack-tox-py27/e413441/tox/py... file, and the first failure I see matching the errors in yours ran with the versions in
http://logs.openstack.org/62/619162/1/check/openstack-tox-py27/809a281/tox/p... on 2018-11-21 (it wasn't run for the intervening 2 weeks so we have a fairly large window of potential external breakage there). A diff of those suggests the following dependencies updated between them:
coverage: 4.5.1 -> 4.5.2 cryptography: 2.3.1 -> 2.4.1 httplib2: 0.11.3 -> 0.12.0 oslo.cache: 1.31.1 -> 1.31.0 (downgraded) oslo.service: 1.32.0 -> 1.33.0 python-neutronclient: 6.10.0 -> 6.11.0 requests: 2.20.0 -> 2.20.1 WebOb: 1.8.3 -> 1.8.4
Make sure with your local attempts at reproduction you're running with these newer versions of dependencies, for example by clearing any existing tox envs with the -r flag or `git clean -dfx` so that stale versions aren't used instead. -- Jeremy Stanley
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
Hi all, I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the latest release I made is "6.0.0.0b1"? [1] http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-o... On Tue, Dec 4, 2018 at 9:09 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Thank Jeremy for the clear instructions.
On Tue, Dec 4, 2018 at 2:05 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-12-04 00:28:30 +0900 (+0900), Trinh Nguyen wrote:
Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI?
I don't know of any recent changes which would result in the indicated test failures. According to the log it looks like it's a functional testsuite and the tests are failing to connect to the search API. I don't see your job collecting any service logs however, so it's unclear whether the API service is failing to start, or spontaneously crashes, or something else is going on. My first guess would be that one of your dependencies has released and brought some sort of regression.
According to
http://zuul.openstack.org/builds?job_name=openstack-tox-py27&project=openstack%2Fsearchlight&branch=master the last time that job passed for your repo was 2018-11-07 with the installed package versions listed in the
http://logs.openstack.org/56/616056/1/gate/openstack-tox-py27/e413441/tox/py... file, and the first failure I see matching the errors in yours ran with the versions in
http://logs.openstack.org/62/619162/1/check/openstack-tox-py27/809a281/tox/p... on 2018-11-21 (it wasn't run for the intervening 2 weeks so we have a fairly large window of potential external breakage there). A diff of those suggests the following dependencies updated between them:
coverage: 4.5.1 -> 4.5.2 cryptography: 2.3.1 -> 2.4.1 httplib2: 0.11.3 -> 0.12.0 oslo.cache: 1.31.1 -> 1.31.0 (downgraded) oslo.service: 1.32.0 -> 1.33.0 python-neutronclient: 6.10.0 -> 6.11.0 requests: 2.20.0 -> 2.20.1 WebOb: 1.8.3 -> 1.8.4
Make sure with your local attempts at reproduction you're running with these newer versions of dependencies, for example by clearing any existing tox envs with the -r flag or `git clean -dfx` so that stale versions aren't used instead. -- Jeremy Stanley
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
On Wed, Dec 5, 2018, at 8:50 AM, Trinh Nguyen wrote:
Hi all,
I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the latest release I made is "6.0.0.0b1"?
[1] http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-o...
It is testing the change you pushed which is 11 commits ahead of 6.0.0.0b1. PBR knows that if the most recent release was 6.0.0.0b1 then the next possible release must be at least 6.0.0.0b2. The 11 comments since 6.0.0.0b1 form the .dev11 suffix. Basically this is PBR being smart to attempt to give you monotonically increasing version numbers that are also valid should you tag a release. More details at https://docs.openstack.org/pbr/latest/user/features.html#version. Clark
Oh Jeremy, Clark, Thank for the info. Pretty helpful. Bests, On Thu, Dec 6, 2018 at 2:12 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Wed, Dec 5, 2018, at 8:50 AM, Trinh Nguyen wrote:
Hi all,
I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the latest release I made is "6.0.0.0b1"?
[1]
http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-o...
It is testing the change you pushed which is 11 commits ahead of 6.0.0.0b1. PBR knows that if the most recent release was 6.0.0.0b1 then the next possible release must be at least 6.0.0.0b2. The 11 comments since 6.0.0.0b1 form the .dev11 suffix.
Basically this is PBR being smart to attempt to give you monotonically increasing version numbers that are also valid should you tag a release. More details at https://docs.openstack.org/pbr/latest/user/features.html#version.
Clark
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
I'm not sure if this matters: "failed with error code 1 in /home/zuul/src/ git.openstack.org/openstack/searchlight, falling back to uneditable format, Could not determine repository location of /home/zuul/src/ git.openstack.org/openstack/searchlight...Could not determine repository location,searchlight==6.0.0.0b2.dev11" On Thu, Dec 6, 2018 at 2:17 AM Trinh Nguyen <dangtrinhnt@gmail.com> wrote:
Oh Jeremy, Clark,
Thank for the info. Pretty helpful.
Bests,
On Thu, Dec 6, 2018 at 2:12 AM Clark Boylan <cboylan@sapwetik.org> wrote:
Hi all,
I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when
On Wed, Dec 5, 2018, at 8:50 AM, Trinh Nguyen wrote: the
latest release I made is "6.0.0.0b1"?
[1]
http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-o...
It is testing the change you pushed which is 11 commits ahead of 6.0.0.0b1. PBR knows that if the most recent release was 6.0.0.0b1 then the next possible release must be at least 6.0.0.0b2. The 11 comments since 6.0.0.0b1 form the .dev11 suffix.
Basically this is PBR being smart to attempt to give you monotonically increasing version numbers that are also valid should you tag a release. More details at https://docs.openstack.org/pbr/latest/user/features.html#version.
Clark
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
-- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
On 2018-12-06 02:24:45 +0900 (+0900), Trinh Nguyen wrote:
I'm not sure if this matters:
"failed with error code 1 in /home/zuul/src/ git.openstack.org/openstack/searchlight, falling back to uneditable format, Could not determine repository location of /home/zuul/src/ git.openstack.org/openstack/searchlight...Could not determine repository location,searchlight==6.0.0.0b2.dev11" [...]
It's benign. Because Zuul pushes the repository onto the test node, it has no Git remote. Clark has proposed https://github.com/pypa/pip/pull/4760 to substitute a file:// URL. -- Jeremy Stanley
On 2018-12-06 01:50:14 +0900 (+0900), Trinh Nguyen wrote:
I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the latest release I made is "6.0.0.0b1"?
[1] http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-o... [...]
Python PEP 440 sorts .dev versions earlier than the equivalent string prior to the .dev portion, so PBR is generating a version for you which sorts after 6.0.0.0b1 (the most recent tag on that branch) but before 6.0.0.0b2 (the next possible beta tag you might use in the future). The "11" there indicates it sees you have 11 additional commits on that branch since the 6.0.0.0b1 tag was applied. -- Jeremy Stanley
participants (3)
-
Clark Boylan
-
Jeremy Stanley
-
Trinh Nguyen