Re: "checkout scm" in multibranch/pipeline

['Björn Pedersen' via Jenkins Developers]

Hi,
Would a local (e.g on your jenkins master) reference repository help? Then 
most objects are resolved from that, and only very fresh changes need to be 
fetched from master. See the advanced git clone option.

See e.g. 
http://randyfay.com/content/reference-cache-repositories-speed-clones-git-clone-reference
 
for a basic overview with plain git.

Björn

Am Donnerstag, 7. April 2016 18:46:30 UTC+2 schrieb nigelm:
>
>
>
> On Thu, Apr 7, 2016 at 5:22 PM, Jesse Glick  > wrote:
>
>> On Wed, Apr 6, 2016 at 10:39 AM, Nigel Magnay > > wrote:
>> > I could probably build a container image with an baseline git
>> > repo in it
>>
>> Or keep a persistent workspace that the container mounts, so you can
>> `git clean -fdx` (or the equivalent `GitSCM` extension) and just do a
>> small update.
>>
>>
> ​Hmm - sounds tricky. I'm running a docker cloud (on Triton), so I never 
> know which physical
> machine it's going to be on, and multiple builds are often running 
> concurrently. I could 'mount' in the sense of a file share I guess.
>
>  
>
>> > It occurred to me that the change detection logic is already storing a 
>> clone
>> > of the repo, (in 
>> JENKINS_HOME/jobs/.../branches/master/workspace@script).
>>
>> Not once I fix JENKINS-33273.
>>
>> Note that the Git plugin *does* have a caching facility, but currently
>> it is internal to `GitSCMSource` and used only for branch scanning
>> (for the plain Git SCM source—not used for GitHub). This could perhaps
>> be extended to support caching as a user-level feature, as in the
>> Mercurial plugin. In principle `git-bundle` could be used to transfer
>> incremental updates to the agent. (The other use case supported by
>> such a feature is agents with no network connection other than to the
>> master, though this is probably unusual.)
>>
>>
> ​I was thinking of something relatively simple (rather than playing with 
> bundles), as the semantics of "checkout scm" are quite nice (check me out 
> the version of the source I'm meant to be building​). If I can translate 
> that from a "git checkout https://github/blah @ revision" to "git fetch 
>  into (per-job) cache, rewrite checkout to call cache rather than github". 
> I like the transparency too of not having to change Jenkinsfiles to make it 
> work. Exposing the (cached) git repository is probably little more than 
> exposing the directory for HTTP at a push.
>
> I might take a look at the Git SCM source and see if I can hack something 
> up.
>
>
>
>
>

-- 
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/40657737-8425-4664-80a0-ca2ccac4c8f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin to use git commands on script pre-build step

['Björn Pedersen' via Jenkins Developers]

Hi,
So you actually need a step that runs after check-out, but before the 
normal job script?

Depending on the result your build should have, you have some options:
 
 * use a simple shell step and return with exit 1 if your preconditions are 
not met -> status: ->failed
 * use the release-build-plugin and configure a pre-release step
 * use the conditional-build plugin and use the provided conditional-build 
steps

Björn

Am Mittwoch, 20. April 2016 16:05:17 UTC+2 schrieb Vincent Domingues:
>
> Hello,
>
> I'm looking for a plugin that's allow me to use *git commands* on a 
> *pre-build 
> script step* to perfom some controls.
>
> Actually before launching a build, i want to check if all the reports have 
> been made for this i need this command :
>
> git merge-base --is-ancestor  
>
> I have mad some search and i may be i don't need a plugin but i hope you 
> can tell me.
>
> I have been thinking about installing git on my jenkins server and slaves 
> and i'll be able to perfome my git commands on the workspace ?
>
> Thank you in advance.
>
> Regards,
> Vincent
>

-- 
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/2746b34d-b493-458f-8a3a-66078083e6a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

sec-170: What need plugins to do to declare vars they provide?

['Björn Pedersen' via Jenkins Developers]

Hi,

Since sec-170 all unknown variables  will get dropped. What needs to be 
done in a plugin to correctly declare the vars they provide?

Björn

-- 
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/6ef47e98-d70c-4a9d-be82-2b91ad0ce009%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins-infra] Scheduled infrastructure maintenance window June 14 00:00 UTC

