Re: Information Request - Pipeline Execution Node Run Schema

[Jimmy Ray]

So, to be clear, you all are not doing anymore work on the Stage View 
Visualization?  Will Blue Ocean expose an API that non-Jenkins apps can 
consume for these data?

On Thursday, 27 July 2017 15:41:40 UTC-4, Jesse Glick wrote:
>
> On Thu, Jul 27, 2017 at 1:28 PM, Jimmy Ray  > wrote: 
> > We are building solutions using the RESTful wfapi 
>
> This is written by / only used by the Stage View visualization, which 
> is dormant, all the active work going into Blue Ocean. So I would not 
> really recommend relying on it, though presumably no one is about to 
> actively break it either. 
>

-- 
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/394cdab0-1707-48e0-b529-b21ada079f3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Information Request - Pipeline Execution Node Run Schema

[Jesse Glick]

On Thu, Jul 27, 2017 at 1:28 PM, Jimmy Ray  wrote:
> We are building solutions using the RESTful wfapi

This is written by / only used by the Stage View visualization, which
is dormant, all the active work going into Blue Ocean. So I would not
really recommend relying on it, though presumably no one is about to
actively break it either.

-- 
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/CANfRfr2amdC9n-Yawg-5W2Aw475nrY9FtYiuiUSJ0HDoBT2%3D6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

HockeyApp Plugin Maintainers

[Simon StJohn-Green]

I'd like to contact the maintainers of the HockeyApp 
plugin, https://wiki.jenkins.io/display/JENKINS/Hockeyapp+Plugin who are 
listed as:
* Oliver Hoeltke (ohoeltke)
* Brenton Bartel (Brantone)

I've had a couple of pull requests pending for a few months and haven't 
received any replies when attempting to contact either maintainer (brantone 
via github comment on the pull request, and ohoeltke by email).

If no-one responds then I would be happy to step in, otherwise I will mark 
the plugin as up for adoption.

Thanks,
Simon

-- 
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/8f6e02c7-7209-4102-b8b4-0dd6ed28864d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins mark usage request from CloudBees

[Kohsuke Kawaguchi]

On behalf of CloudBees, I’d like to request the permission to use the
following name that uses ‘Jenkins’ in it:

   - CloudBees Jenkins Advisor


To help people understand how this name is going to be used, let me
describe a bit about the effort for which we’d like to use this name.

CloudBees is going to launch a new free-as-in-beer
 service, delivered through
a Jenkins plugin, which makes Jenkins instances periodically submit the
support bundle (see support-core plugin
) to our
hosted system. Our system will analyze the contents of this, do some
pattern matching against known issues and symptoms of problems, and send
out e-mails when it detects new issues that require administrator’s
attention.

When we look at name approval requests like this, a key criteria is to make
sure it doesn’t create confusion about the origin of the effort. From that
perspective, this name has ‘CloudBees’ clearly in front of it, and it is
consistent with other names that are already approved. The situation and
the considerations that led to the approval of the past requests hasn't
really changed, so I hope the new name doesn’t raise any eyebrows and
result in a smooth approval.

I’ve put this up as an agenda for Aug 2nd project meeting to be able to get
a decision there. I might not be able to make it to that meeting, so I’ve
asked Tyler to sponsor this agenda item. If you have any concerns or
objections, please chime in on this thread prior to the meeting, so that we
can address them.

-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4x5%2BtTCTJ6n67aXq0MoWqYBo6nL8gZ%2BXUa0E08bW5U%2BMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Information Request - Pipeline Execution Node Run Schema

[Jimmy Ray]

We are building solutions using the RESTful wfapi, and I am trying to 
discern the node schema that is used on the resultant JSON payloads.  Given 
the output below, I am seeing nodes 6 and 11 that have useful data.  My 
question is, how would I know which nodes from which to gather logs, if 
were going to use the 
"/job/Examples/job/ExamplePipelineDSLJob/:run-id/execution/node/:node-id/wfapi/log"?
 
 Would I have to first traverse the "run" itself?


{"_links": {"self": {"href": "
/job/Examples/job/ExamplePipelineDSLJob/3/wfapi/describe"}},"id": "3","name"
: "#3","status": "SUCCESS","startTimeMillis": 1501173099695,"endTimeMillis": 
0,"durationMillis": 0,"queueDurationMillis": 114,"pauseDurationMillis": 0,"
stages": [{"_links": {"self": {"href": "
/job/Examples/job/ExamplePipelineDSLJob/3/execution/node/6/wfapi/describe"}}
,"id": "6","name": "scm","execNode": "","status": "SUCCESS","startTimeMillis
": 1501173099809,"durationMillis": 65,"pauseDurationMillis": 0},{"_links": {
"self": {"href": "
/job/Examples/job/ExamplePipelineDSLJob/3/execution/node/11/wfapi/describe"}
},"id": "11","name": "build","execNode": "","status": "SUCCESS","
startTimeMillis": 1501173099912,"durationMillis": 68,"pauseDurationMillis": 
0}]}

