-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build tagging; keeping important builds #591
Build tagging; keeping important builds #591
Conversation
wow, that's cool :-) |
both "issues" you described I declare as "features", the latter was intended, the former … not so much actually :-) I can think of use cases where it makes sense to tag "expected" builds before they even arrive |
Based on comments on the group overview individual builds can be tagged. As 'build' by themselves do not own any data the job group is used to store this information. A tag has a 'build' to link it to a build. It also has a 'type' and an optional 'description'. The type can later on be used to distinguish tag types. A 'tag' icon is shown next to tagged builds together with the description on the group_overview page. The index page is not changed to prevent a potential performance regression. Within the sub group_overview the comments are parsed for comments and then passed to the template explicitly to prevent duplicate database queries. Related progress issue: https://progress.opensuse.org/issues/9544
3453f71
to
9497fe9
Compare
updated:
|
9497fe9
to
c51ca23
Compare
=cut | ||
sub bugref { | ||
my ($self) = @_; | ||
$self->text =~ /\b([^t]+#\d+)\b/; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is t
not allowed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because a reference to a test within openqa is not a "bugref".
Adds a possibility to actually revert the action provided by the previous commit. The more recent tag always wins. Related progress issue: https://progress.opensuse.org/issues/9544
As builds can now be tagged we come up with the convention that the 'important' type - the only one for now - is used to tag every job that corresponds to a build as 'important' and keep the logs for these jobs so that we can always refer to the attached data, e.g. for milestone builds, final releases, jobs for which long-lasting bug reports exist, etc. As these jobs are not cleaned up automatically a manual or external cleanup scheme has to be applied for important builds and jobs. Also add tests for 'reduce_result' GRU task. Performance evaluation of getting a tests/overview page, index page and a group overview page including the commit adding build tags. * before: 1.5+-0.1, 2.4+-0.1, 2.2+-0.0 * after: 1.5+-0.1, 2.0+-0.1, 2.2+-0.1 Related progress issue: https://progress.opensuse.org/issues/9544
c51ca23
to
993265a
Compare
updated:
|
Build tagging; keeping important builds
I'm deploying this right now - it's a calm sunday without any builds whatsoever :) |
This PR is suspected at breaking the review process on openqa.suse.de, as new builds are not showing in some job groups :( |
it wasn't - #616 reverts the broken one (I had trouble with anyway for different reason, but merged anyway :) |
Included changes
Detailed description
As builds can now be tagged we come up with the convention that the
'important' type - the only one for now - is used to tag every job that
corresponds to a build as 'important' and keep the logs for these jobs so that
we can always refer to the attached data, e.g. for milestone builds, final
releases, jobs for which long-lasting bug reports exist, etc.
As these jobs are not cleaned up automatically a manual or external cleanup
scheme has to be applied for important builds and jobs.
Also add tests for 'reduce_result' GRU task.
Adds a possibility to actually revert the action provided by the previous
commit. The more recent tag always wins.
Based on comments on the group overview individual builds can be tagged. As
'build' by themselves do not own any data the job group is used to store this
information. A tag has a 'build' to link it to a build. It also has a 'type'
and an optional 'description'. The type can later on be used to distinguish
tag types.
A 'tag' icon is shown next to tagged builds together with the description on
the group_overview page. The index page is not changed to prevent a potential
performance regression.
Within the sub group_overview the comments are parsed for comments and then
passed to the template explicitly to prevent duplicate database queries.
Example screenshot
Performance evaluation
Tested against a production database dump from o.s.d from 2016-02-25 (before we cleaned it to optimize even more). Performance evaluation of getting a tests/overview page, index page and a group overview page including the commit adding build tags. Results in seconds for each complete transaction from 5 iterations:
Related progress issue: https://progress.opensuse.org/issues/9544