The Zuul team is pleased to announce the release of Zuul 4.0.0.
Download it from PyPI: https://pypi.org/project/zuul
The release notes, included below, are also available in the documentation with hyperlink references:
https://zuul-ci.org/docs/zuul/4.0.0/reference/releasenotes.html
Prelude =======
This is the first 4.x release of Zuul. It requires some deployment changes by operators which have been carefully planned in order to facilitate work on Zuul version 5, which will be the first version of Zuul where every component is fault tolerant and able to scale. If you read the release notes for the last 3.x release, you may have already made all of the required changes. If not, please do so before upgrading to version 4. Every required change in version 4 is optionally supported in 3.19, so it is safe to make these changes and then upgrade. Please read all of the notes below, especially in the “Upgrading” section for details. The primary additional requirements are:
TLS ZooKeeper connections
Network connectivity from all components to ZooKeeper
An SQL database
With these changes in place, it is anticipated that further upgrades to Zuul made in support of the scale-out-scheduler work will be done with minimal disruption in the course of normal releases between version 4 and 5.
New Features ============
* The action “promote” is now available via the tenant-scoped REST API using the zuul cli.
* Builds in the SQL reporter have a “held” attribute set to True if the build triggered a autohold request. Builds can be filtered by held status.
* Subdirectories of zuul.d or .zuul.d can be ignored when reading configuration by placing a .zuul.ignore file inside them.
* The find module is now allowed to run on the executor.
* Changes can now be dequeued via the Github checks API. If a github reporter is configured to use the checks API, all running checks will provide a custom “Abort” action.
* Zuul now respects GitHub review requirements when enqueuing into gate pipelines. This works for github.com and GitHub Enterprise starting with version 2.21.0.
* Jobs may specify the new intermediate flag to note they may only be inherited by abstract jobs. This can be useful if building a job hierarchy where wish to limit where a base job is instantiated.
* The builds/ and buildset/ API endpoints now include information about retried builds. They are called non-final as those are all builds that were retried at least once and thus weren’t visible to the user so far.
* The builds/ API can filter those retried builds and you might exclude them from API result by setting final=false in the API request.
* An option to use the URL of the Zuul build page when reporting has been added. This feature requires that all the pipelines in the tenant have a SQL reporter configured, and at least one of tenant.web-root or web.root must be defined.
See tenant.report-build-page.
* REST API: authorizations: add a tenant-scoped endpoint at '/api/tenant/{tenant}/authorizations'. Calling the endpoint will return a list of admin tenants limited to the scoped tenant, if the user has admin privileges on it.
* Host key checking is now disabled for a host in the generated Ansible inventory if host-key-checking is set to False in the corresponding nodepool config.
Upgrade Notes =============
* Support for Ansible 2.7 has been removed.
* If using a SQL reporter, the zuul_builds table will be updated with a new 'held' column. The zuul-scheduler and zuul-web services need to be restarted together for the change to take effect.
* Previously the SqlReporter would record the job name in the database in place of the url if the url was empty. This has now been updated to store a null in the database for that case. Zuul will automatically run a database migration to correct old values.
* The -d switch doesn’t enforce foreground anymore. It only enables debug logging. To start zuul in foreground please add the -f switch instead.
* Support for running Zuul under Python 3.5 has been dropped.
* As further integration with the web interface is planned, the web.root setting in zuul.conf is marked required and future releases may error if it is missing. Please add it to your configuration now. See tenant.web-root for additional information about whitelabel tenants.
* The components zuul-scheduler and zuul-web now require database configuration. There is now only one supported database connection. If multiple sql connections have been configured only the first one will be used.
* Signal based triggering of full-reconfiguration in the scheduler (deprecated since 3.3.0) has been removed. Use zuul-scheduler full-reconfigure instead.
* The zookeeper section in zuul.conf is required for all components, and all components must now be able to connect to ZooKeeper. Additionally, TLS is now required for all ZooKeeper connections. See Encrypted Connections for more details.
Deprecation Notes =================
* Defining database connections using <sql connection> is now deprecated. Refer to Database Configuration how to configure the database now.
* REST API: authorizations: the /api/user/authorizations endpoint is deprecated in favor of the tenant-scoped endpoint. It will be removed next release.
Bug Fixes =========
* Although the documentation states that the MQTT reporter reports the build's log_url, this was only true as long as tenant.report-build-page was disabled. As soon as the setting was enabled, the MQTT reporter reported the url to the build's result page in Zuul. As MQTT is meant to be consumed by machines, this broke use cases like log post processing.
* This was fixed so that the <mqtt schema>.buildset.builds.log_url now always contains the log url, while an additional field <mqtt schema>.buildset.builds.web_url contains the url to the build's result page if tenant.report-build-page is enabled.