- Zuul-discuss - lists.opendev.org

Project dependencies question
by Petar Terziev 03 Dec '19

03 Dec '19

Hi all, I'm new to Zuul - recently started looking at it, as I've been given a task to set my team's project up to use it for CI. The company's Zuul guru has left, and the thing I'm trying to do isn't quite covered by the docs available so I thought I'd reach out to you to first verify if what I want to do is achievable, and then to see how it can be done. We have two repositories, library A and application B, which uses library A. Commits to B have some basic gating requirements for now - allow merging if it builds and some tests pass, etc. A however is not as straight forward. Since changes to its interface can break B's build, I'd like to hold off breaking interface changes to A until B also has a job in the pipeline that includes a patch-set to update how that interface is used: A` <- Commit that changes an interface B uses enters the gating pipeline B` <- Commit that updates B's usage of A and align it with changes from A` enters the pipeline Ideally, A` would go through its check pipeline and review, and then fail gating because it breaks B. Then B` would be queued up and somehow retrigger the failed A` pipeline, but now running it with B`, causing it to succeed. I'm uncertain whether this can be classified as circular dependency, and if not - how to achieve it. I have noted the "Depends-On" stanzas you can add to commit messages which I could use to express the "B` depends on A`" relationship. But would this be enough to give me the desired behaviour above? Or maybe reference A in the "job.required-projects" configuration section of B? The docs say "Speculative merging and cross-repo dependencies will be honored", but I am still unsure whether this means that in the scenario above, B`'s pipeline will speculatively merge A`, and upon its success cause A` to be merged to mainline. The scenario above is not that uncommon, though I realise the whole "hold off the library interface change until the implementer is up-to-date" may not be standard practice. It's a library used in a fairly closed circle, but not closed enough to allow us have A and B live in the same repository. Any pointers to additional methods or more useful documentation would be much appreciated. Thanks!

4 6

Re: Creating OpenDev control-plane docker images and naming
by Ian Wienand 02 Dec '19

02 Dec '19

On Tue, Nov 26, 2019 at 05:31:07PM +1100, Ian Wienand wrote: > What I would propose is that projects do *not* have a single, > top-level Dockerfile, but only (potentially many) specifically > name-spaced versions. > [2] I started looking at installing these together from a Dockerfile > in system-config. The problem is that you have a "build context", > basically the directory the Dockerfile is in and everything under > it. I started looking closely at this, and I think have reversed my position from above. That is, I think we should keep the OpenDev related dockerfiles in system-config. [1] is a change in system-config to add jobs to build openstacksdk, diskimage-builder and nodepool-[builder|launcher] containers. It does this by having these projects as required-projects: in the job configuration and copying the Dockerfile into the Zuul-checked-out source (and using that as the build context). A bit ugly, but it works. However, to use these jobs for nodepool CI requires importing them into zuul/nodepool. This is tested with [2]. However, Zuul just reports: This change depends on a change with an invalid configuration. It only depends-on [1], which has a valid configuration, at least in the opendev tenant. I think that this has to do with the zuul tenant not having the projects that are used by required-jobs: from the new system-config jobs [3], but am not certain it doesn't have something else to do with the config errors at [4]. I have filed [5] because at the minimum a more helpful error would be good. -i [1] https://review.opendev.org/696000 [2] https://review.opendev.org/696486 [3] https://review.opendev.org/696859 [4] https://zuul.opendev.org/t/zuul/config-errors [5] https://storyboard.openstack.org/#!/story/2006968

1 0

Something between "config" and "untrusted"?
by Clint Byrum 12 Nov '19

12 Nov '19