['Björn Pedersen' via Jenkins Developers]

Hi,

seems like the links from changelog pages are broken now ( 
https://issues.jenkins-ci.org/browse/WEBSITE-187)

Björn

Am Dienstag, 14. Juni 2016 02:12:54 UTC+2 schrieb R Tyler Croy:
>
> (replies inline) 
>
> On Mon, 13 Jun 2016, R. Tyler Croy wrote: 
>
> > Reminder, this will be happening in about 45 minutes 
>
>
> issues.jenkins-ci.org is back online with JIRA 7.1.7, wheee! 
>
>
> The majority of the maintenance window was actually taking a full backup, 
> once 
> that was completed the upgrade process only took about 10 minutes! 
>
>
> I'll be lingering on #jenkins-infra for another hour or two to make sure 
> things 
> are performing as they should. 
>
>
> - R. Tyler Croy 
>
> -- 
>  Code:  
>   Chatter:  
>
>   % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F 
> -- 
>

-- 
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/2daf3a3a-8ee0-43d0-b5ac-75f7ecfe07a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JGit api changed - Handling removal of methods from an underlying API

['Björn Pedersen' via Jenkins Developers]

At least gerrit-trigger-plugin up to 2.21.1 uses TreeWalk.release.

Am Dienstag, 21. Juni 2016 23:56:08 UTC+2 schrieb Mark Waite:
>
> The git client plugin 2.0.0 and git plugin 3.0.0 releases will only 
> support JDK 7 and later.  The change to JDK 7 allows code simplifications 
> (try with resources, etc.) and are a good opportunity to upgrade from 
> embedding JGit 3 to embedding JGit 4.
>
> JGit 4 only supports JDK 7 and later.  The API's in JGit 4 have been 
> reworked to support JDK 7 try with resources.  That API rework is what 
> allows the most significant code simplifications.  However, that means 
> there are some JGit 3 API calls which no longer exist in JGit 4 (JGit 3 has 
> TreeWalk.release() 
> ,
>  
> while JGit 4 TreeWalk does not have release() 
> 
> ).
>
> Now the challenge.  The git client plugin intentionally bundles JGit so 
> that other plugins can use JGit without bundling it themselves.  However, a 
> switch of the JGit version from JGit 3 to JGit 4 means that the JGit usage 
> in plugins which depend on JGit as delivered by the git-client plugin may 
> be broken by the upgrade from git client plugin 1 to git client plugin 2.
>
> The scenarios I see can be illustrated with git client and git plugin 
> (since the git plugin has the same problem as other JGit consumers may):
>
> Git client plugin 1.19.6 with git plugin 2.4.4 -> allowed and works as 
> expected (current configuration) (available to Jenkins versions 1.609 and 
> later)
> Git client plugin 1.19.6 with git plugin 3.0.0 -> not allowed because git 
> plugin 3 explicitly depends on git client plugin 2
> Git client plugin 2.0.0 with git plugin 2.4.4 -> allowed but will fail 
> because git plugin 2 depends on at least one JGit 3 API call (available to 
> Jenkins 1.625 and later)
> Git client plugin 2.0.0 with git plugin 3.0.0 -> allowed and works as 
> expected (available to Jenkins 1.625 and later)
>
> I think I could remove the JGit TreeWalk dependency from the git plugin 
> pretty easily, but I suspect there are other plugins which also depend on 
> JGit and which may be harmed by the change from JGit 3 to JGit 4.
>
> Are there other, more effective techniques for managing this type of 
> dependency problem?  I like very much the benefits of Java 7 and of JGit 4, 
> but would like to not break compatibility for other plugins.
>
> Alternately, I could search the plugin tree for JGit references to see the 
> actual scope of the problem.  I haven't detected any other JGit 3 specific 
> dependencies in my integration testing (git plugin, github plugin, GitHub 
> Organization Folders, various workflow uses, etc.), but my failure to 
> detect those dependencies doesn't mean they don't exist...  In my first 
> attempt  
> (searching just for TreeWalk), I found that git plugin and 
> openshift-deployer-plugin both depend on JGit TreeWalk().  Two consumers 
> (one of which I maintain, the other which seems to include its own specific 
> JGit version) is not enough to spend much effort trying to retain 
> compatibility.
>
> Thanks,
> Mark Waite
>

-- 
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/ac10b570-bb2c-47d0-97b6-390602e464e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JGit api changed - Handling removal of methods from an underlying API

['Björn Pedersen' via Jenkins Developers]

Am Mittwoch, 22. Juni 2016 11:21:17 UTC+2 schrieb Robert Sandell:
>
>
>
> On Wed, Jun 22, 2016 at 11:01 AM, 'Björn Pedersen' via Jenkins Developers 
> > wrote:
>
>> At least gerrit-trigger-plugin up to 2.21.1 uses TreeWalk.release.
>>
>
> Really? Where? I found usage of RevWalk but not TreeWalk.
>
You are right, it was RevWalk:

FATAL: org.eclipse.jgit.revwalk.RevWalk.release()Vjava.lang.NoSuchMethodError 
<http://stacktrace.jenkins-ci.org/search?query=java.lang.NoSuchMethodError>: 
org.eclipse.jgit.revwalk.RevWalk.release()V
at 
com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser$1.invoke(GerritTriggerBuildChooser.java:185)
 
<http://stacktrace.jenkins-ci.org/search/?query=com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser$1.invoke&entity=method>
at 
com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser$1.invoke(GerritTriggerBuildChooser.java:166)
 
<http://stacktrace.jenkins-ci.org/search/?query=com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTriggerBuildChooser$1.invoke&entity=method>
at 
org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:27)
 