I mean, is there documentation that illustrates how pipeline execution 
nodes IDs are determined and arranged?  It seems to me that a pipeline is 
subdivided into so-called "execution nodes".  So, while execution node ID 6 
wfapi/log shows success, execution node ID 7 shows actual echo statement 
within the stage.  Is there a schema?  Is there a way to see the entire 
node tree of the run, with the numeric node IDs?

-- 
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/4f2afdc3-57e2-4269-82ea-8d28efece68a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backporting for LTS 2.60.3 started

[Andreas Mandel]

All valid points, for sure. This aspect of the Train Model was not clear to 
me... I need to find a way for me how to reduce the risk to run into such 
issues as much as possible for our productive system. We do tests in 
advance and feedback - but actually this is not very formal (on our side) 
and for sure it lacks some heavy load tests and tests that leave the system 
at work for a longer time period.

Now that I'm affected, I think it is important to somehow flag the LTS with 
such issues - actually one can do a Jira Query to find all known open 
issues or use the https://jenkins.io/changelog-stable/ page to check for 
the weather condition and then decide based on the likely long list of 
tickets if it is OK do go forward or not.

I can not say why the issue did not get more attention earlier. IMHO it is 
a kind of time bomb for every Jenkins installation, it might be undetected 
for smaller installations especially if they go with the weekly releases 
and so get restarted at least once a week. 

At the end we try to support to get the issue solved - hope this happens 
soon.

Thanks and kind regards, Andreas.

Am Donnerstag, 27. Juli 2017 12:56:55 UTC+2 schrieb Daniel Beck:
>
>
> > On 27. Jul 2017, at 07:19, Andreas Mandel  > wrote: 
> > 
> > Thanks for the feedback. Does this mean, according to plan, you release 
> LTS versions even with blocker issues? Or do you judge the severity of the 
> issue different? 
>
> Yes. The train model means we leave the station no matter what. Otherwise 
> we just get bogged down in discussions what constitutes a blocker issue 
> while holding off releases to include well-soaked bug fixes. 
>
> > but time is unfortunately quite limited. 
>
> If I'm right with my guess of 2.53 as the first affected release, the 
> problem was around for almost 3 months between introduction of the issue 
> and the original report, which was created only after 2.60.1 was released. 
> As we rely on users reporting and voting on issues they encounter for 
> things like deciding on an LTS baseline, it's no surprise this got in. 
>
> I asked a month ago in a comment for people who encounter this issue to 
> narrow down in which release the problem was introduced. Despite having 20 
> watchers now, nobody seems to have taken the time to do that yet. 
>
> Does that look consistent with an urgent blocker issue to you? 
>
>

-- 
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/7bf0a889-d95d-4fac-9c39-518e59161068%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Customizing Build Items

[Nikhil Bhoski]

Hi,

I am new to Jenkins plugin writing . I have written a plugin to add new 
Item and new build step . However i would like to know if there is a way to 
exclude few build Items highlighted in blue below . I basically want only 
*Build* to be displayed once somebody selects my project type . I came 
close to ItemGroup Interface however could not find any specific way to 
achieve this . pls help .

[image: Inline image 1]

Regards
Nikhil 

-- 
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/231adf4c-b8e9-4e33-a6de-6fa9c70b01d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trigger promotions from another job

[Sumit Agrawal]

Hi,

Have you got the solution? I am looking for similar feasibility.