For the second time in about 6 months, I've run into a weird problem in our Zuul. We use Zuul for CD, so we often write jobs in one repo that are scoped to a limited set of other repos, and which employ secrets to unlock various deployment-related things either in gate to upload artifacts or in promote to push a merged PR into production. What happens is that we try to make a new repo with some subset of our usual CD on an existing repo, and the new repo can't make use of the old repo's jobs. This is documented and intended, because there's a problem where the new repo could use Depends-On to expose the old repo's secrets. allowed-projects doesn't break this restriction (though I struggle to understand why). The usual answer is to move the top-level playbook and job definitions into a trusted repo. This complicates things for a number of reasons: One, we often have a check version of the same job which runs without secrets that tests that the playbook itself is ok. That ceases to be an option because now the job runs in a trusted context. While the roles are still shared, and we can maintain a separate playbook in the untrusted repo to keep some of this, we want to test *the actual playbook*, not the roles. Two, these two repos are not separated for trust reasons. They're separated for separation of concerns and because they have different release cadences. As such, we don't mind if that new repo exposes the secrets of the old repo, because they're both in the same security zone from our perspective. So, I wonder if we could have another class of repository restriction, which is to make one the partner of the other, and drop this restriction only between these two repos. If this sounds like a good idea, I'll try to carve out a few of my tens of spare minutes per month to implement. :) Thanks!

2 2

Bazel roles for Zuul
by Paul Albertella 08 Nov '19

08 Nov '19

Hi, As Matthieu mentioned, I gave a talk at OSS/ELCE about integrating Zuul and Bazel, and wanted to share some of the work I did with the wider Zuul community. Hence I've just submitted a couple of roles for Bazel to the zuul/zuul-jobs repository: https://review.opendev.org/#/c/693513/ I've tested these on a local Zuul setup, using the containers from the Quick Start tutorial, but wasn't sure if there is anything else I need to do to test them, or to make them easier to use in jobs/playbooks. Any suggestions would be very welcome! Cheers, Paul

1 0

Zuul at FOSDEM
by Thierry Carrez 28 Oct '19

28 Oct '19

Hi everyone, There is a CI/CD devroom at FOSDEM (Feb 1-2, 2020 in Brussels): https://lists.fosdem.org/pipermail/fosdem/2019q4/002880.html Zuul would be a great match for the crowd there. Trying to avoid duplicates... Is anyone planning to attend and present? -- Thierry Carrez

3 3

Zuul statistics on the Train dev cycle
by Matthieu Huin 25 Oct '19

25 Oct '19

Hello, I'd be curious to get some stats on the Train dev cycle from Zuul's standpoint. For example: * Amount of jobs run by Zuul * Amount of nodes managed by Nodepool * Amount of failed gate builds, maybe also as a ratio of failed/total gate builds: this would give an idea (assuming the false negatives are rare) of how critical speculative merging is for OpenStack * Amount of patches with cross-repo dependencies I assume most of these can be computed from the SQL reporter data (granted you have access to that). Has anybody tried to get these stats? If not, would anybody want to help me play around with the data and see what we can come up with? Cheers, -- Matthieu Huin Senior Software Developper Red Hat <https://www.redhat.com> <https://red.ht/sig>

4 8

Feedback on Airship pilot project
by Jeremy Stanley 16 Oct '19

16 Oct '19

Hi fellow Zuulies, The Airship project will start its confirmation process with the OSF Board of Directors at the Board meeting[1] Tuesday next week. A draft of the slide deck[2] they plan to present is available for reference. Per the confirmation guidelines[3], the OSF Board of directors will take into account the feedback from representative bodies of existing confirmed Open Infrastructure Projects (Zuul, OpenStack and Kata) when evaluating Airship for confirmation. You may recall this process from when we did it for Zuul not *that* long ago. ;) Particularly worth calling out, guideline #4 "Open collaboration" asserts the following: Project behaves as a good neighbor to other confirmed and pilot projects. If you have any observations/interactions with the Airship project which could serve as useful examples for how these projects do or do not meet this and other guidelines, please provide them on the etherpad[4] ASAP. If possible, include a citation with links to substantiate your feedback. I'll assemble this feedback and send it to the Board (via the public foundation mailing list) for consideration before their meeting next week. [1] http://lists.openstack.org/pipermail/foundation/2019-October/002800.html [2] https://www.airshipit.org/collateral/AirshipConfirmation-Review-for-the-OSF… [3] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmatio… [4] https://etherpad.openstack.org/p/zuul-community-airship-confirmation-feedba… -- Jeremy Stanley

1 0

Common Questions from Ansiblefest
by Jimmy McArthur 16 Oct '19

16 Oct '19