<http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository&entity=method>


 

> /B 
>
>>
>> Am Dienstag, 21. Juni 2016 23:56:08 UTC+2 schrieb Mark Waite:
>>>
>>> The git client plugin 2.0.0 and git plugin 3.0.0 releases will only 
>>> support JDK 7 and later.  The change to JDK 7 allows code simplifications 
>>> (try with resources, etc.) and are a good opportunity to upgrade from 
>>> embedding JGit 3 to embedding JGit 4.
>>>
>>> JGit 4 only supports JDK 7 and later.  The API's in JGit 4 have been 
>>> reworked to support JDK 7 try with resources.  That API rework is what 
>>> allows the most significant code simplifications.  However, that means 
>>> there are some JGit 3 API calls which no longer exist in JGit 4 (JGit 3 has 
>>> TreeWalk.release() 
>>> <http://download.eclipse.org/jgit/site/3.7.1.201504261725-r/apidocs/org/eclipse/jgit/treewalk/TreeWalk.html>,
>>>  
>>> while JGit 4 TreeWalk does not have release() 
>>> <http://download.eclipse.org/jgit/site/4.3.1.201605051710-r/apidocs/org/eclipse/jgit/treewalk/TreeWalk.html>
>>> ).
>>>
>>> Now the challenge.  The git client plugin intentionally bundles JGit so 
>>> that other plugins can use JGit without bundling it themselves.  However, a 
>>> switch of the JGit version from JGit 3 to JGit 4 means that the JGit usage 
>>> in plugins which depend on JGit as delivered by the git-client plugin may 
>>> be broken by the upgrade from git client plugin 1 to git client plugin 2.
>>>
>>> The scenarios I see can be illustrated with git client and git plugin 
>>> (since the git plugin has the same problem as other JGit consumers may):
>>>
>>> Git client plugin 1.19.6 with git plugin 2.4.4 -> allowed and works as 
>>> expected (current configuration) (available to Jenkins versions 1.609 and 
>>> later)
>>> Git client plugin 1.19.6 with git plugin 3.0.0 -> not allowed because 
>>> git plugin 3 explicitly depends on git client plugin 2
>>> Git client plugin 2.0.0 with git plugin 2.4.4 -> allowed but will fail 
>>> because git plugin 2 depends on at least one JGit 3 API call (available to 
>>> Jenkins 1.625 and later)
>>> Git client plugin 2.0.0 with git plugin 3.0.0 -> allowed and works as 
>>> expected (available to Jenkins 1.625 and later)
>>>
>>> I think I could remove the JGit TreeWalk dependency from the git plugin 
>>> pretty easily, but I suspect there are other plugins which also depend on 
>>> JGit and which may be harmed by the change from JGit 3 to JGit 4.
>>>
>>> Are there other, more effective techniques for managing this type of 
>>> dependency problem?  I like very much the benefits of Java 7 and of JGit 4, 
>>> but would like to not break compatibility for other plugins.
>>>
>>> Alternately, I could search the plugin tree for JGit references to see 
>>> the actual scope of the problem.  I haven't detected any other JGit 3 
>>> specific dependencies in my integration testing (git plugin, github plugin, 
>>> GitHub Organization Folders, various workflow uses, etc.), but my failure 
>>> to detect those dependencies doesn't mean they don't exist...  In my first 
>>> at

