Re: Benchmarking Jenkins using Java Microbenchmark Harness (JMH)

[Oleg Nenashev]

Hi all,

You can find the video recording of the demo 
here: https://www.youtube.com/watch?v=sr28UADG1AE
There is also an ongoing pull request to make it a part of Jenkins Test 
Harness: https://github.com/jenkinsci/jenkins-test-harness/pull/135

Best regards,
Oleg

On Thursday, May 30, 2019 at 6:44:38 PM UTC+2, Matt Sicker wrote:
>
> I'm +1 in using JMH and exploring benchmarks of various functionality. 
> Seems like a good idea, especially with all the reinvented database 
> functionality implicit in Jenkins and plugins. 
>
> On Thu, May 30, 2019 at 12:57 AM Oleg Nenashev  > wrote: 
> > 
> > Hi all, 
> > 
> > Just to facilitate this thread, I am +1 regarding having 
> micro-benchmarking support in Jenkins Test Harness. There are many stories 
> related to performance degradation in Jenkins, and having a framework could 
> help us to have some checks for the critical functionality like permission 
> checks. The end goal of the project is to improve Role Strategy performance 
> (which is far from perfect now), but it would be great if we could reuse 
> the framework in other components. 
> > 
> > Tomorrow at 7am UTC we will be doing a recorded demo of the current 
> framework state, and everybody is welcome to join. 
> > 
> > Best regards, 
> > Oleg 
> > 
> > On Tuesday, May 28, 2019 at 8:20:14 AM UTC+2, sharmaa...@gmail.com 
> wrote: 
> >> 
> >> Hi everyone, 
> >> 
> >> As a part of this year's Google Summer of Code, I have been working on 
> a 
> >> framework for allowing Java Microbenchmark Harness (JMH) benchmarks to 
> be 
> >> run with Jenkins. The basic framework was implemented in the Role 
> Strategy 
> >> Plugin through this pull request: 
> >> https://github.com/jenkinsci/role-strategy-plugin/pull/63 . For each 
> >> benchmark, a temporary Jenkins instance is created, similar to how 
> >> JenkinsRule from Jenkins Test Harness does it. The benchmarks are run 
> >> through a unit test which allows them to be integrated with the normal 
> pull 
> >> request builds (if required). Apart from configuring the Jenkins 
> instance 
> >> for test using Java code, I've also added support for easily 
> configuring the 
> >> instance by YAML files using Jenkins Configuration as Code. The 
> benchmark 
> >> reports are generated as JSON files which are compatible with the 
> jmh-report 
> >> plugin. I have implemented a couple of benchmarks for the Role Strategy 
> >> Plugin which can be seen in the Role Strategy Plugin GitHub repository. 
> I 
> >> have attached screenshots of these results as visualized by the 
> jmh-report 
> >> plugin. To make the framework easier to use, I'm also working on 
> running the 
> >> benchmarks through a Maven profile. 
> >> 
> >> To make it available to the rest of the community, I would like to 
> propose 
> >> to make it either a part of Jenkins Test Harness or a part of new 
> library so 
> >> it can be used by other plugins and perhaps by Jenkins core itself. I 
> would 
> >> to love to hear your feedback, comments and suggestions. It would be 
> even 
> >> better if you could join the project's weekly meetings (Tuesdays and 
> Fridays 
> >> at 7:00 AM UTC) and help us improve this framework. 
> >> 
> >> Thanks 
> >> Abhyudaya 
> >> GitHub: AbhyudayaSharma 
> >> 
> >> 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Jenkins Developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to jenkin...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/09147b86-6565-4b83-a4f8-3fbf48baa6cf%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Matt Sicker 
> Senior Software Engineer, CloudBees 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/676323d7-7d32-43be-9003-d0d8eab9e02e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2.176.1 LTS RC regression found (Was: Jenkins 2.176.1 LTS RC testing started)

[Oleg Nenashev]

Hi all,

Just heads-up, 2.176.1 release will be delayed due to to some 
infrastructure issues. Kohsuke is traveling now, and the ETA for the 
release is Sunday, Jun 09. This is a temporary release infrastructure until 
the Core release Automation project is completed (see this thread 
,
 
contributions are always welcome!). As an outcome, we have several extra 
days for the release candidate testing and fixes if needed.

