Re: [GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[martinda]

Hello Abhishek,

I forgot to mention that we have office hours and all students are invited 
to participate and ask questions.
See https://jenkins.io/projects/gsoc/#office-hours for specific times.

Martin

On Friday, March 16, 2018 at 8:55:52 PM UTC-4, martinda wrote:
>
> On Friday, March 16, 2018 at 5:39:09 PM UTC-4, Abhishek Gautam wrote:
>>
>>
>> *@martinda *
>> While my research I came across something called EnvironmentContributor in 
>> Jenkins. Do you think that we can use this to pass required variables to 
>> the build processes?
>>
>
> Hi Abhishek,
>
> I have never used the EnvironmentContributor, but it would be one of the 
> possibilities. Injecting environment variables is convenient as all 
> sub-commands would inherit them (no explicit argument passing required), it 
> is an implementation detail which can be decided later.
>
> I suggest that you try the existing functionality (see Jesse's reply), and 
> this will help you to write your own project proposal. The existing plugins 
> that I think Jesse is referring to are 
> https://jenkins.io/doc/book/pipeline/multibranch/ and 
> https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/index.html#bitbucket.
>  
> The example projects that seem to go along with these plugins are 
> https://github.com/cloudbeers/multibranch-demo and 
> https://github.com/cloudbeers/multibranch-demo-lib
>
> Like Oleg said, the project idea description is not a specification, it 
> does not have to be followed to the letter.
>
> BR,
> 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/d6f2918e-8e82-4fe9-a0b9-67c41cf72bb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2018] [Student Introduction] Cloud Features for External Work-space Manager Plugin

[martinda]

I forgot to mention that we have office hours and all students are invited 
to participate and ask questions about GSoC.
See https://jenkins.io/projects/gsoc/#office-hours for the times.

Martin

On Friday, March 16, 2018 at 9:50:28 PM UTC-4, martinda wrote:
>
> Hello Vineeth,
>
> Thank you for your interest.
>
> We have some student information, but it looks like you have already read 
> it: https://jenkins.io/projects/gsoc/students/
> If you find something is missing please let us know.
>
> If you have already studied the external workspace manager code base and 
> know the extension points 
> , 
> then I recommend familiarizing yourself with cloud based storage, for 
> example azure, amazon, google, etc. This should help you write your project 
> proposal.
>
> Best Regards,
> Martin d'Anjou
>
> On Friday, March 16, 2018 at 3:18:03 PM UTC-4, Vineeth Reddy wrote:
>>
>>
>> I am a newbie in open source community but i feel i am capable enough to 
>> understand and give back to community my best. 
>>
>> I am interested in working with "CLOUD FEATURES FOR EXTERNAL WORKSPACE 
>> MANAGER PLUGIN. "
>>
>> I spent decent time on understanding project and would like to look into 
>> it more detail.
>>
>> As application closes in 11 days. I am unable to contribute much in prior 
>> but would like to make it this summer.
>>
>> Please guide with through additional info, resources on this project and 
>> ways to selected for this project and in starting  the contribution right 
>> away.
>>
>>

-- 
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/8d8bce06-551a-43ea-a0a7-f89378367ffd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC 2018] EDA Plugin : Developing a Jenkins Plugin for one of the EDA tools viz FuseSOC

[martinda]

Hi Lakhan,

Thank you for your interest in the GSoC project on EDA plugin for Jenkins.

There are many things a Jenkins EDA plugin can do. It can run the EDA tool, 
but that is rather trivial as anyone can shell out and call the tool from 
the command line. But what get more interesting is interpreting and 
reporting the results. Think of what is important when interpreting 
hardware simulations and synthesis results, what users are interested in 
knowing (simulation pass/fail criteria, log parsing, resource utilization, 
timing, etc) and that should provide a lot of material for coding the 
plugin. It is probably better to have one plugin for each EDA tool.

