[JIRA] (JENKINS-61966) Support button is visible for users with no permissions to generate bundles
Title: Message Title Adam Gabryś created an issue Jenkins / JENKINS-61966 Support button is visible for users with no permissions to generate bundles Issue Type: Bug Assignee: Emilio Escobar Attachments: 1-support-button-is-available-in-menu.png, 2-tab-for-generating-bundle.png, 3-missing-permissions.png, global-permissions.png, project-base-matrix.png Components: support-core-plugin Created: 2020-04-20 08:18 Environment: Jenkins: 2.222.1 Support Core Plugin: 2.68 Matrix Authorization Strategy Plugin: 2.5 Priority: Major Reporter: Adam Gabryś The Support button is visible for users, who have no permissions to generate bundles. Step to reproduce: open FreeStyle or Workflow job the support button is visible click the button and a tab for creating bundle is open click Generate Bundle and an error page is displayed Support → Download Bundle permission is unchecked for all users: Project-base strategy is enabled, but it does not provide the Download Bundle permission:
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś commented on JENKINS-61068 Re: Active Choices radio parameter has incorrect default value on parambuild URL Does the cascading of other Active Choices still works? The parambuild and buildWithParameters pages take parameter default values and render them as inputs. No other logic is available or executed. It means that if one field should be changed when another field is changed - the logic won't be executed. Example: For the plugin documentation we state that this plugin only works and is intended for interactive use by a human and not by API. Has this PR changed that? All dynamic actions and validations are still able only for the humans (don't allow checking two radio buttons at the same time etc.). The PR only changes the way of setting the default values of the most basic parameter (not support for references). I know it is not perfect, but make the plugin more usable in basic cases. It also partially solves problem mentioned here JENKINS-28735 (set correct default values for basic parameters when jobs are executed by timers). Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-61068 Active Choices radio parameter has incorrect default value on parambuild URL Change By: Adam Gabryś Attachment: reference-parameter.gif Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204555.1581528008000.4182.1583857740300%40Atlassian.JIRA.
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś commented on JENKINS-61068 Re: Active Choices radio parameter has incorrect default value on parambuild URL Ioannis Moutsatsos you are testing an incorrect page. You opened Build with Parameters. On it everything looks good. The problem is that this page can be used only by humans (impossible to set parameters by using POST data or GET parameters). The pages which should be used by robots are: parambuild - takes parameters from GET buildWithParameters - takes parameters from POST Example for parambuild: As you can see, the default value is set incorrectly (should be 3, but it is filled with 1). My parameter configuration: Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204555.1581528008000.3804.1583839500239%40Atlassian.JIRA.
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-61068 Active Choices radio parameter has incorrect default value on parambuild URL Change By: Adam Gabryś Attachment: parameter-configuration.png Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204555.1581528008000.3800.1583839440226%40Atlassian.JIRA.
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-61068 Active Choices radio parameter has incorrect default value on parambuild URL Change By: Adam Gabryś Attachment: view-parambuild.png Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204555.1581528008000.3796.1583839320212%40Atlassian.JIRA.
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-61068 Active Choices radio parameter has incorrect default value on parambuild URL Change By: Adam Gabryś Attachment: view-build-with-parameters.png Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204555.1581528008000.3792.1583839200370%40Atlassian.JIRA.
[JIRA] (JENKINS-41308) support Use Groovy Sandbox scripts in activeChoiceParams
Title: Message Title
Adam Gabryś commented on JENKINS-41308
Re: support Use Groovy Sandbox scripts in activeChoiceParams
It is possible to use Dynamic DSL. Unfortunately, it has two disadvantages:
it forces to set all parameters, even those which we don't want to set (the default values are fine for us). This behavior is also a cause that the code could stop working after the 3rd-party plugin update (for example a new field has been added)
the code which does simple stuff is much longer and less readable
Examples:
Dynamic DSL:
choiceParameter {
delegate.name(name)
delegate.description(description)
delegate.choiceType('PT_RADIO')
delegate.script {
groovyScript {
script {
script(valuesToString())
sandbox(true)
}
fallbackScript{
script('')
sandbox(true)
}
}
}
delegate.randomName('')
delegate.filterable(false)
delegate.filterLength(0)
}
Static DSL:
activeChoiceParam(name) {
delegate.description(this.description)
delegate.choiceType('RADIO')
delegate.groovyScript {
script(valuesToString()) {
sandbox()
}
}
}
As a user I would be really happy to have this feature merged. From the other side, if you don't want to merge anything related to static DSL, it would be good if you could mark it as deprecated. Keeping it in the current state confuses the users. They use and even create PRs to the code which is frozen (never will be changed - according to the statement that all PRs are declined).
Add Comment
[JIRA] (JENKINS-55908) Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps
Title: Message Title
Adam Gabryś edited a comment on JENKINS-55908
Re: Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps
We started using a new feature introduced in the [Timestamper| [ https://plugins.jenkins.io/timestamper/] ] 1.9 plugin: {{Enable for all Pipeline builds}}. The timestamps are printed correctly.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197310.1549016484000.516.1582795560343%40Atlassian.JIRA.
[JIRA] (JENKINS-55908) Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps
Title: Message Title Adam Gabryś commented on JENKINS-55908 Re: Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps We started using a new feature introduced in the [Timestamper|https://plugins.jenkins.io/timestamper/] 1.9 plugin: Enable for all Pipeline builds. The timestamps are printed correctly. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197310.1549016484000.514.1582795500139%40Atlassian.JIRA.
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś commented on JENKINS-61068 Re: Active Choices radio parameter has incorrect default value on parambuild URL I created a pull request (PR #32) with the fix. Now it works as follow: Code Result Returns ['1:selected', '2', '3', '4', '5'] "1" the default value ['1', '2', '3:selected', '4', '5'] "3" the default value, no difference if it is first or last ['1', '2', '3', '4'] "1" the first element when (no values are marked as default) [] "" empty value (Jenkins cannot handle null) [""] "" the first element (no values are marked as default) ['1:selected', '2', '3:selected', '4'] "1,3" multiple values are checked, so all of them are added (consistent with Build with Parameters behavior) ['1', '2', ':selected', '4'] ""
[JIRA] (JENKINS-61068) Active Choices radio parameter has incorrect default value on parambuild URL
Title: Message Title Adam Gabryś created an issue Jenkins / JENKINS-61068 Active Choices radio parameter has incorrect default value on parambuild URL Issue Type: Bug Assignee: Bruno P. Kinoshita Attachments: build-with-parameters.png, parambuild.png Components: active-choices-plugin, build-with-parameters-plugin Created: 2020-02-12 17:20 Environment: Jenkins 2.204.2 Active Choices Plug-in 2.2.2 Build With Parameters 1.4 Priority: Major Reporter: Adam Gabryś Active Choice radio parameter on parambuild page is always visible as text box (which is fine). Unfortunately, the default value is set incorrectly. The plugin always fills the text box with the first value from the script and does not remove :selected suffix. It means that for the following script: ['1', '2', '3:selected', '4', '5'] it returns 1, and for: ['1:selected', '2', '3', '4', '5'] it returns 1:selected. This behavior makes radio button unusable when builds are triggered by Jenkins Pipeline build
[JIRA] (JENKINS-60901) GitHub manages hooks even when it has not been configured to do it
Title: Message Title Adam Gabryś created an issue Jenkins / JENKINS-60901 GitHub manages hooks even when it has not been configured to do it Issue Type: Bug Assignee: Kirill Merkushev Attachments: github-servers.png, scm-configuration.png Components: github-plugin Created: 2020-01-29 11:54 Priority: Major Reporter: Adam Gabryś Jenkins GitHub plugin requires a user with administration access to manage hooks: "There is no credentials with admin access to manage hooks on GitHubRepositoryName[host=example.org,username=username,repository=repository]" Such approach does not match our security guidelines, so we manage all hooks manually (from GitHub UI). Unfortunately, Jenkins still tries to manage webhooks even when we didn't ask to do it. Our servers list is empty: I searched for any option which will allow disable this behavior but I didn't find anything. This is the configuration of SCM for our projects: I believe it is a bug because Jenkins shouldn't do stuff, when we don't configure it. If this behavior is expected, then this ticket should be changed to a feature: Allow disabling managing webhooks when no GitHub server is configured
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-60874
Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Change By:
Adam Gabryś
GitHub Branch Source plugin has introduced unique symbols (not released yet), so finally we are able to configure traits by using Job DSL dynamic API instead of {{configure block}}. Unfortunately, ForkPullRequestDiscoveryTrait ({{gitHubForkDiscovery}}) is unavailable. For now the only possible option is to still use {{configure}} block:{code:java}branchSources {branchSource {source {github {apiUri(config.scm.apiUrl)id(config.name)repoOwner(config.scm.organisation)repository(config.scm.repository)repositoryUrl(config.scm.url)configuredByUrl(false)credentialsId(config.scm.credentialsId)traits {gitHubBranchDiscovery { strategyId(3)}gitHubPullRequestDiscovery { strategyId(1)}}}}buildStrategies {skipInitialBuildOnFirstBranchIndexing()}}}configure {def traits = it / 'sources' / 'data' / 'jenkins.branch.BranchSource' / 'source' / 'traits'traits << 'org.jenkinsci.plugins.github__branch__source.ForkPullRequestDiscoveryTrait' {strategyId(1)trust(class: 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission')}}{code}List of available traits in Job DSL Dynamic API Vievwer: * gitHubAgedRefsTrait * gitHubBranchDiscovery * gitHubPullRequestDiscovery * gitHubSshCheckout * gitHubTagDiscoveryMissing: * gitHubForkDiscovery ← missing, but exists possible to execute I tried: 1){code:java}gitHubForkDiscovery {strategyId(1)trust('trustPermission')} {code}{noformat}ERROR: (unknown source) No signature of method: javaposse.jobdsl.plugin.structs.DescribableContext.trust() is applicable for argument types: (java.lang.String) values: [trustPermission]Possible solutions: getAt(java.lang.String), print(java.io.PrintWriter), use([Ljava.lang.Object;), print(java.lang.Object), wait(), dump(){noformat}2){code:java}gitHubForkDiscovery {strategyId(1)trust(gitHubTrustPermissions)} {code}{noformat}ERROR: (MultibranchJobFactory.groovy, line 89) No such property: gitHubTrustPermissions for class: javaposse.jobdsl.plugin.structs.DescribableContext{noformat}3){code:java}gitHubForkDiscovery {strategyId(1)trust(gitHubTrustPermissions())} {code}{noformat}ERROR: (unknown source) No signature of method: javaposse.jobdsl.plugin.structs.DescribableContext.gitHubTrustPermissions() is applicable for argument types: () values: []{noformat}4){code:java}gitHubForkDiscovery {strategyId(1)trust {gitHubTrustPermissions()}} {code}{noformat}ERROR: (unknown source) No signature of method:
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-60874
Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Change By:
Adam Gabryś
GitHub Branch Source plugin has introduced unique symbols (not released yet), so finally we are able to configure traits by using Job DSL dynamic API instead of {{configure block}}. Unfortunately, ForkPullRequestDiscoveryTrait ({{gitHubForkDiscovery}}) is unavailable. For now the only possible option is to still use {{configure}} block:{code :java }branchSources {branchSource {source {github {apiUri(config.scm.apiUrl)id(config.name)repoOwner(config.scm.organisation)repository(config.scm.repository)repositoryUrl(config.scm.url)configuredByUrl(false)credentialsId(config.scm.credentialsId)traits {gitHubBranchDiscovery { strategyId(3)}gitHubPullRequestDiscovery { strategyId(1)}}}}buildStrategies {skipInitialBuildOnFirstBranchIndexing()}}}configure {def traits = it / 'sources' / 'data' / 'jenkins.branch.BranchSource' / 'source' / 'traits'traits << 'org.jenkinsci.plugins.github__branch__source.ForkPullRequestDiscoveryTrait' {strategyId(1)trust(class: 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission')}}{code} List of available traits in Job DSL Dynamic API Vievwer:* gitHubAgedRefsTrait* gitHubBranchDiscovery* gitHubPullRequestDiscovery * gitHubSshCheckout* gitHubTagDiscoveryMissing:* gitHubPullRequestDiscovery ← I'm able to configure* gitHubForkDiscovery ← I'm not able to configure missing, but exists I tried: 1) {code :java }gitHubForkDiscovery {strategyId(1)trust('trustPermission')} {code} {noformat}ERROR: (unknown source) No signature of method: javaposse.jobdsl.plugin.structs.DescribableContext.trust() is applicable for argument types: (java.lang.String) values: [trustPermission]Possible solutions: getAt(java.lang.String), print(java.io.PrintWriter), use([Ljava.lang.Object;), print(java.lang.Object), wait(), dump(){noformat}2){code:java}gitHubForkDiscovery {strategyId(1)trust(gitHubTrustPermissions)} {code}{noformat}ERROR: (MultibranchJobFactory.groovy, line 89) No such property: gitHubTrustPermissions for class: javaposse.jobdsl.plugin.structs.DescribableContext{noformat}3){code:java}gitHubForkDiscovery {strategyId(1)trust(gitHubTrustPermissions())} {code}{noformat}ERROR: (unknown source) No signature of method: javaposse.jobdsl.plugin.structs.DescribableContext.gitHubTrustPermissions() is applicable for argument types: () values: []{noformat}4){code:java}gitHubForkDiscovery {strategyId(1)trust {gitHubTrustPermissions()}} {code}{noformat}ERROR: (unknown source) No
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-60874
Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Change By:
Adam Gabryś
GitHub Branch Source plugin has introduced unique symbols (not released yet), so finally we are able to configure traits by using Job DSL dynamic API instead of {{configure block}}. Unfortunately, ForkPullRequestDiscoveryTrait ({{gitHubForkDiscovery}}) is unavailable. For now the only possible option is to still use {{configure}} block:{code}branchSources {branchSource {source {github {apiUri(config.scm.apiUrl)id(config.name)repoOwner(config.scm.organisation)repository(config.scm.repository)repositoryUrl(config.scm.url)configuredByUrl(false)credentialsId(config.scm.credentialsId)traits {gitHubBranchDiscovery { strategyId(3)}gitHubPullRequestDiscovery { strategyId(1)}}}}buildStrategies {skipInitialBuildOnFirstBranchIndexing()}}}configure {def traits = it / 'sources' / 'data' / 'jenkins.branch.BranchSource' / 'source' / 'traits'traits << 'org.jenkinsci.plugins.github__branch__source.ForkPullRequestDiscoveryTrait' {strategyId(1)trust(class: 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission')}}{code}List of available traits in Job DSL Dynamic API Vievwer :* gitHubAgedRefsTrait* gitHubBranchDiscovery* gitHubSshCheckout* gitHubTagDiscoveryMissing:* gitHubPullRequestDiscovery ← I'm able to configure* gitHubForkDiscovery ← I'm not able to configureI tried:{code}gitHubForkDiscovery {strategyId(1)trust('trustPermission')} {code}
Add Comment
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-60874
Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Change By:
Adam Gabryś
GitHub Branch Source plugin has introduced unique symbols (not released yet), so finally we are able to configure traits by using Job DSL dynamic API instead of {{configure block}}. Unfortunately, ForkPullRequestDiscoveryTrait ({{gitHubForkDiscovery}}) is unavailable. For now the only possible option is to still use {{configure}} block:{code}branchSources {branchSource {source {github {apiUri(config.scm.apiUrl)id(config.name)repoOwner(config.scm.organisation)repository(config.scm.repository)repositoryUrl(config.scm.url)configuredByUrl(false)credentialsId(config.scm.credentialsId)traits {gitHubBranchDiscovery { strategyId(3)}gitHubPullRequestDiscovery { strategyId(1)}}}}buildStrategies {skipInitialBuildOnFirstBranchIndexing()}}}configure {def traits = it / 'sources' / 'data' / 'jenkins.branch.BranchSource' / 'source' / 'traits'traits << 'org.jenkinsci.plugins.github__branch__source.ForkPullRequestDiscoveryTrait' {strategyId(1)trust(class: 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission')}}{code}List of available traits:* gitHubAgedRefsTrait* gitHubBranchDiscovery* gitHubSshCheckout* gitHubTagDiscoveryMissing:* gitHubForkDiscovery * gitHubPullRequestDiscovery
Add Comment
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60874 Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API Change By: Adam Gabryś Summary: Cannot configure ForkPullRequestDiscoveryTrait and OriginPullRequestDiscoveryTrait by using Job DSL dynamic API Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204256.1580129713000.6564.1580131320930%40Atlassian.JIRA.
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-60874
Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Change By:
Adam Gabryś
GitHub Branch Source plugin has introduced unique symbols (not released yet), so finally we are able to configure traits by using Job DSL dynamic API instead of {{configure block}}. Unfortunately, ForkPullRequestDiscoveryTrait ({{gitHubForkDiscovery}}) is unavailable. For now the only possible option is to still use {{configure}} block:{code}branchSources {branchSource {source {github {apiUri(config.scm.apiUrl)id(config.name)repoOwner(config.scm.organisation)repository(config.scm.repository)repositoryUrl(config.scm.url)configuredByUrl(false)credentialsId(config.scm.credentialsId)traits {gitHubBranchDiscovery { strategyId(3)}gitHubPullRequestDiscovery { strategyId(1)}}}}buildStrategies {skipInitialBuildOnFirstBranchIndexing()}}}configure {def traits = it / 'sources' / 'data' / 'jenkins.branch.BranchSource' / 'source' / 'traits'traits << 'org.jenkinsci.plugins.github__branch__source.ForkPullRequestDiscoveryTrait' {strategyId(1)trust(class: 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission')}}{code} List of available traits:* gitHubAgedRefsTrait* gitHubBranchDiscovery* gitHubSshCheckout* gitHubTagDiscoveryMissing:* gitHubForkDiscovery* gitHubPullRequestDiscovery
Add Comment
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait and OriginPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60874 Cannot configure ForkPullRequestDiscoveryTrait and OriginPullRequestDiscoveryTrait by using Job DSL dynamic API Change By: Adam Gabryś Summary: Cannot configure ForkPullRequestDiscoveryTrait and OriginPullRequestDiscoveryTrait by using Job DSL dynamic API Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204256.1580129713000.6561.1580130721333%40Atlassian.JIRA.
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60874 Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API Change By: Adam Gabryś Environment: Job DSL: 1.76GitHub Branch Source: 2.5.9-SNAPSHOT (commit: 7179854f068f0012b3d1222f6924e8de5d437513) Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204256.1580129713000.6555.1580129883208%40Atlassian.JIRA.
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60874 Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API Change By: Adam Gabryś Issue Type: Task Bug Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204256.1580129713000.6552.1580129761036%40Atlassian.JIRA.
[JIRA] (JENKINS-60874) Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Title: Message Title
Adam Gabryś created an issue
Jenkins / JENKINS-60874
Cannot configure ForkPullRequestDiscoveryTrait by using Job DSL dynamic API
Issue Type:
Task
Assignee:
Daniel Spilker
Components:
github-branch-source-plugin, job-dsl-plugin
Created:
2020-01-27 12:55
Priority:
Major
Reporter:
Adam Gabryś
GitHub Branch Source plugin has introduced unique symbols (not released yet), so finally we are able to configure traits by using Job DSL dynamic API instead of configure block. Unfortunately, ForkPullRequestDiscoveryTrait (gitHubForkDiscovery) is unavailable. For now the only possible option is to still use configure block:
branchSources {
branchSource {
source {
github {
apiUri(config.scm.apiUrl)
id(config.name)
repoOwner(config.scm.organisation)
repository(config.scm.repository)
repositoryUrl(config.scm.url)
configuredByUrl(false)
credentialsId(config.scm.credentialsId)
traits {
gitHubBranchDiscovery {
strategyId(3)
}
gitHubPullRequestDiscovery {
strategyId(1)
}
}
}
}
buildStrategies {
skipInitialBuildOnFirstBranchIndexing()
}
}
}
configure {
def traits = it / 'sources' / 'data' / 'jenkins.branch.BranchSource' / 'source' / 'traits'
traits << 'org.jenkinsci.plugins.github__branch__source.ForkPullRequestDiscoveryTrait' {
strategyId(1)
trust(class: 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission')
}
}
[JIRA] (JENKINS-57832) How to add permission in GlobalMatrixAuthorizationStrategy through the groovy - for hudson.sercurity.item.Move
Title: Message Title
Adam Gabryś edited a comment on JENKINS-57832
Re: How to add permission in GlobalMatrixAuthorizationStrategy through the groovy - for hudson.sercurity.item.Move
I also need this information. I used Google and found only this ticket and nothing more :( I started searching in plugins and finally I found it :)* Item.Move is defined in {{com.cloudbees.hudson.plugins.folder.relocate.RelocationAction}} class ([CloudBees Folders plugin|https://plugins.jenkins.io/cloudbees-folder] plugin )* Run.Replay is defined in {{org.jenkinsci.plugins.workflow.cps.replay.ReplayAction}} class ([Pipeline: Groovy plugin |https://plugins.jenkins.io/workflow-cps] plugin )More details here:* [Where is hudson.model.Item.Move permission object defined?|https://stackoverflow.com/q/59665525/4944847]* [Where is hudson.model.Run.Replay permission object defined?|https://stackoverflow.com/q/59665635/4944847]
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199789.1559626187000.5633.1578578820200%40Atlassian.JIRA.
[JIRA] (JENKINS-57832) How to add permission in GlobalMatrixAuthorizationStrategy through the groovy - for hudson.sercurity.item.Move
Title: Message Title Adam Gabryś commented on JENKINS-57832 Re: How to add permission in GlobalMatrixAuthorizationStrategy through the groovy - for hudson.sercurity.item.Move I also need this information. I used Google and found only this ticket and nothing more I started searching in plugins and finally I found it Item.Move is defined in com.cloudbees.hudson.plugins.folder.relocate.RelocationAction class (CloudBees Folders plugin plugin) Run.Replay is defined in org.jenkinsci.plugins.workflow.cps.replay.ReplayAction class (Pipeline: Groovy plugin) More details here: Where is hudson.model.Item.Move permission object defined? Where is hudson.model.Run.Replay permission object defined? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199789.1559626187000.5630.1578578760287%40Atlassian.JIRA.
[JIRA] (JENKINS-59788) Timestamps missing for agent-based steps in Pipeline Job 2.190.1
Title: Message Title
Adam Gabryś edited a comment on JENKINS-59788
Re: Timestamps missing for agent-based steps in Pipeline Job 2.190.1
This is the simplest possible pipeline to reproduce (I could try to get the docker image used to create the pod):{code:java}pipeline { agent { label 'tiny' } options { timestamps() } stages { stage('loop') { steps { sh '''while true;do echo 'line' sleep 3done ''' } } }}{code}I see no timestamps in logs:{noformat}Started by user Gabrys, AdamRunning in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeAgent zjs-agabrys-tiny-qtc0t is provisioned from template Kubernetes Pod TemplateRunning on zjs-agabrys-tiny-qtc0t in /var/lib/jenkins/workspace/test[Pipeline] {[Pipeline] timestamps[Pipeline] {[Pipeline] stage[Pipeline] { (loop)[Pipeline] sh+ true+ echo lineline+ sleep 3+ true+ echo lineline+ sleep 3+ true{noformat}Luckily, we found the new option available {{Manage Jenkins → Configure System → Timestamper}}: *{{Enabled for all Pipeline builds}}*. I enabled it, removed {{options}} block from Jenkinsfile and this is the result:{noformat}14:12:42 Started by user Gabrys, Adam14:12:42 Running in Durability level: MAX_SURVIVABILITY14:12:42 [Pipeline] Start of Pipeline14:12:42 [Pipeline] node14:12:57 Still waiting to schedule task14:12:57 All nodes of label ‘tiny’ are offline14:13:07 Agent zjs-agabrys-tiny-xlmd4 is provisioned from template Kubernetes Pod Template14:13:07 Running on zjs-agabrys-tiny-xlmd4 in /var/lib/jenkins/workspace/test14:13:07 [Pipeline] {14:13:07 [Pipeline] stage14:13:07 [Pipeline] { (loop)14:13:07 [Pipeline] sh14:13:09 + true14:13:09 + echo line14:13:09 line14:13:09 + sleep 314:13:12 + true14:13:12 + echo line14:13:12 line14:13:12 + sleep 314:13:14 + true{noformat}We want activate timestamps activated for all our jobs. so we don't have this problem anymore (even though {{timestamps}} option doesn't work).One more interesting thing. Free style jobs never have problems with timestamps. When I add Timestamp wrapper and execute the job on agent I see:{noformat}14:20:07 Started by user Gabrys, Adam14:20:07 Running as SYSTEM14:20:07 Agent zjs-agabrys2-tiny-zfbqr is provisioned from template Kubernetes Pod Template14:20:07 Building remotely on zjs-agabrys2-tiny-zfbqr (tiny) in workspace /var/lib/jenkins/workspace/test214:20:08 [test2] $ /bin/bash -xe /tmp/jenkins1316037729727606180.sh14:20:08 + true14:20:08 + echo line14:20:08 line14:20:08 + sleep 314:20:11 + true14:20:11 + echo line{noformat}
Add Comment
[JIRA] (JENKINS-59788) Timestamps missing for agent-based steps in Pipeline Job 2.190.1
Title: Message Title
Adam Gabryś edited a comment on JENKINS-59788
Re: Timestamps missing for agent-based steps in Pipeline Job 2.190.1
This is the simplest possible pipeline to reproduce (I could try to get the docker image used to create the pod):{code:java}pipeline { agent { label 'tiny' } options { timestamps() } stages { stage('loop') { steps { sh '''while true;do echo 'line' sleep 3done ''' } } }}{code}I see no timestamps in logs:{noformat}Started by user Gabrys, AdamRunning in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeAgent zjs-agabrys-tiny-qtc0t is provisioned from template Kubernetes Pod TemplateRunning on zjs-agabrys-tiny-qtc0t in /var/lib/jenkins/workspace/test[Pipeline] {[Pipeline] timestamps[Pipeline] {[Pipeline] stage[Pipeline] { (loop)[Pipeline] sh+ true+ echo lineline+ sleep 3+ true+ echo lineline+ sleep 3+ true{noformat}Luckily, we found the new option available {{Manage Jenkins → Configure System → Timestamper}}: *{{Enabled for all Pipeline builds}}*. I enabled it, removed \ {{options { timestamps() }} } block from Jenkinsfile and this is the result:{noformat}14:12:42 Started by user Gabrys, Adam14:12:42 Running in Durability level: MAX_SURVIVABILITY14:12:42 [Pipeline] Start of Pipeline14:12:42 [Pipeline] node14:12:57 Still waiting to schedule task14:12:57 All nodes of label ‘tiny’ are offline14:13:07 Agent zjs-agabrys-tiny-xlmd4 is provisioned from template Kubernetes Pod Template14:13:07 Running on zjs-agabrys-tiny-xlmd4 in /var/lib/jenkins/workspace/test14:13:07 [Pipeline] {14:13:07 [Pipeline] stage14:13:07 [Pipeline] { (loop)14:13:07 [Pipeline] sh14:13:09 + true14:13:09 + echo line14:13:09 line14:13:09 + sleep 314:13:12 + true14:13:12 + echo line14:13:12 line14:13:12 + sleep 314:13:14 + true{noformat}We want timestamps activated for all our jobs. so we don't have this problem anymore (even though {{timestamps}} option doesn't work).One more interesting thing. Free style jobs never have problems with timestamps. When I add Timestamp wrapper and execute the job on agent I see:{noformat}14:20:07 Started by user Gabrys, Adam14:20:07 Running as SYSTEM14:20:07 Agent zjs-agabrys2-tiny-zfbqr is provisioned from template Kubernetes Pod Template14:20:07 Building remotely on zjs-agabrys2-tiny-zfbqr (tiny) in workspace /var/lib/jenkins/workspace/test214:20:08 [test2] $ /bin/bash -xe /tmp/jenkins1316037729727606180.sh14:20:08 + true14:20:08 + echo line14:20:08 line14:20:08 + sleep 314:20:11 + true14:20:11 + echo line{noformat}
Add Comment
[JIRA] (JENKINS-59788) Timestamps missing for agent-based steps in Pipeline Job 2.190.1
Title: Message Title
Adam Gabryś edited a comment on JENKINS-59788
Re: Timestamps missing for agent-based steps in Pipeline Job 2.190.1
This is the simplest possible pipeline to reproduce (I could try to get the docker image used to create the pod) :{code:java}pipeline { agent { label 'tiny' } options { timestamps() } stages { stage('loop') { steps { sh '''while true;do echo 'line' sleep 3done ''' } } }}{code}I see no timestamps in logs:{noformat}Started by user Gabrys, AdamRunning in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeAgent zjs-agabrys-tiny-qtc0t is provisioned from template Kubernetes Pod TemplateRunning on zjs-agabrys-tiny-qtc0t in /var/lib/jenkins/workspace/test[Pipeline] {[Pipeline] timestamps[Pipeline] {[Pipeline] stage[Pipeline] { (loop)[Pipeline] sh+ true+ echo lineline+ sleep 3+ true+ echo lineline+ sleep 3+ true{noformat}Luckily, we found the new option available {{Manage Jenkins → Configure System → Timestamper}}: *{{Enabled for all Pipeline builds}}*. I enabled it, removed \ {{options \ { timestamps() }}} from Jenkinsfile and this is the result:{noformat}14:12:42 Started by user Gabrys, Adam14:12:42 Running in Durability level: MAX_SURVIVABILITY14:12:42 [Pipeline] Start of Pipeline14:12:42 [Pipeline] node14:12:57 Still waiting to schedule task14:12:57 All nodes of label ‘tiny’ are offline14:13:07 Agent zjs-agabrys-tiny-xlmd4 is provisioned from template Kubernetes Pod Template14:13:07 Running on zjs-agabrys-tiny-xlmd4 in /var/lib/jenkins/workspace/test14:13:07 [Pipeline] {14:13:07 [Pipeline] stage14:13:07 [Pipeline] { (loop)14:13:07 [Pipeline] sh14:13:09 + true14:13:09 + echo line14:13:09 line14:13:09 + sleep 314:13:12 + true14:13:12 + echo line14:13:12 line14:13:12 + sleep 314:13:14 + true{noformat}We want timestamps activated for all our jobs. so we don't have this problem anymore (even though {{timestamps}} option doesn't work).One more interesting thing. Free style jobs never have problems with timestamps. When I add Timestamp wrapper and execute the job on agent I see:{noformat}14:20:07 Started by user Gabrys, Adam14:20:07 Running as SYSTEM14:20:07 Agent zjs-agabrys2-tiny-zfbqr is provisioned from template Kubernetes Pod Template14:20:07 Building remotely on zjs-agabrys2-tiny-zfbqr (tiny) in workspace /var/lib/jenkins/workspace/test214:20:08 [test2] $ /bin/bash -xe /tmp/jenkins1316037729727606180.sh14:20:08 + true14:20:08 + echo line14:20:08 line14:20:08 + sleep 314:20:11 + true14:20:11 + echo line{noformat}
Add Comment
[JIRA] (JENKINS-59788) Timestamps missing for agent-based steps in Pipeline Job 2.190.1
Title: Message Title
Adam Gabryś commented on JENKINS-59788
Re: Timestamps missing for agent-based steps in Pipeline Job 2.190.1
This is the simplest possible pipeline to reproduce:
pipeline {
agent {
label 'tiny'
}
options {
timestamps()
}
stages {
stage('loop') {
steps {
sh '''
while true;
do
echo 'line'
sleep 3
done
'''
}
}
}
}
I see no timestamps in logs:
Started by user Gabrys, Adam
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Agent zjs-agabrys-tiny-qtc0t is provisioned from template Kubernetes Pod Template
Running on zjs-agabrys-tiny-qtc0t in /var/lib/jenkins/workspace/test
[Pipeline] {
[Pipeline] timestamps
[Pipeline] {
[Pipeline] stage
[Pipeline] { (loop)
[Pipeline] sh
+ true
+ echo line
line
+ sleep 3
+ true
+ echo line
line
+ sleep 3
+ true
Luckily, we found the new option available Manage Jenkins → Configure System → Timestamper: Enabled for all Pipeline builds. I enabled it, removed {{options { timestamps() }}} from Jenkinsfile and this is the result:
14:12:42 Started by user Gabrys, Adam
14:12:42 Running in Durability level: MAX_SURVIVABILITY
14:12:42 [Pipeline] Start of Pipeline
14:12:42 [Pipeline] node
14:12:57 Still waiting to schedule task
14:12:57 All nodes of label ‘tiny’ are offline
14:13:07 Agent zjs-agabrys-tiny-xlmd4 is provisioned from template Kubernetes Pod Template
14:13:07 Running on zjs-agabrys-tiny-xlmd4 in /var/lib/jenkins/workspace/test
14:13:07 [Pipeline] {
14:13:07 [Pipeline] stage
14:13:07 [Pipeline] { (loop)
14:13:07 [Pipeline] sh
14:13:09 + true
14:13:09 + echo line
14:13:09 line
14:13:09 + sleep 3
14:13:12 + true
14:13:12 + echo line
14:13:12 line
14:13:12 + sleep 3
14:13:14 + true
We want timestamps activated for all our jobs. so we don't have this problem anymore (even though timestamps option doesn't work). One more interesting thing. Free style jobs never have problems with timestamps. When I add Timestamp wrapper and execute the job on agent I see:
14:20:07 Started by user Gabrys, Adam
14:20:07 Running as SYSTEM
14:20:07 Agent zjs-agabrys2-tiny-zfbqr is provisioned from template Kubernetes Pod Template
14:20:07 Building remotely on zjs-agabrys2-tiny-zfbqr (tiny) in workspace /var/lib/jenkins/workspace/test2
14:20:08 [test2] $ /bin/bash -xe /tmp/jenkins1316037729727606180.sh
14:20:08 + true
14:20:08 + echo line
14:20:08 line
14:20:08 +
[JIRA] (JENKINS-59191) SPAM-Not an issue
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-59191 SPAM-Not an issue Change By: Adam Gabryś URL: https://apotektitangel.com/jual-viagra-asli-di-medan/ Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201632.1567441959000.1469.1573767600455%40Atlassian.JIRA.
[JIRA] (JENKINS-59191) SPAM-Not an issue
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-59191 SPAM-Not an issue Change By: Adam Gabryś Labels: kuat obat viagra Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201632.1567441959000.1465.1573767600404%40Atlassian.JIRA.
[JIRA] (JENKINS-60026)
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60026 Change By: Adam Gabryś URL: https://www.klinikaborsiradensaleh.com Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202851.1572666918000.1460.1573767420258%40Atlassian.JIRA.
[JIRA] (JENKINS-60026)
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60026 Change By: Adam Gabryś Labels: aborsi jakarta jasa kandungan klinik klinikaborsi klinikradensaleh kuret menggugurkan raden saleh tempat Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202851.1572666918000.1462.1573767420295%40Atlassian.JIRA.
[JIRA] (JENKINS-60026) Klinik Aborsi Raden Saleh | Jasa aborsi di jakarta Apa itu Klinik Raden Saleh
Title: Message Title Adam Gabryś closed an issue as Won't Fix Jenkins / JENKINS-60026 Klinik Aborsi Raden Saleh | Jasa aborsi di jakarta Apa itu Klinik Raden Saleh Change By: Adam Gabryś Status: Open Closed Resolution: Won't Fix Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202851.1572666918000.1456.1573766940638%40Atlassian.JIRA.
[JIRA] (JENKINS-60026) Klinik Aborsi Raden Saleh | Jasa aborsi di jakarta Apa itu Klinik Raden Saleh
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60026 Klinik Aborsi Raden Saleh | Jasa aborsi di jakarta Apa itu Klinik Raden Saleh Change By: Adam Gabryś [Klinik Raden Saleh|https://www _The message has been removed . klinikaborsiradensaleh.com/] adalah klinik aborsi jakarta yang memiliki beberapa orang dokter spesialis kandungan (SpOG). Para dokter di klinik raden saleh telah mendapatkan izin dan legalitas dari dinas kesehatan. Di klinik raden saleh ini kami menangani kasus aborsi dan menerima pasien dengan kasus pendarahan yang disebabkan oleh suatu kejadian ataupun akibat mengkonsumsi obat aborsi (obat peluntur).Klinik raden saleh juga merupakan klinik aborsi legal atau tempat aborsi legal yang mengerjakan tindakan medis bagian penyakit kandungan. Klinik raden saleh ini disebut [klinik aborsi aman|https://www.klinikaborsiradensaleh.com/] tempat rujukan pasien dari para dokter kandungan dari seluruh Indonesia. Di tempat aborsi ini pasien dengan keluhan bagian kandungan dapat memperoleh penanganan oleh dokter spesialis kandungan yang berlisensi dan sudah berpengalaman.Di [klinik aborsi legal|https://www.klinikaborsiradensaleh.com/] ini akan dilakukan pemeriksaan Usg (Ultrasonografi) ataupun pemeriksaan keadaan umum secara manual sebelum melakukan aborsi. Pemeriksaan ini harus dilakukan untuk mengetahui kondisi pasien secara langsung. Karena dari hasil pemeriksaan ini maka dokter dapat menentukan apakah pasien tersebut dapat dilakukan tindakan aborsi atau tidak. Dan setelah itu seminggu kemudian akan disarankan untuk datang kontrol kesehatan untuk memastikan apakah tindakan sebelumnya sudah tuntas atau tidak.Karena sering terjadi kondisi yang lain akibat pasien sebelumnya telah mencoba melakukan aborsi dengan cara yang lain seperti mengkonsumsi obat aborsi, berobat ke dukun atau dengan cara yang lain namun tidak berhasil. Karena hal itu akan menyebabkan berbagai macam efek samping terhadap rahim si pasien. Yang paling sering terjadi adalah sering mengalami pendarahan dan terjadinya infeksi. Pada kondisi seperti ini akan menjadi pertimbangan untuk dokter apakah tindakan aborsi dapat dilakukan atau tidak.Apabila tindakan aborsi telah selesai dilakukan maka pasien diperbolehkan pulang dan seminggu kemudian pasien datang kembali untuk kontrol ulang. Biasanya setelah selesai kontrol pasien juga boleh melakukan suntik KB di klinik raden saleh ini.Di tempat aborsi legal ini tindakan aborsi dilakukan dengan metode vakum aspirasi atau penyedotan oleh dokter spesialis kandungan. Bila dibandingakan dengan metode kuretase zaman dulu yaitu dengan alat kuret (berupa sendok pengeruk) maka metode vakum ini adalah cara yang paling efektif dan praktis. Semua tindakan medis dilakukan berdasarkan standar operasi pelaksanaan kedokteran kandungan.Bagi anda yang ingin berkonsultasi bahkan membutuhkan tindakan medis bagian kandungan boleh datang ke klinik raden saleh ini. Terutama bagi yang ingin melakukan kuretase ataupun aborsi sebelum anda mengalami pendarahan ataupun infeksi.h3. Metode
[JIRA] (JENKINS-60026)
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-60026 Change By: Adam Gabryś Summary: Klinik Aborsi Raden Saleh | Jasa aborsi di jakarta Apa itu Klinik Raden Saleh Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202851.1572666918000.1458.1573766940687%40Atlassian.JIRA.
[JIRA] (JENKINS-43002) Unable to lock by label in a declarative pipeline script
Title: Message Title
Adam Gabryś edited a comment on JENKINS-43002
Re: Unable to lock by label in a declarative pipeline script
I was looking for how others solved this problem ("fixed without breaking backward-compatibility"). The answer is: fixes are not backward-compatible. Some examples:* sauce-ondemand-plugin: JENKINS-41236 ([see changes in code|https://github.com/jenkinsci/sauce-ondemand-plugin/commit/18608f6f3e3188fd0c4f3f0d5002291575c35fb1])* stashnotifier-plugin: [#245|https://github.com/jenkinsci/stashnotifier-plugin/issues/245] ([see changes in code|https://github.com/ westarne jenkinsci /stashnotifier-plugin/commit/d34dbce05b7e7eb2e2d8e42481a6743fdd0fa901])Maybe it is a good time for Lockable Resources plugin 3.X ? ;) You will be able to fix the bug and you don't have to afraid about backward-compatibility (because it is a new major version). What do you think?
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.180016.1490132375000.7774.1572774120388%40Atlassian.JIRA.
[JIRA] (JENKINS-43002) Unable to lock by label in a declarative pipeline script
Title: Message Title
Adam Gabryś edited a comment on JENKINS-43002
Re: Unable to lock by label in a declarative pipeline script
I was looking for how others solved this problem ("fixed without breaking backward-compatibility"). The answer is: fixes are not backward-compatible. Some examples:* sauce-ondemand-plugin: JENKINS-41236 ([ see changes in code|https://github.com/jenkinsci/sauce-ondemand-plugin/commit/18608f6f3e3188fd0c4f3f0d5002291575c35fb1])* stashnotifier-plugin: [#245|https://github.com/jenkinsci/stashnotifier-plugin/issues/245] ([see changes in code|https://github.com/westarne/stashnotifier-plugin/commit/d34dbce05b7e7eb2e2d8e42481a6743fdd0fa901])Maybe it is a good time for Lockable Resources plugin 3.X ? ;) You will be able to fix the bug and you don't have to afraid about backward-compatibility (because it is a new major version). What do you think?
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.180016.1490132375000.7772.1572774000809%40Atlassian.JIRA.
[JIRA] (JENKINS-43002) Unable to lock by label in a declarative pipeline script
Title: Message Title
Adam Gabryś commented on JENKINS-43002
Re: Unable to lock by label in a declarative pipeline script
I was looking for how others solved this problem ("fixed without breaking backward-compatibility"). The answer is: fixes are not backward-compatible. Some examples:
sauce-ondemand-plugin: JENKINS-41236 (changes in code)
stashnotifier-plugin: #245 (see changes in code)
Maybe it is a good time for Lockable Resources plugin 3.X ? You will be able to fix the bug and you don't have to afraid about backward-compatibility (because it is a new major version). What do you think?
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.180016.1490132375000.7742.1572773940458%40Atlassian.JIRA.
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title Adam Gabryś commented on JENKINS-56875 Re: Missing parameters due to SECURITY-170 We've hit it a few times since April. I compared build.xml of two builds of the same jobs (parameters values are very similar): build-missing.txt build-ok.txt I see only important differences in hudson.model.ParametersAction node. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.198544.155436857.25920.1560340440190%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-56875 Missing parameters due to SECURITY-170 Change By: Adam Gabryś Attachment: build-missing.txt Attachment: build-ok.txt Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.198544.155436857.25918.1560340380128%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56738) Double quoted string is evaluated as a command during pipeline run
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-56738 Double quoted string is evaluated as a command during pipeline run Change By: Adam Gabryś Component/s: pipeline-build-step-plugin Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-56875
Missing parameters due to SECURITY-170
Change By:
Adam Gabryś
We have a pipeline which in {{Test}} stage executes a lot of new jobs by using {{build}} step (we cannot move the jobs logic into this pipeline due to JENKINS-52391 - we don't want to rebuild 120 jobs because 1 has randomly failed):{code:java}stage('Test') {steps {script {def parallelTests = [:]def recipes = env.TESTED_RECIPES.split(',')def testSplit = env.TEST_SPLIT != null ? env.TEST_SPLIT.toInteger() : 1def testWebSplit = env.WEBTEST_SPLIT != null ? env.WEBTEST_SPLIT.toInteger() : 1for (def recipe in recipes) {for (def index = 1; index <= testSplit; ++index) {parallelTests["Test JUnit $recipe $index/$testSplit"] = createTestExecutionStage('generic-test-junit', [ string(name: 'PIPELINE_ID', value: params.PIPELINE_ID), string(name: 'RECIPE', value: recipe), string(name: 'TEST_SPLIT_IDX', value: "${index}"), string(name: 'TEST_SPLIT_MAX', value: "${testSplit}"), string(name: 'PRIORITY', value: params.PRIORITY)])}for (def index = 1; index <= testWebSplit; ++index) {parallelTests["Test Web JUnit $recipe $index/$testWebSplit"] = createTestExecutionStage('generic-test-junit', [ string(name: 'PIPELINE_ID', value: params.PIPELINE_ID), string(name: 'RECIPE', value: recipe), booleanParam(name: 'WEB_TESTS', value: true), string(name: 'TEST_SPLIT_IDX', value: "${index}"), string(name: 'TEST_SPLIT_MAX', value: "${testWebSplit}"), string(name: 'PRIORITY', value: params.PRIORITY)], false)}parallelTests["Test Initialization $recipe"] = createTestExecutionStage('generic-test-initialization', [string(name: 'PIPELINE_ID', value: params.PIPELINE_ID),string(name: 'RECIPE', value: recipe),string(name: 'PRIORITY', value: params.PRIORITY)])parallelTests["Test Server $recipe"] = createTestExecutionStage('generic-test-server', [string(name: 'PIPELINE_ID', value: params.PIPELINE_ID),string(name: 'RECIPE', value: recipe),string(name: 'PRIORITY', value: params.PRIORITY)])}parallel parallelTests}}}{code}{code}def createTestExecutionStage(name, parameters, propagate = true) {return {build(job: name, parameters: parameters, propagate: propagate)}}{code}Unfortunately, very rarely we see the following entries in logs:{noformat}Apr 04, 2019 4:30:04 AM WARNING hudson.model.ParametersAction filterSkipped parameter `PIPELINE_ID` as it
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-56875 Missing parameters due to SECURITY-170 Change By: Adam Gabryś Issue Type: Improvement Bug Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-56875 Missing parameters due to SECURITY-170 Change By: Adam Gabryś Issue Type: Bug Improvement Component/s: build-pipeline-plugin Component/s: pipeline-build-step-plugin Environment: Jenkins: 2.164.1Pipeline plugins:* Build Step: 2.8* Job: 2.32 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-56875 Missing parameters due to SECURITY-170 Change By: Adam Gabryś Component/s: pipeline-build-step-plugin Component/s: build-pipeline-plugin Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title Adam Gabryś updated an issue Jenkins / JENKINS-56875 Missing parameters due to SECURITY-170 Change By: Adam Gabryś Issue Type: Improvement Bug Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-56875
Missing parameters due to SECURITY-170
Change By:
Adam Gabryś
We have a pipeline which in {{Test}} stage executes a lot of new jobs by using {{build}} step (we cannot move the jobs logic into this pipeline due to JENKINS-52391 - we don't want to rebuild 120 jobs because 1 has randomly failed):{code:java}stage('Test') {steps {script {def parallelTests = [:]def recipes = env.TESTED_RECIPES.split(',')def testSplit = env.TEST_SPLIT != null ? env.TEST_SPLIT.toInteger() : 1def testWebSplit = env.WEBTEST_SPLIT != null ? env.WEBTEST_SPLIT.toInteger() : 1for (def recipe in recipes) {for (def index = 1; index <= testSplit; ++index) {parallelTests["Test JUnit $recipe $index/$testSplit"] = createTestExecutionStage('generic-test-junit', [ string(name: 'PIPELINE_ID', value: params.PIPELINE_ID), string(name: 'RECIPE', value: recipe), string(name: 'TEST_SPLIT_IDX', value: "${index}"), string(name: 'TEST_SPLIT_MAX', value: "${testSplit}"), string(name: 'PRIORITY', value: params.PRIORITY)])}for (def index = 1; index <= testWebSplit; ++index) {parallelTests["Test Web JUnit $recipe $index/$testWebSplit"] = createTestExecutionStage('generic-test-junit', [ string(name: 'PIPELINE_ID', value: params.PIPELINE_ID), string(name: 'RECIPE', value: recipe), booleanParam(name: 'WEB_TESTS', value: true), string(name: 'TEST_SPLIT_IDX', value: "${index}"), string(name: 'TEST_SPLIT_MAX', value: "${testWebSplit}"), string(name: 'PRIORITY', value: params.PRIORITY)], false)}parallelTests["Test Initialization $recipe"] = createTestExecutionStage('generic-test-initialization', [string(name: 'PIPELINE_ID', value: params.PIPELINE_ID),string(name: 'RECIPE', value: recipe),string(name: 'PRIORITY', value: params.PRIORITY)])parallelTests["Test Server $recipe"] = createTestExecutionStage('generic-test-server', [string(name: 'PIPELINE_ID', value: params.PIPELINE_ID),string(name: 'RECIPE', value: recipe),string(name: 'PRIORITY', value: params.PRIORITY)])}parallel parallelTests}}}{code}{code}def createTestExecutionStage(name, parameters, propagate = true) {return {build(job: name, parameters: parameters, propagate: propagate)}}{code}Unfortunately, very rarely we see the following entries in logs:{noformat}Apr 04, 2019 4:30:04 AM WARNING hudson.model.ParametersAction filterSkipped parameter `PIPELINE_ID` as it
[JIRA] (JENKINS-56875) Missing parameters due to SECURITY-170
Title: Message Title
Adam Gabryś created an issue
Jenkins / JENKINS-56875
Missing parameters due to SECURITY-170
Issue Type:
Improvement
Assignee:
Unassigned
Attachments:
environment.html, generic-test-junit-build-with-parameters.png, generic-test-junit-missing-parameters.png, generic-test-junit-parameters.png
Components:
build-pipeline-plugin, workflow-job-plugin
Created:
2019-04-04 09:02
Priority:
Major
Reporter:
Adam Gabryś
We have a pipeline which in Test stage executes a lot of new jobs by using build step (we cannot move the jobs logic into this pipeline due to JENKINS-52391 - we don't want to rebuild 120 jobs because 1 has randomly failed):
stage('Test') {
steps {
script {
def parallelTests = [:]
def recipes = env.TESTED_RECIPES.split(',')
def testSplit = env.TEST_SPLIT != null ? env.TEST_SPLIT.toInteger() : 1
def testWebSplit = env.WEBTEST_SPLIT != null ? env.WEBTEST_SPLIT.toInteger() : 1
for (def recipe in recipes) {
for (def index = 1; index <= testSplit; ++index) {
parallelTests["Test JUnit $recipe $index/$testSplit"] = createTestExecutionStage('generic-test-junit', [
string(name: 'PIPELINE_ID', value: params.PIPELINE_ID),
string(name: 'RECIPE', value: recipe),
string(name: 'TEST_SPLIT_IDX', value: "${index}"),
string(name: 'TEST_SPLIT_MAX', value: "${testSplit}"),
string(name: 'PRIORITY', value: params.PRIORITY)
])
[JIRA] (JENKINS-55958) Allow executing additional action in timeout step before wrapped steps will be cancelled
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-55958
Allow executing additional action in timeout step before wrapped steps will be cancelled
Change By:
Adam Gabryś
It would be very useful to allow users to define additional steps which will be executed on timeout, but before the processes will be stopped. For example in our case we want to generate {{threaddump.log}} and {{dump.hprof}} files when the executed Java logic is frozen. It is possible to do it by using {{Time-out actions}} provided by {{Build Timeout}} plugin. Unfortunately, I cannot use it with Jenkins Declarative Pipelines.{code:java}timeout(time: 30, onTimeout: {sh """#!/bin/bashecho "Performing thread dump"for pid in \$(ps auxwwe | grep APPLICATION_ID | grep -v grep | grep BUILD_ID=${env.BUILD_ID} | awk '{print \$2}'); doecho "thread dump of \$pid"jstack \$pid > threaddump_\$pid.logdone"""}) {sh "mvn verify"}{code}
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55958) Allow executing additional action in timeout step before wrapped steps will be cancelled
Title: Message Title
Adam Gabryś created an issue
Jenkins / JENKINS-55958
Allow executing additional action in timeout step before wrapped steps will be cancelled
Issue Type:
Improvement
Assignee:
Unassigned
Components:
workflow-basic-steps-plugin
Created:
2019-02-04 15:37
Priority:
Major
Reporter:
Adam Gabryś
It would be very useful to allow users to define additional steps which will be executed on timeout, but before the processes will be stopped. For example in our case we want to generate threaddump.log and dump.hprof files when the executed Java logic is frozen. It is possible to do it by using Time-out actions provided by Build Timeout plugin. Unfortunately, I cannot use it with Jenkins Declarative Pipelines.
timeout(time: 30, onTimeout: {
sh """#!/bin/bash
echo "Performing thread dump"
for pid in \$(ps auxwwe | grep APPLICATION_ID | grep -v grep | grep BUILD_ID=${env.BUILD_ID} | awk '{print \$2}'); do
echo "thread dump of \$pid"
jstack \$pid > threaddump_\$pid.log
done
"""
}) {
sh "mvn verify"
}
[JIRA] (JENKINS-55908) Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-55908
Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps
Change By:
Adam Gabryś
Xvfb cannot connect to a machine when it is enclosed inside {{timestamps}} step or option. The pipeline throws an exception:{noformat}Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from XX.YY.ZZ.WW/XX.YY.ZZ.WW:47130[...]java.lang.IllegalAccessError: tried to access field hudson.remoting.Channel.executor from class org.jenkinsci.remoting.util.AnonymousClassWarnings[...] Caused: java.io.IOException: Remote call on JNLP4-connect connection from XX.YY.ZZ.WW/XX.YY.ZZ.WW:47130 failed{noformat}I checked and the following pipelines throw exceptions:{noformat}pipeline {agent {label 'swarm'}options {timestamps()}stages {stage('Main') {steps {wrap([$class: 'Xvfb']) {echo 'never reached'}}}}}{noformat}{noformat}pipeline {agent {label 'swarm'}stages {stage('Main') {steps {timestamps {wrap([$class: 'Xvfb']) { echo 'never reached'}}}}}}{noformat}and this works correctly:{noformat}pipeline {agent {label 'swarm'}stages {stage('Main') {steps {wrap([$class: 'Xvfb']) {timestamps { echo 'reached'}}}}}}{noformat}
Add Comment
[JIRA] (JENKINS-55908) Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps
Title: Message Title
Adam Gabryś created an issue
Jenkins / JENKINS-55908
Xvfb does not work when wrap([$class: 'Xvfb']) is defined inside timestamps
Issue Type:
Bug
Assignee:
Steven G Brown
Attachments:
Jenkins Master.html, Jenkins Slave.html, stacktrace.txt
Components:
timestamper-plugin, xvfb-plugin
Created:
2019-02-01 10:21
Environment:
Jenkins: 2.150.1 Xvfb: 1.1.3 timestamper: 1.8.10 See more in Jenkins Master.html and Jenkins Slave.html files
Priority:
Major
Reporter:
Adam Gabryś
Xvfb cannot connect to a machine when it is enclosed inside timestamps step or option. The pipeline throws an exception:
Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from XX.YY.ZZ.WW/XX.YY.ZZ.WW:47130
[...]
java.lang.IllegalAccessError: tried to access field hudson.remoting.Channel.executor from class org.jenkinsci.remoting.util.AnonymousClassWarnings
[...]Caused: java.io.IOException: Remote call on JNLP4-connect connection from XX.YY.ZZ.WW/XX.YY.ZZ.WW:47130 failed
I checked and the following pipelines throw exceptions:
pipeline {
agent {
[JIRA] (JENKINS-54779) Publish site reports
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-54779
Publish site reports
Change By:
Adam Gabryś
Maven projects automatically archive Maven-generated sites. The site is served under {{job//site/}}. It would be great if it would be possible to do the same by {{withMaven}}, example:{noformat}stage('Build Docs') { steps {withMaven(publisherStrategy: 'EXPLICIT' options: [ sitePublisher(disabled: false)]) { sh "mvn site"} }}{noformat}Now I use the following workaround:{noformat}stage('Build Docs') { steps {withMaven(publisherStrategy: 'EXPLICIT' options: [ sitePublisher(disabled: false)]) { sh "mvn site"}dir('target') { archiveArtifacts artifacts: 'site/**'} }}{noformat}Documentation is available under: {{ view/maven/ job//job//lastSuccessfulBuild/artifact/site/}} (user is forced to click {{index.html}}).
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54779) Publish site reports
Title: Message Title
Adam Gabryś updated an issue
Jenkins / JENKINS-54779
Publish site reports
Change By:
Adam Gabryś
Maven projects automatically archive Maven-generated sites. The site is served under {{job//site/}}. It would be great if it would be possible to do the same by {{withMaven}}, example:{noformat}stage('Build Docs') { steps {withMaven(publisherStrategy: 'EXPLICIT' options: [ sitePublisher(disabled: false)]) { sh "mvn site"} }}{noformat}Now I use the following workaround:{noformat}stage('Build Docs') { steps {withMaven(publisherStrategy: 'EXPLICIT' options: [ sitePublisher(disabled: false)]) { sh "mvn site"}dir('target') { archiveArtifacts artifacts: 'site/**'} }}{noformat}Documentation is available under: {{ view/maven/ job//job//lastSuccessfulBuild/artifact/site/}} (user is forced to click {{index.html}}).
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54779) Publish site reports
Title: Message Title
Adam Gabryś created an issue
Jenkins / JENKINS-54779
Publish site reports
Issue Type:
New Feature
Assignee:
Alvaro Lobato
Attachments:
maven-site.png
Components:
pipeline-maven-plugin
Created:
2018-11-22 16:01
Priority:
Major
Reporter:
Adam Gabryś
Maven projects automatically archive Maven-generated sites. The site is served under job//site/. It would be great if it would be possible to do the same by withMaven, example:
stage('Build Docs') {
steps {
withMaven(publisherStrategy: 'EXPLICIT' options: [
sitePublisher(disabled: false)
]) {
sh "mvn site"
}
}
}
Now I use the following workaround:
stage('Build Docs') {
steps {
withMaven(publisherStrategy: 'EXPLICIT' options: [
sitePublisher(disabled: false)
]) {
sh "mvn site"
}
dir('target') {
archiveArtifacts artifacts: 'site/**'
}
}
}
Documentation is available under: job//job//lastSuccessfulBuild/artifact/site/ (user is forced to click index.html).
[JIRA] (JENKINS-39120) Loading a script with the fromGit method causes job to run when that repo is pushed to
Title: Message Title Adam Gabryś commented on JENKINS-39120 Re: Loading a script with the fromGit method causes job to run when that repo is pushed to Hi, Is there any chance that this problem would be fixed? I see the last change in the source code was a year ago. I wonder if I should look for alternatives. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [next-executions-plugin] (JENKINS-32652) XSS in Possible Next Executions widget
Title: Message Title Adam Gabryś commented on JENKINS-32652 Re: XSS in Possible Next Executions widget Tested - works correctly! Thank you. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [next-executions-plugin] (JENKINS-32652) XSS in Possible Next Executions widget
Title: Message Title Adam Gabryś assigned an issue to Ignacio Albors Jenkins / JENKINS-32652 XSS in Possible Next Executions widget Change By: Adam Gabryś Assignee: Ignacio Albors Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [next-executions-plugin] (JENKINS-32652) XSS in Possible Next Executions widget
Title: Message Title
Adam Gabryś created an issue
Jenkins / JENKINS-32652
XSS in Possible Next Executions widget
Issue Type:
Bug
Assignee:
Unassigned
Components:
next-executions-plugin
Created:
27/Jan/16 3:10 PM
Environment:
Jenkins: 1.645 next-executions: 1.0.10
Priority:
Critical
Reporter:
Adam Gabryś
You can inject HTML code by set job display name (Configuration -> Advanced Project Options ). I set JOB alert('foo'); and get alert with "foo" text.
Add Comment
[JIRA] [translation] (JENKINS-18612) Confusing behavior for not logged users (403 Forbidden)
Adam Gabryś closed JENKINS-18612 as Fixed Confusing behavior for not logged users (403 Forbidden) Fixed in 1.11. Change By: Adam Gabryś (08/Jan/14 8:50 AM) Status: Open Closed Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś updated JENKINS-21103 Priorities are assigned top down by first match does not work correctly Change By: Adam Gabryś (02/Jan/14 9:23 AM) Attachment: config.xml This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś edited a comment on JENKINS-21103 Priorities are assigned top down by first match does not work correctly Job Group Id is always 1. I attached config.xml with Jenkins configuration (I flag removed data with "!-- removed --"). Jan 02, 2014 9:36:06 AM FINE PrioritySorter.Queue.Items New Item: Id: 2 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: WAITING Jan 02, 2014 9:36:13 AM FINE PrioritySorter.Queue.Items Buildable: Id: 2 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 9:36:13 AM FINE PrioritySorter.Queue.Items Starting: Id: 2 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 10:04:05 AM FINE PrioritySorter.Queue.Items New Item: Id: 3 JobName: ing_trunk_sonar, jobGroupId: -1, priority: 3, weight: 3.0, status: WAITING Jan 02, 2014 10:04:14 AM FINE PrioritySorter.Queue.Items Buildable: Id: 3 JobName: ing_trunk_sonar, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 10:04:14 AM FINE PrioritySorter.Queue.Items Starting: Id: 3 JobName: ing_trunk_sonar, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś commented on JENKINS-21103 Priorities are assigned top down by first match does not work correctly Job Group Id is always 1. I attached config.xml with Jenkins configuration (I flag removed data with "!- removed --"). Jan 02, 2014 9:36:06 AM FINE PrioritySorter.Queue.Items New Item: Id: 2 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: WAITING Jan 02, 2014 9:36:13 AM FINE PrioritySorter.Queue.Items Buildable: Id: 2 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 9:36:13 AM FINE PrioritySorter.Queue.Items Starting: Id: 2 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 10:04:05 AM FINE PrioritySorter.Queue.Items New Item: Id: 3 JobName: ing_trunk_sonar, jobGroupId: -1, priority: 3, weight: 3.0, status: WAITING Jan 02, 2014 10:04:14 AM FINE PrioritySorter.Queue.Items Buildable: Id: 3 JobName: ing_trunk_sonar, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 10:04:14 AM FINE PrioritySorter.Queue.Items Starting: Id: 3 JobName: ing_trunk_sonar, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś edited a comment on JENKINS-21103 Priorities are assigned top down by first match does not work correctly I log with "ALL" (logger-configuration.png). New logs: Jan 02, 2014 11:36:06 AM FINE PrioritySorter.Queue.Items New Item: Id: 4 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: WAITING Jan 02, 2014 11:36:15 AM FINE PrioritySorter.Queue.Items Buildable: Id: 4 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 11:36:15 AM FINE PrioritySorter.Queue.Items Starting: Id: 4 JobName: ing_trunk, jobGroupId: -1, priority: 3, weight: 3.0, status: BUILDABLE This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś commented on JENKINS-21103 Priorities are assigned top down by first match does not work correctly From where I can download the new snapshot? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś edited a comment on JENKINS-21103 Priorities are assigned top down by first match does not work correctly -From where I can download the new snapshot? Link to new snapshot: https://www.dropbox.com/sh/h4nelewu37sx7m5/5SsEY0vfWV This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś edited a comment on JENKINS-21103 Priorities are assigned top down by first match does not work correctly From where I can download the new snapshot? edit: Link to new snapshot: https://www.dropbox.com/sh/h4nelewu37sx7m5/5SsEY0vfWV This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś commented on JENKINS-21103 Priorities are assigned top down by first match does not work correctly I installed new snapshot (2.4-SNAPSHOT (private-01/02/2014 11:43-emsa)). Plugin starts assuming correct priorities Jan 02, 2014 12:00:49 PM FINE PrioritySorter.Queue.Items New Item: Id: 1 JobName: ing_trunk, jobGroupId: 1, priority: 3, weight: 3.0, status: WAITING Jan 02, 2014 12:00:57 PM FINE PrioritySorter.Queue.Items Buildable: Id: 1 JobName: ing_trunk, jobGroupId: 1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 12:00:57 PM FINE PrioritySorter.Queue.Items Starting: Id: 1 JobName: ing_trunk, jobGroupId: 1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 12:03:49 PM FINE PrioritySorter.Queue.Items New Item: Id: 2 JobName: ing_trunk_sonar, jobGroupId: 0, priority: 4, weight: 4.0, status: WAITING Jan 02, 2014 12:03:57 PM FINE PrioritySorter.Queue.Items Buildable: Id: 2 JobName: ing_trunk_sonar, jobGroupId: 0, priority: 4, weight: 4.0, status: BUILDABLE Jan 02, 2014 12:03:57 PM FINE PrioritySorter.Queue.Items Starting: Id: 2 JobName: ing_trunk_sonar, jobGroupId: 0, priority: 4, weight: 4.0, status: BUILDABLE I still get only logs with FINE. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś edited a comment on JENKINS-21103 Priorities are assigned top down by first match does not work correctly I installed new snapshot (2.4-SNAPSHOT (private-01/02/2014 11:43-emsa)). Plugin starts assigning correct priorities Jan 02, 2014 12:00:49 PM FINE PrioritySorter.Queue.Items New Item: Id: 1 JobName: ing_trunk, jobGroupId: 1, priority: 3, weight: 3.0, status: WAITING Jan 02, 2014 12:00:57 PM FINE PrioritySorter.Queue.Items Buildable: Id: 1 JobName: ing_trunk, jobGroupId: 1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 12:00:57 PM FINE PrioritySorter.Queue.Items Starting: Id: 1 JobName: ing_trunk, jobGroupId: 1, priority: 3, weight: 3.0, status: BUILDABLE Jan 02, 2014 12:03:49 PM FINE PrioritySorter.Queue.Items New Item: Id: 2 JobName: ing_trunk_sonar, jobGroupId: 0, priority: 4, weight: 4.0, status: WAITING Jan 02, 2014 12:03:57 PM FINE PrioritySorter.Queue.Items Buildable: Id: 2 JobName: ing_trunk_sonar, jobGroupId: 0, priority: 4, weight: 4.0, status: BUILDABLE Jan 02, 2014 12:03:57 PM FINE PrioritySorter.Queue.Items Starting: Id: 2 JobName: ing_trunk_sonar, jobGroupId: 0, priority: 4, weight: 4.0, status: BUILDABLE I still get only logs with FINE. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś updated JENKINS-21103 Priorities are assigned top down by first match does not work correctly Change By: Adam Gabryś (23/Dec/13 9:43 AM) Attachment: jenkins-configure-priority-sorter.png This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś commented on JENKINS-21103 Priorities are assigned top down by first match does not work correctly I use "Absolute" sorting strategy (screen jenkins-configure-priority-sorter). Today: I have six free executors. The job (which is in both groups) has been started by scm change. In column "Job Priority" I see 3. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś updated JENKINS-21103 Priorities are assigned top down by first match does not work correctly Change By: Adam Gabryś (23/Dec/13 11:39 AM) Attachment: jenkins.advancedqueue.PriorityConfiguration.xml Attachment: jenkins.advancedqueue.PrioritySorterConfiguration.xml This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś commented on JENKINS-21103 Priorities are assigned top down by first match does not work correctly "Just to clarify: Job Priority column will show you the priority of the latest start of the job, so if the Jobs gets triggered by two different causes you will only see the value of the last. From what I understand from this should however not be the issue in this case." I know But in my case, it should show 4 (not 3). "Would it be possible for you to try a pre-release of the next version with some extended logging (JENKINS-21119)?" Yes. Today, I upgraded plugin to version 2.3. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś edited a comment on JENKINS-21103 Priorities are assigned top down by first match does not work correctly "Just to clarify: Job Priority column will show you the priority of the latest start of the job, so if the Jobs gets triggered by two different causes you will only see the value of the last. From what I understand from this should however not be the issue in this case." I know But in my case, it should show 4 (run by scm change), not 3 (run by user). "Would it be possible for you to try a pre-release of the next version with some extended logging (JENKINS-21119)?" Yes. Today, I upgraded plugin to version 2.3. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś created JENKINS-21103 Priorities are assigned top down by first match does not work correctly Issue Type: Bug Assignee: bklarson Attachments: configuration.png Components: prioritysorter Created: 20/Dec/13 8:55 AM Description: Probably plugin incorrectly assigns priorities to jobs. I have a job in two views: Sonar and All (plugin configuration is in the screenshot). According to the description "priorities are assigned top down by first match" - the job should receive priority 4 (or 3 if user run build), and unfortunately always receives 3 (or 2 if user run build). Environment: Jenkins Priority Sorter Plugin 2.2 jenkins-1.544-1.1.noarch java-1.7.0-openjdk-1.7.0.45-2.4.3.4.el6_5.x86_64 Linux kera 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Project: Jenkins Priority: Major Reporter: Adam Gabryś This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [prioritysorter] (JENKINS-21103) Priorities are assigned top down by first match does not work correctly
Adam Gabryś updated JENKINS-21103 Priorities are assigned top down by first match does not work correctly Change By: Adam Gabryś (20/Dec/13 9:06 AM) Description: Probablypluginincorrectlyassignsprioritiestojobs.Ihaveajobintwoviews:SonarandAll(pluginconfigurationisinthescreenshot).Accordingtothedescriptionprioritiesareassignedtopdownbyfirstmatch-thejobshouldreceivepriority4(or3ifuserrunbuild) ,and but unfortunatelyalwaysreceives3(or2ifuserrunbuild). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [translation] (JENKINS-18612) Confusing behavior for not logged users (403 Forbidden)
Adam Gabryś created JENKINS-18612 Confusing behavior for not logged users (403 Forbidden) Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: translation Created: 03/Jul/13 7:59 PM Description: I set Discover right for the anonymous users. When a visitor goes to the login page, he will see the link "Help us localize this page" with a broken image (403 Forbidden). When he click ion the link, nothing happens (403 Forbidden for the file ...plugin/translation/dialog.js). It's a little confusing for the guests. Maybe better idea will be hide the link on the login page or move image and _javascript_ to readable location for the anonymous users? Environment: jenkins-1.521-1.1.noarch java-1.7.0-openjdk-1.7.0.25-2.3.10.4.el6_4.x86_64 Linux synthia.gabrys 2.6.32-358.11.1.el6.x86_64 #1 SMP Wed Jun 12 03:34:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Project: Jenkins Priority: Trivial Reporter: Adam Gabryś This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [viewVC] (JENKINS-18283) Wrong URL in diff
Adam Gabryś assigned JENKINS-18283 to Michael Rumpf Wrong URL in diff Can you prepare a new release and close this bug? Change By: Adam Gabryś (01/Jul/13 7:57 AM) Assignee: DucQuoc MichaelRumpf This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [viewVC] (JENKINS-4860) No support for multi-repository viewVC
Adam Gabryś assigned JENKINS-4860 to Michael Rumpf No support for multi-repository viewVC I agree with Duc Quoc - this bug was fixed in previous releases. Can you close this bug? Change By: Adam Gabryś (01/Jul/13 8:01 AM) Assignee: MichaelRumpf This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [deploy] (JENKINS-18243) Cannot Download plugins.
Adam Gabryś commented on JENKINS-18243 Cannot Download plugins. Do you have a properly configured Update Site in Plugin Manager (http://updates.jenkins-ci.org/update-center.json)? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [viewVC] (JENKINS-18283) Wrong URL in diff
Adam Gabryś created JENKINS-18283 Wrong URL in diff Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: viewVC Created: 11/Jun/13 9:25 AM Description: Hello, At Changes tab, for job, ViewVC links are correct, but for specified revision diff URLs lost part of the link. Project configuration (Source Code Management): URL - http://example.org/viewvc/branches/name/ Repository - repo Example URL's: ViewVC URL - http://example.org/viewvc/branches/name/?view=revroot=reporevision=10 Diff URL - http://example.org/branches/name/java/src/main/File.java?root=repor1=9r2=10diff_format=h Diff URL lost /viewvc/ part. Environment: Centos 6.4 x64 (Linux kera 2.6.32-358.6.2.el6.x86_64 #1 SMP Thu May 16 20:59:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux) Jenkins 1.517 (jenkins-1.517-1.1.noarch) ViewVC 1.6 Project: Jenkins Priority: Major Reporter: Adam Gabryś This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