We also skip one week in the weekly releases (Jun 02), but the only patch 
there was the Remoting rollback due to 
https://issues.jenkins-ci.org/browse/JENKINS-57713 . We already have a 
mirror patch in 2.176.1-rc

Best regards,
Oleg

On Tuesday, May 28, 2019 at 6:26:35 PM UTC+2, ogondza wrote:
>
> Alright, I have filed https://github.com/jenkinsci/jenkins/pull/4047 to 
> revert remoting on master. Once reviewed, I will backport that revert to 
> LTS as well. Thanks!
>
> On Tuesday, May 28, 2019 at 5:13:02 PM UTC+2, Oleg Nenashev wrote:
>>
>> Remoting version downgrade is reasonable IMO.
>>
>>
>> On Tue, May 28, 2019, 17:07 Antonio Muñiz  wrote:
>>
>>> Reverting the remoting upgrade is ok for me too. 
>>> Then we can work on a fix for JENKINS-57713 
>>>  - IMO the "no 
>>> retry" logic should be enabled by a parameter instead of being the default, 
>>> so cloud implementations not wanting this can disable it.
>>>
>>> On Tue, 28 May 2019 at 16:15, Oliver Gondža  wrote:
>>>
 That is spot-on Antonio. I can imagine it will break any plugin using 
 JNLP launcher where the VM can happen to be ready sooner than the 
 computer is created.

 For me, reverting https://github.com/jenkinsci/jenkins/pull/4005 is 
 preferable over changing the baseline this late in the cycle.

 Do you guys intent to revert it in weekly, provide a fix or do 
 something 
 else? I am asking so we can coordinate actions...

 On 28/05/2019 14.44, Antonio Muñiz wrote:
 > JENKINS-57713  - 
 > This is breaking a proprietary cloud implementation. It's a 
 regression 
 > for us.
 > 
 > On Thu, 23 May 2019 at 16:16, Oliver Gondža >>> > > wrote:
 > 
 > Hello everyone,
 > 
 > Latest LTS RC was made public and it is ready to be tested. Final
 > release is scheduled for 2019-06-05.
 > 
 > 
 > Postponed:
 >  JENKINS-57528   CriticalJenkins 
 2.178
 >  Jenkins in Docker does not install detached 
 plugins
 > when there is no
 > UC data
 > https://issues.jenkins-ci.org/browse/JENKINS-57528
 > 
 >  JENKINS-25369   Minor   Jenkins 
 2.178
 >  DNS multicast error messages
 > https://issues.jenkins-ci.org/browse/JENKINS-25369
 > 
 >  JENKINS-57477   CriticalJenkins 
 2.178
 >  Cancelling a job results in "sendctrlc.x64...exe"
 > stops working
 > https://issues.jenkins-ci.org/browse/JENKINS-57477
 > 
 > Fixed:
 >  JENKINS-57412   Major   Jenkins 
 2.177
 >  Incorrect deletion for setup wizard of Chinese
 > localization files on
 > Jenkins LTS 2.176
 > https://issues.jenkins-ci.org/browse/JENKINS-57412
 > 
 >  JENKINS-57111   Major   Jenkins 
 2.177
 >  Base class setChannel does not handle exceptions
 > from onOnline call
 > https://issues.jenkins-ci.org/browse/JENKINS-57111
 > 
 > 
 > Please, report your findings in this thread.
 > 
 > Download bits from
 > http://mirrors.jenkins-ci.org/war-stable-rc/2.176.1/jenkins.war
 > 
 > Thanks!
 > -- 
 > oliver
 > 
 > -- 
 > You received this message because you are subscribed to the Google
 > Groups "Jenkins Developers" group.
 > To unsubscribe from this group and stop receiving emails from it,
 > send an email to jenkin...@googlegroups.com
 > .
 > To view this discussion on the web visit
 > 
 https://groups.google.com/d/msgid/jenkinsci-dev/02142c5b-b89e-fbed-5243-a16b7b956c8c%40gmail.com
 .
 > For more options, visit https://groups.google.com/d/optout.
 > 
 > 
 > 
 > -- 
 > Antonio Muñiz
 > Human, Engineer
 > CloudBees, Inc.
 > 
 > -- 
 > You received this message because you are subscribed to the Google 
 > Groups "Jenkins Developers" grou

Proposal - Adding JCasC tests into Jenkins core test suite

