-
Bug
-
Resolution: Fixed
-
Minor
-
Jenkins 2.166, stash-pull-request-builder 1.8
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user.
There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created.
I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings.
The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to use the global setting. The checkbox is whether to customize the global setting. So we should simply respect the setting for the job, whatever is set by the Jenkins core.
Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting and ignores the per-job setting. We should use job.getQuietPeriod() and set an example for others.
[JENKINS-56337] Stash Pull Request Builder ignores quiet time
| Description |
Original:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job and trust that the use and the Jenkins core do it right. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting. We should use job.getQuietPeriod() and set an example for others. |
New:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job and trust that the user and the Jenkins core do it right. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting. We should use job.getQuietPeriod() and set an example for others. |
| Description |
Original:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job and trust that the user and the Jenkins core do it right. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting. We should use job.getQuietPeriod() and set an example for others. |
New:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job, whatever is set by the Jenkins core. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting. We should use job.getQuietPeriod() and set an example for others. |
| Description |
Original:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job, whatever is set by the Jenkins core. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting. We should use job.getQuietPeriod() and set an example for others. |
New:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job, whatever is set by the Jenkins core. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting and ignored the per-job setting. We should use job.getQuietPeriod() and set an example for others. |
| Description |
Original:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job, whatever is set by the Jenkins core. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting and ignored the per-job setting. We should use job.getQuietPeriod() and set an example for others. |
New:
The call to scheduleBuild2() in StashBuildTrigger.java passes 0 as the first argument (quiet period). This ignores the quiet time settings supplied by the user. There are two places where the quiet time can be set. One is the global configuration, another is the configuration for the Job under "Advanced Project Options". Ignoring the later is particularly bad. If the user sets the quiet time for the job, that job should respect it. Why else would the user set it? It doesn't matter that the trigger is cron driven and that some time has passed since the PR was created. I understand when the quiet period is skipped when the user clicks a button or when a command line interface is used, but the normal use should respect the settings. The global configuration is used if the setting for the job is not set (I checked that). There is no checkbox whether to +use+ the global setting. The checkbox is whether to +customize+ the global setting. So we should simply respect the setting for the job, whatever is set by the Jenkins core. Other PR builders use this.getInstance().getQuietPeriod(). They are wrong, it gives the global setting and ignores the per-job setting. We should use job.getQuietPeriod() and set an example for others. |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
| URL | New: https://github.com/jenkinsci/stash-pullrequest-builder-plugin/pull/46 | |
| Issue Type | Original: New Feature [ 2 ] | New: Bug [ 1 ] |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Review [ 10005 ] | New: Resolved [ 5 ] |