We recently attended Ansiblefest in Atlanta and Zuul had a booth there. It was a great opportunity to meet with existing and potential Zuulies. Some common questions popped up over and over again, so I wanted to crowd source some answers that we could place on our FAQ: * How does Zuul compare to: ** Jenkins ** Molecule ** Tower * Is Zuul a replacement for Jenkins? * Does it work with GitLab? I believe those were the majors. Let me know if you're able to contribute some responses Cheers, Jimmy

4 5

OSF booth at KubeCon+CloudNativeCon in San Diego
by denise＠openstack.org 15 Oct '19

15 Oct '19

Hello Everyone, We wanted to let you know that the OpenStack Foundation will have a booth at the upcoming KubeCon+CloudNativeCon event in San Diego, CA on November 18-21, 2019. We are in booth #S23 and we will be featuring the OpenStack Foundation in addition to all the projects - Airship, Kata Containers, StarlingX, OpenStack and Zuul. At the booth we will have stickers and educational collateral about each project to distribute. We would like to invite you to help us in the following areas: Represent your project by staffing the OSF booth If you can spare 1 hour/day (or any time at all!) to represent your specific project in the OSF booth Here is the [ link ]( https://docs.google.com/spreadsheets/d/1mZzK0GHm9OQ0IL9njTWLxPLuAeR6jqmyeM6… ) to the google doc to sign up Project Demos in the OSF booth If you are interested in delivering a project-specific demo in the OSF booth, please contact [ Denise ]( http://denise@openstack.org ) Looking forward to seeing all of you in San Diego! Best regards, OSF Marketing team Denise, Claire, Allison and Ashlee

1 0

Ansible version changes to Zuul
by Paul Belanger 11 Oct '19

11 Oct '19

Greetings! This came up again today in #openstack-infra, which reminded me to send this email. I'd like to propose we make the following changes to Zuul to increase the versions of Ansible we are supporting. For example: Remove support for ansible 2.5: https://review.opendev.org/650431/ We have marked Ansible 2.5 deprecated for some time, and the Ansible project move 2.5 branch to EOL 6 months ago. I believe it is time for Zuul to also drop it. Switch ansible_default to 2.8: https://review.opendev.org/676695/ Both zuul.ansible.com and Zuul tenant on zuul.opendev.org have been running Ansible 2.8 for a while now. I don't believe we've seen any issues related to Ansible 2.8 (but I could be mistaken). I believe it is somewhat safe to default the version of Ansible to 2.8 now. This also marks Ansible 2.6 as deprecated, as it will move into EOL upstream in the next month when Ansible 2.9 is released. WIP: Support Ansible 2.9: https://review.opendev.org/674854/ Finally, with Ansible 2.9 to be released at the end of the month, I think it would be fantastic if we could also do a same day release of Zuul. This only adds Ansible 2.9 support, but doesn't change the default version used by jobs. Reviews on this would be helpful! For all above, I think we should try to over-communicate the changes, maybe email to announce list, then in 1 or 2 weeks work to merge them. Thoughts? Paul

1 0

Fwd: Important Shanghai PTG Information
by Kendall Nelson 09 Oct '19

09 Oct '19

