Test commit for testing Zuul CI

[cboylan]

Working on getting Zuul CI running for kata. Lets see what happens.

Depends-On: https://review.openstack.org/602628

[opendev-zuul]

Build failed (third-party-check pipeline) integration testing with
OpenStack. For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

• kata-runsh : FAILURE in 22m 27s

[opendev-zuul]

Build failed (third-party-check pipeline) integration testing with
OpenStack. For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

• kata-runsh : FAILURE in 36m 24s

[opendev-zuul]

This change depends on a change that failed to merge.

[chavafg]

Fedora job failed because fdisk is not found in the PATH:

�[91m�[1m• Failure [0.075 seconds]�[0m
docker volume
�[90m/home/zuul/src/github.com/kata-containers/tests/integration/docker/volume_test.go:18�[0m
  passing a block device
  �[90m/home/zuul/src/github.com/kata-containers/tests/integration/docker/volume_test.go:122�[0m
    �[91m�[1mshould be mounted [It]�[0m
    �[90m/home/zuul/src/github.com/kata-containers/tests/integration/docker/volume_test.go:123�[0m

    �[91mExpected error:
        <*errors.errorString | 0xc420092430>: {
            s: "bash: fdisk: command not found\n",
        }
        bash: fdisk: command not found
        

Seems like zuul machines do not include /usr/sbin in the PATH.
I have opened https://review.openstack.org/#/c/625679/ to fix the issue.

[chavafg]

recheck

[opendev-zuul]

Build failed (third-party-check pipeline) integration testing with
OpenStack. For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

• kata-runsh : FAILURE in 58m 56s
• kata-runsh-fedora-28 : SUCCESS in 1h 01m 10s

[jodh-intel]

Any further progress on this on @cboylan, @mnaser?

[grahamwhaley]

tbh, the next most likely step for kata and Zuul is for me to try and get the metrics CI jobs running on Zuul. I'm not going to get to that in the next couple of weeks though I suspect.
Until we have a permanent stable Zuul CI implementation, or if we decided to drop the notion, then I think this PR will just sit here as a test case...

[chavafg]

for QA CI, the fedora job is fixed, but still need to check why the ubuntu job fails... I'll try to make some time this week for that.

[grahamwhaley]

recheck

as SoB/DCO merge has landed in Zuul configs: https://review.openstack.org/#/c/630998/

[grahamwhaley]

recheck

[opendev-zuul]

Build failed (third-party-check pipeline) integration testing with
OpenStack. For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

• dco-license : SUCCESS in 33s
• kata-runsh : FAILURE in 1h 03m 46s
• kata-runsh-fedora-28 : FAILURE in 49m 40s

[grahamwhaley]

@ttx @fungi

Well, looks like the zuul DCO test is enabled and working - above we can see the SUCCESS status for dco-license in the Zuul comment (the test commit does have a Signed-off-by in it).
If we follow the link to the logs, the Ansible-ish logs look a touch confusing, as there is a 'fail' task that is predicated on the DCO check failing - so what you get in the logs is a second element which is basically 'the fail failed', meaning it passed ;-) The key word there is 'skipped'.

From the logs:

2019-01-18 20:56:09.752436 | TASK [validate-dco-license : Developer Certificate of Origin (DCO) license check]
2019-01-18 20:56:10.426418 | localhost | ok: Runtime: 0:00:00.015914
2019-01-18 20:56:10.471529 | 
2019-01-18 20:56:10.471753 | TASK [validate-dco-license : License check failed]
2019-01-18 20:56:10.541009 | localhost | skipping: Conditional result was False

[fungi]

Agreed, while I recommend the ara-report interface there for browsing the task breakdown more conveniently than attempting to parse the stream log, the logic in the validate-dco-license role is pretty confusing. I'm not sure why it has two tasks and breaks the actual failure logic into a separate one from the commit message parsing, but I might be missing a subtle problem which makes it necessary. @pabelanger can hopefully explain the reasoning behind that.

[pabelanger]

The reason for the double task, is if validate-dco-license : Developer Certificate of Origin actually fails --sign-off check, we don't error, we because the shell code actually worked. So, we register the results and use the next task with the fail task to format somewhat of an error message. The key here is failed_when: > 1. We can change this, but the idea was if > 1, when we likely have an issue with the git commands.

So yes, we skip the failed here, because result != 0

[fungi]

@pabelanger: Thanks. So the reason the validate-dco-license : Developer Certificate of Origin doesn't explicitly perform an exit 1 or similar instead of setting result=1 is to avoid masking other errors which might result from running git show?

[pabelanger]

Yah, basically. I am not opposed to change it, this was v1 for ansible-network worked. If we remove it, and that task fails, we won't be able to display any failure message. So there is trade offs.

[ttx]

Agree the resulting logs are quite confusing... just so that you can differentiate an unlikely git show error. At the very least we should change that "License check failed" title into something more explicit...

[grahamwhaley]

/zuul-recheck
as I'd quite like to see the WIP check pick up the label on this one :-)

[ttx]

Oh actually the /zuul-recheck does only trigger SoB rechecking, not WIP (which can be retriggered by unlabeling/labeling). We could change that though.

[grahamwhaley]

yeah, indeed. Right now I think that is OK/correct - the WIP should only need to re-check if a label changes or the PR is updated (and hence the subject line may have changed). Let's see how it goes - it is easy to apply the recheck logic later to WIP if we need to.

[grahamwhaley]

/zuul-recheck
with https://review.openstack.org/#/c/641086/ landed, hopefully we have a Zuul CI job tied back to the proxy repo again, which we can then build upon. Let's see if it fires.....

[jodh-intel]

@cboylan, @grahamwhaley, @ttx - this PR has been open for 328 days. Please can we close it now? :)

[grahamwhaley]

@jodh-intel - I looked at this earlier and contemplated the same. It was used back in March, but also has a 'friend' in #154 which also serves a very similar purpose.
We can probably close this one. let's get at least one ack from either @ttx or @cboylan ... or at least give them a chance ;-)

[jodh-intel]

Sorry, I don't understand why we need two PRs for the same thing...? Also, why is this taking so long? Could someone summarise the situation to avoid having to read the entirety of these two PRs?

[grahamwhaley]

The PRs have handled between them three different cycles of testing the Zuul intergration for Kata:

1. this PR for the original Zuul integration
2. this PR was then used for the WIP/SOB stuff as well when we deprecated pullapprove
3. the other PR was opened by me as I needed some subtle differences in what it was checking, and I do not own this PR so could not modify it.

As I say, yes, we can probably close this one, but should give the owners a chance to respond.

[cboylan]

No objection from me to close this. The zuul integration has evolved and largely moved on from this PR.

[grahamwhaley]

Thanks @cboylan , and for your on-going support on working out Zuul. Closing now...