Re: Plugin mvn release:perform

['Björn Pedersen' via Jenkins Developers]

Hi, 

see https://groups.google.com/d/msg/jenkinsci-dev/PFD_b370H20/0B0bQ4hSCAAJ

Björn

Am Dienstag, 30. August 2016 14:08:32 UTC+2 schrieb pallen:
>
> Hi Guys,
>
> Has the server moved? or login requirements changed?
>
> Running the final step `mvn release:perform` I get a broken pipe error:
>
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ p4 
> ---
>
> [INFO] Installing 
> /Users/pallen/Workspaces/main.p4-jenkins/public/target/checkout/target/p4.hpi 
> to /Users/pallen/.m2/repository/org/jenkins-ci/plugins/p4/1.4.5/p4-1.4.5.hpi
>
> [INFO] Installing 
> /Users/pallen/Workspaces/main.p4-jenkins/public/target/checkout/pom.xml to 
> /Users/pallen/.m2/repository/org/jenkins-ci/plugins/p4/1.4.5/p4-1.4.5.pom
>
> [INFO] Installing 
> /Users/pallen/Workspaces/main.p4-jenkins/public/target/checkout/target/p4.jar 
> to /Users/pallen/.m2/repository/org/jenkins-ci/plugins/p4/1.4.5/p4-1.4.5.jar
>
> [INFO] Installing 
> /Users/pallen/Workspaces/main.p4-jenkins/public/target/checkout/target/p4-sources.jar
>  
> to 
> /Users/pallen/.m2/repository/org/jenkins-ci/plugins/p4/1.4.5/p4-1.4.5-sources.jar
>
> [INFO] Installing 
> /Users/pallen/Workspaces/main.p4-jenkins/public/target/checkout/target/p4-javadoc.jar
>  
> to 
> /Users/pallen/.m2/repository/org/jenkins-ci/plugins/p4/1.4.5/p4-1.4.5-javadoc.jar
>
> [INFO] 
>
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ p4 ---
>
> Uploading: 
> http://maven.jenkins-ci.org/content/repositories/releases/org/jenkins-ci/plugins/p4/1.4.5/p4-1.4.5.hpi
>
> Aug 30, 2016 12:47:27 PM 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec 
> execute
>
> INFO: I/O exception (java.net.SocketException) caught when processing 
> request to {}->http://maven.jenkins-ci.org:80: Broken pipe
>
> Aug 30, 2016 12:47:27 PM 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec 
> execute
>
> INFO: Retrying request to {}->http://maven.jenkins-ci.org:80
>
> Aug 30, 2016 12:47:31 PM 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec 
> execute
>
> INFO: I/O exception (java.net.SocketException) caught when processing 
> request to {}->http://maven.jenkins-ci.org:80: Broken pipe
>
> Aug 30, 2016 12:47:31 PM 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec 
> execute
>
> INFO: Retrying request to {}->http://maven.jenkins-ci.org:80
>
> Aug 30, 2016 12:47:34 PM 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec 
> execute
>
> INFO: I/O exception (java.net.SocketException) caught when processing 
> request to {}->http://maven.jenkins-ci.org:80: Broken pipe
>
> Aug 30, 2016 12:47:34 PM 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec 
> execute
>
> INFO: Retrying request to {}->http://maven.jenkins-ci.org:80
>
> Uploading: 
> http://maven.jenkins-ci.org/content/repositories/releases/org/jenkins-ci/plugins/p4/1.4.5/p4-1.4.5.pom
>
> [INFO] 
> 
>
> [INFO] BUILD FAILURE
>
> [INFO] 
> 
>
> [INFO] Total time: 44.534 s
>
> [INFO] Finished at: 2016-08-30T12:47:41+01:00
>
> [INFO] Final Memory: 94M/2131M
>
> [INFO] 
> 
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) 
> on project p4: Failed to deploy artifacts: Could not transfer artifact 
> org.jenkins-ci.plugins:p4:hpi:1.4.5 from/to maven.jenkins-ci.org (
> http://maven.jenkins-ci.org/content/repositories/releases/): Protocol 
> wrong type for socket -> [Help 1]
>
>
>
> My .m2 settings:
>
>
> 
>
>   
>
> org.jenkins-ci.tools
>
>   
>
>
>   
>
> 
>
> 
>
>   jenkins
>
>   
>
> true 
>
>   
>
>   
>
> 
>
>   repo.jenkins-ci.org
>
>   http://repo.jenkins-ci.org/public/
>
> 
>
>   
>
>   
>
> 
>
>   repo.jenkins-ci.org
>
>   http://repo.jenkins-ci.org/public/
>
> 
>
>   
>
> 
>
>   
>
>
>   
>
> 
>
>   repo.jenkins-ci.org
>
>   http://repo.jenkins-ci.org/public/
>
>   m.g.o-public
>
> 
>
>   
>
>
>   
>
> 
>
>   maven.jenkins-ci.org 
>
>   p4paul
>
>   
>
> 
>
>   
>
> 
>
>
>
>

-- 
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/ec767085-07b5-498e-86db-44a36481d973%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git Mutlibranch Merge (>2 branches)

['Björn Pedersen' via Jenkins Developers]

Am Samstag, 8. Oktober 2016 06:31:02 UTC+2 schrieb Jeremy C:
>
> Yes, I already have a working implentation written in Python for our 
> current CI tool, BuildBot. I use an octopus merge to get the job done. I'll 
> definitely look at your code, thank you!
>
> Anyone else have ideas on how to accomplish what I've detailed out above? 
> Thank you in advance. 
>

I have a a few remarks/hints/questions:

1) jenkins does not force you to use the ui to do the merge. I would  
probably first try to do it in a shell/python/whatever script:
  * Jenkins is configured to clone and fetch  the branch under 
