Skip to content

Change default behaviour of "Suppress progress updates in job check" #299

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

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

Conversation

ventojna
Copy link

Change default behaviour of "Suppress progress updates in job check" to reduce GitHub API call because of the rate limit and add a global config for this setting.
We tried to enforce the the global setting but we need some advice about Jelly on this

thx to @meiswjn

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

@ventojna ventojna requested a review from a team as a code owner October 18, 2022 14:30
Copy link
Member

@timja timja left a comment

Choose a reason for hiding this comment

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

Could you expand a bit on the issue you are hitting and what's causing the rate limit issue?

We do disable it on our setup because of the large number of builds we have.
It would probably be possible to batch these rather than making so many calls.

@meiswjn
Copy link

meiswjn commented Oct 19, 2022

Hi Tim,
Thanks for your fast response!

We are using GitHub Cloud, so we cannot disable the rate limit. Our controller is used by many different teams and they often share the same rate limit.

If I am not mistaken, batching the calls would likely not help here, since the feature is about constant status updates on how far the build job is - if we batch those, they would be delayed and don't make any sense anymore anyways, if you understand what I mean.

@timja
Copy link
Member

timja commented Oct 19, 2022

If I am not mistaken, batching the calls would likely not help here, since the feature is about constant status updates on how far the build job is - if we batch those, they would be delayed and don't make any sense anymore anyways, if you understand what I mean.

It depends on how often the updates currently are being sent. if they were grouped to send no more often than 1-2 minutes per job then that may alleviate it while still being fresh enough to being useful.

@meiswjn
Copy link

meiswjn commented Oct 19, 2022

Do you mean batching the calls from multiple jobs?

Since it is currently already possible to disable the progress updates on a per-job level, it would be nice to have the feature of this PR to change the default value globally :)

Copy link
Member

@timja timja left a comment

Choose a reason for hiding this comment

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

concept is fine can you check the CI issues around static checks failures, and refactor so it's not setting the static field on startup as that will never get updated

Comment on lines +147 to +148
public static final boolean defaultSkipProgressUpdates;
public static final boolean enforceSkipProgressUpdates;
Copy link
Member

Choose a reason for hiding this comment

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

these shouldn't be final / static, why do you need them in here? these will only get set on jenkins start

Comment on lines +20 to +26
<j:var set="readOnlyMode" value="${descriptor.enforceSkipProgressUpdates}" />
<j:if test="${!readP}">
<f:entry title="${%Suppress progress updates in job check}" field="skipProgressUpdates"
description="${%Queued, checkout and completed will still be sent}">
<f:checkbox default="${descriptor.defaultSkipProgressUpdates}"/>
</f:entry>
</j:if>
Copy link

Choose a reason for hiding this comment

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

We would need some advice on Jelly conditional rendering here.. we try to hide the option on the jobs, if the global configuration says that the option is enforced.
It seems like ${!readOnlyMode} does not resolve correctly here (we tried it with and without the descriptor). If you have any idea, let us know. Thanks!

Comment on lines +20 to +21
<j:var set="readOnlyMode" value="${descriptor.enforceSkipProgressUpdates}" />
<j:if test="${!readP}">
Copy link
Member

Choose a reason for hiding this comment

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

why not just do this?

Suggested change
<j:var set="readOnlyMode" value="${descriptor.enforceSkipProgressUpdates}" />
<j:if test="${!readP}">
<j:if test="${!descriptor.enforceSkipProgressUpdates}">

Copy link

Choose a reason for hiding this comment

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

Same result. We built that complicated workaround because this did not work initially.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants