Build tagging; keeping important builds #591
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
You can actually 'create' new builds to show up in the group overview by typing a build number which doesn't exist |
|
wow, that's cool :-) |
|
it also works when you type something different than ' |
|
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
okurz
force-pushed
the
feature/build_tagging_poo#9544
branch
from
3453f71
to
9497fe9
Compare
|
updated:
|
okurz
force-pushed
the
feature/build_tagging_poo#9544
branch
from
9497fe9
to
c51ca23
Compare
| =cut | ||
| sub bugref { | ||
| my ($self) = @_; | ||
| $self->text =~ /\b([^t]+#\d+)\b/; |
There was a problem hiding this comment.
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
okurz
force-pushed
the
feature/build_tagging_poo#9544
branch
from
c51ca23
to
993265a
Compare
|
updated:
|
aaannz
pushed a commit
that referenced
this pull request
Mar 18, 2016
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 :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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