Hi all, Olivier: While we agreed to switch weekly versions to the new release > environment, we didn't clarify who should be responsible for those weekly > releases and when we trigger them.
Mark: I think you're proposing a "build master" role for the weekly build. > That role would investigate build failures, raise issues, and monitor their > resolution. I like that idea. It might fit as a role that could be taken > by one of many people, overseen by the Release Officer. > I agree that it should be a formal on-rotation assignment shared among Jenkins core maintainers and, maybe, the release team. Bot roles are documented here: https://github.com/jenkinsci/jenkins/blob/master/docs/MAINTAINERS.adoc#roles One problem is that the "Release team" members are not formalized at the moment, and we could clarify that. We have a number of usual suspects (Oliver Gondza for LTS, Daniel Beck for Security, Mark and me for weekly), but IMO it makes sense to make it more formal and maybe to add more contributors. Best regards, Oleg On Friday, April 24, 2020 at 11:43:37 PM UTC+2, Mark Waite wrote: > > > > On Fri, Apr 24, 2020 at 3:21 PM Tim Jacomb <timja...@gmail.com > <javascript:>> wrote: > >> Couldn’t multiple instances run it? >> > > Yes, multiple instances could run it > > >> It makes sense to me that release runs the the tests on the artifacts, >> > > The plan is that the package step will run tests on the packaged > components. There are docker based tests that I've created which are > intended to run within the package job. They check that the packages > install from the files that the build generated (deb, rpm, rpm for SUSE, > eventually MSI). What they don't test is that the install works from the > Jenkins package repository. In the case of Debian and Fedora, there are > additional checks applied to the installer when it is downloaded from a > package repository. > > The acceptance test jobs exercise those additional checks already. Those > acceptance tests could also be executed inside the release.ci..jenkins.io > CI server as well. It seemed like duplication of effort to run them both > on release.ci.jenkins.io and ci.jenkins.io. > > >> >> And also makes sense that ci.jenkins.io has tests that it’s working >> (possibly it could have simpler tests and doesn’t need to run the full >> acceptance tests set) >> >> > When I say "acceptance tests" in this case, I mean the existing small > tests which perform an installation from the official package repository. > These are not tests from the acceptance test harness. They are > installation smoke tests. > > >> Thanks >> Tim >> >> On Fri, 24 Apr 2020 at 21:08, Mark Waite <mark.e...@gmail.com >> <javascript:>> wrote: >> >>> >>> >>> On Fri, Apr 24, 2020 at 12:52 PM Jesse Glick <jgl...@cloudbees.com >>> <javascript:>> wrote: >>> >>>> On Fri, Apr 24, 2020 at 12:19 PM Mark Waite <mark.e...@gmail.com >>>> <javascript:>> wrote: >>>> > The test results aggregator plugin might help us combine test results >>>> from multiple jobs into a single summary job. >>>> >>>> Or just combine them into one job. >>>> >>>> >>> That is certainly an option and is worth discussion. >>> >>> The acceptance test jobs run on ci.jenkins.io because they don't need >>> the added security provided by release.ci.jenkins.io. They are using >>> the publicly available Debian, CentOS, and OpenSUSE images to install the >>> latest weekly Jenkins from the public repositories. They are part of a >>> repository that is also used to check that the ci.jenkins.io >>> infrastructure is providing the expected agent labels and is executing jobs >>> promptly. >>> >>> The build and package jobs run on release.ci.jenkins.io because they >>> need credentials and permissions that we'd rather not include in >>> ci.jenkins.io . >>> >>> We could move the acceptance test jobs to release.ci.jenkins.io but >>> then they are no longer able to help us confirm the health of >>> ci.jenkins.io. >>> >>> Mark Waite >>> >>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Jenkins Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to jenkin...@googlegroups.com <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0BbRGafPyrCDukMdt8SQGdo4X2W8pgNOEzxHcbsqhE6A%40mail.gmail.com >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to jenkin...@googlegroups.com <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFCuA9LmG7BW0sdDvrYinO9T8jGeYptwBnSwLFu69QuAQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFCuA9LmG7BW0sdDvrYinO9T8jGeYptwBnSwLFu69QuAQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jenkin...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidMfABzCzVPs4RX2XRZWseEhzGTsPZ%2BUDQANyaJZ7kc%3Dw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidMfABzCzVPs4RX2XRZWseEhzGTsPZ%2BUDQANyaJZ7kc%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f5b34b14-89f7-458e-997e-bfab59808aef%40googlegroups.com.
