action #16062
closed[tools]Better user information about openQA changes
Added by okurz over 7 years ago. Updated almost 5 years ago.
100%
Description
Raised as an idea during the SUSE QA SLE retrospective
user epic¶
As a frequent user relying on openQA I want to know what cool new features and fixes are available in a deployed openQA instance so that I know how I can conduct the review efficiently
further details¶
old content which okurz thinks is a feature we should not invest time on as it is an administration issue: see version of backend from (all) workers to know which backend features are expected to be working already for tests relying on it
Updated by mkittler over 7 years ago
Oh, I see there is already a ticket for it and szarate is already working on this.
On package generation a log file is already updated: https://build.opensuse.org/package/view_file/devel:openQA/openQA/openQA.changes
So we just need to make it available to the web UI and then just display it from there.
Updated by coolo over 7 years ago
you can copy the .changes file into public/Changelog during package build. Then it's available to apache as openqa.opensuse.org/Changelog
Updated by szarate over 7 years ago
While talking with @mkittler, there's the idea to have the changelog as part of a new "Info" menu for the web UI (And there we can link the API documentation, openQA documentation itself and other stuff). Also the worker (os-autoinst) changelog needs to be added too.
@mkittler, the idea proposed by @coolo actually will remove the branding problem, we can use the same approach for both, the webui and os-autoinst (placing the file in say /usr/doc/os-autoinst/Changelog)
Updated by mkittler over 7 years ago
Ok, so let's package the logs decently then.
Anyways here's a first approach reading the logs just via rpm command: https://github.com/os-autoinst/openQA/pull/1184
Updated by okurz over 7 years ago
- Description updated (diff)
problems I see with the proposed approach:
- changelog from RPM may no be complete, e.g. when OBS fails to build a package for some time
- It is specific to OBS
- new menu is too much. You are probably over-estimating the capabilities of users to filter stuff on a webui
- os-autoinst should be considered "just any backend" and not be relied upon from the webui perspective
- automatically generated changelog is too verbose for the user to digest directly. changelogs need a manual review process
I suggest the following for anyone who is up to the task to do:
- on a bi-weekly basis looks for the last git commit of openQA that is not totally broken
git log --format=oneline <last_tag>..<the_one_commit_that_should_become_the_new_version> > changelog- filter out un-interesting stuff from the changelog, e.g. low-level internal refactoring and fixes for issues that never hit users
- create tag with message details including the changelog and with an increasing version number, e.g. 4.5, 4.6, …, 4.99, …, 4.165
- put that as "release" on the github project
- make OBS package
devel:openQA:stable/openQAautomatically be triggered by new releases on github with the according version and changelog - do the same for os-autoinst
- every 6w (that would be for each "milestone", covering three releases) collect changelog from all 6 releases (3 openQA + 3 os-autoinst) the interesting parts on an even higher level, blog about it and brag about it
Updated by szarate over 7 years ago
- Target version set to Milestone 7
@okurz, can you please update the description on what's expected from the Test Developer (And other perspectives) regarding this feature?. As we clearly got to a point with different opinions regarding what a Changelog and a Release note is, and what to have where.
What you are suggesting in your last comment, is to have a proper release process for openQA (and as you mention os-autoinst, is a different project, that would need it's own release process), but IMHO differs a lot with the the user story itself and the further details these are two things again: openQA version and os-autoinst version, Changelog and release notes :)
Updated by coolo over 7 years ago
If OBS fails to build the package, we won't deploy it. I thought this is about having the changelog of deployment?
Updated by szarate over 7 years ago
The discussion scaled quickly :), and it was not just deployment... Its a bit more complicated :)
Updated by szarate over 7 years ago
- Related to action #16232: Display openQA version in web UI added
Updated by okurz over 7 years ago
- Subject changed from Better changelog and/or release notes for openQA releases to Better user information about openQA changes
- Description updated (diff)
Updated by okurz over 7 years ago
szarate wrote:
@okurz, can you please update the description on what's expected from the Test Developer (And other perspectives) regarding this feature?. As we clearly got to a point with different opinions regarding what a Changelog and a Release note is, and what to have where.
What you are suggesting in your last comment, is to have a proper release process for openQA (and as you mention os-autoinst, is a different project, that would need it's own release process), but IMHO differs a lot with the the user story itself and the further details these are two things again: openQA version and os-autoinst version, Changelog and release notes :)
I split this ticket which I now consider a user epic into three parts, this epic and two user stories as subtickets. Please take a look if this is better now.
Updated by RBrownSUSE about 7 years ago
- Subject changed from Better user information about openQA changes to [tools]Better user information about openQA changes
Updated by coolo about 6 years ago
- Status changed from New to Resolved
we have changelog in the webui and announce sprints