consideration 
  * The script does the necessary merging
  * the test run

2) Do you need to check if a change happens on a feature, or do you also 
want to check the reverse case (master/etc.. advance) and the features need 
a re-test?

Björn 

-- 
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/f61fccef-24d9-4506-a44b-2637d413283a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Update center offers wrong version to upgrade to

['Björn Pedersen' via Jenkins Developers]

Hi,

On a 2.17 install the update center always offers an upgrade to the 2.19.1 
LTS version instead of  the correct 2.25. (I manually ran refresh in the 
plugin manager already.)

Is this an update center problem or is it something client side (In that 
case I will just download the correct version manually)? 

Björn

-- 
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/d9fa6bfb-f72b-474c-bf9d-4c38933bf737%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center offers wrong version to upgrade to

['Björn Pedersen' via Jenkins Developers]

Looks good, thanks. 

Björn


-- 
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/7d0c37f9-a8a3-4ca3-a64f-e532fd30fcde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

['Björn Pedersen' via Jenkins Developers]

FreeBSD : not sure how those handle packages vs system releases. 
http://www.freshports.org/java/openjdk8 doesn't give info on system version 
it applies to
It's available at least in FreeBSD9.1  (which is already quite old)
 

-- 
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/28d1fe05-2ca4-4ad1-a411-a35330d67c2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center offers wrong version to upgrade to