Wanted to make sure you all saw this too :) While I realize Zuul hasn't planned to meet, if any of you will be in Shanghai, this info is important. -Kendall (diablo_rojo) ---------- Forwarded message --------- From: Kendall Waters <kendall(a)openstack.org> Date: Wed, Oct 9, 2019 at 10:09 AM Subject: Important Shanghai PTG Information To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Hello Everyone! As I’m sure you already know, the Shanghai PTG is going to be a very different event from PTGs in the past so we wanted to spell out the differences so you can be better prepared. Registration & Badges Registration for the PTG is included in the cost of the Summit. It is a single registration for both events. Since there is a single registration for the event, there is also one badge for both events. You will pick it up when you check in for the Summit and keep it until the end of the PTG. The Space Rooms The space we are contracted to have for the PTG will be laid out differently. We only have a couple dedicated rooms which are allocated to those groups with the largest numbers of people. The rest of the teams will be in a single larger room together. To help people gather teams in an organized fashion, we will be naming the arrangements of tables after OpenStack releases (Austin, Bexar, Cactus, etc). Food & Beverage Rules Unfortunately, the venue does not allow ANY food or drink in any of the rooms. This includes coffee and tea. Lunch will be from 12:30 to 1:30 in the beautiful pre-function space outside of the Blue Hall. Moving Furniture You are allowed to! Yay! If the table arrangements your project/team/group lead requested don’t work for you, feel free to move the furniture around. That being said, try to keep the tables marked with their names so that others can find them during their time slots. There will also be extra chairs stacked in the corner if your team needs them. Hours This venue is particularly strict about the hours we are allowed to be there. The PTG is scheduled to run from 9:00 in the morning to 4:30 in the evening. Its reasonably likely that if you try to come early or stay late, security will talk to you. So please be kind and respectfully leave if they ask you to. Resources Power While we have been working with the venue to accomodate our power needs, we won’t have as many power strips as we have had in the past. For this reason, we want to remind everyone to charge all their devices every night and share the power strips we do have during the day. Sharing is caring! Flipcharts While we won’t have projection available, we will have some flipcharts around. Each dedicated room will have one flipchart and the big main room will have a few to share. Please feel free to grab one when you need it, but put it back when you are finished so that others can use it if they need. Again, sharing is caring! :) Onboarding A lot of the usual PTG attendees won’t be able to attend this event, but we will also have a lot of new faces. With this in mind, we have decided to add project onboarding to the PTG so that the new contributors can get up to speed with the projects meeting that week. The teams gathering that will be doing onboarding will have that denoted on the print and digital schedule on site. They have also been encouraged to promote when they will be doing their onboarding via the PTGBot and on the mailing lists. If you have any questions, please let us know! Cheers, The Kendalls (wendallkaters & diablo_rojo)

1 0

[all] Final PTG Schedule
by Kendall Nelson 07 Oct '19

07 Oct '19

Hello Everyone! After a few weeks of shuffling and changes, we have a final schedule! It can be seen here on the 'Schedule' tab[1]. -Kendall (diablo_rojo) [1] https://www.openstack.org/PTG

1 0

Leadership meet-n-greet opportunities for the community in Shanghai
by Jeremy Stanley 07 Oct '19

07 Oct '19

A couple of events have been included in the Shanghai Open Infrastructure Summit schedule, to help attendees see that leadership roles in the projects gathering there are attainable and the folks who fill them are approachable and eager to engage in person: https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24417/ https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24426/ It would be great if any Zuul Maintainers are available to be present for either or both of these sessions. If you'll be at the summit and are interested in helping represent the Zuul leadership at one of them, there's a sign-up here: https://etherpad.openstack.org/p/meet-the-project-leaders It's also an opportunity to plug any sessions or related activities we have coming up during the rest of the week and attempt to drum up additional attendance, as well as generally encourage more participation in the project. -- Jeremy Stanley

1 0

Re: Proposed Forum Schedule
by Jimmy McArthur 04 Oct '19

04 Oct '19

The forum schedule is now live: https://www.openstack.org/summit/shanghai-2019/summit-schedule/global-searc… If you'd prefer to use the spreadsheet view: https://drive.google.com/file/d/1qp0I9xnyOK3mhBitQnk2a7VuS9XClvyF Please let Kendall Nelson or myself know as soon as possible if you see any conflicts. Cheers, Jimmy > Jimmy McArthur <mailto:jimmy@openstack.org> > October 3, 2019 at 11:42 AM > Hello! > > I'm attaching a PDF of the proposed Shanghai Forum Schedule. I'll > publish the same on the actual website later this afternoon. However, > there is still time for feedback/time changes, assuming there aren't > conflicts for speakers/moderators. > > This is also available for download here: > https://drive.google.com/file/d/1qp0I9xnyOK3mhBitQnk2a7VuS9XClvyF/view?usp=… > > > Please respond to this thread with any concerns. > > Cheers, > Jimmy >

1 0

Developing a Gitlab driver
by Paul Albertella 30 Sep '19

30 Sep '19

Hi, I saw the @ZuulCI tweet about developing a Gitlab driver for Zuul (and responded as @reiterative) and would love to know more, as this is something that I had already been contemplating. I'm not a Zuul user yet, but it has been recommended by some colleagues and I'm keen to explore its possibilities on the projects that I'm involved in, which use Gitlab. Has any work already been done on a Gitlab driver, which could provide a starting point? Or is the existing GitHub driver the best starting point? Cheers, Paul