Note that we are also in contact with the librecores community regarding 
this plugin, so you should definitely join that community too 
(https://gitter.im/librecores/Lobby). A good approach would be to use one 
of their open source projects and build it with the EDA plugin. Lastly we 
have office hours (https://jenkins.io/projects/gsoc/#office-hours), all 
students are invited to participate and ask questions.

Best Regards,
Martin d'Anjou


On Friday, March 16, 2018 at 1:04:02 AM UTC-4, Lakhan Shiva wrote:
>
> Hi, 
>
> My name is Lakhan Shiva Kamireddy. I am a second year graduate student at 
> University of Colorado Boulder. I am interested in developing a Jenkins 
> Plugin for one of the EDA tools viz,
> FuseSOC, Yosys, icetools, ArachnePnr, etc. It will help to report FPGA 
> resource utilization per build, etc. 
>
> I am a user of Jenkins CI build platform while i was a backend web 
> application developer for a multinational consulting corporation (Deloitte 
> Consulting).
>
> Last year summer, I was an intern at Google, Sunnyvale office in 
> Califronia,as a Hardware Engineering intern and developed a Formal 
> Verification library (SystemVerilog and Perl)
> which falls under RTL design and Verification domain. I think this would 
> be a great project and would like to come up with a proposal for this. I 
> would like to get as much details as possible 
> for this project and also its potential to get accepted as a GSOC 2018 
> project for Jenkins.
>
> I have pursued some graduate level courses like Logic Synthesis and 
> Optimization, Computer Aided Verification(Formal Verification) at the 
> University of Colorado Boulder in the past years. 
>
> Kindly contact me, to fuel this project as a potential GSOC 2018 candidate.
>
> Thanks and Kind Regards, 
> Lakhan Shiva Kamireddy
>

-- 
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/272fa5d1-1092-434c-a1a4-0090dea52cd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2018] [Student Introduction] Cloud Features for External Work-space Manager Plugin

[martinda]

Hello Vineeth,

Thank you for your interest.

We have some student information, but it looks like you have already read 
it: https://jenkins.io/projects/gsoc/students/
If you find something is missing please let us know.

If you have already studied the external workspace manager code base and 
know the extension points 
, 
then I recommend familiarizing yourself with cloud based storage, for 
example azure, amazon, google, etc. This should help you write your project 
proposal.

Best Regards,
Martin d'Anjou

On Friday, March 16, 2018 at 3:18:03 PM UTC-4, Vineeth Reddy wrote:
>
>
> I am a newbie in open source community but i feel i am capable enough to 
> understand and give back to community my best. 
>
> I am interested in working with "CLOUD FEATURES FOR EXTERNAL WORKSPACE 
> MANAGER PLUGIN. "
>
> I spent decent time on understanding project and would like to look into 
> it more detail.
>
> As application closes in 11 days. I am unable to contribute much in prior 
> but would like to make it this summer.
>
> Please guide with through additional info, resources on this project and 
> ways to selected for this project and in starting  the contribution right 
> away.
>
>

-- 
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/c15041c5-57e9-4c00-8b5d-cf3be70703cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[martinda]

On Friday, March 16, 2018 at 11:17:02 AM UTC-4, Jesse Glick wrote:
>
> you are proposing some YAML 
> format—easily handled by an existing pair of extension points in 
> `workflow-multibranch`. I have discussed this is another thread.
>

Hi Jesse,

I could be wrong but I have the impression that you are saying that this 
GSoC project idea is a bit too shallow on the quantity of code for GSoC. If 
that is the case, do you have recommendations to make it more substantial? 
Maybe some enhancements to the existing PR plugins?

Note that in addition to building the PR, the proposed plugin would have 
some automatic detection of reports like JUnit XML reports, HTML reports, 
summary display reports, etc. I also though about adding a default merge 
before build, a default of having PR builds triggered by the user (rather 
than automatic), some default way to set the build description, etc.

Thanks,
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/836a943a-ad4a-4044-bb1a-4053cfafa1a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[martinda]

On Friday, March 16, 2018 at 5:39:09 PM UTC-4, Abhishek Gautam wrote:
>
>
> *@martinda *
> While my research I came across something called EnvironmentContributor in 
> Jenkins. Do you think that we can use this to pass required variables to 
> the build processes?
>

Hi Abhishek,

I have never used the EnvironmentContributor, but it would be one of the 
possibilities. Injecting environment variables is convenient as all 
sub-commands would inherit them (no explicit argument passing required), it 
is an implementation detail which can be decided later.

I suggest that you try the existing functionality (see Jesse's reply), and 
this will help you to write your own project proposal. The existing plugins 
that I think Jesse is referring to are 
https://jenkins.io/doc/book/pipeline/multibranch/ and 
https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/index.html#bitbucket.
 
The example projects that seem to go along with these plugins are 
https://github.com/cloudbeers/multibranch-demo and 
https://github.com/cloudbeers/multibranch-demo-lib

Like Oleg said, the project idea description is not a specification, it 
does not have to be followed to the letter.

BR,
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/9e0fec3a-9cfa-454e-9ce9-aa18e7d94bb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[Andrew Bayer]

It’s a normal step - what I’m talking about is counting Pipelines
containing one or more script blocks, I.e., what percentage of total
Declarative Pipelines use script blocks, which I think is a more useful
metric than just how many script block invocations there are.

A.

On Fri, Mar 16, 2018 at 5:32 PM R. Tyler Croy  wrote:

> (replies inline)
>
> On Fri, 16 Mar 2018, Andrew Bayer wrote:
>
> > If we???re going to be tracking step invocations anyway, it???d be
> interesting
> > to count the number of Declarative Pipelines with a script block, maybe?
>
> I kind of assumed that if we were incrementing a counter on step
> invocations
> that script{} would be collected already by the machinery, e.g. isn't it
> "just"
> a step?
>
> If it's a special snowflake then I'll make sure to include it in my design.
>
>
> A few more which come to mind now that I'm thinking about Script:
>
>  * Count of stages per Pipeline
>  * Count of Pipelines with the Groovy sandbox disable
>  * Time spent in script{} block
>
>
> Thanks for the ideas abayer!
>
>
> Cheers
> - R. Tyler Croy
>
> --
>  Code: 
>   Chatter: 
>  xmpp: rty...@jabber.org
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
> --
>
> --
> 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/20180316213201.ckenekkqcbgtsuzx%40blackberry.coupleofllamas.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/CAPbPdOaweqqiquGq6AWohdyBC_4ZwM51YLQJ53eHOrvFL6zijw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[Abhishek Gautam]

Hello Everyone,

Thank you for the clarifications.

Oleg Nenashev and James Nord thank you for the recommendation of *"Snake 
YAML".*

*@martinda *
While my research I came across something called EnvironmentContributor in 
Jenkins. Do you think that we can use this to pass required variables to 
the build processes?

-- 
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/f1ec0dbc-7383-4af0-b321-6b15ae56b350%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

(replies inline)

On Fri, 16 Mar 2018, Andrew Bayer wrote:

> If we???re going to be tracking step invocations anyway, it???d be interesting
> to count the number of Declarative Pipelines with a script block, maybe?

I kind of assumed that if we were incrementing a counter on step invocations
that script{} would be collected already by the machinery, e.g. isn't it "just"
a step?

If it's a special snowflake then I'll make sure to include it in my design.


A few more which come to mind now that I'm thinking about Script:

 * Count of stages per Pipeline
 * Count of Pipelines with the Groovy sandbox disable
 * Time spent in script{} block


Thanks for the ideas abayer!


Cheers
- R. Tyler Croy

--
 Code: 
  Chatter: 
 xmpp: rty...@jabber.org

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
--

-- 
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/20180316213201.ckenekkqcbgtsuzx%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

(replies inline)

On Fri, 16 Mar 2018, Daniel Beck wrote:

> 
> > On 16. Mar 2018, at 21:28, R. Tyler Croy  wrote:
> > 
> > * What are other metrics which would positively impact the development of
> >   Jenkins?
> 
> Assuming the Essentials setup allows for whitelisting pipeline methods, 
> knowing which methods are whitelisted (or got rejected on whitelisting 
> attempt) would be useful to guide improvements of the default whitelist and 
> the blacklist.
> 
> Basically, INFRA-1285, which I haven't had time to work on.


Good suggestion! I'll incorporate that into my design document.


- R. Tyler Croy

--
 Code: 
  Chatter: 
 xmpp: rty...@jabber.org

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
--

-- 
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/20180316212801.rzjh7tpe4gftp4ta%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[Liam Newman]

I think it would be interesting to record some metrics around the
complexity of Pipelines, such as cyclomatic complexity and number of lines
in the Jenkinsfile.  If shared libraries are used record the complexity and
size of those.
Also the size of the strings passed to external scripting steps (sh, cmd,
python, powershell, etc).



On Fri, Mar 16, 2018 at 1:41 PM Daniel Beck  wrote:

>
> > On 16. Mar 2018, at 21:28, R. Tyler Croy  wrote:
> >
> > * What are other metrics which would positively impact the development of
> >   Jenkins?
>
> Assuming the Essentials setup allows for whitelisting pipeline methods,
> knowing which methods are whitelisted (or got rejected on whitelisting
> attempt) would be useful to guide improvements of the default whitelist and
> the blacklist.
>
> Basically, INFRA-1285, which I haven't had time to work on.
>
> --
> 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/CEB8092F-4EAD-459B-BE96-FA2946E19B44%40beckweb.net
> .
> 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/CAA0qCNyn2Wu9gUb1wpbazWtctK9xmcMXdHO164scZ81XNjCu3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[Jesse Glick]

On Fri, Mar 16, 2018 at 4:28 PM, R. Tyler Croy  wrote:
>* distinct built-in step invocations (i.e. not counting Global Variable 
> invocations)

Careful with metasteps: `step` and `wrap` should count their
`delegate`s, so we count individual plugins contributing
`SimpleBuildStep` / `SimpleBuildWrapper`. Also see JENKINS-37227 for
`SCM`.


The `workflow-cps` plugin already collects a few metrics from running
Pipeline builds that get reported to `support-core`, since they are
thought to be correlated with people trying to do way too much in
Groovy and killing their system. These should also be sent to
telemetry:

· Groovy parse time
· class loading time
· in-VM run time
· `program.dat` save time
· flow graph load/save time
· flow graph size (roughly proportional to number of steps)


For those using Pipeline-as-code, we would like `branch-api` to report
the number of branch projects (of each type: branch, PR, tag) per
repo, and the number of repos per org, and probably some other stuff
like the volume of events being received and the frequency and
duration of full reindexings.

-- 
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/CANfRfr3ATr0Ua5xqbEidiCO_%2B19ZvUqeF4h0eNtHNR50A5%3DmkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Using non default locations for builds and workspaces (was: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome)

[Jesse Glick]

On Fri, Mar 16, 2018 at 4:20 PM, Baptiste Mathus  wrote:
> yes, users should still backup, JENKINS-49406 is *not* a backup system

True, though users will try to treat it as one.

-- 
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/CANfRfr15Ap21T-ja87J1pbVT-9%2Bk289A9xTxzqhsWLhnyWkuXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[Daniel Beck]

> On 16. Mar 2018, at 21:28, R. Tyler Croy  wrote:
> 
> * What are other metrics which would positively impact the development of
>   Jenkins?

Assuming the Essentials setup allows for whitelisting pipeline methods, knowing 
which methods are whitelisted (or got rejected on whitelisting attempt) would 
be useful to guide improvements of the default whitelist and the blacklist.

Basically, INFRA-1285, which I haven't had time to work on.

-- 
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/CEB8092F-4EAD-459B-BE96-FA2946E19B44%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[Andrew Bayer]

If we’re going to be tracking step invocations anyway, it’d be interesting
to count the number of Declarative Pipelines with a script block, maybe?

A.

On Fri, Mar 16, 2018 at 4:28 PM R. Tyler Croy  wrote:

> The successful adoption and iterative improvement of Jenkins Essentials
> [0] is
> heavily contingent on a spectrum of automated feedback which I've been
> referring to as "telemetry" in many of the design documents. I wanted to
> start
> discussing the prospect of collecting anonymized Pipeline usage telemetry
> to
> help Jenkins Essentials, Blue Ocean, and Pipeline teams understand how
> users
> are actually using Jenkins Pipeline.
>
> James Dumay has already prototyped some similar work[1] for collecting
> behavioral telemetry in Blue Ocean, but what I'm proposing would be much
> more
> broad in scope[2]. The metrics I am interested in, to help us understand
> how
> Pipeline is being used, are:
>
>  * Counts:
>* configured Declarative Pipelines
>* configured Script Pipelines
>* Pipeline executions
>* distinct built-in step invocations (i.e. not counting Global Variable
> invocations)
>* Global Shared Pipelines configured
>* Folder-level Shared Pipelines configured
>* Agents used per-Pipeline
>* Post-directive breakdown (stable,unstable,changed,etc)
>
>  * Timers
>* Runtime duration per step invocation
>* Runtime duration per Pipeline
>
>
> I believe this is a sufficiently useful set of metrics to send along, but
> the
> two questions I could use help answering are:
>
>  * What are other metrics which would positively impact the development of
>Jenkins?
>  * Are there concerns about implementation feasibility for any of these?
>
>
> I am planning on using statsd (sent to the project's Datadog account), so
> sampling and controlling the volume of individual metrics is not something
> I'm
> terribly worried about.
>
>
>
> Happy to hear any feedback y'all are willing to share!
>
>
> [0] https://github.com/jenkins-infra/evergreen#evergreen
> [1] https://github.com/jenkinsci/blueocean-plugin/pull/1653
> [2] https://issues.jenkins-ci.org/browse/JENKINS-49852
>
>
>
> Cheers
> - R. Tyler Croy
>
> --
>  Code: 
>   Chatter: 
>  xmpp: rty...@jabber.org
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
> --
>
> --
> 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/20180316202818.hgl5irxnuqduq24v%40blackberry.coupleofllamas.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/CAPbPdOYCryfDV8Edo1D6XTa7qhu9ik-wNEqLc4OYQVFh4hKvXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

The successful adoption and iterative improvement of Jenkins Essentials [0] is
heavily contingent on a spectrum of automated feedback which I've been
referring to as "telemetry" in many of the design documents. I wanted to start
discussing the prospect of collecting anonymized Pipeline usage telemetry to
help Jenkins Essentials, Blue Ocean, and Pipeline teams understand how users
are actually using Jenkins Pipeline.

James Dumay has already prototyped some similar work[1] for collecting
behavioral telemetry in Blue Ocean, but what I'm proposing would be much more
broad in scope[2]. The metrics I am interested in, to help us understand how
Pipeline is being used, are:

 * Counts:
   * configured Declarative Pipelines
   * configured Script Pipelines
   * Pipeline executions
   * distinct built-in step invocations (i.e. not counting Global Variable 
invocations)
   * Global Shared Pipelines configured
   * Folder-level Shared Pipelines configured
   * Agents used per-Pipeline
   * Post-directive breakdown (stable,unstable,changed,etc)

 * Timers
   * Runtime duration per step invocation
   * Runtime duration per Pipeline


I believe this is a sufficiently useful set of metrics to send along, but the
two questions I could use help answering are:

 * What are other metrics which would positively impact the development of
   Jenkins?
 * Are there concerns about implementation feasibility for any of these?


I am planning on using statsd (sent to the project's Datadog account), so
sampling and controlling the volume of individual metrics is not something I'm
terribly worried about.



Happy to hear any feedback y'all are willing to share!


[0] https://github.com/jenkins-infra/evergreen#evergreen
[1] https://github.com/jenkinsci/blueocean-plugin/pull/1653
[2] https://issues.jenkins-ci.org/browse/JENKINS-49852



Cheers
- R. Tyler Croy

--
 Code: 
  Chatter: 
 xmpp: rty...@jabber.org

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
--

-- 
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/20180316202818.hgl5irxnuqduq24v%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Using non default locations for builds and workspaces (was: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome)

[Baptiste Mathus]

@Jesse The alternative I had considered too was to just have multiple
volumes. But I agree having only one is also more inlined with Essentials
philosophy, having only one volume to actually backup (because yes, users
should still backup, JENKINS-49406 is *not* a backup system) is simpler.

@James I agree with your comment on logs.

   - For Jenkins logs: unsolved yet, but we will have to dig into it very
   soon for JENKINS-49805, which is another critical part for the success of
   the project. I think if we go the way surfacing above, i.e. adding another
   level under $JENKINS_HOME to separate what is snapshotted, and what is not,
   we would kind of have a good place for those anyway.
   - For access logs: good point, though same, not enabled yet. I think we
   could also decide to use a reverse proxy for this purpose, since anyway
   we're likely to need to introduce that component so that users connected to
   Jenkins via their browsers see a breakage when Jenkins is restarting.

Will adjust the proposal very soon with all this.

Thanks a lot for your feedback, I feel we're progressively reaching a more
decent thing together, which is always an intent for reviews. So that's
great.

Cheers


2018-03-16 17:26 GMT+01:00 Jesse Glick :

> On Thu, Mar 15, 2018 at 12:27 PM, R. Tyler Croy 
> wrote:
> > I
> > assume that it "just works" and there's no quality concerns we should
> have from
> > a non-standard placement of data on disk?
>
> Any obvious problems would have been reported long ago. (I remember
> some fixes involving folder renames or something like that.) By
> forcing Essentials users to run with this mode, we would quickly flush
> out remaining corner cases, I would think.
>
> > From my understanding of the potential failure scenarios with a plugin
> or core
> > upgrade is that unreadable build.xmls won't present a problem
>
> Not that I am aware of.
>
> > or be mutated by
> > a new plugin update
>
> It is possible for a plugin to mutate the `build.xml` of a completed
> build, but unusual, and probably even less likely that such an update
> would occur during Jenkins startup.
>
> > mutable state should not be scattered around inside the container's
> temporary
> > filesystem, but rather contained in the single mounted volume, e.g.:
> >
> > docker run -v /srv/jenkins:/var/jenkins_home jenkins/evergreen
>
> So we could have a volume which contains `$JENKINS_HOME` as a
> subdirectory, which would be the root of a Git repository; plus some
> other subdirectories for other unversioned data. That makes more sense
> to me than what was written in JEP-301.
>
> --
> 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/CANfRfr3RUuod%3D5aqV2F_Hwu%3D1K%3DnVmM9a9VhvySVnccL-_
> mvpw%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/CANWgJS6uckBBUkmUUWXP1c6yKw2hxzu%2BjkTApzYwnoHy2PEthQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2018] [Student Introduction] Cloud Features for External Work-space Manager Plugin

[Vineeth Reddy]

I am a newbie in open source community but i feel i am capable enough to 
understand and give back to community my best. 

I am interested in working with "CLOUD FEATURES FOR EXTERNAL WORKSPACE 
MANAGER PLUGIN. "

I spent decent time on understanding project and would like to look into it 
more detail.

As application closes in 11 days. I am unable to contribute much in prior 
but would like to make it this summer.

Please guide with through additional info, resources on this project and 
ways to selected for this project and in starting  the contribution right 
away.

I feel its great to associate with jenkins and starting off by open source 
journey. 

Thank you!!!

Best Regards,
VIneeth.
Twitter  | Github 


>
>
>
>
>
>

-- 
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/933baddf-ea45-4564-afeb-76a80f000a71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Using non default locations for builds and workspaces (was: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome)

[Jesse Glick]

On Thu, Mar 15, 2018 at 12:27 PM, R. Tyler Croy  wrote:
> I
> assume that it "just works" and there's no quality concerns we should have 
> from
> a non-standard placement of data on disk?

Any obvious problems would have been reported long ago. (I remember
some fixes involving folder renames or something like that.) By
forcing Essentials users to run with this mode, we would quickly flush
out remaining corner cases, I would think.

> From my understanding of the potential failure scenarios with a plugin or core
> upgrade is that unreadable build.xmls won't present a problem

Not that I am aware of.

> or be mutated by
> a new plugin update

It is possible for a plugin to mutate the `build.xml` of a completed
build, but unusual, and probably even less likely that such an update
would occur during Jenkins startup.

> mutable state should not be scattered around inside the container's temporary
> filesystem, but rather contained in the single mounted volume, e.g.:
>
> docker run -v /srv/jenkins:/var/jenkins_home jenkins/evergreen

So we could have a volume which contains `$JENKINS_HOME` as a
subdirectory, which would be the root of a Git repository; plus some
other subdirectories for other unversioned data. That makes more sense
to me than what was written in JEP-301.

-- 
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/CANfRfr3RUuod%3D5aqV2F_Hwu%3D1K%3DnVmM9a9VhvySVnccL-_mvpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch event listener for Github PR labels

[Jesse Glick]

On Fri, Mar 16, 2018 at 11:21 AM, Steven F  wrote:
> GHBS's
> PullRequest event returns a null revision in case of a PR merge

I suppose you are referring to

https://github.com/jenkinsci/github-branch-source-plugin/blob/245300dd6c2e1667b11155e2772b30c5f435f0ca/src/main/java/org/jenkinsci/plugins/github_branch_source/PullRequestGHEventSubscriber.java#L325-L328

So far the only case I can find where any caller pays attention to the
values in the map returned by this API is

https://github.com/jenkinsci/branch-api-plugin/blob/dcc0d23a0870058c6138362d3aa017c0d56effc2/src/main/java/jenkins/branch/MultiBranchProject.java#L1549-L1569

which seems to be a performance optimization, to avoid an extra call
to `SCMSource.retrieve` to look up the current head revision.

Stephen Connolly wrote most of this code and would be best placed to
answer questions like this.

-- 
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/CANfRfr14%2Bc5J4nAnciMt59a52eDz3qO8%3DLALNf5APxZTZ%3D5SdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch event listener for Github PR labels

[Steven F]

On Friday, March 16, 2018 at 3:05:30 PM UTC, Jesse Glick wrote:
>
> It is important. When a PR branch project is built, `checkout scm` and 
> related features will select a particular commit from the PR (not 
> always the most recent), and may additionally merge it against a 
> particular commit in the base branch. 
>

Ok, the reason I thought it might not be important is that GHBS's 
PullRequest event returns a null revision in case of a PR merge, so I was 
testing that as a first step. I just noticed that the PullRequestSCMHead is 
used by the GHBS events, but its class constructor is also package private 
while I've been using regular SCMHead. I still haven't found where these 
returned heads are later referenced, but I'm worried that GHBS will reject 
any non-PullRequestSCMHeads or revisions in which case there's nothing I 
can do here.

-- 
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/c615e9ca-3fcc-4c7b-b510-5622660e78c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[Jesse Glick]

On Thu, Mar 15, 2018 at 10:22 PM, martinda  wrote:
> there there is another model which is to have a job that handles all the pull 
> requests of a git repo to a given branch. For example say there is a git 
> repository called jupiter/juno.git (jupiter is the name of the github org or 
> of the bitbucket project). Then the pull requests destined to the master 
> branch of the juno git repository could have a correspondig job called 
> jupiter/juno/master.

Which is already a standard part of Jenkins 2, including GitHub and
Bitbucket support. The only thing distinct from the proposal as it
stands is that using the default set of plugins, the jobs are
configured from a `Jenkinsfile` whereas you are proposing some YAML
format—easily handled by an existing pair of extension points in
`workflow-multibranch`. I have discussed this is another thread.

-- 
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/CANfRfr1_hTLxt8gJWdSi7%3Dto%2Bs0C19%3DQkMf5Y%3Dk8MeiXSohVLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome

[Jesse Glick]

On Wed, Mar 14, 2018 at 1:55 PM, R. Tyler Croy  wrote:
> core and plugin upgrades can result in
> modification of config.xml and other object-serialized-files on disk when an
> upgrade occurs.

Does happen, but rarely. In most cases, format changes take effect on
disk only when a `Saveable` object is in fact saved for some other
reason—a *Save* button in the UI, for example.

> This means an upgrade of Jenkins Essentials has a very real potential to cause
> irreversible modifications to files on disk which prevent a safe rollback.

This is true.

> "bricking" a Jenkins Essentials instance is a severe failure for the project

This is what needs to be defined much more carefully. What would cause
an installation to be “bricked”, exactly? Years of work by core devs
(see JIRA issues with label `robustness`) have solved most cases where
Jenkins would fail to start or be used in a basic capacity merely due
to unreadable configuration files. You might get *Discard Old Data*
warnings, of course, but these are not fatal.

> we need to prevent against irreversible modifications to files causing
> runtime failures

That is a much broader requirement, at least if “runtime failures”
could be interpreted as things like “the deployment stage in all my
pipelines started failing”, and it is not clear to me that the
proposal as it stands comes close to satisfying it.

-- 
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/CANfRfr2-jQ7HgKteHX%3DvyqPrCEHATD-q2QJwqE8ggJOYM%3D6Bcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch event listener for Github PR labels

[Jesse Glick]

On Thu, Mar 15, 2018 at 4:44 AM, Steven F  wrote:
> I was unable to return a PullRequestSCMRevision for
> the PR head because its constructor is package private. Then, I couldn't
> tell if that was important because I couldn't trace where these returned
> heads are used in github branch source. I don't know if the resulting source
> fetch is scoped to these heads.

It is important. When a PR branch project is built, `checkout scm` and
related features will select a particular commit from the PR (not
always the most recent), and may additionally merge it against a
particular commit in the base branch.

> Sorry if this is all basic, my Java isn't that strong

I am afraid the multibranch system has become a rather complex API
with the addition of events and traits. It is not easy even for
experienced Jenkins developers to follow the details.

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

Re: first draft of a new JEP: Jenkins X: Jenkins for Kubernetes CD

[James Strachan]

sounds like a great idea! What kind of times would suit folks?

On 15 March 2018 at 22:35, Michael Neale  wrote:

> Nice description!
>
> Given the disparate timezones of everyone involved, would it make sense to
> have a few office hour type things? (not sure if there is enough interest
> in APAC timezone, if there is, let me know.
>
> On Thursday, March 15, 2018 at 1:32:48 PM UTC+11, Kohsuke Kawaguchi wrote:
>>
>> Thanks James,
>>
>> This is an important and exciting JEP for me, because it sets the mission
>> & scope for a new project “Jenkins X.”
>> Starting from Jenkins 2, in contributor events and Jenkins Worlds, I’ve
>> always pitched that our Jenkins project needs to take a bigger role and
>> responsibility in serving our users and solving their challenges.
>> Historically, by and large we did it by writing plugins, but we’ve been so
>> successful in doing that, now we need to create solutions that combine
>> those plugins.
>>
>>
>>
>> --
> 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/d5b2101c-6d5d-47e5-8848-115728369ed5%
> 40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
James
---
Twitter: @jstrachan
Email: james.strac...@gmail.com
Blog: https://medium.com/@jstrachan/

CI / CD for kubernetes

-- 
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/CALTd4v-9WM81M%2BGMTv2ssbxaLgU-4kQEw85AAFG_oPstP5y%2B7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[James Nord]

On Friday, March 16, 2018 at 10:12:33 AM UTC, Oleg Nenashev wrote:
>
>
> We just need to get input from YAML file and do things according to that.
>>
>> There is a java lib available to parse YAML file: 
>> https://github.com/FasterXML/jackson-dataformats-text/tree/master/yaml
>>
>
> According to my experience, I would rather recommend Snake YAML. Actually 
> we use FasterXML as well in many plugins... Generally we tend to package 
> such libs as API plugins, like this one: 
> https://github.com/jenkinsci/jackson2-api-plugin/blob/master/pom.xml . 
> Any library can be used.
>
>
I have been using snakeyaml in a few plugins - and It would probably 
benefit from being in a library plugin rather than pulled in - (but at the 
same time plugin dependency hell and well)

As for Jackson and YAML - I raised 2 JIRAs yesterday for that plugin 
JENKINS-50202  is the 
one for the YAML parser in dataformats and the related JENKINS-50201 
 for using jax-b 
annotations with jackson.

/James

>

-- 
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/2601dc97-62c6-4801-8478-093b9da172b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Valgrind plugin maintainer out of action

[Oleg Nenashev]

Thanks for the update!
If you are interested in co-maintaining the plugin, feel free to reach out 
to the maintainer. Usually the plugins need much more love than a 
particular person can dedicate, and having multiple 
maintainers/contributors could improve the plugin's health a lot.

BR, Oleg

On Thursday, March 15, 2018 at 3:48:46 PM UTC+1, ni...@tern.is wrote:
>
> Hi Oleg,
>
> Thank you for the procedural information. Yes, things started shaping up 
> now, thank you Johannes if you are reading this.
>
> Cheers,
> Nils
>
> On Tuesday, 6 March 2018 20:09:29 UTC, Oleg Nenashev wrote:
>>
>> Hi Nils,
>>
>> We do not appoint maintainers, all maintainers are contributors. If 
>> somebody is interested to take ownership, he just needs to ping the 
>> original maintainer in public channel and wait for an approval from the 
>> current maintainer or for a 2-week timeout.
>>
>> OTOH I see the ongoing activities in the plugin: 
>> https://github.com/jenkinsci/valgrind-plugin/commits . There was a 
>> release 2 hours ago. Maybe you have already got a response.
>>
>> BR, Oleg
>>
>>
>> On Monday, March 5, 2018 at 7:52:44 PM UTC+1, ni...@tern.is wrote:
>>>
>>> Hi,
>>>
>>> The valgrind plugin maintainer seems to be out of action. There are a 
>>> number of pending pull requests including pipeline support that are really 
>>> valuable.
>>>
>>> Would it be possible for someone to merge these pull requests? Could a 
>>> new maintainer be appointed?
>>>
>>>
>>> I already posted this to the users list, it was suggested I repost here. 
>>> It was also asked whether I could take over, and the answer is no. I'm not 
>>> a java programmer, mostly do C and C++. If necessary I can fix bugs, but I 
>>> don't have time to start learning the intricacies of modern java and the 
>>> jenkins framework.
>>>
>>> If I needed to suggest someone it would be Jan Wulkop who implemented 
>>> the pipeline support (not yet merged).
>>>
>>> Cheers,
>>> Nils
>>>
>>

-- 
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/fe851552-f759-426f-af7b-f4c39a377aea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC 2018] [Student Introduction & query] Simple Pull-Request Job Plugin

[Oleg Nenashev]

Hi Abhishek,

+1 to what you say. Any comments about the project proposal will be 
appreciated. Actually we expect students to make their own proposals, so do 
not consider the project idea description as a specification.

We just need to get input from YAML file and do things according to that.
>
> There is a java lib available to parse YAML file: 
> https://github.com/FasterXML/jackson-dataformats-text/tree/master/yaml
>

According to my experience, I would rather recommend Snake YAML. Actually 
we use FasterXML as well in many plugins... Generally we tend to package 
such libs as API plugins, like this one: 
https://github.com/jenkinsci/jackson2-api-plugin/blob/master/pom.xml . Any 
library can be used.

Best regards,
Oleg

On Friday, March 16, 2018 at 3:22:31 AM UTC+1, martinda wrote:
>
> Hello Abhishek,
>
> Thanks for your interest in the Jenkins GSoC projects.
>
> > But then for every pull request administrator of the project needs to 
> create a job and then trigger a build. I think this will be cumbersome.
>
> Yes that is a model that I have seen. But there there is another model 
> which is to have a job that handles all the pull requests of a git repo to 
> a given branch. For example say there is a git repository called 
> jupiter/juno.git (jupiter is the name of the github org or of the bitbucket 
> project). Then the pull requests destined to the master branch of the juno 
> git repository could have a correspondig job called jupiter/juno/master. 
> There could be other models too.
>
> > pull request payloads have all of the above things, so we can extract 
> them from the pull request payload itself.
>
> I did not know this. How do the PR coordinates (source and destination 
> branches and repositories) get into the variables of a build if they are 
> not input parameters? Does this require the installation of plugins in 
> other systems?
>
> I would suggest that you consider preparing an application with your ideas 
> and suggestions in a google doc document.
>
> Best Regards,
> Martin d'Anjou
>
>

-- 
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/887ad6fc-63aa-4a1b-a655-2eefaa0a78a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.