Skip to content
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.

Sign up for GitHub

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

Clarify instructions for "Process this rule at most (times)" #149

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Clarify instructions for "Process this rule at most (times)" #149

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cae921e
Clarify instructions for "Process this rule at most (times)" #148
Eccenux Nov 12, 2024
60a4c15
Clarify instructions for "Process this rule at most (times)" #148
Eccenux Nov 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 16 additions & 5 deletions ...esources/pl/damianszczepanik/jenkins/buildhistorymanager/model/Rule/help-matchAtMost.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,23 @@
<p>The rule will stop being processed after a certain number of matched builds.
Once this condition is met, only the other rules will continue to be processed.</p>

<p><b>Use cases</b></p>
<p>This feature provides the option to control the number of builds the rule can process. It may save a significant amount of time when the build history is long.</p>
<p>Internally and in the documentation, this value is called <code>matchAtMost</code>.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from the user perspective this is valuable how to use/configure and not how this is named internally


<p>There are some special values:</p>
<ul>
<li>If the value is set to <code>-1</code>, there is no limitation, all builds will be evaluated.</li>
<li>If the value is set to <code>0</code>, no builds will be evaluated. This disables the rule as it will not apply to any build.</li>
<li>If the value is set to <code>1..n</code>, once the value is reached, the rule is effectively disabled and is no longer applied.</li>
<li>If <code>matchAtMost = -1</code>, there is no limitation; all builds will be evaluated.</li>
<li>If <code>matchAtMost = 0</code>, no builds will be evaluated. This disables the rule, as it will not apply to any build.</li>
<li>If <code>matchAtMost > 0</code>, this rule will only be applied <code>matchAtMost</code> times
in each build history manager process (in each loop over builds after a build).</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

build history manager process -> plugin, if I understand correctly meaning

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant the process the plugin follows after each build. Haven't looked much in the code but I guess there is some function that is executed as a hook/event from Jenkins. That function has some algorithm (process).

</ul>

<p><b>Use cases</b></p>
<p>This feature provides the option to control the number of builds the rule can process.
If used with specific actions it can save a significant amount of time when the build history is long.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this suggests that the option has only performance impact while the better performance is only side effect - the real purpose of this flag is to make sure that action is executed at mostn times

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm... This was the original use case actually :-)


<p>This feature also provides the option to skip a number of builds while processing builds.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not also - this is the only feature

Copy link
Author

@Eccenux Eccenux Nov 14, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the original use case is still valid. You can use matchAtMost to skip tail (and maybe save some time) and you can also use it to skip head (and preserve top builds).

To skip 5 builds, you should create a rule with the "Match every build" condition and no action, then set <code>matchAtMost = 5</code>.
This will effectively skip 5 builds in each build history manager process. It’s equivalent to saying <code>buildToCheck = lastBuildNo - 5</code>.</p>

<p><b>Warning!</b></p>
<p>If the <code>matchAtMost</code> value is set to zero, the rule is effectively disabled. This is useful if the user wants to disable a rule while keeping its other configuration values.</p>
Loading