[Joseph P]

Hi All

In an effort to improve JCasC compatibility we would like to add the 
configuration-as-code-plugin 
 into the Jenkins 
core test suite 

This will help us improve test coverage of JCasC and we would avoid 
regressions that are related to configuration-as-code

We have several issues open that are related to Jenkins core and currently 
a few in progress. See dashboard (sort by component and check core) 


This is based on Oleg's suggestion: 
https://github.com/jenkinsci/jenkins/pull/3994#issuecomment-498730322

Best regards
Joseph Petersen

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/5a8f61c7-88f1-4b9d-b0bc-c1e30f7c0544%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal - Adding JCasC tests into Jenkins core test suite

[Jon Brohauge]

Sounds like a great idea to me.

My 2-cents
Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/063e07a8-f215-4942-a5e9-ab852bc49ac2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal - Adding JCasC tests into Jenkins core test suite

[Jesse Glick]

On Tue, Jun 4, 2019 at 1:23 PM Joseph P  wrote:
> we would avoid regressions that are related to configuration-as-code

I think that should be handled differently, for example by something
like JENKINS-45047, or `plugin-compat-tester`, or
`buildPlugin.recommendedConfigurations()`, or Dependabot. There are
plenty of critical plugins which are prone to breaking due to changes
in core, and we cannot possibly stuff the core test suite full of all
of them. (In fact I would prefer to be _removing_ some plugins from
the `test` POM.) Instead, plugins define tests and a `jenkins.version`
known to pass them, and we use various tooling to ensure that these
tests are also run against newer dependency versions so that
regressions are caught in a timely manner.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ALHHvTcOeRRrmLV10B%3DaeODTGWsOcQ2yCWu4BKoT5dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal - Adding JCasC tests into Jenkins core test suite

[Slide]

I agree with Jesse. The suite as is is so large already. The
plugin-compat-test was made for purposes similar to this I believe, so why
not use the tools that are available?

On Tue, Jun 4, 2019 at 11:29 AM Jesse Glick  wrote:

> On Tue, Jun 4, 2019 at 1:23 PM Joseph P  wrote:
> > we would avoid regressions that are related to configuration-as-code
>
> I think that should be handled differently, for example by something
> like JENKINS-45047, or `plugin-compat-tester`, or
> `buildPlugin.recommendedConfigurations()`, or Dependabot. There are
> plenty of critical plugins which are prone to breaking due to changes
> in core, and we cannot possibly stuff the core test suite full of all
> of them. (In fact I would prefer to be _removing_ some plugins from
> the `test` POM.) Instead, plugins define tests and a `jenkins.version`
> known to pass them, and we use various tooling to ensure that these
> tests are also run against newer dependency versions so that
> regressions are caught in a timely manner.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ALHHvTcOeRRrmLV10B%3DaeODTGWsOcQ2yCWu4BKoT5dw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Website: http://earl-of-code.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVduMQyrmKzkjyktOCHw8EhbzzOhMO6tAotZVSvO5cp8dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Accessing PR head commit sha from a pipeline using branch source plugin

[Julien HENRY]

Hi,

We are trying to simplify integration of SonarQube with most popular pull
request provider, like GitHub or Bitbucket.
Those ALM usually provide some API to report issues on PR (GitHub checks,
Bitbucket Code Insight, ...). The APIs require to pass the PR HEAD commit
sha1.

We are trying to get this commit ref automatically when the SonarQube
scanner is executed in a Jenkins pipeline. The problem I'm facing is that
Jenkins is creating a local merge of the PR head with the PR base branch,
and the value of GIT_COMMIT is the ref of this local transcient commit,
which is pretty useless for reporting back to the ALM.

Example:

For PR with HEAD at ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b:
[image: image.png]

Using this pipeline:

node {
stage 'Checkout'
def scmVars = checkout scm
def commitHash = scmVars.GIT_COMMIT
println commitHash

}

Produces this log:

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url
https://github.com/henryju/test-jenkins.git # timeout=10
Fetching without tags
Fetching upstream changes from https://github.com/henryju/test-jenkins.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials
 > git fetch --no-tags --force --progress
