3eacddb2d7
I'm not sure why, but previously we have not passed .log.gz files through to the htmlify web-app. This means clicking on it in the browser prompts to download the file. This is unlikley to be what devlopers investigating logs interactively want. Traditionally in devstack-gate there's been a bunch of renaming log->log.txt that happens to make the files presentable [1]. With zuulv3 native jobs this happens less and everyone has to be aware of this behaviour (e.g. Ia7415d2fbbb320f8eddc4e46c3a055414df5f997 is a good example of raw .log files being added). I think it is fine to assume a .log file is text that is safe to pass through os-loganalyze. From my reading of os-loganalyze [2], a .log.gz file would get mached by util.use_passthrough_view and by default be filtered via a HTMLView -- thus the file_conditions.yaml update is perhaps unnecessary, but provided just to keep things in sync with .txt which has always been there (I9cda9c05f42c5658d1c1dde8aa2efbc0abcc48a2) [1] https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n869 [2] https://git.openstack.org/cgit/openstack-infra/os-loganalyze/tree/os_loganalyze/view.py#n237 Change-Id: I72e4f752713e7947bd66dfe8164976f0a4e3af24
OpenStack Continuous Integration Module
Overview
Configures an OpenStack Continuous Integration System
Developing
If you are adding features to this module, first ask yourself: "Does this logic belong in the module for the service?"
An example of this is the gearman-logging.conf file needed by the zuul service. This file should be managed by the zuul module, not managed here. What should go in this module is high level directives and integrations such as a list of jenkins plugins to install or a class that instantiates multiple services.