Hello,
I'm trying to change the names of projects which will be triggered by a
build via the Groovy console.
I got as far as being able to extract the field from the data structures
but didn't find a way to set it with a new value.
Here is the code I got so far:
import hudson.model.*
import
Hi Stuart,
some pinged me today about your plugin, it appears very useful. Maybe it
could be worth to release it properly to have more people know about it and
let them install it directly from the plugin manager?
If you need some help with that I can give a hand.
Cheers,
Vincent
2013-11-21
Hi Kohsuke et al.
I'm defiantly interested in the workflow brainstorming/hacking/discussing etc.
assuming I get travel approval.
Having something focused is easier to get approved rather than a generic
unconference.
/James
-Original Message-
From: jenkinsci-dev@googlegroups.com
Sounds like a great idea Kohsuke!
Emanuele Zattin
---
-I don't have to know an answer. I don't feel frightened by not knowing
things; by being lost in a mysterious universe without any purpose — which
is the way it really is, as far as I can tell,
Hi Vincent!
Thanks for getting in touch. Yeah, I always meant to get round to
officially releasing it - the code was here, I was just tidying it up.
If you want to pass my e-mail along, I can talk to them directly and make
sure it does what they are looking for.
Stu
On 31 July 2014 10:23,
I've not touched this in a while Daniel, but I found that if I was queuing
multiple copies of the same job, I could give it a unique ID - whereas
/build simply gives you the information it's queuing.
That's not to say that the queue API has improved to include information
like this - like I say,
Thanks, Stephen. nice approach. but what to do if I just moved some fields
from one job property to another new one (not swapping them entirely)
On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:
Note that you need to be swapping like for like... you can swap one
Publisher
On 31.07.2014, at 12:19, Stuart Davidson stuart.david...@spedge.com wrote:
I've not touched this in a while Daniel, but I found that if I was queuing
multiple copies of the same job, I could give it a unique ID - whereas /build
simply gives you the information it's queuing.
That's not
I think the question you really need to ask yourself is what is driving the
update.
So for example there are some changes to the SCM api in 1.568... if you
want to pick up support for them then there is really only one way to do
that... now I would advocate waiting for those changes to hit an
As I understand it, a build could be queued, cancelled, queued again and
thus end up with the same build id. With this plugin, I'm appending a UUID
to the build in order to identify a unique run no matter what happened in
the queue.
However, you've shown a way of uniquely identifying a build by
I like the idea of selecting a threshold and not moving to a newer version
until the installed base has adopted at least that release.
How can I find the installed base numbers by version so that I can
calculate the threshold by version?
Thanks
Mark Waite
On Thu, Jul 31, 2014 at 4:24 AM,
Thanks for your answer.
The problem was that I had specified the old groupId 'org.hudsonci.plugins'
where it was called windows-slaves-plugin and not 'windows-slaves' as in
the new groupId 'org.jenkins-ci.plugins'.
2014-07-31 2:13 GMT+02:00 Jesse Glick jgl...@cloudbees.com:
On Mon, Jul 14,
Construct a new builder object and replace the old one, that is basically
what the save button does.
/B
2014-07-31 9:05 GMT+02:00 Amos S amos.shap...@gmail.com:
Hello,
I'm trying to change the names of projects which will be triggered by a
build via the Groovy console.
I got as far as
On 31.07.2014, at 12:36, Stuart Davidson stuart.david...@spedge.com wrote:
As I understand it, a build could be queued, cancelled, queued again and thus
end up with the same build id. With this plugin, I'm appending a UUID to the
build in order to identify a unique run no matter what
Finally I have ended with following solution.
1. add removed fields and mark them as transient
2. register static method with @Initializer(after =
InitMilestone.JOB_LOADED)
3. for each job do check whether new job property exists if not create new
one and move transient fields to it and then
I worry about the startup time scanning all jobs... there can be 1000's of
them... better if you can have something that kicks in when the job is
being saved... as that way people can revert your upgrade if there is
something wrong without loosing data.
Oh and whatever approach you take, remember
On 31.07.2014, at 12:51, Mark Waite mark.earl.wa...@gmail.com wrote:
How can I find the installed base numbers by version so that I can calculate
the threshold by version?
The newest numbers I have are from when 1.570 was brand new (end of June).
86144 total installs
74978 on 1.509 or newer
Hi,
I don't know if it is due to the upgrade to Jenkins ver. 1.565.1
http://jenkins-ci.org/ but I'm noticing in my logs a lot of SEVERE errors
I didn't see before :
Jul 31, 2014 3:14:32 PM
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager
freeConnection
SEVERE: Host connection
Thanks. I think that data from June is already enough to justify moving
the git plugin and the git client plugin from 1.509 to 1.532.
On Thu, Jul 31, 2014 at 6:55 AM, Daniel Beck m...@beckweb.net wrote:
On 31.07.2014, at 12:51, Mark Waite mark.earl.wa...@gmail.com wrote:
How can I find
Hi All,
I have two proposals:
1. Include the LineNumbers plugin in the Jenkins core and make that the
default behaviour for the console log screen?
2. Make the Console link in the sidebar menu and the progress bar under a
running build navigate to:
Are people still building Jenkins core using JDK 6? I ask because it
would be helpful to be able to assume 7+:
· We could make use of 7+ APIs, especially java.nio.file.*, without
using reflection (just guarding usage via @IgnoreJRERequirement and
catching NoClassDefFoundError or the like).
·
-1 from me. I like the current behavior and since you can add the line
numbers as a plugin, why make it part of core? I also like seeing only
partial console logs since my build logs can get quite large.
On Jul 31, 2014 6:51 AM, Andrew Gray andrew.paul.g...@gmail.com wrote:
Hi All,
I have two
thanks again, Stephen. Could I ask more questions? excerpt from
https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
says *Hudson has an automatic data format upgrade capability* - what does
it mean?
I have one more issue with my final
On 31 July 2014 15:27, addict@gmail.com wrote:
thanks again, Stephen. Could I ask more questions? excerpt from
https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
says *Hudson has an automatic data format upgrade capability* - what
You provide no reasons why this would be an improvement. Here are some why it
wouldn't be:
1. Will be a regression for everyone parsing console output and assuming a line
starts with the actual output.
2. I already have to download logs to view them in a editor all the time
because the
Hi.
Kevin created a PR some time ago re tweaking the Console Output page to
make the default output look more like
terminal: https://github.com/jenkinsci/jenkins/pull/1272
There was a fair bit of discussion on the PR but consensus was not reached.
Some people felt the changes might effect
Hi,
I created a pull request for the git-plugin last week:
https://github.com/jenkinsci/git-plugin/pull/245
This pull request fixes JENKINS-22009 and potentially also some related
issues. I tested the fix locally, and also provided a test case in the pull
request. The code has also been reviewed
For reference, this is the maven release plugin issue:
https://jira.codehaus.org/browse/MRELEASE-812 AFAIK.
2014-07-31 15:12 GMT+02:00 Marco Miller miller.ma...@me.com:
Indeed; and that is basically the info I added to the wiki(*) some weeks
ago, when I experienced such troubles myself:
(*)
I think the actual white page is better because despite the page name is
console it's actually a log output and not a terminal emulator.
So put this way, and being the actual Jenkins theme background white, my
vote is to keep the actual consult scheme, but not discard some theming
options for
Thanks.
That's what I was suspecting that I'll have to do but didn't find the code
to do it.
I'll also have to be able to somehow copy over everything else from the
existing object except for this change.
Would you know where can I find an example, or at least a class name to
look for?
I think the default should not be changed: black text on white is the most
readable scheme to most humans.
Am 31.07.2014 um 21:08 schrieb Bruno Meneguello br...@meneguello.com:
I think the actual white page is better because despite the page name is
console it's actually a log output and not
+1 for moving up to Java7 as a build requirement. I don't see any problem.
(Just to avoid confusion, the runtime requirement will remain Java6+. We
are just talking about the build requirement.)
On 07/31/2014 06:56 AM, Jesse Glick wrote:
Are people still building Jenkins core using JDK 6? I
Slippery slope... How can we grease is some more (roll on JDK 8 as min
runtime)
On Friday, 1 August 2014, Kohsuke Kawaguchi k...@kohsuke.org wrote:
+1 for moving up to Java7 as a build requirement. I don't see any problem.
(Just to avoid confusion, the runtime requirement will remain Java6+.
Hi,
I would like to check whether there exists any plugin that matches the
following use case
1) Create a parent Job that acts as the template with a specified set of
User fields
2) On running the plugin, the plugin should spawn new job(child job) of the
same template.
3) If the new job
I would be very interested in this also. I think its a great idea.
On Wednesday, July 30, 2014 4:31:25 PM UTC-5, Kohsuke Kawaguchi wrote:
Some of you were in the Jenkins Scalability Summit last year [1,2,3].
I'm trying to see if we can do a similar one this year back to back with
JUC Bay
+ 10 for black
On 31 Jul 2014, at 18:41, Tom Fennelly tom.fenne...@gmail.com wrote:
Hi.
Kevin created a PR some time ago re tweaking the Console Output page to make
the default output look more like terminal:
https://github.com/jenkinsci/jenkins/pull/1272
There was a fair bit of
-∞
But not because I think black on white is better; that is a matter of
preference.
This change forces the author's preference on everyone with no way to opt
out of it for people who prefer the existing theme. Furthermore, you would
then ask the maintainers of other plugins to have to change
37 matches
Mail list logo