https://github.com/henryju/test-jenkins.git
+refs/pull/1/head:refs/remotes/origin/PR-1
+refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit
57ff7166357a4939da69bc43db84961536557c21 into PR head commit
ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b
 > git merge 57ff7166357a4939da69bc43db84961536557c21 # timeout=10
 > git rev-parse HEAD^{commit} # timeout=10
Merge succeeded, producing 6a95262014cca41cf11e810401bd5c1bc0954515
Checking out Revision 6a95262014cca41cf11e810401bd5c1bc0954515 (PR-1)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 6a95262014cca41cf11e810401bd5c1bc0954515
Commit message: "Merge commit
'57ff7166357a4939da69bc43db84961536557c21' into HEAD"
 > git rev-list --no-walk ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b # timeout=10



GIT_COMMIT will return 6a95262014cca41cf11e810401bd5c1bc0954515 while this
is useless for reporting issues in GitHub. Is there any simple way (except
some fragile local Git operation) to access the original Git sha1 that
triggered the PR build? In my example I need to get
ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b

Note that I have the same need with the Bitbucket Branch Source Plugin.

Thanks,

Julien Henry | SonarSource

Developer
https://sonarsource.com

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAD9wyxE5J9JN5H%2BToScP-vjudgoj3B59sRn07SrQtvr4uOiy3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal - Adding JCasC tests into Jenkins core test suite

[Jon Brohauge]

If it makes sense to use the plugin-compat-test, we should go with this. I
wasn't aware of its existence.

On Tue, 4 Jun 2019, 22.18 Slide,  wrote:

> I agree with Jesse. The suite as is is so large already. The
> plugin-compat-test was made for purposes similar to this I believe, so why
> not use the tools that are available?
>
> On Tue, Jun 4, 2019 at 11:29 AM Jesse Glick  wrote:
>
>> On Tue, Jun 4, 2019 at 1:23 PM Joseph P  wrote:
>> > we would avoid regressions that are related to configuration-as-code
>>
>> I think that should be handled differently, for example by something
>> like JENKINS-45047, or `plugin-compat-tester`, or
>> `buildPlugin.recommendedConfigurations()`, or Dependabot. There are
>> plenty of critical plugins which are prone to breaking due to changes
>> in core, and we cannot possibly stuff the core test suite full of all
>> of them. (In fact I would prefer to be _removing_ some plugins from
>> the `test` POM.) Instead, plugins define tests and a `jenkins.version`
>> known to pass them, and we use various tooling to ensure that these
>> tests are also run against newer dependency versions so that
>> regressions are caught in a timely manner.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ALHHvTcOeRRrmLV10B%3DaeODTGWsOcQ2yCWu4BKoT5dw%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Website: http://earl-of-code.com
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/cgbYEB3c_Vc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVduMQyrmKzkjyktOCHw8EhbzzOhMO6tAotZVSvO5cp8dw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAKob%2BgMc_eRNPqHvnCtL0%3D2fNBV-0ew56afb_fzu%2B5JigVBnZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal - Phasing out Java 7 support in Jenkins Dev tools

[Oleg Nenashev]

taking the consensus here, I will proceed with creating tickets and pull 
requests for the components mentioned in the original proposal (actually, 
just few of them like Plugin POM)