4 3

Elevator Pitch for Zuul
by Greg Dekoenigsberg 27 Sep '19

27 Sep '19

"Speculative gating saved our project." --Johannes Foufas, Volvo The most important question around Zuul is: why? Why, among all of the other CI/CD projects of various descriptions, should anyone choose Zuul? You generally get a very short time to explain to users why they should bother with a new technology, and the answer "Project X Uses It," while important, is seldom sufficient. I'd like to propose a 50-word elevator pitch for Zuul that focuses on its key differentiator: multi-project gating. It goes like this: "Complexity doesn't go away; it just moves. In the age of monolithic applications, complexity lived in the single application. Now, in the age of microservices, complexity lives in the relationships between applications. Zuul is the essential CI/CD project for the age of microservices, because it provides predictive gating between multiple projects." I believe that good marketing consists of two pieces: simplifying a story to the resonant essence, and then amplifying that story as much as possible. If we can agree that this simple story resonates, maybe we can figure out how to get this story in front of as many people as possible. --g

8 8

Gerrit support in master unstable
by corvus＠inaugust.com 19 Sep '19

19 Sep '19

Hi, We recently merged a bunch of changes which altered the Gerrit driver in master, and unfortunately real-world testing has exposed some errors which were not caught in either manual or automated testing. If you use Gerrit, particularly if you have it configured with an HTTP password, you may wish to avoid running master and stick with 3.10.2 for the moment until we fix those problems. I do not think they are very complicated and believe that we can merge fixes to them in not much more time than it would take to revert the changes, but if I'm wrong about that, we'll revert the stack and make another attempt. -Jim

1 0

Proposed new project: zuul-registry
by corvus＠gnu.org 17 Sep '19

17 Sep '19

Hi, We broke new ground with speculative container images, but in using this feature over the past few months, we have found some rough edges that I think can be smoothed by implementing our own container image registry server. Hear me out. :) There are two container image registries involved in the system: the intermediate registry and the buildset registry. The intermediate registry is a long-lived service which holds images after builds complete in order to transfer them between buildsets. In other words, when we build an image, we put it in the intermediate registry, and if, later, a change arrives which depends on that image, we pull it from that registry, and place it in the buildset registry. The buildset registry is short-lived, and is meant to supply images that we have local builds of if they appear in the dependency chain, or supply them from upstream dockerhub otherwise. Ideally the requirements for the intermediate registry are: * Authenticated write access * Anonymous read access * Support for more than one registry namespace (e.g., docker hub, quay, etc) Only "authenticated write access" is met by the current docker registry server -- and that's by putting the entire thing behind authentication -- read and write. In addition, we have found that the docker registry service seems to have problems working with a swift backend -- occasionally it writes zero-byte image objects, and the existing registry server logging isn't giving us any clues why. Ideally the requirements for the buildset registry are: * Authenticated access * Pass-through support for images not present * Support for more than one registry namespace Only "authenticated access" is met by the current docker registry; we accomplish the second by running a second instance and configuring them both as mirrors. I believe that if we make our own registry software, we can satisfy all of the requirements. The two registry servers have differing needs, but a single piece of software should be able to satisfy both by enabling or disabling certain options. It will be easy for us to configure whether read access requires authentication. We should be able to emulate different registry servers by observing the "Host" header (or, failing that, run on different ports). We can implement our own logic to perform pass-through requests automatically if an image is not present locally. And finally, we should be able to make uploading to swift more robust (though, obviously that alone is not a compelling reason to do this). I have made an initial implementation in Python which performs the basic functions of a registry (push and pull work). At this point, I have enough of an understanding of the protocol to feel that the remaining goals are achievable with a reasonable amount of effort. If folks don't object, I'd like to create a new repository ("zuul-registry" perhaps?) to hold this and continue further development. I would consider this an optional part of Zuul which operators could choose to deploy if they have a speculative image pipeline. -Jim

4 4

Open Infrastructure Summit Shanghai: Forum Submissions Open
by Jimmy McArthur 16 Sep '19

16 Sep '19