['Björn Pedersen' via Jenkins Developers]

Hi,

is there any update on this? I still get 2.19.1 offered instead of 2.25.

Björn

Am Mittwoch, 12. Oktober 2016 09:33:00 UTC+2 schrieb Björn Pedersen:
>
> Looks good, thanks. 
>
> Björn
>
>
>

-- 
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/c75aa083-1a18-42f6-bae8-c88e1f01281d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Current Stage name inside the SimpleBuildStep.perform(...) method?

['Björn Pedersen' via Jenkins Developers]

(comments inline)

Am Sonntag, 22. Januar 2017 03:05:45 UTC+1 schrieb Jesse Glick:
>
> On Fri, Jan 20, 2017 at 11:48 AM, Adakar > 
> wrote: 
> > how to get current Stage name inside the 
> > SimpleBuildStep.perform(Run run, FilePath workspace, Launcher 
> launcher, 
> > TaskListener listener)method? 
>
> You cannot. 
>
> If you switched from `SimpleBuildStep` to a full-fledged `Step`, you 
> could get your `FlowNode` from the `StepContext` and use 
> `FlowScanningUtils.fetchEnclosingBlocks` to look for `LabelAction`, 
> which will match `stage(…) {…}` as well as some other steps that 
> define labels in block scope. 
>
> (But do you *really* need this information?) 
>


This sounds interessing. I also have a use case for that (the  
gerrit-verify-status-reporter-plugin) 

It should report back the status and timing of parts of a job in a pipeline 
run, possibly setting a link 
to the relevant part of the log as well. There I would either need  the 
predecessor node or an enclosing
block, if I am not mistaken. So this then needs to be a full step. How to 
handle non-pipeline jobs then?
Do  I need a separate  implementation then?

Björn

-- 
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/f80d535a-11a6-49cc-8601-13f4f43b5c3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Encountering issues while using float types in a pipeline plugin

['Björn Pedersen' via Jenkins Developers]