On Monday, June 3, 2019 at 6:23:39 PM UTC+2, Baptiste Mathus wrote:
>
> +1 from me obviously. Anyone actually needed old *dev* tooling can use 
> current tags/releases, though I believe nobody really does need this.
>
> Le lun. 3 juin 2019 à 15:27, Oleg Nenashev  > a écrit :
>
>> Hi all,
>>
>> Java 7 has not been supported in Jenkins LTS since 2.60.1, which was 
>> released almost 2 years ago (June 27, 2017). Over past two years, a 
>> majority of plugins updated their requirements to 2.60.3 and above, and 
>> there are only few exceptions in top-50 plugins (Mailer, Git Client, Git 
>> Server, Pipeline: Stage Step, Pipeline: REST API). First 3 plugins are also 
>> about moving to 2.60.x+ because of the ongoing work on JCasc plugin support 
>> in these plugins. I think it is a time to discuss phasing out Java 7 
>> support in our development tools.
>>
>> *Why?*
>>
>>- Not all upstream libraries still support Java 7 (e.g. Animal 
>>Sniffer 1.18 in this PR 
>>). So we cannot 
>>update newest patches, including ones which might be required for JDK 11 
>>support in our build tools
>>- We have some dependencies and profiles specific to Java 7. It 
>>increases the maintenance cost
>>- While we support Java 7, It is harder to include new dependencies 
>>and improve our test frameworks
>>
>> *What do I propose to change?*
>>
>>- Drop Java 7 and Jenkins 2.59- support in Plugin POM 
>>
>>- Drop Java 7 support from Jenkins parent POM 
>> (one we use for core and its libs)
>>- Drop Java 7 support from Jenkins Test Harness, bump the target core 
>>to 2.60.3. 
>>   - It will allow us to extend the test frameworks, e.g. by 
>>   embedding JCasC support there (e.g. this benchmarking PR 
>>    by 
>>   Abhyudaya)
>>- Drop Java 7 support in Docker Fixtures and other test libraries we 
>>maintain in the Jenkins community
>>- Drop Java 7 support and old Core support from Plugin Compat Teste 
>>r, if feasible
>>- Remove 2.59- test conditions and checks from Jenkins Acceptance 
>>Test Harness 
>>- ... // and so on
>>
>> Such phase out could be done incrementally when maintainers or 
>> contributors are interested to do so. I would consider this thread as 
>> giving a green light to whomever wants to drop old Java version support 
>> from Dev tools.
>>
>> Would appreciate feedback.
>>
>> Best regards,
>> Oleg
>>
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDExo3iEqugyCABm9cT3zsaXwF4qhmr63%3Deej3Yt1%2BdKA%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/09118298-8595-4bb4-8871-276c1bb42ed0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Common Coding Questions in GSoC 2019

[martinda]

Hi Yufei,

I am running on commit 19164b7 with these versions:
~/Downloads/apache-maven-3.6.0/bin/mvn compile
[INFO] Scanning for projects...
[INFO] 
[INFO] -< org.jenkins-ci.plugins:external-workspace-manager 
>--
[INFO] Building External Workspace Manager Plugin 1.1.3-SNAPSHOT
[INFO] [ hpi 
]-
[INFO] 
[INFO] --- maven-hpi-plugin:3.5:validate (default-validate) @ 
external-workspace-manager ---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.0.0-M2:display-info (display-info) @ 
external-workspace-manager ---
[INFO] Maven Version: 3.6.0
[INFO] JDK Version: 1.8.0_212 normalized as: 1.8.0-212
[INFO] OS Info: Arch: amd64 Family: unix Name: linux Version: 
4.15.0-47-generic


And I run in the same error as the Jenkins build in the pull-request 62 
build #5 

:
[ERROR] 
/home/martin/git/jenkinsci/external-workspace-manager-plugin/src/main/java/org/jenkinsci/plugins/ewm/clouds/Aws/AwsEfsMounter.java:[13,15]
 
modifier static not allowed here
[ERROR] 
/home/martin/git/jenkinsci/external-workspace-manager-plugin/src/main/java/org/jenkinsci/plugins/ewm/clouds/Aws/AwsEfsMounter.java:[29,38]
 
cannot find symbol
  symbol:   class ProfileCredentialsProvider
  location: class org.jenkinsci.plugins.ewm.clouds.Aws.AwsEfsMounter
[ERROR] 
/home/martin/git/jenkinsci/external-workspace-manager-plugin/src/main/java/org/jenkinsci/plugins/ewm/steps/ExwsAllocateExecution.java:[97,50]
 
incompatible types: org.jenkinsci.plugins.ewm.definitions.Disk cannot be 
converted to org.jenkinsci.plugins.ewm.definitions.AwsEfsDisk


It's probably something in your local environment.

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/20ac897e-0d01-4839-b534-b812576daa99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing PR head commit sha from a pipeline using branch source plugin

[Jesse Glick]

On Tue, Jun 4, 2019 at 5:16 PM Julien HENRY
 wrote:
> Is there any simple way (except some fragile local Git operation) to access 
> the original Git sha1 that triggered the PR build? In my example I need to 
> get ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b

There is not currently any environmental variable for that purpose
that I know of. You can simply try publishing a commit status for the
hash you are given, and if that gives a 422 response, try its first
parent instead, as I suggested in the thread leading to

https://jira.sonarsource.com/browse/SONAR-10794

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1Dt3Bn3MWKM9uBaeDYnXxjwEUVuZC5Wai2Fh5i3xHv%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.