Hello Everyone! We are now accepting Forum [1] submissions for the 2019 Open Infrastructure Summit in Shanghai [2]. Please submit your ideas through the Summit CFP tool [3] through September20th. Don't forget to put your brainstorming etherpad up on the Shanghai Forum page [4]. This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1]. Keep in mind, Forum submissions are for discussions, not presentations. The timeline for submissions is as follows: Sep 4th | Formal topic submission tool opens: https://cfp.openstack.org. Sep 20th | Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda. Sep 30th | Draft Forum schedule published. Crowd sourced session conflict detection. Forum promotion begins. Oct 7th | Scheduling committee final meeting Oct 14th | Forum schedule final Nov 4-6| Forum Time! If you have questions or concerns, please reach out to speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. Cheers, Jimmy [1] https://wiki.openstack.org/wiki/Forum [2] https://www.openstack.org/summit/shanghai-2019/ [3] https://cfp.openstack.org [4] https://wiki.openstack.org/wiki/Forum/Shanghai2019

1 1

Can we start adding ansible-molecule files for testing zuul roles?
by Sorin Sbarnea 06 Sep '19

06 Sep '19

As this question raised on irc I think is time to get some feedback on it. Molecule is the official Ansible role testing framework which allows testing of Ansible roles (or playbooks) in isolation by taking care care of provisioning and cleanup of the required resources. Most common use-case is to use docker containers to test, where you can start running your role code in a couple of seconds, being able to run in parallel lots of platforms. Mainly as a role developer (or even occasional contributor), it makes extremely easy to run tests locally*, before even creating a change-request. So this opens few sub-questions: a) can we allow people to add molecule files, even if we do not run molecule in check/gates? -- there is value in this, even without jobs. b) can/should we add molecule jobs for these so we can assure they keep running? c) would this create duplication between what is tested as standalone zuul jobs and what what is tested via molecule ones? Is this a reason to worry or not? These roles are used on multiple zuul server so is in our interest to make them as reusable as possible. Maybe on opendev.org instance we do not have the resources to test them on all possible platforms, but this does not mean that other zuul instances cannot run these tests. In addition to making a role developer life easier by allowing it to run ansible code in a say similar to running unittests, we can even see other benefits: uploaded CRs would be of better quality and we will also lower zuul load, improving the build-response-time even for users that do not test their changes locally before uploading them. * Developer can still define DOCKER_HOST=ssh://host and fully avoid the need to install docker locally. So the term "locally" is a bit relaxed, as you can offload the work to external systems. Is more of running tests on my own hardware, but isolated, so I would not mess my localhost. Thanks Sorin Sbarnea

1 0

Root Ara report removed from Zuul Jobs
by Clark Boylan 06 Sep '19

06 Sep '19

Hello Everyone, We have removed the top level Zuul job Ara reports from our Zuul jobs. This was done to reduce the total number of objects we are uploading to our swift/ceph object stores as some clouds have indicated the total object volume is a bit high. Analysis showed that Ara represented a significant chunk of that data. We did not remove that information though. Zuul's build dashboard is able to render a similar report for builds. You can find that by clicking on the "Console" tab of a build. For exampe, here is one for a nova tox job: http://zuul.openstack.org/build/8e581b24d38b4e5c8ff046be081c4525/console We hope this makes our log storage easier to support while still providing the information you need to debug your jobs. Note jobs that run a nested ara-report are not affected by this. I think TripleO, OSA, and others do this. Thank you, Clark

1 0

Report from Gerrit User Summit
by corvus＠inaugust.com 04 Sep '19

04 Sep '19