Looking at the pipeline devguide 
(https://github.com/jenkinsci/pipeline-plugin/blob/master/DEVGUIDE.md#variable-substitutions),
it seems like there should be setters/getters that transform from strings 
to the desired internal representation, instead of using 
these types directly.

Björn

Am Dienstag, 24. Januar 2017 16:37:17 UTC+1 schrieb Robert Sandell:
>
> Looks similar to https://issues.jenkins-ci.org/browse/JENKINS-38004
>
> /B
>
> On Tue, Jan 24, 2017 at 3:06 PM, Andrius Ordojan  > wrote:
>
>> I'm trying to add pipeline support to an existing plugin. I'm finding 
>> some strange behaviours when dealing with floats.
>>
>> I implemented SimpleBuildStep in my publisher and that seems to be 
>> working as expected. For now I just tried using the snippet generator to 
>> see if everything evaluates correctly.
>>
>> it generates codesonar conditions: [], credentialId: '', hubAddress: 
>> '10.10.10.10', projectName: '${JOB_NAME}', protocol: 'http'
>>
>>
>> 
>>
>>
>> When I added a condition I get this
>>
>>
>> 
>>
>>
>> codesonar conditions: [warningCountIncreaseNewOnly(percentage: > type java.lang.Float>)], credentialId: '', hubAddress: '10.10.10.10', 
>> projectName: '${JOB_NAME}', protocol: 'http'
>>
>> Instead of a number, I get . This 
>> doesn't happen with integers.
>>
>> I noticed an exception in the terminal as well
>>
>> Jan 23, 2017 3:39:40 PM 
>> org.jenkinsci.plugins.structs.describable.DescribableModel uninstantiate2
>> WARNING: Cannot create control version of class 
>> org.jenkinsci.plugins.codesonar.conditions.NewWarningsIncreasedByPercentageCondition
>>  
>> using {}
>> java.lang.UnsupportedOperationException: not yet handling 
>> @DataBoundConstructor default value of float; pass an explicit value for 
>> percentage
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.buildArguments(DescribableModel.java:317)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.instantiate(DescribableModel.java:257)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.uninstantiate2(DescribableModel.java:536)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.uninstantiate2_(DescribableModel.java:612)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableParameter.uncoerce(DescribableParameter.java:193)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableParameter.uncoerce(DescribableParameter.java:187)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableParameter.inspect(DescribableParameter.java:141)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.uninstantiate2(DescribableModel.java:522)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.uninstantiate2_(DescribableModel.java:612)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableParameter.uncoerce(DescribableParameter.java:193)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableParameter.inspect(DescribableParameter.java:141)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.uninstantiate2(DescribableModel.java:522)
>> at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.uninstantiate2_(DescribableModel.java:612)
>> at 
>> org.jenkinsci.plugins.workflow.steps.StepDescriptor.uninstantiate(StepDescriptor.java:239)
>> at 
>> org.jenkinsci.plugins.workflow.cps.Snippetizer.object2Groovy(Snippetizer.java:124)
>> at 
>> org.jenkinsci.plugins.workflow.cps.Snippetizer.step2Groovy(Snippetizer.java:79)
>> at 
>> org.jenkinsci.plugins.workflow.cps.Snippetizer.doGenerateSnippet(Snippetizer.java:495)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at 
>> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
>> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
>> at 
>> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
>> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121)
>> at 
>> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
>> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
>> at org.kohsuke.stapler.MetaClass$13.dispatch(MetaClass.java:411)
>> at org.koh

Re: update center certificate expired?

['Björn Pedersen' via Jenkins Developers]

See https://issues.jenkins-ci.org/browse/INFRA-1060

Am Freitag, 10. Februar 2017 02:27:05 UTC+1 schrieb Richard Bywater:
>
> Working fine "here". Its valid from 11 November 2016 to 9 February 2018 at 
> 03:41:22 UTC. 
>
> Although is that a mirrored site? Is one of the mirrors got a certificate 
> shorter than the rest?
>
> Richard.
>
> On Fri, 10 Feb 2017 at 14:18 Scott Hebert > 
> wrote:
>
>> Hi,
>>
>> One of my PRs is failing to build with an error of:
>>
>> java.lang.AssertionError: Failed to parse update center data of 
>> https://updates.jenkins-ci.org/update-center.json at 
>> /tmp/update-center.json Caused by: javax.net.ssl.SSLHandshakeException: 
>> sun.security.validator.ValidatorException: PKIX path validation failed: 
>> java.security.cert.CertPathValidatorException: timestamp check failed 
>> Caused by: sun.security.validator.ValidatorException: PKIX path validation 
>> failed: java.security.cert.CertPathValidatorException: timestamp check 
>> failed Caused by: java.security.cert.CertPathValidatorException: timestamp 
>> check failed Caused by: java.security.cert.CertificateExpiredException: 
>> NotAfter: Thu Feb 09 03:41:22 UTC 2017
>>
>> Complete log at [1].
>>
>> Has the update center certificate expired?
>>
>> Thanks
>>
>> Scott
>>
>> [1] 
>> https://ci.jenkins.io/job/Plugins/job/jms-messaging-plugin/view/Pull%20Requests/job/PR-16/3/console
>>
>> -- 
>> 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-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CALtL2uG5cSOGwrvy4AcXVwvT%2Bwrg%2BN2UWGtkd8XKn%3DHUd4eBUw%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/406245be-9b7c-49b0-9e18-ec2ec9846226%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.