On Wednesday, April 15, 2015 at 7:24:46 PM UTC+5:30, Varal wrote:
>
> Hey everyone,
>
> For the past 2 days I've been struggling with the following issue:
> I have a few jobs whose builds are promoted to "Latest" when certain 
> requirements are met. Once a night I would like to run a 
> "Promote_to_nightly" job which runs regression, coverity and other tests 
> against these promoted to "Latest" builds across different jobs. If 
> everything ends well the "Promote_to_nightly" job should trigger a 
> promotion called "Nightly" on the "Latest" build. At the end of it all I 
> should have jobs A B C D with builds that are promoted both to "Latest" and 
> "Nightly". 
>
> The promotion is done by defining a "Nightly" promotion in each job 
> configuration with the "Only when manually approved" option ticked and 
> running the approve() method which can be found 
> in hudson.plugins.promoted_builds.conditions.ManualCondition.java
>
> I managed to write a groovy script that does the promotion but it has a 
> side effect. The builds get promoted and an "Unknown Task" is displayed in 
> the build queue and Jenkins error log shows the following message:
>
> java.lang.IllegalStateException: no parent set on hudson.plugins.
> promoted_builds.PromotionProcess[Nightly]
>  at hudson.model.AbstractItem.getParent(AbstractItem.java:179)
>  at hudson.plugins.promoted_builds.PromotionProcess.getParent(
> PromotionProcess.java:140)
>  at hudson.plugins.promoted_builds.PromotionProcess.getOwner(
> PromotionProcess.java:148)
>  at hudson.plugins.promoted_builds.PromotionProcess.getAssignedLabel(
> PromotionProcess.java:195)
>  at hudson.model.Queue$Item.getAssignedLabel(Queue.java:1415)
>  at hudson.model.Node.canTake(Node.java:330)
>  at hudson.model.Queue$JobOffer.canTake(Queue.java:277)
>  at hudson.model.Queue.maintain(Queue.java:1049)
>  at hudson.model.Queue$MaintainTask.doRun(Queue.java:2048)
>  at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471
> )
>  at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
>  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.
> access$301(ScheduledThreadPoolExecutor.java:178)
>  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.
> run(ScheduledThreadPoolExecutor.java:293)
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> java:1145)
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:615)
>  at java.lang.Thread.run(Thread.java:745)
>
> The code I'm using (only the needed part from my testing) is as follows:
>
> import hudson.model.*
> import hudson.model.ItemGroup
> import hudson.scm.*
> import java.util.*
> import hudson.plugins.promoted_builds.*
> import hudson.plugins.promoted_builds.conditions.*
>
> println "RUNNING NIGHTLY PROMOTION GROOVY SCRIPT"
>   
> //These are the jobs that are under the "Nightly" promotion process
> def jobsToPromote = [Hudson.instance.getJob("Test_job")]
>
> //Object for the nightly promotion
> PromotionProcess nightlyPromotion = new 
> PromotionProcess(jobsToPromote[0].getParent(), "Nightly")
>
> //Object for the manual approval of the nightly promotion
> ManualCondition manualPromotion = new ManualCondition()
>
> //Array for storing builds promoted to "Latest"
> def jobBuildsToPromote = []
>
> //Get builds of Jobs promoted to "Latest" and store them in 
> jobBuildsToPromote array
> jobsToPromote.each { job -> (job.getBuilds()).find
>   {
>build -> (build.getActions(PromotedBuildAction)).find
> {
>   action -> if(action.contains("Latest"))
>   {
> jobBuildsToPromote.add(build)
> return true
>   }
> }
>   }
> }
>
> manualPromotion.approve(jobBuildsToPromote[0], nightlyPromotion)
>
>
> //Function for reading environment variables
> def getBuildVariable(String key)
> {
> def config = new HashMap()
> def thr = Thread.currentThread()
> def build = thr?.executable
> def envVarsMap = build.parent.builds[0].properties.get("envVars")
>
> config.putAll(envVarsMap)
> return config.get(key)
> }
>
> return
>
>
> Does anyone have an idea how to solve this issue?
> Many thanks in advance for all your suggestions :)
>
>

-- 
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/c2c5a69d-5439-42d8-b6dd-401974db4922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backporting for LTS 2.60.3 started

[Daniel Beck]

> On 27. Jul 2017, at 07:19, Andreas Mandel  wrote:
> 
> Thanks for the feedback. Does this mean, according to plan, you release LTS 
> versions even with blocker issues? Or do you judge the severity of the issue 
> different?

Yes. The train model means we leave the station no matter what. Otherwise we 
just get bogged down in discussions what constitutes a blocker issue while 
holding off releases to include well-soaked bug fixes.

> but time is unfortunately quite limited. 

If I'm right with my guess of 2.53 as the first affected release, the problem 
was around for almost 3 months between introduction of the issue and the 
original report, which was created only after 2.60.1 was released. As we rely 
on users reporting and voting on issues they encounter for things like deciding 
on an LTS baseline, it's no surprise this got in.

I asked a month ago in a comment for people who encounter this issue to narrow 
down in which release the problem was introduced. Despite having 20 watchers 
now, nobody seems to have taken the time to do that yet.

Does that look consistent with an urgent blocker issue to you?

-- 
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/6C6FDB86-4015-4DDA-8376-B7A1F5C28B52%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Backporting for LTS 2.60.3 started

[Oliver Gondža]

On 2017-07-27 07:19, Andreas Mandel wrote:
Thanks for the feedback. Does this mean, according to plan, you release 
LTS versions even with blocker issues? Or do you judge the severity of 
the issue different?


We are trying to narrow this further down to the versions you have 
mentioned in the ticket but time is unfortunately quite limited.


The severity of the issue affects the likelihood someone will work on 
that in the near future but that is pretty much it. So if we do not have 
the fix, the LTS will not be postponed to incorporate it. And even if we 
do, I tend to prefer to have the fix soaked in weakly first unless the 
bug is particularly bag to outweigh the risks.


Try to look at it this way, the regression has sneaked in, quite likely, 
despite the review process and testing when community had all the time 
to incorporated it. Trying to device a fix in a hurry and expedite it 
into the stable branch has a potential to cause lot more damage. 
Especially if we do not have a QE army to verity the result, which we do 
not have.


--
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/a9d87944-da8b-e050-0bec-865f45fc4d55%40gmail.com.
For more options, visit https://groups.google.com/d/optout.