Hi, Monty and I attended the Gerrit User Summit and hackathon last week. Zuul came up quite a lot, so I wanted to highlight some things here. For a fuller report of the event, see my mail to the OpenStack-Infra mailing list here: http://lists.openstack.org/pipermail/openstack-infra/2019-September/006475.… The following is an extract of the Zuul-relevant parts from that: Zuul ---- Zuul is happily used at Volvo by the propulsion team at Volvo (currently v2, working on moving to v3) [2]. Other teams are looking into it. The Gerrit maintainers are interested in using Zuul to run Gerrit's upstream CI system. Monty and I plan on helping to implement that. We spoke at length with Edwin and Alice who are largely driving the development of the new "checks" API in Gerrit. It is partially implemented now and operational in upstream Gerrit. As written, we would have some difficulty using it effectively with Zuul. However, with Zuul as a use case, some further changes can be made so that I think it will integrate quite well, and with more work could be a quite nice integration. At a very high level, a "checker" in Gerrit represents a single pass/fail result from a CI system or code analyzer, and must be configured on the project in advance by an administrator. Since we want Zuul to report the result of each job it runs on a change, and we don't know that set of jobs until we start, the current implementation doesn't fit the model very well. For the moment, we can use the checks API to report the overall buildset result, but not the jobs. We can, of course, still use Gerrit change messages to report the results of individual jobs just as we do now. But ideally, we'd like to take full advantage of the structured data and reporting the checks API provides. To that end, I've offered to write a design document[1] describing an implementation of support for "sub-checks" -- an idea which appeared in the original checks API design as a potential follow-up. Sub-checks would simply be structured data about individual jobs which are reported along with the overall check result. With this in place, Zuul could get out of the business of leaving comments with links to logs, as each sub-check would support its own pass/fail, duration, and log url. Later, we could extend this to support reporting artifact locations as well, so that within Gerrit, we would see links to the log URL and docs preview sites, etc. There is an opportunity to do some cross-repo testing between Zuul and Gerrit as we work on this. Upstream Gerrit's Gerrit does not have the SSH event stream available, so before we can do any work against it, we need an alternative. I think the best way forward is to implement partial (experimental) support for the checks API, so that we can at least use it to trigger and report on changes, get OpenDev's Zuul added as a checker, and then work on implementing sub-checks in upstream Gerrit and then Zuul. Conclusion ---------- I'm sure I'm leaving stuff out, so feel free to prompt me with questions. In general we got a lot of work done and I think we're set up very well for future collaboration. -Jim [1] https://gerrit-review.googlesource.com/Documentation/dev-contributing.html#… [2] https://model-engineers.com/en/company/references/success-stories/volvo-car…

1 0

Zuul posts non hiddable Gerrit comments
by Vitaliy Lotorev 04 Sep '19

04 Sep '19

Hi, Starting with at least v2.15 Gerrit is able to differentiate bot comments and hide them using 'Show comments' trigger on web UI. This is achived either using tagged comments or robot comments. A while ago I filed an issue about Zuul not using these technics [1] (ticket has links for Gerrit docs with tagged and robot comments). This results that Zuul comments are not hiddable in Gerrit. AFAIK, sending tagged comments via SSH to Gerrit is easy (one-line of code at [2]). I could try providing a patch for tagged comments. What Zuul maintainers think about adding support for bot comments? Should not be sending tagged comments done only if Gerrit version >= 2.15? [1] https://storyboard.openstack.org/#!/story/2005661 [2] https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/gerrit/gerritco…

4 4

review.opendev.org Outage September 16 to Perform Project Renames
by Clark Boylan 04 Sep '19

04 Sep '19

Hello, We will be taking a Gerrit outage of about an hour on September 16 at 14:00 UTC to perform project renames. Please let us know if this scheduling does not work for some reason. We have tried to schedule this for a quiet time at the end of OpenStack's Train release cycle. Also, if you'd like to rename a project, now is the time to start prepping for that. Feel free to ask us any questions you have or bring up your concerns with us. Thank you for your patience, Clark

1 0

Zuul at the Open Source Summit Europe; Zuul swag
by Matthieu Huin 30 Aug '19

30 Aug '19

Hello list, I am pleased to announce that I will be giving a presentation on Zuul with Fabien Boucher at the upcoming Open Source Summit in Lyon, France! The description of the session can be found here: https://osseu19.sched.com/event/TLMB/stop-merging-broken-code-an-introducti… This summit is right before the Shanghai Summit (October 28-30). Feel free to advertise our session! It would be nice to have some Zuul swag before the OSS to hand out and leave around; especially stickers as they were a huge hit at FOSDEM this year. Who should I contact about this? -- Matthieu Huin Senior Software Developper Red Hat <https://www.redhat.com> <https://red.ht/sig>

3 3