Re: Is it possible to configure job at https://jenkins.ci.cloudbees.com/job/plugins/ to use java 8?

[Joseph P]

The magic word is inside the POM:

  
8
  

I'd suggest making a Jenkinsfile, take a look at 
this https://github.com/jenkins-infra/pipeline-library/
then create a infra 
ticket https://issues.jenkins-ci.org/projects/INFRA/issues

This is how I did it 
https://github.com/jenkinsci/accurev-plugin/blob/master/Jenkinsfile which 
then simply builds the maven project :)

Best of luck!


Den tirsdag den 21. februar 2017 kl. 02.26.21 UTC+1 skrev Patrick Huang:
>
> Hi, 
>
> Our plugin declare java 8 in pom and uses java 8 in source. But the auto 
> created job at https://jenkins.ci.cloudbees.com/job/plugins/ is 
> running/using java 7:
>
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /opt/java/sdk/Oracle/x86_64/jdk1.7.0_79/jre
>
>
> So it failed the build. Is there anyway we can configure the job to use 
> java 8? Like putting some magic word in github PR description? Should I be 
> better off applying a job at https://ci.jenkins.io/job/Plugins/? Thanks.
>

-- 
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/4bc721cf-f14d-4819-ac61-c5bf9a339045%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Changes to global settings introduces null pointer on jobs, Accurev Plugin.

[Joseph P]

I am trying to resolve an issue, changes to server name on global settings 
introduces null pointer on jobs.

https://issues.jenkins-ci.org/browse/JENKINS-31316

I cannot find a decent way to introduce safety when changes to global 
settings are changed.

Current code is 

public boolean configure(StaplerRequest req, JSONObject formData) 
throws FormException {
this._servers = req.bindJSONToList(AccurevServer.class, 
formData.get("server"));
pollOnMaster = req.getParameter("descriptor.pollOnMaster") != 
null;
save();
return true;
}

Cannot find anything on jelly how to ensure the formdata with a 
unique/identifier.

How would I go about changing the identifier from names to something more 
realiable.

-- 
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/e3ff0804-39fb-4d58-8043-21f0379cd005%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

accurev-plugin, request for commit access

[Joseph P]

Hi

 

I would like to be a maintainer for the accurev plugin.

https://wiki.jenkins-ci.org/display/JENKINS/AccuRev+Plugin

 

Would also appreciate a code review on 
https://github.com/jenkinsci/accurev-plugin/pull/25

 

GitHub id: casz

Jenkins id: casz

 

Best regards

Joseph

-- 
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/f0c0c35c-5787-4c4e-8558-96a3aca4a3e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Quoting ArgumentListBuilder addQuoted(""). Fails to run on unix.

[Joseph P]

I'd be happy to report a issue. Was thinking someone here had experience 
with escaping it properly before creating an issue.

Den tirsdag den 18. oktober 2016 kl. 13.16.00 UTC+2 skrev Daniel Beck:
>
> This is not where you report bugs. 
>
> https://wiki.jenkins-ci.org/display/JENKINS/How+to+report+an+issue 
>
> > On 17.10.2016, at 20:38, Joseph P <jose...@gmail.com > 
> wrote: 
> > 
> > Hi 
> > 
> > I have a login command which accepts no password by "" or '' 
> > Command execute fine on Windows. 
> > 
> > This is how the ProcStarter gets going. 
> > ProcStarter starter = launcher.launch().cmds(command); 
> > 
> > The command is: /Applications/AccuRev/bin/accurev login josp "" 
> > Or: "C:\Program Files\AccuRev\bin\accurev.exe" login josp "" 
> > 
> > I have tried different escaping but nothing has worked. 
> > 7, 5, 3, 2 back slashes. backticks... single quoting. etc. 
> > Also tried StringEscapeUtils, even .cmdAsSingleString 
> > 
> > Any ideas would be appreciated why Java/Unix is eating my quotes. 
> > 
> > Files in question: 
> > 
> https://github.com/jenkinsci/accurev-plugin/blob/FixEmptyPassword/src/main/java/hudson/plugins/accurev/cmd/Login.java
>  
> > 
> https://github.com/jenkinsci/accurev-plugin/blob/FixEmptyPassword/src/main/java/hudson/plugins/accurev/AccurevLauncher.java
>  
> > 
> > Best regards, Joseph. 
> > 
> > -- 
> > 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/a67b09dc-30b7-443b-8a12-1a0d2b81cba0%40googlegroups.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/d8a2a9e7-c055-4b25-a269-986c699d5388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Quoting ArgumentListBuilder addQuoted(""). Fails to run on unix.

[Joseph P]

Issue created https://issues.jenkins-ci.org/browse/JENKINS-39066

Den mandag den 17. oktober 2016 kl. 20.38.56 UTC+2 skrev Joseph P:
>
> Hi
>
> I have a login command which accepts no password by "" or ''
> Command execute fine on Windows.
>
> This is how the ProcStarter gets going.
> ProcStarter starter = launcher.launch().cmds(command);
>
> The command is: /Applications/AccuRev/bin/accurev login josp ""
> Or: "C:\Program Files\AccuRev\bin\accurev.exe" login josp ""
>
> I have tried different escaping but nothing has worked.
> 7, 5, 3, 2 back slashes. backticks... single quoting. etc.
> Also tried StringEscapeUtils, even .cmdAsSingleString
>
> Any ideas would be appreciated why Java/Unix is eating my quotes.
>
> Files in question: 
>
> https://github.com/jenkinsci/accurev-plugin/blob/FixEmptyPassword/src/main/java/hudson/plugins/accurev/cmd/Login.java
>
> https://github.com/jenkinsci/accurev-plugin/blob/FixEmptyPassword/src/main/java/hudson/plugins/accurev/AccurevLauncher.java
>
> Best regards, Joseph.
>

-- 
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/95f70208-81fc-47a7-aa35-1f1a8bc17924%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: LDAP Plugin STARTTLS support

[Joseph P]

Seems to be a old issue never resolved:
https://issues.jenkins-ci.org/browse/JENKINS-14520

Den torsdag den 6. april 2017 kl. 15.12.05 UTC+2 skrev GWarBand:
>
> Hello,
>
> I have solved the problem by recompile acegi-security-1.0.7 with starttls 
> support.
> I have also recompile the ldap plugin with starttls support.
>
> This is only a workaround but works fine for me, maybe in future there is 
> an officiell plugin for 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/18f09952-d5cf-4d26-99ec-5d0cbb673760%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] Evaluate env var in text box to populate drop down list

[Joseph P]

First off your doFill method should be called doFillItems

Take a look here for creating a listener: 
https://github.com/jenkinsci/accurev-plugin/blob/master/src/main/java/hudson/plugins/accurev/cmd/ShowStreams.java#L133-L153
and for build env look 
here: 
https://github.com/jenkinsci/accurev-plugin/blob/master/src/main/java/hudson/plugins/accurev/AccurevLauncher.java#L479-L493

Hope that helps

Den torsdag den 6. april 2017 kl. 02.08.22 UTC+2 skrev JordanGS:
>
> I have two elements, a text box which takes a path and a drop down list 
> below it that will populate the drop down list. How do i modify the doFill 
> Items method to expand the value. See below method
>
> zapSettingsDir is the textbox with the path from the jelly config file.
>
>   
> 
>   
> 
>   
>
> and the associated java code is
>
> public ListBoxModel doFillActiveScanPolicyItems(@QueryParameter 
> String zapSettingsDir) {
> ListBoxModel items = new ListBoxModel();
>
> /* No workspace before the first build, so workspace is null. 
> */
> if (workspace != null) {
> File[] listFiles = {};
> try {
> listFiles = workspace.act(new PolicyFileCallable(
> zapSettingsDir));
> }
> catch (IOException e) {
> e.printStackTrace(); /* No listener because it's not 
> during a build but it's on the job config page. */
> }
> catch (InterruptedException e) {
> e.printStackTrace(); /* No listener because it's not 
> during a build but it's on the job config page. */
> }
>
> items.add(""); /* To not load a policy file, add a blank 
> choice. */
>
> for (File listFile : listFiles)
> items.add(FilenameUtils.getBaseName(listFile.getName
> ())); /* Add policy files to the list, without their extension. */
> }
> return items;
> }
>
> My problem being that i have no build variable at the moment and no 
> listener since it's not at the build step yet but on the job's config page. 
> Thanks :)
>

-- 
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/c4c89eb0-e4a2-4d97-83ee-b32cd14e54b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] Evaluate env var in text box to populate drop down list

[Joseph P]

I would discourage against trying to grab something from slave nodes, how 
do you determine the right node? You can traverse all nodes but that seems 
a little over the top.
The two github links are examples of how to get a listener, and node (in 
this case Jenkins.instance can be casted to node) to access either files or 
command line tools or whatever have you.

Den torsdag den 13. april 2017 kl. 01.09.22 UTC+2 skrev JordanGS:
>
> You say odd stuff, but then that would make it possible? Do you have an 
> example i can look at maybe?
>

-- 
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/aa5b90f0-b853-4853-a3e9-d9f89980047b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: IntelliJ licenses

[Joseph P]

Hi

Since nothing became of the last meeting talking about the licensing 
issue: 
http://meetings.jenkins-ci.org/jenkins-meeting/2016/jenkins-meeting.2016-03-30-18.00.html
I would like to step up as the contact person for Jetbrains

I will send an email to Jetbrains asking about their OS license.
When I get a response I will add it here, and if further actions are 
required put it on the meeting agenda

Den mandag den 22. februar 2016 kl. 23.02.42 UTC+1 skrev Daniel Beck:
>
> Hi everyone, 
>
> JetBrains recently changed the rules on open-source licenses, and KK is no 
> longer eligible to manage them. 
>
> https://www.jetbrains.com/buy/opensource/?product=idea 
>
> Ideally, someone else who qualifies would handle the IntelliJ IDEA 
> licenses for the software project. 
>
> Any volunteers? 
>
> Daniel 
>
>

-- 
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/a5e56911-16a4-46e7-b9b8-78c8ef177790%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regarding the recent waves of mailing list spam

[Joseph P]

I would also be willing. Timezone CEST/CET :)

Den mandag den 17. april 2017 kl. 17.53.45 UTC+2 skrev R Tyler Croy:
>
>
> As you may have noticed, there has been an uptick in spam getting through 
> to 
> the Google Groups run by the Jenkins project. On some lists, these have 
> resulted in Google flagging the group and bouncing emails from those 
> groups. 
>
> This was discussed during our last project meeting 
> (
> http://meetings.jenkins-ci.org/jenkins-meeting/2017/jenkins-meeting.2017-04-12-18.00.html),
>  
>
> and as promised I wanted to let everybody know where things stand and why. 
>
>
> If you receive emails as they're posted (non-digest mode) from Google 
> Groups, 
> if a spamemr gets through, there's nothing we can do for you. While I have 
> added a couple more "Manager" roles to the jenkinsci-users@ list, who can 
> ban 
> authors and delete posts, once something is delivered to your inbox, 
> there's 
> nothing we can do. 
>
> Some people have suggested first-poster moderation, which is one option, 
> but 
> not one I'm personally willing to turn on until more people are active 
> moderators. Unfortunately I took a weekend off from my morning-routine of 
> banning spammers two weekends ago, which seems to have led to the recent 
> surge 
> and flagging of the group. 
>
>
> What we are evaluating between last project meeting and the upcoming one 
> (April 
> 26) is whether Google Groups is still a viable option for the Jenkins 
> project. 
> A number of other projects have moved to groups.io, which would be a 
> likely 
> destination if Google continues to flag our groups. 
>
>
>
> Consider yourselves updated, feel free to ping me on IRC (rtyler) with 
> questions. 
>
>
> 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/67550b76-a94f-4a36-b085-7ab424c690dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] Evaluate env var in text box to populate drop down list

[Joseph P]

The config page only runs on master.
So if you need an environment variable from slave then you have to do some 
odd stuff :S

Den torsdag den 6. april 2017 kl. 07.42.45 UTC+2 skrev JordanGS:
>
> The field attribute above is a text box that provides a path, in the form 
> of an environment variable.
>
> The do fill provides information for the drop down list
>
>
> 
>
> 
>
> As you can see, it's properly named. I'll try the posted link and update 
> tomorrow on progress. I'm wondering how it will be able to evaluate the 
> environment variable when it's on the slave and not the master while on the 
> job config page and not in the build.
>
> Cheers, Goran.
>
> On Apr 6, 2017, 1:33 AM -0400, Joseph P <jose...@gmail.com >, 
> wrote:
>
> First off your doFill method should be called doFillItems
>
> Take a look here for creating a listener: 
> https://github.com/jenkinsci/accurev-plugin/blob/master/src/main/java/hudson/plugins/accurev/cmd/ShowStreams.java#L133-L153
> and for build env look here: 
> https://github.com/jenkinsci/accurev-plugin/blob/master/src/main/java/hudson/plugins/accurev/AccurevLauncher.java#L479-L493
>  
>
> Hope that helps
>
> Den torsdag den 6. april 2017 kl. 02.08.22 UTC+2 skrev JordanGS: 
>>
>> I have two elements, a text box which takes a path and a drop down list 
>> below it that will populate the drop down list. How do i modify the doFill 
>> Items method to expand the value. See below method
>>
>> zapSettingsDir is the textbox with the path from the jelly config file.
>>
>>   
>> 
>>   
>> 
>>   
>>
>> and the associated java code is
>>
>> public ListBoxModel doFillActiveScanPolicyItems(@QueryParameter 
>> String zapSettingsDir) {
>> ListBoxModel items = new ListBoxModel();
>>
>> /* No workspace before the first build, so workspace is 
>> null. */
>> if (workspace != null) {
>> File[] listFiles = {};
>> try {
>> listFiles = workspace.act(new PolicyFileCallable(
>> zapSettingsDir));
>> }
>> catch (IOException e) {
>> e.printStackTrace(); /* No listener because it's not 
>> during a build but it's on the job config page. */
>> }
>> catch (InterruptedException e) {
>> e.printStackTrace(); /* No listener because it's not 
>> during a build but it's on the job config page. */
>> }
>>
>> items.add(""); /* To not load a policy file, add a blank 
>> choice. */
>>
>> for (File listFile : listFiles)
>> items.add(FilenameUtils.getBaseName(listFile.getName
>> ())); /* Add policy files to the list, without their extension. */
>> }
>> return items;
>> }
>>
>> My problem being that i have no build variable at the moment and no 
>> listener since it's not at the build step yet but on the job's config page. 
>> Thanks :)
>>
> --
> You received this message because you are subscribed to a topic in the 
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/jenkinsci-dev/_SC7dwWpIb8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> jenkinsci-de...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/c4c89eb0-e4a2-4d97-83ee-b32cd14e54b6%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/c4c89eb0-e4a2-4d97-83ee-b32cd14e54b6%40googlegroups.com?utm_medium=email_source=footer>
> .
> 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/9f3f13ca-b74c-4bcb-97c9-112d24aeb3ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Joseph P]

ETA on Release?

Den mandag den 26. juni 2017 kl. 18.13.07 UTC+2 skrev Stephen Connolly:
>
> On 26 June 2017 at 08:14, Joseph P <jose...@gmail.com > 
> wrote:
>
>> This UI is a lot better! Looking forward to the massive upgrade!
>>
>> Just wondering with the refactoring will it be possible for PRs to 
>> rebuild when changes to target branch is notified?
>> When the option for Merge PR with Target branch is selected.
>>
>> That would be AWESOME!
>>
>
> So right now that would be a controversial feature...
>
> What I want to do is add the concept of interesting and non-interesting 
> revisions to SCM-API
>
> I feel that it is necessary to have that concept in order to enable 
> support for Tag discovery (because you certainly want old tags as 
> non-interesting, if not all tags as non-interesting)
>
> Then the idea would be that the Branch-API's multi-branch project would 
> not build non-interesting revisions by default.
>
> With the above changes then we could do things like:
>
> 1. Merge commits where only the target branch changes are non-interesting 
> (which is a win for the people who do not want build storms on indexing)
> 2. Merge commits where the target branch changes are interesting (which is 
> what you want)
>
> With some of the other changes in SCM-API it would then be safe to add 
> multi-branch project triggering change requests when the target branch 
> changes because we'd have 
> https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixin/ChangeRequestSCMHead.java#L57
>  
> and 
> https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixin/ChangeRequestSCMHead2.java#L45
>  
> so we'd know that the checkout strategy is merge and hence if 
> https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixin/ChangeRequestSCMRevision.java#L65
>  
> has changed then we should re-fetch the effective head revision... and if 
> it is interesting then we can rebuild.
>
> At least that is my current thinking...
>
> But right now there are two camps of people:
>
>- Those who want the build storm
>- Those who do not want the build storm
>
> Until I can satisfy both camps we will have to live with the current 
> "build storm only on indexing" situation.
>   
>
>>
>>
>> Den fredag den 23. juni 2017 kl. 15.32.54 UTC+2 skrev Stephen Connolly:
>>>
>>> How do you find the new UI compared with the previous one?
>>>
>>> On 23 June 2017 at 14:18, Joseph P <jose...@gmail.com> wrote:
>>>
>>>> Upgrade on "prod like" went smooth :)
>>>> Could we move the question for behaviours closer to the behaviours text?
>>>>
>>>>
>>>> <https://lh3.googleusercontent.com/-6ZYEdujPA6I/WU0Ut447ZXI/Bro/MO4YEevB3rAPfGAWqoJnqkqruXW26SBFACLcBGAs/s1600/shot_170623_151622.png>
>>>>
>>>>
>>>>
>>>>
>>>> Den torsdag den 22. juni 2017 kl. 08.10.41 UTC+2 skrev Joseph P:
>>>>>
>>>>> I will try and get around to testing it today.
>>>>>
>>>>> Den onsdag den 21. juni 2017 kl. 20.30.03 UTC+2 skrev Stephen Connolly:
>>>>>>
>>>>>> How many people have been able to try this so far?
>>>>>>
>>>>>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <
>>>>>> stephen.al...@gmail.com> wrote:
>>>>>>
>>>>>>> If you are chomping at the bit, here are all the binaries:
>>>>>>>
>>>>>>>
>>>>>>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>>>>>>>
>>>>>>> SHA1 checksums:
>>>>>>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>>>>>>> 16da429f09fb585fd1d744809ee22c8d612fb62c  
>>>>>>> cloudbees-bitbucket-branch-source.hpi
>>>>>>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>>>>>>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>>>>>>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>>>>>>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>>>>>>
>>>>>>> SHA256 checksums:
>>>>>>> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7  
>>>>>>> branch-api.hpi
>>>>>>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e0

Re: Jenkins 2.60.2 LTS RC testing started

[Joseph P]

I can't seem to see from jira issues which fixes it includes.

Den torsdag den 6. juli 2017 kl. 11.48.33 UTC+2 skrev ogondza:
>
> Hello everyone, 
>
> Latest LTS RC was made public and it is ready to be tested. Release is 
> scheduled for 2017-07-19. 
>
> Report your findings in this thread or on the test plan wiki page. 
>
> Download bits from 
> http://mirrors.jenkins-ci.org/war-stable-rc/2.60.2/jenkins.war 
> Check community maintained LTS test plan 
> https://wiki.jenkins-ci.org/display/JENKINS/LTS+2.60.x+RC+Testing 
>
> Thanks 
> -- 
> oliver 
>

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

Re: IntelliJ licenses

[Joseph P]

The person from Jetbrains I wrote with was Nadya Davydova Community Support
Manager

lør. 29. apr. 2017 kl. 01.04 skrev Kohsuke Kawaguchi <k...@kohsuke.org>:

> Thanks. I've submitted a renewal request and cited this conversation. Do
> you know which person in JetBrains you have been talking to? I'd like
> whoever going to review this request to be able to connect dots on their
> sides.
>
> On Fri, Apr 28, 2017 at 1:27 PM Joseph P <joseph...@gmail.com> wrote:
>
>> So I got a reply from Jetbrains and they would be willing to supply us
>> with licenses expect for those that get paid to work on jenkins or sell a
>> jenkins product (ie. Cloudbees).
>> However they mentioned Kohsuke could still be the administrator but
>> anyone could apply as long as they project lead or core committer.
>>
>> Here is the emails between Jetbrains and me
>>
>> ---
>>
>> Hello Joseph,
>>
>> Our apologies for a delay with a response from our side. Seems like your
>> me=
>> ssages were blocked by Spam filter.
>>
>> We used to support Jenkins project in our OS Program before the change in
>> t=
>> he rules. Our contact from your side has been Kohsuke Kawaguchi. To apply
>> f=
>> or the OS licenses on behalf of an OS project one should be the project
>> lea=
>> d or a core committer. Especially when a project is big as yours.
>> [Here](ht=
>> tps://
>> groups.google.com/forum/#!msg/jenkinsci-dev/3XRhnf8ferI/VqUvT-xtAQAJ)=
>>  is mentioned Kohsuke Kawaguchi is no longer eligible to manage them. Why
>> d=
>> o you think so and who is the team lead now?
>>
>> We look forward to your response. Should you have any further questions -
>> w=
>> e are happy to help. Have a nice day!
>>
>> ---
>>
>> Hi
>>
>> Thanks for getting back to me
>>
>> Kohsuke is still the project lead, though he works for Cloudbees, which
>> sel=
>> ls enterprise grade Jenkins.
>>
>> Which also exclude most of the core contributor, since they work for
>> Cloudbees, from applying to the JetBrains OS license.
>> https://www.cloudbees.com/products
>>
>> So according to a Jenkins meeting they saw the need to find a contributor
>> that was not working directly for cloudbees,
>> That did not fall under the "Projects that are sponsored by a commercial
>> company or organization, or those with employees paid to work on the
>> project are not eligible"
>>
>> http://meetings.jenkins-ci.org/jenkins-meeting/2016/jenkins-meeting.2016-03-30-18.00.html
>>
>> http://meetings.jenkins-ci.org/jenkins-meeting/2016/jenkins-meeting.2016-03-30-18.00.log.html
>> http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-02-18-19.01.html
>>
>> http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-02-18-19.01.log.html
>>
>> And according to those meeting batmat one of Jenkins core contributor,
>> that does not work for Cloudbees, were suppose to figure out the license
>> owner for Jenkins.
>>
>> He has regrettably been too busy from my understanding, this is where I
>> com=
>> e in as a Plugin maintainer decided to take action.
>> https://github.com/jenkinsci/accurev-plugin
>>
>> But if we could figure something out.
>> I would happily put it on next meeting agenda for the Jenkins project
>> March 1st or March 15th:
>> https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda
>>
>> Looking forward to your response :)
>>
>> /Joseph
>>
>> ---
>>
>> Hello Joseph,
>>
>> Thank you for a prompt and detailed response. Sorry for a short delay
>> from my side.
>>
>> I've talked to the PMM for IntelliJ IDEA. We can support Jenkins with the
>> free OS licenses.
>> Kohsuke Kawaguchi can still remain the administrator for your project.
>> This means he can send the request and distribute the licenses. He is not
>> eligible for the free OS license - that's true.
>>
>> Do you wish to apply on behalf of Jenkins in general or on behalf of the
>> plugins? How many licenses are needed?
>>
>> We look forward to your response. Should you have any further questions -
>> we are happy to help. Have a nice day :-)
>>
>> Den mandag den 22. februar 2016 kl. 23.02.42 UTC+1 skrev Daniel Beck:
>>>
>>> Hi everyone,
>>>
>>> JetBrains recently changed the rules on open-source licenses, and KK is
>>> no longer eligible to manage them.
>>>
>>> https://www.jetbrains.com/buy/opensource/?product=idea
>>>
>>> Ideally, someone else who qualifies would handle the IntelliJ IDEA
>>> licenses for the software project.
>>>
>>> Any volunteers?
>>>
>>> Daniel
>>>
>>> --
> 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/CAHOoXs3V_6RyAc4SNLR%2BS7FyeH7uuRnTS0_d6tE-%3DLCkDm9C1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: IntelliJ licenses

[Joseph P]

So I got a reply from Jetbrains and they would be willing to supply us with 
licenses expect for those that get paid to work on jenkins or sell a 
jenkins product (ie. Cloudbees). 
However they mentioned Kohsuke could still be the administrator but anyone 
could apply as long as they project lead or core committer.

Here is the emails between Jetbrains and me

---

Hello Joseph,

Our apologies for a delay with a response from our side. Seems like your me=
ssages were blocked by Spam filter.

We used to support Jenkins project in our OS Program before the change in t=
he rules. Our contact from your side has been Kohsuke Kawaguchi. To apply f=
or the OS licenses on behalf of an OS project one should be the project lea=
d or a core committer. Especially when a project is big as yours. [Here](ht=
tps://groups.google.com/forum/#!msg/jenkinsci-dev/3XRhnf8ferI/VqUvT-xtAQAJ)=
 is mentioned Kohsuke Kawaguchi is no longer eligible to manage them. Why d=
o you think so and who is the team lead now?

We look forward to your response. Should you have any further questions - w=
e are happy to help. Have a nice day!
 
---

Hi

Thanks for getting back to me

Kohsuke is still the project lead, though he works for Cloudbees, which sel=
ls enterprise grade Jenkins.

Which also exclude most of the core contributor, since they work for 
Cloudbees, from applying to the JetBrains OS license.
https://www.cloudbees.com/products

So according to a Jenkins meeting they saw the need to find a contributor 
that was not working directly for cloudbees,
That did not fall under the "Projects that are sponsored by a commercial 
company or organization, or those with employees paid to work on the 
project are not eligible"
http://meetings.jenkins-ci.org/jenkins-meeting/2016/jenkins-meeting.2016-03-30-18.00.html
http://meetings.jenkins-ci.org/jenkins-meeting/2016/jenkins-meeting.2016-03-30-18.00.log.html
http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-02-18-19.01.html
http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-02-18-19.01.log.html

And according to those meeting batmat one of Jenkins core contributor, that 
does not work for Cloudbees, were suppose to figure out the license owner 
for Jenkins.

He has regrettably been too busy from my understanding, this is where I com=
e in as a Plugin maintainer decided to take action.
https://github.com/jenkinsci/accurev-plugin

But if we could figure something out.
I would happily put it on next meeting agenda for the Jenkins project March 
1st or March 15th:
https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda

Looking forward to your response :)

/Joseph

---

Hello Joseph,

Thank you for a prompt and detailed response. Sorry for a short delay from 
my side.

I've talked to the PMM for IntelliJ IDEA. We can support Jenkins with the 
free OS licenses. 
Kohsuke Kawaguchi can still remain the administrator for your project. 
This means he can send the request and distribute the licenses. He is not 
eligible for the free OS license - that's true.

Do you wish to apply on behalf of Jenkins in general or on behalf of the 
plugins? How many licenses are needed?

We look forward to your response. Should you have any further questions - 
we are happy to help. Have a nice day :-)

Den mandag den 22. februar 2016 kl. 23.02.42 UTC+1 skrev Daniel Beck:
>
> Hi everyone, 
>
> JetBrains recently changed the rules on open-source licenses, and KK is no 
> longer eligible to manage them. 
>
> https://www.jetbrains.com/buy/opensource/?product=idea 
>
> Ideally, someone else who qualifies would handle the IntelliJ IDEA 
> licenses for the software project. 
>
> Any volunteers? 
>
> Daniel 
>
>

-- 
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/399d3e79-25ce-4df7-999f-d898431efc1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: plugins.jenkins.io cutting code blocks

[Joseph P]

it's not cutting them, check the html :)
it just doesn't know how to display code div




Den mandag den 8. maj 2017 kl. 22.19.48 UTC+2 skrev Cyrille Le Clerc:
>
> Dear all,
>
> plugins.jenkins.io seems to cut the code blocks used in Confluence pages.
> I noticed the problem with the Pipeline Maven Plugin (see screenshot 
> below).
>
>
>- Confluence page with code blocks: 
>https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Maven+Plugin
>- plugins.jenkins.io page without the code blocks: 
>https://plugins.jenkins.io/pipeline-maven
>
>
> *Is there a plan to support "{code}"  blocks and "{noformat}" blocks on 
> plugins.jenkins.io ?* I feel that these code 
> blocks are particularly important to document the usage in Jenkins 
> pipelines.
>
> Cyrille
>
>
>
>
>
>
>
> 
>
>

-- 
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/c5f199b5-cc19-4d56-a6f6-3425cd7240c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Joseph P]

I will try and get around to testing it today.

Den onsdag den 21. juni 2017 kl. 20.30.03 UTC+2 skrev Stephen Connolly:
>
> How many people have been able to try this so far?
>
> On Tue 20 Jun 2017 at 14:52, Stephen Connolly  > wrote:
>
>> If you are chomping at the bit, here are all the binaries:
>>
>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>>
>> SHA1 checksums:
>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>> 16da429f09fb585fd1d744809ee22c8d612fb62c  
>> cloudbees-bitbucket-branch-source.hpi
>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>
>> SHA256 checksums:
>> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7  
>> branch-api.hpi
>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03  
>> cloudbees-bitbucket-branch-source.hpi
>> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248  git.hpi
>> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20  
>> github-branch-source.hpi
>> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c  
>> mercurial.hpi
>> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481  
>> scm-api.hpi
>>
>> -Stephen
>>
>> On 20 June 2017 at 14:29, Stephen Connolly > > wrote:
>>
>>> OK! Here we are... testing time!
>>>
>>> These are the plugins that are being covered: (download links should be 
>>> live in an hour or two)
>>>
>>> scm-api 2.2.0-alpha-1 
>>> https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
>>> branch-api 2.0.11-alpha-1 
>>> https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
>>> git 3.4.0-alpha-1 
>>> https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
>>> mercurial 2.0-alpha-1 
>>> https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
>>> github-branch-source 2.2.0-alpha-1 
>>> https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
>>> cloudbees-bitbucket-branch-source 2.2.0-alpha-1 
>>> https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi
>>>
>>> Recommended testing procedure:
>>>
>>> 1. Set up a throw-away Jenkins running a version similar to your 
>>> production environment *with the pre-upgrade versions of the plugins 
>>> you are using*.
>>> 2. Set up ideally at least one organization folder and one standalone 
>>> multibranch project building your source code - to a first order you do not 
>>> care if the builds succeed or fail, only that the branches are found.
>>> 3. Trigger a scan / index of your organization folders and standalone 
>>> multibranch projects.
>>> 4. Wait for the queue to complete
>>> 5. Run the script in the system script console: 
>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
>>> save the output to smoke-pre-upgrade.txt
>>> 6. Upgrade the relevant plugins, restart Jenkins.
>>> 7. Run the script in the system script console: 
>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
>>> save the output to smoke-post-upgrade.txt
>>> 8. Trigger a scan / index of your organization folders and standalone 
>>> multibranch projects.
>>> 9. Wait for the queue to complete
>>> 10. Run the script in the system script console: 
>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
>>> save the output to smoke-post-rescan.txt
>>>
>>> At this point, do a diff between smoke-pre-upgrade.txt and 
>>> smoke-post-rescan.txt
>>>
>>> You are looking for three classes of difference:
>>>
>>> a. branch jobs that have been rebuilt for no reason (i.e. the revision 
>>> is the same)
>>> b. branch jobs that have disappeared for no good reason (i.e. the branch 
>>> is still present in the backing scm)
>>> c. branch jobs that have suddenly appeared for no good reason (i.e. the 
>>> branch was there before but not found) [expecting some of these for 
>>> BitBucket PRs from forks, but only after configuration updated, saved and 
>>> another rescan performed]
>>>
>>> My expectation is that nobody will have these kinds of issues.
>>>
>>> Also try out the new UI to see what you think.
>>>
>>> Please report back your testing results either way. Don't forget to 
>>> report back your UI feedback too ;-)
>>>
>>> After doing that test in a throw-away Jenkins, you can *optionally* 
>>> repeat the test on a *more* production*-like* (emphasis on being 
>>> production-like not production) instance... but this is code that has not 
>>> yet completed code review (hence -alpha-1 not -beta-1) so it is at your own 
>>> risk. There are additional issues to be aware when using more 
>>> production-like environment:
>>>
>>> a. You may 

Re: Question: Git Branch Source and the traits / behaviours

[Joseph P]

Adding discover branch trait makes a lot of sense when other traits will 
join in.
So take the migration part now.

And if your need more vertical space, just flip your monitor into 
porTrait.. pun intended. :D

Den fredag den 23. juni 2017 kl. 15.29.20 UTC+2 skrev Stephen Connolly:
>
> So before we cut a GA release of the JENKINS-43507 changes I thought it 
> might be a good idea to resolve one question.
>
> To understand the context of this, we first need to acknowledge 
> https://issues.jenkins-ci.org/browse/JENKINS-33445 
>
> There are some users who would like the *Branch* source to also return 
> *Tag*s
>
> Now in a sense this is perfectly reasonable. I think there are some things 
> that need to be ironed out first before we can enable discovery of tags. To 
> give an example, you probably do not want to trigger a build storm of all 
> your old tags if you recreate the multibranch project... in fact if you 
> were using the pipeline to deploy to production when it detects the build 
> is on a tag... this would be a very bad plan.
>
> So before we enable the discovery of tags, we need to solve some 
> problems...
>
> But now, let's take it as read that we have solved those problems... this 
> means that the Git source could be configured into one of four possible 
> states:
>
>1. Stupid state: discovers nothing
>2. Branches only
>3. Tags only
>4. Both branches and tags
>
> The natural way, given the conventions in the GitHub and Bitbucket 
> behaviours / traits is that we would have one behaviour for discovering 
> branches and one for discovering tags...
>
> Well right now GitSCMSource has neither, it just discovers branches always.
>
> That means we would have to grandfather in the discovery of branches.
>
> So if we read a GitSCMSource from disk and it has no discovery traits we 
> would then assume it is not configured thus by the user intent on it being 
> in the stupid state... rather they want to discover branches... the 
> constructor would have to always add the discovery trait from the start and 
> people would need to configure away branch discovery... it seems like a bit 
> of a mess to me.
>
> So what I am thinking is that we just add a Git specific "Discover 
> Branches" behaviour to the plugin before the 3.4.0 GA release. The legacy 
> constructor would inject it as would readResolve and the UI would always 
> propose it when creating via the UI
>
> It does mean that the UI will always start with Discover Branches present 
> (taking up vertical space that is effectively useless until we get Discover 
> Tags) but I think it will make the addition of Discover Tags much less risky
>
> WDYT?
>
> -Stephen
>

-- 
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/c76e7027-5bbc-42f4-9ee6-bc2fa1eed920%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Joseph P]

This UI is a lot better! Looking forward to the massive upgrade!

Just wondering with the refactoring will it be possible for PRs to rebuild 
when changes to target branch is notified?
When the option for Merge PR with Target branch is selected.

That would be AWESOME!

Den fredag den 23. juni 2017 kl. 15.32.54 UTC+2 skrev Stephen Connolly:
>
> How do you find the new UI compared with the previous one?
>
> On 23 June 2017 at 14:18, Joseph P <jose...@gmail.com > 
> wrote:
>
>> Upgrade on "prod like" went smooth :)
>> Could we move the question for behaviours closer to the behaviours text?
>>
>>
>> <https://lh3.googleusercontent.com/-6ZYEdujPA6I/WU0Ut447ZXI/Bro/MO4YEevB3rAPfGAWqoJnqkqruXW26SBFACLcBGAs/s1600/shot_170623_151622.png>
>>
>>
>>
>>
>> Den torsdag den 22. juni 2017 kl. 08.10.41 UTC+2 skrev Joseph P:
>>>
>>> I will try and get around to testing it today.
>>>
>>> Den onsdag den 21. juni 2017 kl. 20.30.03 UTC+2 skrev Stephen Connolly:
>>>>
>>>> How many people have been able to try this so far?
>>>>
>>>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <stephen.al...@gmail.com> 
>>>> wrote:
>>>>
>>>>> If you are chomping at the bit, here are all the binaries:
>>>>>
>>>>>
>>>>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>>>>>
>>>>> SHA1 checksums:
>>>>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>>>>> 16da429f09fb585fd1d744809ee22c8d612fb62c  
>>>>> cloudbees-bitbucket-branch-source.hpi
>>>>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>>>>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>>>>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>>>>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>>>>
>>>>> SHA256 checksums:
>>>>> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7  
>>>>> branch-api.hpi
>>>>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03  
>>>>> cloudbees-bitbucket-branch-source.hpi
>>>>> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248  
>>>>> git.hpi
>>>>> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20  
>>>>> github-branch-source.hpi
>>>>> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c  
>>>>> mercurial.hpi
>>>>> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481  
>>>>> scm-api.hpi
>>>>>
>>>>> -Stephen
>>>>>
>>>>> On 20 June 2017 at 14:29, Stephen Connolly <stephen.al...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> OK! Here we are... testing time!
>>>>>>
>>>>>> These are the plugins that are being covered: (download links should 
>>>>>> be live in an hour or two)
>>>>>>
>>>>>> scm-api 2.2.0-alpha-1 
>>>>>> https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
>>>>>> branch-api 2.0.11-alpha-1 
>>>>>> https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
>>>>>> git 3.4.0-alpha-1 
>>>>>> https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
>>>>>> mercurial 2.0-alpha-1 
>>>>>> https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
>>>>>> github-branch-source 2.2.0-alpha-1 
>>>>>> https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
>>>>>> cloudbees-bitbucket-branch-source 2.2.0-alpha-1 
>>>>>> https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi
>>>>>>
>>>>>> Recommended testing procedure:
>>>>>>
>>>>>> 1. Set up a throw-away Jenkins running a version similar to your 
>>>>>> production environment *with the pre-upgrade versions of the plugins 
>>>>>> you are using*.
>>>>>> 2. Set up ideally at least one organization folder and one standalone 
>>>>>> multibranch project building your source code - to a first order you do 
>>>>>

Re: GitHub and Bitbucket branch source UI refactoring

[Joseph P]

Upgrade on "prod like" went smooth :)
Could we move the question for behaviours closer to the behaviours text?

<https://lh3.googleusercontent.com/-6ZYEdujPA6I/WU0Ut447ZXI/Bro/MO4YEevB3rAPfGAWqoJnqkqruXW26SBFACLcBGAs/s1600/shot_170623_151622.png>




Den torsdag den 22. juni 2017 kl. 08.10.41 UTC+2 skrev Joseph P:
>
> I will try and get around to testing it today.
>
> Den onsdag den 21. juni 2017 kl. 20.30.03 UTC+2 skrev Stephen Connolly:
>>
>> How many people have been able to try this so far?
>>
>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <stephen.al...@gmail.com> 
>> wrote:
>>
>>> If you are chomping at the bit, here are all the binaries:
>>>
>>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>>>
>>> SHA1 checksums:
>>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>>> 16da429f09fb585fd1d744809ee22c8d612fb62c  
>>> cloudbees-bitbucket-branch-source.hpi
>>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>>
>>> SHA256 checksums:
>>> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7  
>>> branch-api.hpi
>>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03  
>>> cloudbees-bitbucket-branch-source.hpi
>>> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248  git.hpi
>>> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20  
>>> github-branch-source.hpi
>>> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c  
>>> mercurial.hpi
>>> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481  
>>> scm-api.hpi
>>>
>>> -Stephen
>>>
>>> On 20 June 2017 at 14:29, Stephen Connolly <stephen.al...@gmail.com> 
>>> wrote:
>>>
>>>> OK! Here we are... testing time!
>>>>
>>>> These are the plugins that are being covered: (download links should be 
>>>> live in an hour or two)
>>>>
>>>> scm-api 2.2.0-alpha-1 
>>>> https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
>>>> branch-api 2.0.11-alpha-1 
>>>> https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
>>>> git 3.4.0-alpha-1 
>>>> https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
>>>> mercurial 2.0-alpha-1 
>>>> https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
>>>> github-branch-source 2.2.0-alpha-1 
>>>> https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
>>>> cloudbees-bitbucket-branch-source 2.2.0-alpha-1 
>>>> https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi
>>>>
>>>> Recommended testing procedure:
>>>>
>>>> 1. Set up a throw-away Jenkins running a version similar to your 
>>>> production environment *with the pre-upgrade versions of the plugins 
>>>> you are using*.
>>>> 2. Set up ideally at least one organization folder and one standalone 
>>>> multibranch project building your source code - to a first order you do 
>>>> not 
>>>> care if the builds succeed or fail, only that the branches are found.
>>>> 3. Trigger a scan / index of your organization folders and standalone 
>>>> multibranch projects.
>>>> 4. Wait for the queue to complete
>>>> 5. Run the script in the system script console: 
>>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
>>>> save the output to smoke-pre-upgrade.txt
>>>> 6. Upgrade the relevant plugins, restart Jenkins.
>>>> 7. Run the script in the system script console: 
>>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
>>>> save the output to smoke-post-upgrade.txt
>>>> 8. Trigger a scan / index of your organization folders and standalone 
>>>> multibranch projects.
>>>> 9. Wait for the queue to complete
>>>> 10. Run the script in the system script console: 
>>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
>>>> save the output to smoke-post-rescan.txt
&g

Re: GitHub and Bitbucket branch source UI refactoring

[Joseph P]

I'd love to get the bitbucket going, I really want merged PRs TODAY :D

Den fredag den 16. juni 2017 kl. 20.19.12 UTC+2 skrev Stephen Connolly:
>
> Just a quick status update.
>
> In final stages of this work now. Bobby is being a superstar and reviewing 
> my 13k LoC change on the Bitbucket branch source - brings lots of feature 
> parity with GitHub and adds the configuration ability of the pure Git 
> branch source
>
> I am finalising the GitHub Branch Source changes... likely to be another 
> big PR
>
> Then there's a 5k LoC change in the Git plugin
>
> Plan is to try and get all merged next week and cut a beta
>
> I'll be looking for people to help test at that stage.
>
> Please respond if you think you can help (lots of bugs fixed as a side 
> effect of the refactoring - it makes things more easy to test => I found 
> and fixed bugs)
> -- 
> Sent from my phone
>

-- 
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/67c8f0cd-0797-4935-9164-3b45dde68721%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Joseph P]

BB server :) so all good

Den lørdag den 17. juni 2017 kl. 00.52.07 UTC+2 skrev Stephen Connolly:
>
>
> On Fri 16 Jun 2017 at 23:32, Joseph P <jose...@gmail.com > 
> wrote:
>
>> I'd love to get the bitbucket going, I really want merged PRs TODAY :D
>>
>
> If you are on BB server you should be fine
>
> If you are on BB cloud, unless you set permissions up when forking, only 
> PRs from forks in the team account and PRs from the origin repo will be 
> built.
>
> You can choose merge, head or both
>
>
>>
>> Den fredag den 16. juni 2017 kl. 20.19.12 UTC+2 skrev Stephen Connolly:
>>>
>>> Just a quick status update.
>>>
>>> In final stages of this work now. Bobby is being a superstar and 
>>> reviewing my 13k LoC change on the Bitbucket branch source - brings lots of 
>>> feature parity with GitHub and adds the configuration ability of the pure 
>>> Git branch source
>>>
>>> I am finalising the GitHub Branch Source changes... likely to be another 
>>> big PR
>>>
>>> Then there's a 5k LoC change in the Git plugin
>>>
>>> Plan is to try and get all merged next week and cut a beta
>>>
>>> I'll be looking for people to help test at that stage.
>>>
>>> Please respond if you think you can help (lots of bugs fixed as a side 
>>> effect of the refactoring - it makes things more easy to test => I found 
>>> and fixed bugs)
>>> -- 
>>> Sent from my phone
>>>
>> -- 
>> 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/67c8f0cd-0797-4935-9164-3b45dde68721%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/67c8f0cd-0797-4935-9164-3b45dde68721%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Sent from my phone
>

-- 
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/93ff87a3-fed4-4b14-8476-d870c9fffa70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: IntelliJ IDEA license

[Joseph P]

I'd like to request one, maintainer atm for 
https://github.com/jenkinsci/accurev-plugin/

Den fredag den 5. maj 2017 kl. 16.28.17 UTC+2 skrev Kohsuke Kawaguchi:
>
> Thank to Joseph P and other people's persistence, we got the open-source 
> license from JetBrains. Thanks everyone and JetBrains for their support.
>
> Things have changed a bit since the last time we did this. Now, I don't 
> get one key that I can hand out, but rather I get 10 floating licenses. 
> There's also additional restrictions on the license:
>
> > You do not provide any paid support, consulting or training services for 
> your OS project,
> > and you do not distribute paid versions of your OS software. 
> Contributors who are
> > paid to work on the project are not eligible.
>
> If you are eligible and want to use the license, please reply to this 
> email with some description of what you do in the project (plugins you work 
> on, etc.) I'll come back in a week, tally the responses and figure out who 
> to give out the licenses to.
> -- 
> 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/374aa3bd-5de2-43a8-89ff-25cea18ebfd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: IntelliJ IDEA license

[Joseph P]

I'd like to request one :)

Den fredag den 5. maj 2017 kl. 16.28.17 UTC+2 skrev Kohsuke Kawaguchi:
>
> Thank to Joseph P and other people's persistence, we got the open-source 
> license from JetBrains. Thanks everyone and JetBrains for their support.
>
> Things have changed a bit since the last time we did this. Now, I don't 
> get one key that I can hand out, but rather I get 10 floating licenses. 
> There's also additional restrictions on the license:
>
> > You do not provide any paid support, consulting or training services for 
> your OS project,
> > and you do not distribute paid versions of your OS software. 
> Contributors who are
> > paid to work on the project are not eligible.
>
> If you are eligible and want to use the license, please reply to this 
> email with some description of what you do in the project (plugins you work 
> on, etc.) I'll come back in a week, tally the responses and figure out who 
> to give out the licenses to.
> -- 
> 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/824a87df-6101-4edb-a2b1-1bb879bbb157%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Team/repo associations cleanup: You may have lost some permissions today

[Joseph P]

Don't know why I was on so many repos, that I have never touched when 
looking that INFRA-1421 

In any case, I lost my accurev-plugin admin rights a couple of months ago, 
could I have it back? 

Den fredag den 1. december 2017 kl. 07.55.56 UTC+1 skrev Daniel Beck:
>
>
> > On 28. Nov 2017, at 14:59, Daniel Beck  
> wrote: 
> > 
> > These three repos have so many team associations that they break the 
> GitHub UI (90-130 teams each), so I'm in contact with GitHub support to fix 
> them: 
> > emmacoveragecolumn-plugin 
> > matrix-reloaded-plugin 
> > selenium-tests 
>
> GitHub support fixed whatever broke the UI for this, and roughly 350 mouse 
> clicks later (still quicker than writing a script for this), some other org 
> members may have lost access to these repos, too. 
>
> Added these repos and potentially impacted users to INFRA-1421. 
>
>

-- 
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/c129f984-2946-4aa6-9b16-8f87027f26c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Selecting Delegates for the first wave of JEPs

[Joseph P]

Nicolas and Ewelina, please keep up the good work. Looking forward to 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/9ee6ee90-bdd7-485a-b924-f86ebbab4b6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: My video tutorial series on plugin dev for Jenkins at Apache

[Joseph P]

Stephen awesome vids :)

Is this another attempt at getting me to implement SCM Source for Accurev? 
:P
I'll definitely keep a eye out for these videos <3 

Once work allows me to focus on Accurev Plugin, sure.

Den mandag den 30. oktober 2017 kl. 19.56.36 UTC+1 skrev Stephen Connolly:
>
> I’ve been recording a series of (approx 20min) videos focused on getting 
> better usage of Jenkins at Apache.
>
> The first episode is live.
>
> https://youtu.be/W8BRtJmq_2Y
>
> The second is a “double episode” as I wanted to get to an MVP.
>
> If you are interested in plugin development you might like the series 
> -- 
> Sent from my phone
>

-- 
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/c859b056-f36c-400a-b40d-787c18dc0821%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins World 2018] - Graders wanted

[Joseph P]

Managed to grade everything . This is going to be a great event! 

fredag den 13. april 2018 kl. 18.09.08 UTC+2 skrev alytong13:
>
> Hello,
>
> I am looking for additional graders to join the Jenkins World (JW) review 
> committee to help grade Jenkins World 2018 SF & EU proposals.
>
> Time commitment expected:
>
>- JW SF: 137 Jenkins submissions.
>- JW EU: 76 Jenkins submissions at the moment but most likely will 
>increase after close of CFP this Sunday.
>
> What you get:
>
>- Pix, bio on the Committee webpage (part of JW website)
>- JW swag
>- Free conference ticket to JW
>
> Criteria:
>
>- You love to read and has a keen mind for the latest and greatest, 
>trendy technical topics
>
> Pls respond to this thread if you're interested.
>
> BR,
> alyssa 
>
>

-- 
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/a30d5a25-9db0-4157-a6b0-ea3b74f7f1c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Looking for maintainer for Accurev Plugin

[Joseph P]

Hi Jenkins Developers

I no longer work for a company who is using AccuRev so my interest in the
plugin is somewhat lost and my current company does not want me to spend
bandwidth on the plugin. So I have put the plugin up for adoption.

I'll will do my best to maintain and release any contribution until a
maintainer is found.

Best regards
Joseph Petersen

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

Re: using Kotlin inside Jenkins Plugins

[Joseph P]

With that in mind, I will go ahead with creating 
a kotlin-stdlib-1-api-plugin to avoid plugins loading the incorrect major 
version of Kotlin.

Den torsdag den 18. januar 2018 kl. 14.57.14 UTC+1 skrev Joseph P:
>
> I might have misread it: 
>
> Experimental features are not backwards compatible with different minor 
> versions.
> However for the JVM
>
> Compatibility guarantees for Kotlin releases 
> <https://kotlinlang.org/docs/reference/compatibility.html#compatibility-guarantees-for-kotlin-releases>
>
> Kotlin for JVM:
>
>- patch version updates (e.g. 1.1.X) are fully compatible;
>- minor version updates (e.g. 1.X) are backwards compatible.
>
>
> Den torsdag den 18. januar 2018 kl. 14.54.31 UTC+1 skrev Joseph P:
>>
>> This should cover the compatibility question, 
>> https://kotlinlang.org/docs/reference/compatibility.html, seems like we 
>> would have to create a plugin for each 1.X version  or we could 
>> probably do something with the compatibility modes
>>
>> Seems gradle with gradle-jpi-plugin using the Kotlin Gradle DSL or groovy 
>> is the best choice then sadly gradle 4.x has issue with sezpoz 
>> <https://github.com/jglick/sezpoz> when needing to process Jenkins 
>> annotation like @Extension and so on.
>> Reported here https://github.com/jglick/sezpoz/issues/12
>> Possible fix/workaround here: 
>> https://github.com/jenkinsci/gradle-jpi-plugin/pull/97
>>
>> Den torsdag den 18. januar 2018 kl. 12.44.31 UTC+1 skrev Robert Sandell:
>>>
>>> Does Kotlin have a deprecation/compatibility policy that is compatible 
>>> with Jenkins? i.e. would a plugin compiled and tested against kotlin 1.3 
>>> work with kotlin 2,3,4 etc?
>>>
>>> If that is the case then I think a kotlin-stdlib-plugin would be the 
>>> best choice.
>>>
>>> regarding the build step, we haven't even added the groovy build step to 
>>> it yet so I don't know :)
>>>
>>> /B
>>>
>>> 2018-01-17 20:02 GMT+01:00 Joseph P <jose...@gmail.com>:
>>>
>>>> Also there's the question of should Kotlin build steps be added to 
>>>> parent pom?
>>>> https://github.com/jenkinsci/plugin-pom
>>>>
>>>> Den onsdag den 17. januar 2018 kl. 19.56.44 UTC+1 skrev Joseph P:
>>>>>
>>>>> Hey there,
>>>>>
>>>>> We need to solve a problem for those wanting to use Kotlin 
>>>>> "stdlib-jre8"
>>>>> I see two solutions
>>>>>
>>>>>1. Create a Jenkins Kotlin plugin for Kotlin standard library.
>>>>>2. Each plugin that uses Kotlin standard library can set plugin 
>>>>>first class loader to true.
>>>>>
>>>>> Looking at existing Kotlin plugins.
>>>>>
>>>>> Some decided for plugin first class loader.
>>>>> https://github.com/jenkinsci/doktor-plugin/blob/master/build.gradle.kts
>>>>>
>>>>> https://github.com/casz/accurev-client-plugin/blob/master/build.gradle.kts
>>>>>
>>>>> https://github.com/SimpleFinance/jenkins-firebase-test-plugin/blob/master/build.gradle.kts
>>>>>
>>>>> others are living a dangerous life:
>>>>>
>>>>> https://github.com/michaelsiepmann/Jenkinsstate-Plugin/blob/master/build.gradle
>>>>>
>>>>> https://github.com/koral--/android-gradle-jenkins-plugin/blob/master/plugin/build.gradle
>>>>>
>>>>> https://github.com/aaron-vaz/github-release-helper-plugin/blob/master/build.gradle.kts
>>>>>
>>>>> This would hopefully help others in adopting Kotlin inside the Jenkins 
>>>>> plugin community.
>>>>>
>>>>> Best regards
>>>>> Joseph
>>>>>
>>>> -- 
>>>> 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/51d5e829-d4a8-4e86-9393-47ef74088714%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/51d5e829-d4a8-4e86-9393-47ef74088714%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> -- 
>>> *Robert Sandell*
>>> Software Engineer
>>> CloudBees, Inc.
>>> [image: CloudBees-Logo.png] <http://www.cloudbees.com/>
>>> E: rsan...@cloudbees.com
>>> Twitter: robert_sandell
>>>
>>

-- 
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/85d9ebcc-fefc-4b2f-a723-232ad1a8bbf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: using Kotlin inside Jenkins Plugins

[Joseph P]

This should cover the compatibility question, 
https://kotlinlang.org/docs/reference/compatibility.html, seems like we 
would have to create a plugin for each 1.X version  or we could 
probably do something with the compatibility modes

Seems gradle with gradle-jpi-plugin using the Kotlin Gradle DSL or groovy 
is the best choice then sadly gradle 4.x has issue with sezpoz 
<https://github.com/jglick/sezpoz> when needing to process Jenkins 
annotation like @Extension and so on.
Reported here https://github.com/jglick/sezpoz/issues/12
Possible fix/workaround 
here: https://github.com/jenkinsci/gradle-jpi-plugin/pull/97

Den torsdag den 18. januar 2018 kl. 12.44.31 UTC+1 skrev Robert Sandell:
>
> Does Kotlin have a deprecation/compatibility policy that is compatible 
> with Jenkins? i.e. would a plugin compiled and tested against kotlin 1.3 
> work with kotlin 2,3,4 etc?
>
> If that is the case then I think a kotlin-stdlib-plugin would be the best 
> choice.
>
> regarding the build step, we haven't even added the groovy build step to 
> it yet so I don't know :)
>
> /B
>
> 2018-01-17 20:02 GMT+01:00 Joseph P <jose...@gmail.com >:
>
>> Also there's the question of should Kotlin build steps be added to parent 
>> pom?
>> https://github.com/jenkinsci/plugin-pom
>>
>> Den onsdag den 17. januar 2018 kl. 19.56.44 UTC+1 skrev Joseph P:
>>>
>>> Hey there,
>>>
>>> We need to solve a problem for those wanting to use Kotlin "stdlib-jre8"
>>> I see two solutions
>>>
>>>1. Create a Jenkins Kotlin plugin for Kotlin standard library.
>>>2. Each plugin that uses Kotlin standard library can set plugin 
>>>first class loader to true.
>>>
>>> Looking at existing Kotlin plugins.
>>>
>>> Some decided for plugin first class loader.
>>> https://github.com/jenkinsci/doktor-plugin/blob/master/build.gradle.kts
>>>
>>> https://github.com/casz/accurev-client-plugin/blob/master/build.gradle.kts
>>>
>>> https://github.com/SimpleFinance/jenkins-firebase-test-plugin/blob/master/build.gradle.kts
>>>
>>> others are living a dangerous life:
>>>
>>> https://github.com/michaelsiepmann/Jenkinsstate-Plugin/blob/master/build.gradle
>>>
>>> https://github.com/koral--/android-gradle-jenkins-plugin/blob/master/plugin/build.gradle
>>>
>>> https://github.com/aaron-vaz/github-release-helper-plugin/blob/master/build.gradle.kts
>>>
>>> This would hopefully help others in adopting Kotlin inside the Jenkins 
>>> plugin community.
>>>
>>> Best regards
>>> Joseph
>>>
>> -- 
>> 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/51d5e829-d4a8-4e86-9393-47ef74088714%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/51d5e829-d4a8-4e86-9393-47ef74088714%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> *Robert Sandell*
> Software Engineer
> CloudBees, Inc.
> [image: CloudBees-Logo.png] <http://www.cloudbees.com/>
> E: rsan...@cloudbees.com 
> Twitter: robert_sandell
>

-- 
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/be2c88f3-36b4-43bc-bb8b-718b67dc80f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

using Kotlin inside Jenkins Plugins

[Joseph P]

Hey there,

We need to solve a problem for those wanting to use Kotlin "stdlib-jre8"
I see two solutions

   1. Create a Jenkins Kotlin plugin for Kotlin standard library.
   2. Each plugin that uses Kotlin standard library can set plugin first 
   class loader to true.

Looking at existing Kotlin plugins.

Some decided for plugin first class loader.
https://github.com/jenkinsci/doktor-plugin/blob/master/build.gradle.kts
https://github.com/casz/accurev-client-plugin/blob/master/build.gradle.kts
https://github.com/SimpleFinance/jenkins-firebase-test-plugin/blob/master/build.gradle.kts

others are living a dangerous life:
https://github.com/michaelsiepmann/Jenkinsstate-Plugin/blob/master/build.gradle
https://github.com/koral--/android-gradle-jenkins-plugin/blob/master/plugin/build.gradle
https://github.com/aaron-vaz/github-release-helper-plugin/blob/master/build.gradle.kts

This would hopefully help others in adopting Kotlin inside the Jenkins 
plugin community.

Best regards
Joseph

-- 
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/7baf00f9-7cae-4806-b31b-bd38fce79dcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: using Kotlin inside Jenkins Plugins

[Joseph P]

Also there's the question of should Kotlin build steps be added to parent 
pom?
https://github.com/jenkinsci/plugin-pom

Den onsdag den 17. januar 2018 kl. 19.56.44 UTC+1 skrev Joseph P:
>
> Hey there,
>
> We need to solve a problem for those wanting to use Kotlin "stdlib-jre8"
> I see two solutions
>
>1. Create a Jenkins Kotlin plugin for Kotlin standard library.
>2. Each plugin that uses Kotlin standard library can set plugin first 
>class loader to true.
>
> Looking at existing Kotlin plugins.
>
> Some decided for plugin first class loader.
> https://github.com/jenkinsci/doktor-plugin/blob/master/build.gradle.kts
> https://github.com/casz/accurev-client-plugin/blob/master/build.gradle.kts
>
> https://github.com/SimpleFinance/jenkins-firebase-test-plugin/blob/master/build.gradle.kts
>
> others are living a dangerous life:
>
> https://github.com/michaelsiepmann/Jenkinsstate-Plugin/blob/master/build.gradle
>
> https://github.com/koral--/android-gradle-jenkins-plugin/blob/master/plugin/build.gradle
>
> https://github.com/aaron-vaz/github-release-helper-plugin/blob/master/build.gradle.kts
>
> This would hopefully help others in adopting Kotlin inside the Jenkins 
> plugin community.
>
> Best regards
> Joseph
>

-- 
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/51d5e829-d4a8-4e86-9393-47ef74088714%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: using Kotlin inside Jenkins Plugins

[Joseph P]

Fair enough, if anything I would be happy to create a custom parent pom for 
other Kotlin based Jenkins plugins to use.

Already had to create a custom parent POM for the plugin to support 
Kotlin's split architecture of their standard library in jre7 and jre8

Den torsdag den 18. januar 2018 kl. 18.58.22 UTC+1 skrev Jesse Glick:
>
> On Wed, Jan 17, 2018 at 2:02 PM, Joseph P <jose...@gmail.com > 
> wrote: 
> > should Kotlin build steps be added to parent 
> > pom? 
>
> Please, no. I in fact have a to-do item to *remove* the support for 
> Groovy compilation from the parent POM. Plugin maintainers who wish to 
> use alternative languages or build technologies are on their own. 
>
> In general, core maintainers have had poor experiences with plugins 
> using alternative JVM languages. It seems neat on the face of it, but 
> turns into a serious maintenance burden for the ecosystem as a whole. 
> In particular there have been multiple recent disasters with 
> (J)Ruby-based plugins and I hope to find time to propose deprecating 
> the entire runtime system and rewriting in Java the handful of popular 
> plugins using 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/c354b066-9623-462d-90f4-ec254dcdf86a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: using Kotlin inside Jenkins Plugins

[Joseph P]

I might have misread it: 

Experimental features are not backwards compatible with different minor 
versions.
However for the JVM

Compatibility guarantees for Kotlin releases 
<https://kotlinlang.org/docs/reference/compatibility.html#compatibility-guarantees-for-kotlin-releases>

Kotlin for JVM:

   - patch version updates (e.g. 1.1.X) are fully compatible;
   - minor version updates (e.g. 1.X) are backwards compatible.


Den torsdag den 18. januar 2018 kl. 14.54.31 UTC+1 skrev Joseph P:
>
> This should cover the compatibility question, 
> https://kotlinlang.org/docs/reference/compatibility.html, seems like we 
> would have to create a plugin for each 1.X version  or we could 
> probably do something with the compatibility modes
>
> Seems gradle with gradle-jpi-plugin using the Kotlin Gradle DSL or groovy 
> is the best choice then sadly gradle 4.x has issue with sezpoz 
> <https://github.com/jglick/sezpoz> when needing to process Jenkins 
> annotation like @Extension and so on.
> Reported here https://github.com/jglick/sezpoz/issues/12
> Possible fix/workaround here: 
> https://github.com/jenkinsci/gradle-jpi-plugin/pull/97
>
> Den torsdag den 18. januar 2018 kl. 12.44.31 UTC+1 skrev Robert Sandell:
>>
>> Does Kotlin have a deprecation/compatibility policy that is compatible 
>> with Jenkins? i.e. would a plugin compiled and tested against kotlin 1.3 
>> work with kotlin 2,3,4 etc?
>>
>> If that is the case then I think a kotlin-stdlib-plugin would be the best 
>> choice.
>>
>> regarding the build step, we haven't even added the groovy build step to 
>> it yet so I don't know :)
>>
>> /B
>>
>> 2018-01-17 20:02 GMT+01:00 Joseph P <jose...@gmail.com>:
>>
>>> Also there's the question of should Kotlin build steps be added to 
>>> parent pom?
>>> https://github.com/jenkinsci/plugin-pom
>>>
>>> Den onsdag den 17. januar 2018 kl. 19.56.44 UTC+1 skrev Joseph P:
>>>>
>>>> Hey there,
>>>>
>>>> We need to solve a problem for those wanting to use Kotlin "stdlib-jre8"
>>>> I see two solutions
>>>>
>>>>1. Create a Jenkins Kotlin plugin for Kotlin standard library.
>>>>2. Each plugin that uses Kotlin standard library can set plugin 
>>>>first class loader to true.
>>>>
>>>> Looking at existing Kotlin plugins.
>>>>
>>>> Some decided for plugin first class loader.
>>>> https://github.com/jenkinsci/doktor-plugin/blob/master/build.gradle.kts
>>>>
>>>> https://github.com/casz/accurev-client-plugin/blob/master/build.gradle.kts
>>>>
>>>> https://github.com/SimpleFinance/jenkins-firebase-test-plugin/blob/master/build.gradle.kts
>>>>
>>>> others are living a dangerous life:
>>>>
>>>> https://github.com/michaelsiepmann/Jenkinsstate-Plugin/blob/master/build.gradle
>>>>
>>>> https://github.com/koral--/android-gradle-jenkins-plugin/blob/master/plugin/build.gradle
>>>>
>>>> https://github.com/aaron-vaz/github-release-helper-plugin/blob/master/build.gradle.kts
>>>>
>>>> This would hopefully help others in adopting Kotlin inside the Jenkins 
>>>> plugin community.
>>>>
>>>> Best regards
>>>> Joseph
>>>>
>>> -- 
>>> 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/51d5e829-d4a8-4e86-9393-47ef74088714%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/51d5e829-d4a8-4e86-9393-47ef74088714%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> *Robert Sandell*
>> Software Engineer
>> CloudBees, Inc.
>> [image: CloudBees-Logo.png] <http://www.cloudbees.com/>
>> E: rsan...@cloudbees.com
>> Twitter: robert_sandell
>>
>

-- 
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/3097082f-44f1-4252-9da0-051513eaa666%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Joseph P]

Hi Andrei 

A good place to start is by reading the plugin 
tutorial https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial
Or by looking at Jenkins org at Github, here is a simple search for "job" 
https://github.com/search?q=org%3Ajenkinsci+language%3Ajava+job
To see similar job plugins

/Joseph

Den torsdag den 15. februar 2018 kl. 01.43.04 UTC+1 skrev Andrei Vînătoru:
>
> Hello Everyone,
>
> My name is Andrei Vinatoru, and I am currently in the 4th year at the 
> Faculty of Automatic Control and Computer Science, at Politehnica Univerity 
> of Bucharest, Romania. 
> My interests include Java, Continuous Integration, Automation, C, C++, 
> Operating Systems and Networking.
>
> I am familiar with Jenkins, because I worked with it during an internship 
> last summer, and I think this is a good opportunity for me to learn about 
> working on an open-source project and learn more about Jenkins.
> This is my github profile: https://github.com/hntr94 and this is my 
> LinkedIn profile: 
> https://www.linkedin.com/in/andrei-v%C3%AEn%C4%83toru-36b88363/.
>
> The project that sounds interesting to me is Simple Pull-Request Job 
> Plugin.
> I do not have many ideas about how to start, and I hope we can discuss 
> some starting points and get some advice.
>
> Thank you,
> Andrei Vinatoru
>

-- 
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/92a83b78-2bed-45c6-bcfd-b593bef52ea1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Joseph P]

https://jenkins.io/projects/gsoc/gsoc2018-project-ideas/#simple-pull-request-job-plugin
The idea is to create a YAML file similar to Travis' YAML file but it could 
properly be extending that plugin since the infrastructure for being a 
Github bot is already there :)

Den torsdag den 15. februar 2018 kl. 10.15.46 UTC+1 skrev mvala:
>
>
> > The project that sounds interesting to me is Simple Pull-Request Job 
> Plugin. 
> > I do not have many ideas about how to start, and I hope we can discuss 
> some 
> > starting points and get some advice. 
>
> What will this plugin do? Is it something like this 
> https://plugins.jenkins.io/ghprb ? 
>
> -- 
> Michal Vala 
> OpenJDK QE 
> Red Hat Czech 
>

-- 
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/f662eb6d-c82c-4c11-9b61-306b0b70ae33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JENKINS-52868] - Fixing Windows installer OOTB experience on 64-bit platforms

[Joseph P]

I suggest you setup automatic update (AU) that is run as part of a 
jenkinsfile build stage.

See 
https://github.com/chocolatey/chocolatey-coreteampackages/tree/master/automatic/apache-httpd
 
as an example how to package a service and using AU.
AU allows for parsing a website parsing JSON, XML or HTML and automatically 
update chocolatey package and deploy it if any changes.

fredag den 3. august 2018 kl. 16.26.52 UTC+2 skrev Oleg Nenashev:
>
> Would we also consider an option to add a "chocolatey" install package for 
>> Jenkins?  I'm not a chocolatey user, but have seen increasing interest in 
>> it as a package manager for Windows.
>
>
> +1 though I am not sure how well it works with services
>   
>
> On Fri, Aug 3, 2018 at 4:18 PM, Slide > 
> wrote:
>
>> Chocolatey would be great! 
>>
>>
>> On Fri, Aug 3, 2018, 06:58 Mark Waite > 
>> wrote:
>>
>>> On Fri, Aug 3, 2018 at 4:19 AM Oleg Nenashev >> > wrote:
>>>
 Hi all,

 I am looking for feedback regarding the 32/64bit support in Windows 
 installers. Currently we offer only a single Windows package for 32 bits 
 in 
 https://jenkins.io/download/, but there are known issues when 32bit 
 Java is used on 64bit machines. This is tracked as JENKINS-52868 
 . 

 Fir example, WinP (and hence the core) cannot terminate processes 
 correctly: https://github.com/kohsuke/winp#platform-support. 
  In the current 
 Windows installer is bogus OOTB. Once a user installs Jenkins on a 64bit 
 machine without Java, he/she gets a configuration which will not work on 
 the machine by default. All process termination attempts while aborting 
 builds will fail and lead to runaway processes. There were several reports 
 about that before, JENKINS-52865 
  is there recent 
 one.

 There are other issues, e.g. Jenkins is being always installed to 
 "Program Files (x86)", which is quite unexpected for 64bit systems

 I see the following options:

- Offer separate packaging for 32bit and 64bit versions
   - It is a non-breaking option for users, but it will require to 
   modify the current Jenkins release flows
   

>>> This is my preferred option with regard to installer packaging.  It 
>>> preserves 32 bit delivery for those attached to 32 bit and adds 64 bit 
>>> delivery for the vast majority of users.
>>>
>>> Windows Server versions since 2008 R2 have only been provided as 64 bit 
>>> versions. 
>>>

- 
- Deprecate 32bit packaging and ship 64bit only
   - I believe that the most of the Jenkins users have already 
   moved masters to 64bit setups (proof?). 4GB RAM limit may be a good 
   justification for that, if there is no platform tweaks used in JVM
   - Even if the packaging is deprecated, Jenkins will be still 
   installable via WAR and updateable via self-update feature offered 
 in the 
   Windows lifecycle
   
 I am also fine with this alternative.  The process memory limits of 32 
>>> bit processes make 32 bit Jenkins masters much less interesting to me. 
>>>
>>>
- Remove Java from Windows packaging at all, update documentation
   - This option may have extra merit, because Jenkins users won't 
   depend on the Java version package in Jenkins. And we also will need 
 less 
   resources to keep this dependency up-to-date
   - It may have even more sense once Oracle stops shipping OpenJDK 
   8 to community users (see JEP-211 
    about 
   Java support)

 I think that "remove Java from Windows packaging" makes sense no matter 
>>> which option is chosen.
>>>

- Remove Windows Installer at all, eh?
   - It is not that bad, because Jenkins has option to be installed 
   as service in Web UI. But this option works only if the Jenkins 
 process is 
   launched as an Administrator
   
 I would like to discuss this options in this thread and at the one of 
 the next Platform SIG  meetings 
 which has been created recently. Then the change will likely require a 
 JEP. 
 Please let me know what you think.


>>> I'd love to participate in those discussions.
>>>
>>> Would we also consider an option to add a "chocolatey" install package 
>>> for Jenkins?  I'm not a chocolatey user, but have seen increasing interest 
>>> in it as a package manager for Windows.
>>>  
>>>
 Thanks in advance,
 Oleg

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and 

Re: Optional automated source code formatting - prep for JEP

[Joseph P]

I just realized this is the minimum

*.java eol=lf

However this would be could to have in all repos:
* text=auto
*.java eol=lf

onsdag den 25. juli 2018 kl. 14.26.22 UTC+2 skrev Joseph P:
>
> The action needed to avoid line endings being messed with is 
> * text=auto
>
> However this would be enough for the formatter
> *.java text eol=lf
>
> But I would recommend the text=auto
>
> And if the maintainer needs something more fancy they can customise it 
> further but lucky shouldn't have anything like Visual Studio
> *.slntext eol=crlf
>
> If a maintainer mess it up the answer would be to add the .gitattributes 
> and run 
> git add --renormalize .
>
> Like I did in the first PR.
>
> onsdag den 25. juli 2018 kl. 14.06.31 UTC+2 skrev Mark Waite:
>>
>>
>>
>> On Wed, Jul 25, 2018 at 4:44 AM Joseph P  wrote:
>>
>>> Just to touch on the line endings issue... See 
>>> https://github.com/jenkinsci/vstestrunner-plugin/pull/16 when it 
>>> becomes an issue. I just wanted to fix a minor thing but because of the 
>>> maintainer did a commit where they messed with line endings it screwed up 
>>> the history for https://github.com/jenkinsci/vstestrunner-plugin/pull/17
>>>
>>>
>> I see the changes in line endings between those two commits but am not 
>> clear on the actions which are needed by a maintainer to avoid the problem.
>>
>> Is it enough to have the .gitattributes file that sets the line endings 
>> of files that will be automatically formatted?
>>
>> If that's not enough, could you explain further what is needed?
>>
>> Mark Waite
>>  
>>
>>> tirsdag den 24. juli 2018 kl. 14.30.01 UTC+2 skrev Mark Waite:
>>>>
>>>> On Tue, Jul 24, 2018 at 1:48 AM Joseph P  wrote:
>>>>
>>>>> The problem I have noticed with FMT Maven plugin. The formatter does 
>>>>> not handle CR LF line endings rather it converts everything to LF which 
>>>>> will mess with commits because it causes high rewrites. So you would need 
>>>>> to ensure that git attributes is in all repos as well to avoid incorrect 
>>>>> commit history.
>>>>>
>>>>> Tomas Bjerre is using it on his repos: 
>>>>> https://github.com/jenkinsci/violation-comments-to-stash-plugin
>>>>> See this commit message: 
>>>>> https://github.com/jenkinsci/violation-comments-to-stash-plugin/pull/50/commits/1f2fd46632aaf65493f41bf74e660710221fd70f
>>>>>
>>>>>
>>>> I like the idea of including a .gitattributes file as part of the 
>>>> transition to optional automatic formatting in a repository.  I'll include 
>>>> that in the proposal.  Additional files were needed with the transition to 
>>>> support incrementals and that transition seems to be progressing very well.
>>>>
>>>> I prefer (and accept) the intentional setting of line endings.  I 
>>>> consider that part of the standardization of the formatting.  I think that 
>>>> maintainers that don't want line endings standardized or that cannot 
>>>> accept 
>>>> LF as the standard would choose to not enable automatic formatting in the 
>>>> plugins they maintain.
>>>>
>>>> Thanks,
>>>> Mark Waite
>>>>  
>>>>
>>>
>>>>> tirsdag den 24. juli 2018 kl. 03.36.42 UTC+2 skrev Mark Waite:
>>>>>>
>>>>>> I'd like to submit a Jenkins Enhancement Proposal for optional 
>>>>>> automated source code formatting available from the plugin pom so that 
>>>>>> plugins which build with maven could choose to "opt-in" to automated 
>>>>>> source 
>>>>>> code formatting.
>>>>>>
>>>>>> Key attributes of the idea:
>>>>>>
>>>>>>- *Optional* - plugins only get source code formatting if they 
>>>>>>enable it
>>>>>>- *Automatic* - when source code formatting is enabled, it 
>>>>>>happens automatically as part of the maven compile phase
>>>>>>- *Common* - when source code formatting is enabled, the source 
>>>>>>code formatting settings are not intended to be altered by the plugin
>>>>>>
>>>>>> I've implemented a sample in the platformlabeler plugin 
>>>>>> <https://github.com/jenkinsci/platformlabeler-plugin/blob/fcae9d81f557c4fdcb1b991487e28113f718a81

Re: Bitbucket Branch Source Plugin Maintainer

[Joseph P]

I am pretty familiar with the code base, contributed and reviewed a lot of 
the PRs, so if your up for it wouldn't mind being the second maintainer.
Also maintainer on the bitbucket webhook plugin for non native webhook 
bitbucket.



torsdag den 30. august 2018 kl. 09.47.21 UTC+2 skrev Antonio Muñiz:
>
> BTW, I'm one of the maintainers, but I'd like to get at least one more 
> review from another maintainer.
>
> On Thu, 30 Aug 2018 at 09:18, Antonio Muñiz  > wrote:
>
>> Review done.
>>
>> On Wed, 29 Aug 2018 at 04:05, Richard Bywater > > wrote:
>>
>>> Hi
>>>
>>> Just wanted to put out a call to see who identifies with being the 
>>> maintainer for the Bitbucket Branch Source Plugin at the moment.
>>>
>>> Reason I ask is that there's a few PRs building up at the moment and one 
>>> of them ( 
>>> https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/115 ) 
>>> would be of great use for those of us who use a different URL for HTTP & 
>>> SSH.
>>>
>>> Thanks in advance :)
>>> Richard.
>>>
>>> -- 
>>> 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/CAMui946PmsQ-M%2B%3DV2vOcAvwdqz5D%2BP0AVv4_CuVKxuvPH5Hr-g%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Antonio Muñiz
>> Software Engineer
>> CloudBees, Inc.
>>
>
>
> -- 
> Antonio Muñiz
> Software Engineer
> CloudBees, Inc.
>

-- 
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/0a70622e-2c66-4887-8307-2331dab66f24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: using Kotlin inside Jenkins Plugins

[Joseph P]

Done 
https://github.com/casz/kotlin-v1-plugin
We use the parent POM to set Kotlin version and depend on 
`org.jenkins-ci.plugins:plugin` and then use the plugin pom for plugins to 
use.

Naming is still open for discussion tbh

I created a plugin using the Jenkins plugin archetypes and just changed the 
parent to the Kotlin plugin pom and BAM you could start using Kotlin 

Surprised how easy it was to setup with maven 

Den torsdag den 18. januar 2018 kl. 22.03.09 UTC+1 skrev Jesse Glick:
>
> On Thu, Jan 18, 2018 at 1:27 PM, Joseph P <jose...@gmail.com > 
> wrote: 
> > I would be happy to create a custom parent pom for 
> > other Kotlin based Jenkins plugins to use. 
>
> If possible, it should extend `org.jenkins-ci.plugins:plugin` so as to 
> pick up common stuff. 
>

-- 
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/343de5b4-326f-49a2-83b6-337f197ececc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: repository-connector plugin maintainence

[Joseph P]

I suggest you take a look at the Jenkinsfile there are a few options: 
https://github.com/jenkinsci/accurev-plugin/blob/master/Jenkinsfile
https://github.com/jenkinsci/git-client-plugin/blob/master/Jenkinsfile

You get automatic builds then on ci.jenkins.io
https://ci.jenkins.io/job/Plugins/job/accurev-plugin/

/Joseph

Den mandag den 22. januar 2018 kl. 22.19.28 UTC+1 skrev Jae Gangemi:
>
>
>   would it be possible to get admin access to this repo? i'd like to set 
> up travis to build pull requests but i don't currently have access.
>
>   i have cc-ed domi here. i tried reaching out to touch base and discuss 
> this last week but i have not heard back and wanted to cover my bases.
>
>   thanks!!
>
>
> On Sun, Jan 14, 2018 at 1:21 PM, Baptiste Mathus  > wrote:
>
>> Thanks for your patience. 
>> Just added you as a committer Jae. 
>>
>> Obviously you will want to go through PRs for changes, and leave some 
>> time to Domi to review it as much as possible.
>>
>> When/if you wish to release, you'll need to file a PR against the 
>> permissions repo, but that's probably not needed yet at that point. 
>>
>> Cheers and welcome!
>>
>> 2018-01-10 16:38 GMT+01:00 Jae Gangemi :
>>
>>>
>>>   awesome!
>>>
>>>   jenkins: jgangemi (jgangemi at gmail)
>>>   github: jgangemi
>>>
>>> On Tuesday, January 9, 2018 at 11:39:56 PM UTC-7, domi wrote:

 Hi Jae,

 I’m more then happy if you want to help out with the 
 repository-connector!
 The reason why I did not answer to your first mail is, that my 
 subscription to the jerkins-dev googlegroup does not work anymore - I’m 
 fighting with it since months and have no idea why it does not work…
 /Domi

 On 10 Jan 2018, at 00:22, Jae Gangemi  wrote:


   thanks! 

   adding original maintainers (as listed in wiki page) to cc list.

 On Tue, Jan 9, 2018 at 2:36 PM, Baptiste Mathus  
 wrote:

> Hello!
>
> Thank you for your interest! We've documented the process on this 
> page: https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>
> To sum up, you want to put them in CC (hint: use git history, there 
> should be a bunch of emails there in commits) here, and either they 
> answer, 
> or we have a typical 2 weeks timeout before giving you the necessary 
> permissions to take over.
>
> Thanks again
>
> 2018-01-08 18:59 GMT+01:00 Jae Gangemi :
>
>> i'm trying to reach the maintainers of the repostitory-connector 
>> plugin to see if they are still interested in maintaining it and if not, 
>> what steps i need to do in order to take over and provide support.
>>
>> thanks!!
>>
>> --
>> -jae
>>
>> -- 
>> 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/cec61c51-0840-4dd8-ab7a-57136056cd49%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/jenkinsci-dev/X3nHpfaeD9M/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to 
> jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS62Kvt8Y76s4h8ep3yirks9dye1FuiCncFfPY1ODHv_qg%40mail.gmail.com
>  
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



 -- 
 -jae


 -- 
>>> 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/e5755176-9209-43ad-8b50-db4f7b93121e%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> You received 

Re: Github Branch Source with large number of repositories

[Joseph P]

Take a look at https://ci.jenkins.io they categorize repos into meaningful 
groups for instance Plugins folder contains all repos with the name 
*-plugin in the repo name.

Den torsdag den 8. marts 2018 kl. 05.24.57 UTC+1 skrev Cuong Tran:
>
> How do folks manage a large number of repositories in a single 
> organization when you use the Github Branch Source to automatically create 
> jobs?
>

-- 
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/1cbc6b95-ac92-4b74-85df-68bfce430df2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Github Branch Source with large number of repositories

[Joseph P]

You might be able to write an SCM trait extension plugin to understand 
repository topics filtering, however, I think you would need to send a Pull 
Request to the Github Branch Source plugin to have the topics data 
available from the API wrapper :)

GitHub API wrapper used by GitHub Branch Source plugin 
https://github.com/kohsuke/github-api/blob/master/src/main/java/org/kohsuke/github/GHRepository.java
https://developer.github.com/v3/repos/#list-organization-repositories the 
topics is definitely on the repo :)

Den torsdag den 8. marts 2018 kl. 07.28.37 UTC+1 skrev Cuong Tran:
>
> Joseph,
>
> Thanks for pointing me to that instance.  Without admin access, I can only 
> guess that these grouping are manually defined.  I'm looking for a more 
> dynamic way to group them (for example, using github topic) without relying 
> on the naming pattern alone.
>
> On Wednesday, March 7, 2018 at 8:34:09 PM UTC-8, Joseph P wrote:
>>
>> Take a look at https://ci.jenkins.io 
>> <https://www.google.com/url?q=https%3A%2F%2Fci.jenkins.io=D=1=AFQjCNG6KNAp1Lg_VxwmmerdGctEObs8Xg>
>>  
>> they categorize repos into meaningful groups for instance Plugins folder 
>> contains all repos with the name *-plugin in the repo name.
>>
>> Den torsdag den 8. marts 2018 kl. 05.24.57 UTC+1 skrev Cuong Tran:
>>>
>>> How do folks manage a large number of repositories in a single 
>>> organization when you use the Github Branch Source to automatically create 
>>> jobs?
>>>
>>

-- 
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/9b71d4fa-6494-4c23-a292-a2ece46b8a93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would like to adopt windows-exe-runner-plugin

[Joseph P]

Usually there is a 14 days wait period but since there has not been any 
activity in the past 5 years it should be up for adoption, so hopefully if 
ask nicely on IRC you might get a faster response.

/Joseph

Den fredag den 9. marts 2018 kl. 23.10.29 UTC+1 skrev Michael Fowler:
>
> Can anyone advise on this?
>
> On Monday, March 5, 2018 at 12:35:35 PM UTC-5, Michael Fowler wrote:
>>
>> Hello,
>>  I would like to adopt the windows-exe-runner plugin. It hasn't been 
>> updated in almost 5 years and the developer is no longer active on github. 
>> I have modified the plugin to be pipeline compatible and would like to get 
>> that published to the plugin index. What do I have to do to adopt it? 
>> Thanks,
>> -Michael
>>
>

-- 
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/b4a511cf-391d-4a17-ac99-683f0274b4d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Jenkins World 2018] - Graders wanted

[Joseph P]

I'd appreciate the chance to help, been contributing to Jenkins project and 
a plugin maintainer. :)

BR,
Joseph

fredag den 13. april 2018 kl. 18.09.08 UTC+2 skrev alytong13:
>
> Hello,
>
> I am looking for additional graders to join the Jenkins World (JW) review 
> committee to help grade Jenkins World 2018 SF & EU proposals.
>
> Time commitment expected:
>
>- JW SF: 137 Jenkins submissions.
>- JW EU: 76 Jenkins submissions at the moment but most likely will 
>increase after close of CFP this Sunday.
>
> What you get:
>
>- Pix, bio on the Committee webpage (part of JW website)
>- JW swag
>- Free conference ticket to JW
>
> Criteria:
>
>- You love to read and has a keen mind for the latest and greatest, 
>trendy technical topics
>
> Pls respond to this thread if you're interested.
>
> BR,
> alyssa 
>
>

-- 
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/4a4a333b-fd8d-4eae-b975-a89ed657f05f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Joseph P]

Usually the wait period is 2 weeks :) I would not recommend creating another 
plugin.

-- 
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/8b9ce146-6cf1-4b5a-a702-108ffe540d29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remoting work dir configuration of JNLP Launcher

[Joseph P]

Any GitHub user can fork a repo and create a branch on that fork. So fork, 
commit, push, create pull request to the Jenkins repo. 
https://guides.github.com/introduction/flow/

/Joseph 

-- 
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/7fc82df9-c216-44fd-bfaf-353a4aec4ad5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JEP: Modification of "Accepted" JEPs

[Joseph P]

Reading the updated JEP 1 sounds like PR 59 for JEP 201 would pass as minor 
changes which provides clarification.
Unless I am misinterpreting the intend of both pull requests 

Den onsdag den 4. april 2018 kl. 08.42.21 UTC+2 skrev Liam Newman:
>
> Hello all,
> I've attempted to synthesize the key points made here into a PR for JEP 1:
> https://github.com/jenkinsci/jep/pull/76
>
> The scope of this change expanded a bit, but I think the result is clearer.
> Please feel free to comment (or even better to commit edits directly). 
>
> Thanks, 
> Liam
>
>
> On Monday, March 26, 2018 at 1:25:34 PM UTC-7, Liam Newman wrote:
>>
>> Andrew,
>>
>> That's an interesting point as well. The process is still relatively new, 
>> so it's not surprising that there's a learning curve and a need for more 
>> examples. JEPs with tighter focus will definitely move through the process 
>> more quickly, since they will require less discussion, design-time, 
>> implementation time, and consensus building.   JEP-200 was a good example 
>> of that tight focus and it still took some time.
>>
>> One way that Tyler has been addressing the scope considerations in 
>> relation the Jenkins Essentials is splitting the overall project into 
>> multiple JEPs.  JEP-300 covers the overall goals and high-level design, and 
>> delegates the internal design of those components to sub-JEPs that are 
>> being filed as work gets rolling.   I don't know if that means JEP-300 will 
>> be accepted sooner or will remain as draft, but it looks like that will be 
>> the case.  
>>
>> It would be nice to have more JEPs filed to for a base of examples we can 
>> point people to, but I suspect we'll have to wait for that to grow 
>> organically over time.
>>
>> -L. 
>>
>>
>> On Sat, Mar 24, 2018 at 7:48 AM Andrew Bayer > > wrote:
>>
>>> I think it’s more a cultural thing re comfortableness of followup JEPs - 
>>> we need to have precedents and examples so that people will feel like oh, 
>>> it’s ok that this stuff didn’t get into that JEP, we can just do a new JEP 
>>> with it. Leaving proposals open for too long in order to make sure every 
>>> possible tangentially related matter gets in is a path to stagnation. We’re 
>>> far better off with more JEPs of potentially smaller size/scope, 
>>> potentially amending earlier JEPs, than a small number of bloated ones, IMO.
>>>
>>> A.
>>>
>>> On Sat, Mar 24, 2018 at 9:34 AM Liam Newman >> > wrote:
>>>
 This is a ton of great feedback, thanks!  

 Ewelina,

 JEPs have a number of purposes, but they are definitely _not_ meant to 
 stifle innovation.  At minimum though, they are meant to provide a medium 
 for building consensus on the design and implementation of major 
 features/processes of the Jenkins (and related) project.  

 Without JEP, contributors such as yourself, might do months of work 
 only to have that work rejected or asked to be redesigned.  From the other 
 side, the Project might get random contributors who ride in and want to 
 have drop in some massive features without having discussed and reviewed 
 with the rest of the project. 

 I think the main misunderstanding (due to lack of clarity in JEP-1) is 
 the idea that a JEP must be "Accepted" in order for contributors to have 
 confidence in the value and validity of their work. That is absolutely not 
 the case.

 "Accepted" means that that Reviewer and Sponsor have looked at the JEP 
 and agreed that _scoping and design_ are complete and have the consensus 
 of 
 the community, and that what remains is completing the (already well 
 underway) implementation.  "Accepted" is a description of the technical 
 state of the proposed component/feature/process.  "Accepted" is _not_ (and 
 should not be viewed or used as) a "vote of confidence".  

 Conversely, "Draft" is not a commentary on the likelihood that the JEP 
 will eventually be "Accepted".  That can only determined by the Sponsors 
 and the Reviewers based on discussion and feedback on the mailing list or 
 other forums. "Draft" is _not_ (and should not be viewed as) an indicator 
 of any lack of confidence in a proposal. 

 > Now when I see a requirement 
 *> "all 'significant changes' to a JEP should be completed before it is 
 Accepted"*
 > it makes me worry that if I end up working on next JEP, for another 
 project, 
 > I will be very careful and it will take ages to put it into 
 "Accepted" (maybe it's
 > not a problem). And then, like with JCasC, we learn while we 
 implement it, 
 > we discover issues and things that we can't do the way we want to do. 
 > Do we have to discover all of that before "Accepting" JEP?

 In short, yes, but as you might gather from my response above, that is 
 not a bad thing. 

 In the case of JEP-201, 

Re: form round trip tests fail after upgrading to jenkins version 1.642.3

[Joseph P]

Created: https://github.com/jenkinsci/cmakebuilder-plugin/pull/8 
implementing SimpleBuildStep is the easiest and fastest way to get going :) 

The main reason why SimpleBuildStep is wonderful:

https://github.com/jenkinsci/jenkins/blob/11c81cacf5776415cd68ee26f32e5d28549a0322/core/src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java#L63-L82


https://github.com/jenkinsci/jenkins/blob/11c81cacf5776415cd68ee26f32e5d28549a0322/core/src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java#L63-L82

https://github.com/jenkinsci/jenkins/blob/11c81cacf5776415cd68ee26f32e5d28549a0322/core/src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java#L63-L82


Den tirsdag den 20. marts 2018 kl. 23.06.39 UTC+1 skrev Joseph P:
>
> Your implementation of a separate step and using workflow plugin seems 
> overkill to support pipeline.
>
> All you need is for your builder to implement SimpleBuildStep and provide 
> the descriptor with a simple
>
> /Joseph
>
> Den tirsdag den 20. marts 2018 kl. 21.00.49 UTC+1 skrev Martin Weber:
>>
>> To implement pipeline compatibility for the cmakebuilder plugin[1], I 
>> changed 
>> the required jenkins version from 1.580.3 to 1.643.3. 
>> Parent pom version is 2.7. 
>>
>> With 1.643.3, my form-round-trip tests [2] fail with 'internal server 
>> error'. 
>> I also ran the test from eclipse, which gave me some more output in the 
>> console: 
>>
>> INFO: Started @11170ms 
>> === Starting 
>> checkValidation(hudson.plugins.cmake.CmakeBuilderFormRoundTripTest) 
>> Mar 20, 2018 8:54:55 PM hudson.ExpressionFactory2$JexlExpression evaluate 
>> WARNING: Caught exception evaluating: i.descriptor in /jenkins/job/test0/ 
>> configure. Reason: java.lang.reflect.InvocationTargetException 
>> java.lang.reflect.InvocationTargetException 
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>  
>>
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
>>  
>>
>> 43) 
>> at java.lang.reflect.Method.invoke(Method.java:606) 
>> at 
>> org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java: 
>>
>> 125) 
>> ... 
>> at java.lang.Thread.run(Thread.java:748) 
>> Caused by: java.lang.AssertionError: class 
>> hudson.plugins.cmake.CmakeBuilder 
>> is missing its descriptor 
>> at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1223) 
>> at hudson.tasks.Builder.getDescriptor(Builder.java:67) 
>> at 
>> hudson.plugins.cmake.CmakeBuilder.getDescriptor(CmakeBuilder.java:395) 
>>
>>
>> Can someone please explain whats going wrong/different with 1.643.3 and 
>> give 
>> me some hints how to fix the test? 
>>
>> TIA, 
>> Martin 
>>
>> [1] https://github.com/jenkinsci/cmakebuilder-plugin 
>> [2] <https://github.com/jenkinsci/cmakebuilder-plugin/blob/ 
>> 994787a44529895ba4af766f5b5d7491339fb417/src/test/java/hudson/plugins/cmake/ 
>>
>> CmakeBuilderFormRoundTripTest.java#L21 
>> <https://github.com/jenkinsci/cmakebuilder-plugin/blob/994787a44529895ba4af766f5b5d7491339fb417/src/test/java/hudson/plugins/cmake/CmakeBuilderFormRoundTripTest.java#L21><
>>  
>>
>> -- 
>> E-Mails sollten Text sein, Text und nur Text. 
>> Wenn Gott gewollt hätte, dass E-Mails in HTML geschrieben würden, 
>> endeten Gebete traditionell mit . 
>>
>

-- 
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/3bca97f1-6875-4d9b-80e6-87b3c7b1e9fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

form round trip tests fail after upgrading to jenkins version 1.642.3

[Joseph P]

It is in the error stack. Your builder is missing its descriptor implementation 
class.

Read this. 
https://jenkins.io/doc/developer/plugin-development/pipeline-integration/

-- 
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/6246eb70-4f5e-4a1d-aea4-96feacd567ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: form round trip tests fail after upgrading to jenkins version 1.642.3

[Joseph P]

Your implementation of a separate step and using workflow plugin seems 
overkill to support pipeline.

All you need is for your builder to implement SimpleBuildStep and provide 
the descriptor with a simple

/Joseph

Den tirsdag den 20. marts 2018 kl. 21.00.49 UTC+1 skrev Martin Weber:
>
> To implement pipeline compatibility for the cmakebuilder plugin[1], I 
> changed 
> the required jenkins version from 1.580.3 to 1.643.3. 
> Parent pom version is 2.7. 
>
> With 1.643.3, my form-round-trip tests [2] fail with 'internal server 
> error'. 
> I also ran the test from eclipse, which gave me some more output in the 
> console: 
>
> INFO: Started @11170ms 
> === Starting 
> checkValidation(hudson.plugins.cmake.CmakeBuilderFormRoundTripTest) 
> Mar 20, 2018 8:54:55 PM hudson.ExpressionFactory2$JexlExpression evaluate 
> WARNING: Caught exception evaluating: i.descriptor in /jenkins/job/test0/ 
> configure. Reason: java.lang.reflect.InvocationTargetException 
> java.lang.reflect.InvocationTargetException 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
>
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
>  
>
> 43) 
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at 
> org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java: 
>
> 125) 
> ... 
> at java.lang.Thread.run(Thread.java:748) 
> Caused by: java.lang.AssertionError: class 
> hudson.plugins.cmake.CmakeBuilder 
> is missing its descriptor 
> at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1223) 
> at hudson.tasks.Builder.getDescriptor(Builder.java:67) 
> at 
> hudson.plugins.cmake.CmakeBuilder.getDescriptor(CmakeBuilder.java:395) 
>
>
> Can someone please explain whats going wrong/different with 1.643.3 and 
> give 
> me some hints how to fix the test? 
>
> TIA, 
> Martin 
>
> [1] https://github.com/jenkinsci/cmakebuilder-plugin 
> [2]  994787a44529895ba4af766f5b5d7491339fb417/src/test/java/hudson/plugins/cmake/ 
>
> CmakeBuilderFormRoundTripTest.java#L21 
> <
>  
>
> -- 
> E-Mails sollten Text sein, Text und nur Text. 
> Wenn Gott gewollt hätte, dass E-Mails in HTML geschrieben würden, 
> endeten Gebete traditionell mit . 
>

-- 
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/9c647185-e59c-4c1f-9129-f318d7dbef8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to merge fixes to plugins with no maintainer

[Joseph P]

He himself could become the maintainer if he so wishes.

If not I believe it falls under open for adoption, and I can recall the 
exact, but I believe it then falls to the core maintainer.

On Tuesday, March 26, 2019 at 9:58:30 PM UTC+1, martinda wrote:
>
> A GSoC student wants to merge a trivial fix to a plugin that no longer has 
> a maintainer.
>
> The plugin is changes-since-last-success-plugin 
>  (ndeloof is no 
> longer the maintainer as per this message 
> )
>
> The PR is:
> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3
>
> How does the student proceed?
>
> 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/dc5ba9ff-c2ce-4a21-be38-98beb0ba884d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copying file from Master to slave

[Joseph P]

You want to use FilePath class as much as possible, it has methods that 
work regardless if it is on master or agent.

See the JavaDoc: https://javadoc.jenkins.io/hudson/FilePath.html


On Tuesday, February 26, 2019 at 8:44:02 AM UTC+1, Nikhil Bhoski wrote:
>
> I have my plugin which creates a file in the jenkins workspace. however if 
> i configure slave and force the job to run on slave then i see file on 
> slave is not getting created. 
>
> I am using workspace.getRemote() to get the workspace path and Java 
> File.copy() utility to copy the file in workspace.getRemote() path . 
> However the file is not getting created on slave. Any suggestions to make 
> it work ?
>

-- 
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/1e0a992a-6528-4f15-8399-e8ce0befb66f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Commit access to plugin office-365-connector-plugin

[Joseph P]

You should cc the original authors.

On Monday, February 18, 2019 at 12:27:53 AM UTC+1, damian.pu...@gmail.com 
wrote:
>
> Hi,
>
> As active user and contributor of the office-365-connector-plugin 
> I'd
>  
> like to have permission to merge and publish new versions.
>
> There are a few reasons for that:
>
>- plugin is currently unmaintainable by owners - last release 
> 
>took place almost year ago
>- there are waiting pull requests, bug fixes are merged 
>
> 
>  
>but released yet
>- I use this plugin on production so then I can keep quality and 
>perform tests before merge/release, I wrote several tests 
>
> 
>  
>for this plugin
>- Number of installations 
> has doubled in last 
>year (and is related to Microsoft Teams 
> 
>popularity) so we need to make this plugin active...
>- ... and at least support several requests or bugs 
> that 
>are waiting for feedback
>
> I'm the owner/maintainer of a few other popular Jenkins plugins so I 
> believe I can handle this
>
> Thanks,
> Damian
>

-- 
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/140de8cb-9b31-41d9-a24a-91716913767a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Commit access to plugin office-365-connector-plugin

[Joseph P]

The procedure is pretty 
clear: 
https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin#AdoptaPlugin-Requestcommitaccess

We have to wait for 2 weeks 

On Thursday, February 21, 2019 at 12:31:41 AM UTC+1, Tyler Smith wrote:
>
> With the rise in popularity of MS Teams, this plugin needs an active 
> maintainer or two.  There are many bug fixes and features waiting for a 
> maintainer to merge and released.  I think the original author is `outconn` 
> and he hasn't been very active in GitHub in the last year, how can we go 
> over his head to get Damian named the maintainer?
>
> Tyler
>
>
> On Tuesday, February 19, 2019 at 2:55:47 PM UTC-6, Damian Szczepanik wrote:
>>
>> I don't know who is the original author but I see you have merged recent 
>> commits then I believe your opinion matters.
>>
>> Also added second maintainer to CC.
>>
>> Damian
>>
>>
>> You should cc the original authors.
>>
>> On Monday, February 18, 2019 at 12:27:53 AM UTC+1, damian.pu...@gmail.com 
>> wrote:
>>
>> Hi,
>>
>> As active user and contributor of the office-365-connector-plugin 
>> I'd
>>  
>> like to have permission to merge and publish new versions.
>>
>> There are a few reasons for that:
>>
>>- plugin is currently unmaintainable by owners - last release 
>> 
>>took place almost year ago 
>>- there are waiting pull requests, bug fixes are merged 
>>
>> 
>>  
>>but released yet 
>>- I use this plugin on production so then I can keep quality and 
>>perform tests before merge/release, I wrote several tests 
>>
>> 
>>  
>>for this plugin 
>>- Number of installations 
>> has doubled in last 
>>year (and is related to Microsoft Teams 
>> 
>>popularity) so we need to make this plugin active... 
>>- ... and at least support several requests or bugs 
>> 
>>that are waiting for feedback 
>>
>> I'm the owner/maintainer of a few other popular Jenkins plugins so I 
>> believe I can handle this
>>
>> Thanks,
>> Damian -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-dev/NolCZIkGc_M/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/140de8cb-9b31-41d9-a24a-91716913767a%40googlegroups.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/c30bbbc0-9595-4cbf-af8f-0364327fd749%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Automating dependency management for repositories inside the jenkinsci org

[Joseph P]

Please enable it for

* bitbucket-branch-source-plugin
* mstest-plugin
* vstestrunner-plugin

On Thursday, February 21, 2019 at 2:43:48 PM UTC+1, Oleg Nenashev wrote:
>
> Dear all,
>
> I would like to follow-up on the Dependabot request from Jesse Glick in 
> INFRA-1975 . Dependabot 
>  is a service for automated dependency updates 
> which supports many languages/tools, including Maven, Docker and Gradle 
> which are being heavily used in Jenkins. 
>
> Dependency management is a problem in Jenkins, because we have hundreds of 
> repositories with many dependencies there. Maintainers spend a lot of time 
> on managing dependencies, and sometimes it leads to ancient dependencies in 
> components. Especially in the development tools which "just work". By 
> automating dependency updates we could give maintainers more time to focus 
> on other tasks.
>
> Dependabot is one of the engines we could use for dependency management. 
> It is free for open-source projects, and it is a SaaS application which can 
> be almost completely managed from GitHub. It can just create pull requests 
> or, if we want, implement validated merge with help of ci.jenkins.io. No 
> special infrastructure required, and this is an advantage for us. There are 
> other implementations (including UpdateBot 
>  by Fabric8/Jenkins X which has a 
> Jenkins plugin), but it would require more efforts to deploy the 
> infrastructure. It could be considered in the future if we want to have 
> Jenkins-powered update management in the final implementation.
>
> My proposal would be to enable Dependabot for a *limited number* of 
> Jenkins repositories so that we can experiment with it. I propose to focus 
> on development tools and pre-1.0 projects only for now so that we can 
> experiment with flow without a risk of impact on components being used in 
> production in the Jenkins project. And we will be setting up auto-updates 
> only for projects with existing test automation.
>
>- Jenkinsfile Runner - Example PRs in my local repo 
>
>- ci.jenkins.io-runner - Example PRs 
> (bot was 
>disabled after moving the repo)
>- plugin-pom - Example PRs in my local repo 
>
>- maven-hpi-plugin - Example PRs in my local Repo 
>
>
> More repositories can be added if somebody is interested to participate in 
> the Dependabot evaluation. If there is a positive feedback after the 
> initial evaluation, we could proceed with creating a JEP to define the flow 
> and the usage/administration policies.
>
> What do you think?
>
> Thanks in advance,
> Oleg
>
>

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

Re: Request maintainer/co-maintainer for vstestrunner-plugin

[Joseph P]

14 days have passed :)

On Thursday, January 24, 2019 at 7:45:27 PM UTC+1, Joseph P wrote:
>
> Hi
>
> This is my official request for maintainership of vstestrunner-plugin
>
> @Erik Goughnour  You never got the chance to look 
> at the PRs after previous attempts at getting the open PRs merged.
>
> Best regards
> Joseph Petersen
>
> -- Forwarded message -
> From: Joseph P 
> Date: Wed, Jul 25, 2018 at 2:03 PM
> Subject: Re:
> To: 
>
>
> An answer is always better then no answer  No rush
>
> Venlig hilsen / Best regards
> Joseph Petersen
>
>
> On Wed, Jul 25, 2018 at 1:53 PM Erik Goughnour  
> wrote:
>
>> Joseph, 
>>
>> I did take a brief look this morning.  I will try to make a release or at 
>> very least a determination whether to release within a few days.  Rest 
>> assured that I am not stating this in the context of geologic time scales.
>>
>> Erik
>>
>> On Jul 25, 2018, at 6:49 AM, Joseph P  wrote:
>>
>> Hi Erik
>>
>> Would you mind taking a look at the open PRs for vstestrunner plugin 
>> https://github.com/jenkinsci/vstestrunner-plugin/pulls
>>
>> Best regards
>> Joseph Petersen
>>
>>

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

Re: Request maintainer/co-maintainer for vstestrunner-plugin

[Joseph P]

Filed the permission PR :)
https://github.com/jenkins-infra/repository-permissions-updater/pull/1025


On Thursday, February 7, 2019 at 10:22:54 PM UTC+1, Baptiste Mathus wrote:
>
> Done!
> Thanks and welcome again :P.
>
> Remember to file a permission PR when you need to release.
>
> -- Baptiste
>
> Le jeu. 7 févr. 2019 à 21:43, Joseph P > 
> a écrit :
>
>> 14 days have passed :)
>>
>> On Thursday, January 24, 2019 at 7:45:27 PM UTC+1, Joseph P wrote:
>>>
>>> Hi
>>>
>>> This is my official request for maintainership of vstestrunner-plugin
>>>
>>> ...@Erik Goughnour  You never got the chance to look at 
>>> the PRs after previous attempts at getting the open PRs merged.
>>>
>>> Best regards
>>> Joseph Petersen
>>>
>>> -- Forwarded message -
>>> From: Joseph P >
>>> Date: Wed, Jul 25, 2018 at 2:03 PM
>>> Subject: Re:
>>> To: >
>>>
>>>
>>> An answer is always better then no answer  No rush
>>>
>>> Venlig hilsen / Best regards
>>> Joseph Petersen
>>>
>>>
>>> On Wed, Jul 25, 2018 at 1:53 PM Erik Goughnour >> > wrote:
>>>
>>>> Joseph, 
>>>>
>>>> I did take a brief look this morning.  I will try to make a release or 
>>>> at very least a determination whether to release within a few days.  Rest 
>>>> assured that I am not stating this in the context of geologic time scales.
>>>>
>>>> Erik
>>>>
>>>> On Jul 25, 2018, at 6:49 AM, Joseph P > 
>>>> wrote:
>>>>
>>>> Hi Erik
>>>>
>>>> Would you mind taking a look at the open PRs for vstestrunner plugin 
>>>> https://github.com/jenkinsci/vstestrunner-plugin/pulls
>>>>
>>>> Best regards
>>>> Joseph Petersen
>>>>
>>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/8b3e6550-5776-4827-bf07-5296bc92b7b2%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/8b3e6550-5776-4827-bf07-5296bc92b7b2%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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/64b9f4d9-5ac8-4f3f-b622-020f7b268513%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Request maintainer for mstest-plugin

[Joseph P]

Hi

Here is my official request for maintainer rights for the mstest plugin :)
https://github.com/jenkinsci/mstest-plugin

Following several contact attempts
https://github.com/jenkinsci/mstest-plugin/pull/11

https://github.com/jenkinsci/mstest-plugin/pull/10#issuecomment-286546341
this comment makes me believe that this transfer could be handled
immediately.

I have of course also cc'ed the current maintainer

Best regards
Joseph Petersen

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

Re: Request maintainer for mstest-plugin

[Joseph P]

Sweet, we are good to go ✨

> Le ven. 15 févr. 2019 à 15:31, Ivo Bellin Salarin  a
> écrit :

Awesome, thanks! :-)
> You will see that the repository contains unreleased code, if you need
> help taking over just ask!


Best regards
Joseph Petersen

On Fri, Feb 15, 2019 at 3:33 PM Ivo Bellin Salarin  wrote:

> Sorry Joseph, you will have to transfer my reply to the Jenkins Dev
> mailing list, it has been bounced...
>
> Le ven. 15 févr. 2019 à 15:31, Ivo Bellin Salarin  a
> écrit :
>
>> Awesome, thanks! :-)
>>
>> You will see that the repository contains unreleased code, if you need
>> help taking over just ask!
>>
>> Le ven. 15 févr. 2019 à 14:06, Joseph P  a écrit :
>>
>>> Hi
>>>
>>> Here is my official request for maintainer rights for the mstest plugin
>>> :)
>>> https://github.com/jenkinsci/mstest-plugin
>>>
>>> Following several contact attempts
>>> https://github.com/jenkinsci/mstest-plugin/pull/11
>>>
>>> https://github.com/jenkinsci/mstest-plugin/pull/10#issuecomment-286546341
>>> this comment makes me believe that this transfer could be handled
>>> immediately.
>>>
>>> I have of course also cc'ed the current maintainer
>>>
>>> Best regards
>>> Joseph Petersen
>>>
>>

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

Re: Request maintainer for mstest-plugin

[Joseph P]

slide is right there in the second link to the PR 11 

in any doubt: casz

On Friday, February 15, 2019 at 4:43:54 PM UTC+1, slide wrote:
>
> What is your github username?
>
> On Fri, Feb 15, 2019 at 6:06 AM Joseph P > 
> wrote:
>
>> Hi
>>
>> Here is my official request for maintainer rights for the mstest plugin :)
>> https://github.com/jenkinsci/mstest-plugin  
>>
>> Following several contact attempts
>> https://github.com/jenkinsci/mstest-plugin/pull/11
>>
>> https://github.com/jenkinsci/mstest-plugin/pull/10#issuecomment-286546341
>> this comment makes me believe that this transfer could be handled 
>> immediately.
>>
>> I have of course also cc'ed the current maintainer
>>
>> Best regards
>> Joseph Petersen
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAHOoXs1DAycx4vecLvpSOpJdGXApo8%3DfA0X71BG2QpEPkgEO_Q%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAHOoXs1DAycx4vecLvpSOpJdGXApo8%3DfA0X71BG2QpEPkgEO_Q%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Website: http://earl-of-code.com
>

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

Re: Request maintainer for mstest-plugin

[Joseph P]

Created cooperating repo permission 
PR: https://github.com/jenkins-infra/repository-permissions-updater/pull/1034

On Friday, February 15, 2019 at 9:43:02 PM UTC+1, Joseph P wrote:
>
> slide is right there in the second link to the PR 11 
>
> in any doubt: casz
>
> On Friday, February 15, 2019 at 4:43:54 PM UTC+1, slide wrote:
>>
>> What is your github username?
>>
>> On Fri, Feb 15, 2019 at 6:06 AM Joseph P  wrote:
>>
>>> Hi
>>>
>>> Here is my official request for maintainer rights for the mstest plugin 
>>> :)
>>> https://github.com/jenkinsci/mstest-plugin  
>>>
>>> Following several contact attempts
>>> https://github.com/jenkinsci/mstest-plugin/pull/11
>>>
>>> https://github.com/jenkinsci/mstest-plugin/pull/10#issuecomment-286546341
>>> this comment makes me believe that this transfer could be handled 
>>> immediately.
>>>
>>> I have of course also cc'ed the current maintainer
>>>
>>> Best regards
>>> Joseph Petersen
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAHOoXs1DAycx4vecLvpSOpJdGXApo8%3DfA0X71BG2QpEPkgEO_Q%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAHOoXs1DAycx4vecLvpSOpJdGXApo8%3DfA0X71BG2QpEPkgEO_Q%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Website: http://earl-of-code.com
>>
>

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

Re: [DevOps World Jenkins World 2019]: Volunteers needed for review committee

[Joseph P]

Thanks for creating a form this year. Submitted :)

On Tuesday, February 19, 2019 at 8:43:51 PM UTC+1, alytong13 wrote:
>
> Hi All,
>
> If you're interested in joining this year's review committee, pls complete 
> below form:
>
> https://docs.google.com/forms/d/1EXfFcyT07wunLRX9000TdpN8ipVzjoIX_fCHvXJBtXY/
>
> For those interested in sharing your Jenkins stories, the CFP is still open
> https://www.cvent.com/c/abstracts/6eb10034-9500-43a1-97cd-ab4d9230d7f9
>
> Thnx,
> alyssa
>

-- 
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/906aad3f-4610-4533-b04d-4fec33f83063%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Release not showing up

[Joseph P]

The best place to post issues and see issues for infrastructure is 
here: https://issues.jenkins.io/projects/INFRA
On Friday, January 25, 2019 at 7:41:59 AM UTC+1, Steve Springett wrote:
>
> Hello,
>
> I released a new version of the OWASP Dependency-Track plugin yesterday, 
> but it still hasn’t shown up on the update site.  The version in question 
> is 2.1.0.
>
>
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/dependency-track/2.1.0/
>
> https://updates.jenkins.io/download/plugins/dependency-track/
>
> Anything I need to do to make this available?
>
> —Steve
>

-- 
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/95337a3b-f9f7-438f-b7da-dbfa9e15e31b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adopt instant-messaging-plugin

[Joseph P]

Please share link to code review 

On Thursday, January 24, 2019 at 4:10:31 PM UTC+1, Jim Klimov wrote:
>
> Hello all, 
>
>  I am making some improvements to our Jenkins master interaction over 
> internal IRC, and it seems that the IM plugin which does the actual work is 
> not quite often updated (last release in 2015). 
>
>   I would like to bump its priority in the eyes of current maintainer 
> (CCed) and/or ask to add myself to the list of maintainers to to some 
> generic codebase cleanup (e.g. indentations are such a mess that the code 
> is hard to read) and to land my PRs eventually. Reviews welcome :D 
>
> Thanks, Jim Klimov 
> github and jenkins handles: jimklimov 
> -- 
> Typos courtesy of K-9 Mail on my Android 
>

-- 
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/b4359b82-523f-4dd2-b03f-f7578fd9173c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adopt instant-messaging-plugin

[Joseph P]

Assisting others: https://github.com/jenkinsci/instant-messaging-plugin/pulls

On Thursday, January 24, 2019 at 5:14:51 PM UTC+1, Joseph P wrote:
>
> Please share link to code review 
>
> On Thursday, January 24, 2019 at 4:10:31 PM UTC+1, Jim Klimov wrote:
>>
>> Hello all, 
>>
>>  I am making some improvements to our Jenkins master interaction over 
>> internal IRC, and it seems that the IM plugin which does the actual work is 
>> not quite often updated (last release in 2015). 
>>
>>   I would like to bump its priority in the eyes of current maintainer 
>> (CCed) and/or ask to add myself to the list of maintainers to to some 
>> generic codebase cleanup (e.g. indentations are such a mess that the code 
>> is hard to read) and to land my PRs eventually. Reviews welcome :D 
>>
>> Thanks, Jim Klimov 
>> github and jenkins handles: jimklimov 
>> -- 
>> Typos courtesy of K-9 Mail on my Android 
>>
>

-- 
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/5e3b86fa-1383-4a30--c2f02501667b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Request maintainer/co-maintainer for vstestrunner-plugin

[Joseph P]

Hi

This is my official request for maintainership of vstestrunner-plugin

@Erik Goughnour  You never got the chance to look at
the PRs after previous attempts at getting the open PRs merged.

Best regards
Joseph Petersen

-- Forwarded message -
From: Joseph P 
Date: Wed, Jul 25, 2018 at 2:03 PM
Subject: Re:
To: 


An answer is always better then no answer  No rush

Venlig hilsen / Best regards
Joseph Petersen


On Wed, Jul 25, 2018 at 1:53 PM Erik Goughnour 
wrote:

> Joseph,
>
> I did take a brief look this morning.  I will try to make a release or at
> very least a determination whether to release within a few days.  Rest
> assured that I am not stating this in the context of geologic time scales.
>
> Erik
>
> On Jul 25, 2018, at 6:49 AM, Joseph P  wrote:
>
> Hi Erik
>
> Would you mind taking a look at the open PRs for vstestrunner plugin 
> https://github.com/jenkinsci/vstestrunner-plugin/pulls
>
> Best regards
> Joseph Petersen
>
>

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

Re: Is there Python support for ci.jenkins.io plugin builds?

[Joseph P]

We use testcontainers in JCasC with great success and we are able to run 
those tests on Windows (if only they weren't so unstable)

We use assumeTrue to disable tests when docker is not available.

See 
here: 
https://github.com/jenkinsci/configuration-as-code-plugin/blob/791fee41018fbe9e00c32409aadc92eb30df/plugin/src/test/java/io/jenkins/plugins/casc/vault/VaultSecretSourceTest.java#L66

On Thursday, May 16, 2019 at 2:23:55 PM UTC+2, Chris Kilding wrote:
>
> I was able to substitute in the fabric8 Docker Maven Plugin to run Moto. 
> It seems to work fine on the Linux build agent, but the Windows agent 
> doesn’t like it (no Docker host or docker.sock available.)
>
> Is there another way to get Docker support on the Windows agent, or is 
> this ‘in the works’ for the future?
>
> Chris
>
> On Wed, 15 May 2019, at 6:45 PM, R. Tyler Croy wrote:
>
> (replies inline)
>
> On Wed, 15 May 2019, Chris Kilding wrote:
>
> > Yep, that sounds reasonable. (I had suspected as much - there would be 
> no end
> > to the possible system packages that plugin developers might want.)
> > 
> > Do the ‘docker’-labelled Jenkins agents support the usual 
> ‘dockerfile’
> > directive to let the build define a Docker image ad-hoc? Or do all 
> images have
> > to be pre-packed and hosted on a registry?
>
>
> The 'docker' labeled agents are all full VMs and the pipelines do have full
> access to the Docker socket, so Dockerfiles should be fine.
>
>
>
> --
> GitHub:  https://github.com/rtyler
>
> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkin...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/WOA6p30q5mgycsLk5VZWSBiSey1OiqQD4rFxG5C_2j1RKEGXDJYRZKpdymzN5Sl2z8BnWWsD7k9XBQvtlLx6PX8FVVDESCa8G4-N2vd-Xng%3D%40brokenco.de
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> *Attachments:*
>
>- signature.asc
>
>
>

-- 
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/d4ed2144-0377-4fa0-9a8b-0578bbc01bb6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: AWS Secrets Manager Credentials Provider plugin

[Joseph P]

>
> - If I update to parent POM v3.36+ then Findbugs is replaced by Spotbugs. 
> Will the Jenkins Findbugs report publisher (which all plugin builds have 
> access to) understand Spotbugs reports?
>

Yes, SpotBugs is configured to work as a replacement and Jenkins CI will 
continue to fail.

Latest that is the experience many repos who have switched have noticed, 
see this PR: https://github.com/jenkinsci/credentials-plugin/pull/114
Which has a commit directed for "fix spotbugs"

On Friday, May 17, 2019 at 2:19:43 PM UTC+2, Chris Kilding wrote:
>
> Alrighty, the manual way it is.
>
> I’m following the steps to trim down the plugin POM in the release manual. 
> However I’ve noticed the following quirks:
>
> - When I inherit the parent POM’s groupId, I get the older 
> “org.jenkins-ci.plugins” rather than the newer “io.jenkins.plugins”. Is 
> this a problem, or can I stick with the older groupId? (It seems preferable 
> for the plugin to inherit settings wherever possible.)
> - When I took out the repositories and pluginRepositories sections, the 
> plugin could not compile. Is there a fix for this, or should I keep a local 
> copy of those sections in my POM?
> - If I update to parent POM v3.36+ then Findbugs is replaced by Spotbugs. 
> Will the Jenkins Findbugs report publisher (which all plugin builds have 
> access to) understand Spotbugs reports?
>
> Regards,
>
> Chris
>
> On Thu, 16 May 2019, at 7:15 PM, Slide wrote:
>
> There is not currently an automated way to do this, the manual way is the 
> only way.
>
> On Thu, May 16, 2019 at 10:55 AM Chris Kilding  > wrote:
>
>
> The plugin now has a passing CI build on its master branch.
>
> The next step would probably be to release an alpha version to the update 
> site. I’ve seen the instructions for doing this manually, but I’m wondering 
> if Jenkins has an automated pipeline to release plugins?
>
> Chris
>
> On Tue, 14 May 2019, at 11:03 AM, Chris Kilding wrote:
>
> The plugin is now hosted by @jenkinsci at 
> https://github.com/jenkinsci/aws-secrets-manager-credentials-provider-plugin
>
> Jeff - could you delete and re-create your fork, so that the @jenkinsci 
> repo is the authoritative root of the repository graph?
>
> Regards,
>
> Chris
>
> On Mon, 13 May 2019, at 2:17 PM, Chris Kilding wrote:
>
> Due to the interest in the plugin I’ve now opened a hosting request to 
> transfer it to @jenkinsci at 
> https://issues.jenkins-ci.org/browse/HOSTING-763
>
> Chris
>
> On Mon, 13 May 2019, at 12:08 AM, Chris Kilding wrote:
>
> Hi Jeff,
>
> Yep, the compile error appears to be because the Maven localize plugin is 
> not run when our IDEs compile the project, so the Messages class is never 
> generated from the translation files. I’ll see about a fix tomorrow. The 
> workaround in the meantime is to run ‘mvn localize:generate’ manually and 
> then resume compilation with the IDE.
>
> For testing I’d appreciate your team’s input on aspects like:
>
> - Checking plugin stability over time - can it run for long periods 
> without memory leaks or crashing?
> - Finding edge cases related to AWS secrets lifecycle management (eg rapid 
> soft deletion or undeletion of secrets).
> - Finding edge cases related to AWS API calls (the AWS SDK does retry with 
> backoff and jitter automatically, but are the defaults good for our use 
> case - or do we need to tweak the retry / timeout / delay parameters?)
> - Documentation - is the README easy enough for a first-time user to 
> understand?
>
> Regards,
>
> Chris
>
> On Sun, 12 May 2019, at 2:56 PM, Jeff Pearce wrote:
>
> I think you forgot to include some resources - when I build it can't find 
> Messages.*. I can work around for my testing though
>
> On Friday, May 10, 2019 at 6:08:31 AM UTC-7, Chris Kilding wrote:
>
> The AWS Secrets Manager Credentials Provider plugin is now up on Github at 
> https://github.com/chriskilding/aws-secrets-manager-credentials-provider-plugin
>
> I need to do some initial exploratory testing and bug fixing on the plugin 
> before I can release any official builds of the compiled .hpi file. But if 
> you’d like to try it, you can check it out, install dependencies, and run 
> ‘mvn clean verify’ to build it (see the README).
>
> Once the plugin is ready, I’ll get the show on the road to migrate it to 
> @jenkinsci and make it official.
>
> Chris
>
> On Tue, 7 May 2019, at 2:19 PM, Chris Kilding wrote:
>
> Hello again,
>
> I solved my previous question when I found that Jenkins would sensibly 
> handle a CredentialsUnavailableException thrown from the getSecret() 
> implementation. This is just a suitably named unchecked exception that’s 
> provided by the credentials plugin.
>
> Chris
>
> On Tue, 23 Apr 2019, at 5:37 PM, Chris Kilding wrote:
>
> Hi Stephen,
>
> I did have one question that’s not covered by the guide...
>
> The guide says that a credential that fetches its secret value from a 
> remote service must throw an IOException if there is a data-related problem 
> (eg 404 not 

Proposal - Adding JCasC tests into Jenkins core test suite

[Joseph P]

Hi All

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

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

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


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

Best regards
Joseph Petersen

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

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

[Joseph P]

If SCMHead is not the thing you want:
You can retrieve from the git build data:
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L1328

On Wednesday, June 5, 2019 at 12:39:19 PM UTC+2, Joseph P wrote:
>
> To clarify from the SCMHead: you should be able to get the commit sha
>
> On Wednesday, June 5, 2019 at 12:37:37 PM UTC+2, Joseph P wrote:
>>
>> Jesse that is simply not true for branch source plugins:
>>
>> branch source plugin uses branch API plugin which contributes the 
>> environment variables.
>> There is also a way for plugins to retrieve this see 
>> https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchNameContributor.java
>> and 
>> https://github.com/jenkinsci/office-365-connector-plugin/blob/8b8834c9766b12ae71820a4090caa094f66d5cf1/src/main/java/jenkins/plugins/office365connector/ActionableBuilder.java#L59-L88
>>
>> Hopefully, you find that helpful Julien
>>
>> On Wednesday, June 5, 2019 at 3:07:31 AM UTC+2, Jesse Glick wrote:
>>>
>>> On Tue, Jun 4, 2019 at 5:16 PM Julien HENRY 
>>>  wrote: 
>>> > Is there any simple way (except some fragile local Git operation) to 
>>> access the original Git sha1 that triggered the PR build? In my example I 
>>> need to get ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b 
>>>
>>> There is not currently any environmental variable for that purpose 
>>> that I know of. You can simply try publishing a commit status for the 
>>> hash you are given, and if that gives a 422 response, try its first 
>>> parent instead, as I suggested in the thread leading to 
>>>
>>> https://jira.sonarsource.com/browse/SONAR-10794 
>>>
>>

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

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

[Joseph P]

To clarify from the SCMHead: you should be able to get the commit sha

On Wednesday, June 5, 2019 at 12:37:37 PM UTC+2, Joseph P wrote:
>
> Jesse that is simply not true for branch source plugins:
>
> branch source plugin uses branch API plugin which contributes the 
> environment variables.
> There is also a way for plugins to retrieve this see 
> https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchNameContributor.java
> and 
> https://github.com/jenkinsci/office-365-connector-plugin/blob/8b8834c9766b12ae71820a4090caa094f66d5cf1/src/main/java/jenkins/plugins/office365connector/ActionableBuilder.java#L59-L88
>
> Hopefully, you find that helpful Julien
>
> On Wednesday, June 5, 2019 at 3:07:31 AM UTC+2, Jesse Glick wrote:
>>
>> On Tue, Jun 4, 2019 at 5:16 PM Julien HENRY 
>>  wrote: 
>> > Is there any simple way (except some fragile local Git operation) to 
>> access the original Git sha1 that triggered the PR build? In my example I 
>> need to get ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b 
>>
>> There is not currently any environmental variable for that purpose 
>> that I know of. You can simply try publishing a commit status for the 
>> hash you are given, and if that gives a 422 response, try its first 
>> parent instead, as I suggested in the thread leading to 
>>
>> https://jira.sonarsource.com/browse/SONAR-10794 
>>
>

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

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

[Joseph P]

Jesse that is simply not true for branch source plugins:

branch source plugin uses branch API plugin which contributes the 
environment variables.
There is also a way for plugins to retrieve this see 
https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchNameContributor.java
and 
https://github.com/jenkinsci/office-365-connector-plugin/blob/8b8834c9766b12ae71820a4090caa094f66d5cf1/src/main/java/jenkins/plugins/office365connector/ActionableBuilder.java#L59-L88

Hopefully, you find that helpful Julien

On Wednesday, June 5, 2019 at 3:07:31 AM UTC+2, Jesse Glick wrote:
>
> On Tue, Jun 4, 2019 at 5:16 PM Julien HENRY 
> > wrote: 
> > Is there any simple way (except some fragile local Git operation) to 
> access the original Git sha1 that triggered the PR build? In my example I 
> need to get ab86fe3afa0b9473ea9da76c87872bf89b9b5f3b 
>
> There is not currently any environmental variable for that purpose 
> that I know of. You can simply try publishing a commit status for the 
> hash you are given, and if that gives a 422 response, try its first 
> parent instead, as I suggested in the thread leading to 
>
> https://jira.sonarsource.com/browse/SONAR-10794 
>

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

Re: github app approval for jenkinsci org?

[Joseph P]

Done and done, though I do not appreciate the triple system duplication of 
the information, notification noise and confusion it creates.

On Wednesday, May 8, 2019 at 10:53:50 AM UTC+2, Oleg Nenashev wrote:
>
> Currently we have several active contributors with GitHub administrative 
> access
>
> Generally these requests should go to the INFRA team (JIRA ticket + 
> mailing list ping).
> If it is about a new org-wide application to be enabled (or about 
> evaluation in few repos), starting a thread in the Dev list is probably the 
> best way
>
> BR, Oleg
>
>
> On Friday, April 26, 2019 at 3:26:09 AM UTC+2, Joseph P wrote:
>>
>> Who should I contact about getting a GitHub app approval for jenkinsci 
>> org.
>>
>> Feel overkill firing off to the mailing list and inside Jira, it will 
>> just be lost in the sea.
>>
>> The specific app in question is: https://github.com/apps/settings
>>
>>
>> https://github.com/jenkinsci/configuration-as-code-plugin/pull/856#issuecomment-486155499
>>
>>> This PR is currently blocked by requested app approval.
>>> I have a request for "settings <https://github.com/probot/settings>" 
>>> waiting to be approved for configuration-as-code-plugin repo
>>>
>>> @daniel-beck <https://github.com/daniel-beck> I think a @jenkinsci/admin 
>>> group 
>>> would make sense so I can poke more than one individual [image: sweat] or 
>>> is there a better channel? [image: confused]
>>> should I use the mailing list or should I use Jira?
>>> I find it confusing that we live outside of 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/c7f77b26-29ce-4155-b77d-cd63730ae188%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: github app approval for jenkinsci org?

[Joseph P]

https://issues.jenkins-ci.org/browse/INFRA-2103 

On Saturday, May 11, 2019 at 6:01:33 PM UTC+2, Joseph P wrote:
>
> Done and done, though I do not appreciate the triple system duplication of 
> the information, notification noise and confusion it creates.
>
> On Wednesday, May 8, 2019 at 10:53:50 AM UTC+2, Oleg Nenashev wrote:
>>
>> Currently we have several active contributors with GitHub administrative 
>> access
>>
>> Generally these requests should go to the INFRA team (JIRA ticket + 
>> mailing list ping).
>> If it is about a new org-wide application to be enabled (or about 
>> evaluation in few repos), starting a thread in the Dev list is probably the 
>> best way
>>
>> BR, Oleg
>>
>>
>> On Friday, April 26, 2019 at 3:26:09 AM UTC+2, Joseph P wrote:
>>>
>>> Who should I contact about getting a GitHub app approval for jenkinsci 
>>> org.
>>>
>>> Feel overkill firing off to the mailing list and inside Jira, it will 
>>> just be lost in the sea.
>>>
>>> The specific app in question is: https://github.com/apps/settings
>>>
>>>
>>> https://github.com/jenkinsci/configuration-as-code-plugin/pull/856#issuecomment-486155499
>>>
>>>> This PR is currently blocked by requested app approval.
>>>> I have a request for "settings <https://github.com/probot/settings>" 
>>>> waiting to be approved for configuration-as-code-plugin repo
>>>>
>>>> @daniel-beck <https://github.com/daniel-beck> I think a 
>>>> @jenkinsci/admin group would make sense so I can poke more than one 
>>>> individual [image: sweat] or is there a better channel? [image: 
>>>> confused]
>>>> should I use the mailing list or should I use Jira?
>>>> I find it confusing that we live outside of 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/92245111-f080-4da2-8f88-91af96d54c4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[INFRA-2086] - Switching ci.jenkins.io builds to AdoptOpenJDK

[Joseph P]

Sounds perfectly reasonable to me 
We use AdoptOpenJDK at work too.

-- 
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/4ded0ddd-9966-4467-bae4-df573c17a38e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JenkinsRule and docker

[Joseph P]

We have some integrations tests for Vault UI, I would imagine it could be 
very similar to a git docker container.

https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/plugin/src/test/java/io/jenkins/plugins/casc/vault

On Friday, April 26, 2019 at 1:06:03 AM UTC+2, Ullrich Hafner wrote:
>
> I’m currently trying to write some integration tests with Jenkins test 
> harness (i.e. JenkinsRule) that were previously part of ATH. For some of 
> the ATH concepts I did not yet find a counterpart in our integration tests. 
>
> Is someone already writing integration tests that use agents that are 
> provided by a docker container and has an example to share? 
>
> Since my plugins interact with Git I want to create a Git Repository in 
> the test setup with fake data. Do we have a kind of API to fill a Git 
> repository (like GitRepo in ATH)? 
>
>

-- 
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/376c6af5-d85e-431a-9ce8-891b337d6cad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: JenkinsRule and docker

[Joseph P]

We have some integrations tests for Vault, I would imagine it could be very 
similar to a git docker container.

https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/plugin/src/test/java/io/jenkins/plugins/casc/vault

On Friday, April 26, 2019 at 1:06:03 AM UTC+2, Ullrich Hafner wrote:
>
> I’m currently trying to write some integration tests with Jenkins test 
> harness (i.e. JenkinsRule) that were previously part of ATH. For some of 
> the ATH concepts I did not yet find a counterpart in our integration tests. 
>
> Is someone already writing integration tests that use agents that are 
> provided by a docker container and has an example to share? 
>
> Since my plugins interact with Git I want to create a Git Repository in 
> the test setup with fake data. Do we have a kind of API to fill a Git 
> repository (like GitRepo in ATH)? 
>
>

-- 
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/8dcc3860-231b-4367-8a3f-46c475f7cbaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

github app approval for jenkinsci org?

[Joseph P]

Who should I contact about getting a GitHub app approval for jenkinsci org.

Feel overkill firing off to the mailing list and inside Jira, it will just 
be lost in the sea.

The specific app in question is: https://github.com/apps/settings

https://github.com/jenkinsci/configuration-as-code-plugin/pull/856#issuecomment-486155499

> This PR is currently blocked by requested app approval.
> I have a request for "settings " 
> waiting to be approved for configuration-as-code-plugin repo
>
> @daniel-beck  I think a @jenkinsci/admin 
> group 
> would make sense so I can poke more than one individual [image: sweat] or 
> is there a better channel? [image: confused]
> should I use the mailing list or should I use Jira?
> I find it confusing that we live outside of 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/d529aa2d-76cd-4b9d-aeac-cce680c35240%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Preparing your modules/library/plugin to be consumed by dependabot

[Joseph P]

Hi Gavin, we actually made that change in JCasC to prepare 
for https://github.com/jenkins-infra/plugin-site-api/pull/54
Good that dependabot is something you can depend on 

Original PR 
https://github.com/jenkinsci/configuration-as-code-plugin/pull/1004

On Tuesday, August 27, 2019 at 6:50:38 PM UTC+2, Gavin Mogan wrote:
>
> Hey Ya'll,
>
> tl;dr - Make sure project > scm > url is set to github, (example 
> https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/pom.xml#L41
> )
>
> ---
>
> I thought I'd share my limited findings with all of your. A couple weeks 
> ago I contacted dependabot support to try and find out why some javascript 
> modules had changelogs/release notes mentioned. I got a bunch of good 
> responses back, and nudged them to document this info publicly.
>
> But for now, I share what I learned.
>
> Dependabot has a lot of open source code, including how it processes 
> module metadata.
>
>
> https://github.com/dependabot/dependabot-core/blob/e654f214a932672d8ac0ea428ef9d672ac5bba33/maven/lib/dependabot/maven/metadata_finder.rb#L52
>
> It loops through a bunch of properties inside the maven pom file, project 
> > url (which should point at wiki/plugins site for us), project > scm > url 
> (which right place to set it), and lastly project > issueManagement > url 
> (which probably defaults to jira)
>
> When that url is set right, dependabot knows where to pull information 
> from. See https://github.com/jenkinsci/ci.jenkins.io-runner/pull/192 as a 
> good example.
>
> It'll list the commits between tags. Release Notes if you use github 
> releases (release drafter makes that easy) and Changelog if it can find a 
> changelog file in the repo. I can go into more details about this if people 
> want.
>
> *But I strongly recommend at least setting up project > scm > url, and 
> either a changelog file, or preferably release notes for releases.*
>
> That'll make other plugin authors know if its worth upgrading/what 
> potentially might break when getting a dependabot PR.
>
> Thanks,
> Gavin
>
>

-- 
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/73df2ca3-23a2-4ec2-9af5-a34f9b1291e0%40googlegroups.com.

Re: Unable to configure Fork Change Request Trait using Job DSL

[Joseph P]

Thanks for creating a patch for this 殺

/Joseph

On Monday, August 19, 2019 at 9:17:45 PM UTC+2, Daniel Spilker wrote:
>
> Hi Parichay,
>
> I meant changing the constructor to
>
> public ForkMergeRequestDiscoveryTrait(int strategyId, SCMHeadAuthority 
> trust) {
>
> until Structs plugin supports parameters with parameterized type. 
>
> I opened a pull request to add some support for parameterized types to 
> Structs plugin:
> https://github.com/jenkinsci/structs-plugin/pull/52
>
> I tested the fix with Job DSL. It will enable the DSL syntax from my 
> previous post.
>
> Regards,
> Daniel
>
>
> On Mon, Aug 19, 2019 at 5:39 PM Parichay Barpanda  > wrote:
>
>> Thanks Daniel. But I didn't understand by what you meant "remove the type 
>> parameters". I was able to configure the trait using `configure` block. 
>> https://gist.github.com/baymac/f1a2249a0ec7b999c057056937e752a6 
>>
>> On Saturday, August 17, 2019 at 5:09:03 PM UTC+5:30, Daniel Spilker wrote:
>>>
>>> Hi Parichay,
>>>
>>> the Job DSL script would be this:
>>>
>>> organizationFolder('example') {
>>>   organizations {
>>> gitLabSCMNavigator {
>>>   projectOwner('test')
>>>   traits {
>>> gitLabForkDiscovery {
>>>   strategyId(42)
>>>   trust {
>>> gitLabTrustNobody()
>>>   }
>>> }
>>>   }
>>> }
>>>   }
>>> }
>>>
>>> But the script will fail. The problem is caused by the "trust" 
>>> constructor parameter of ForkMergeRequestDiscoveryTrait. Job DSL uses 
>>> the Structs plugin for introspection of Describables. Unfortunately Structs 
>>> does not handle parameter types with generics except for sub classes of 
>>> java.util.Collection. So the trait will not be shown in the API viewer.
>>>
>>> To check if a class is supported by Structs (and Job DSL), run the 
>>> following in the Jenkins script console:
>>>
>>> org.jenkinsci.plugins.structs.describable.DescribableModel.of(io.jenkins.plugins.gitlabbranchsource.ForkMergeRequestDiscoveryTrait)
>>>
>>> The result will be
>>>
>>> ForkMergeRequestDiscoveryTrait(strategyId: int, trust: 
>>> java.lang.UnsupportedOperationException: do not know how to categorize 
>>> attributes of type jenkins.scm.api.trait.SCMHeadAuthority>> io.jenkins.plugins.gitlabbranchsource.GitLabSCMSourceRequest, ? extends 
>>> jenkins.scm.api.mixin.ChangeRequestSCMHead2, ? extends 
>>> jenkins.scm.api.SCMRevision>)
>>>
>>> As a workaround, you can remove the type parameters from the "trust" 
>>> constructor parameter. 
>>>
>>> @Jesse: would it be feasible to fallback to the raw type when a 
>>> parameterized type is detected?
>>>
>>> https://github.com/jenkinsci/structs-plugin/blob/structs-parent-1.20/plugin/src/main/java/org/jenkinsci/plugins/structs/describable/ParameterType.java#L104
>>>
>>> Regards,
>>> Daniel
>>>
>>>
>>> On Fri, Aug 16, 2019 at 3:11 PM Parichay Barpanda  
>>> wrote:
>>>
 Hi all,

 I am trying to configure GitLab Branch Source Plugin organizational 
 folder using Job DSL. But unfortunately job dsl api viewer doesn't detect 
 Fork 
 Merge Request Trait 
 .
  
 All the detected traits in Job dsl api viewer takes either 
 int/boolean/string values. But in Fork Merge Request Trait the trust field 
 takes an SCMHeadAuthority object. How does one configure Job DSL with fork 
 `change request` trait for any of the branch source plugin?

 Can someone help me with figuring out what is wrong here. I have the 
 following cases:

 1. Job DSL doesn't support Fork Merge Request Trait.

 2. There is something wrong with the impl of Fork Merge Request Trait.

 3. Our Job DSL configuration is incorrect (note unable to configure 
 fork merge request in this configuration):

 organizationFolder(name) {
   organizations {
 displayName(config.displayName)
 description(orgDescription)
 gitLabSCMNavigator {
   projectOwner(config.group)
   credentialsId('gitlab_ssh_key')
   serverName('git.3shape.local')
   traits {
 subGroupProjectDiscoveryTrait() // discover projects 
 inside subgroups
 gitLabBranchDiscovery {
   strategyId(3) // discover all branches
 }
 originMergeRequestDiscoveryTrait {
   strategyId(1) // discover MRs and merge them with target 
 branch
 }
 gitLabTagDiscovery() // discover tags
 gitLFSPullTrait()
   }
 }
   }
   orphanedItemStrategy {
 discardOldItems {
   daysToKeep(7)
   numToKeep(10)
 }
   }
   if (!isSandbox()) {
 triggers {
  

Request maintainership of Hashicorp vault plugin

[Joseph P]

Hi Peter and Jenkins Devs

I'd like to request maintainership of Hashicorp vault plugin.

https://github.com/jenkinsci/configuration-as-code-plugin/issues/968
https://github.com/jenkinsci/hashicorp-vault-plugin/pull/23#issuecomment-516285769


We would like to move JCasC vault functionality to Hashicorp vault plugin
to avoid class loading issues between the two plugins.

https://github.com/jenkinsci/hashicorp-vault-plugin

JCasC vault code:
https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/plugin/src/main/java/io/jenkins/plugins/casc/impl/secrets/VaultSecretSource.java
https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/plugin/src/main/java/io/jenkins/plugins/casc/impl/secrets/vault


Venlig hilsen / Best regards
Joseph Petersen

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

Fwd: Request maintainership of Hashicorp vault plugin

[Joseph P]

Peter responded to my request, here is the forwarded email

-- Forwarded message -
From: Peter Tierno 
Date: Tue, Jul 30, 2019 at 5:28 PM
Subject: RE: Request maintainership of Hashicorp vault plugin
To: Joseph P 


Jospeh,



File a PR for
https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-hashicorp-vault-plugin.yml
adding your artifactory username to the developers list and link me to the
PR so I can approve.



Thanks

Pete



*From:* Peter Tierno
*Sent:* Tuesday, July 30, 2019 11:19 AM
*To:* Joseph P ; Jenkins Developers <
jenkinsci-dev@googlegroups.com>
*Subject:* RE: Request maintainership of Hashicorp vault plugin



Hi Jospeh,



I haven’t had the time to put much effort into maintaining this plugin so
having another maintainer would be great. I’ll work on that now.



Thanks

Peter



*From:* Joseph P 
*Sent:* Tuesday, July 30, 2019 4:49 AM
*To:* Peter Tierno ; Jenkins Developers <
jenkinsci-dev@googlegroups.com>
*Subject:* Request maintainership of Hashicorp vault plugin



Hi Peter and Jenkins Devs



I'd like to request maintainership of Hashicorp vault plugin.



https://github.com/jenkinsci/configuration-as-code-plugin/issues/968
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jenkinsci_configuration-2Das-2Dcode-2Dplugin_issues_968=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=MKh5FA41q5SP4mD7crrr-wwa49IYO-qRc4QIrDgAYDQ=7SWJ-3IbdzY1fOM4PlWEFCfBsXP5x-6qbF-qoUNTryU=Vzh3NQcXqNElIHqf_qUCn3kv2ISeQXkTnmq1JWHxZWE=>


https://github.com/jenkinsci/hashicorp-vault-plugin/pull/23#issuecomment-516285769
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jenkinsci_hashicorp-2Dvault-2Dplugin_pull_23-23issuecomment-2D516285769=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=MKh5FA41q5SP4mD7crrr-wwa49IYO-qRc4QIrDgAYDQ=7SWJ-3IbdzY1fOM4PlWEFCfBsXP5x-6qbF-qoUNTryU=h0Blxtn5AvAmb0xBY2bI4HaeH5e0_AYfNptg3zvflf8=>



We would like to move JCasC vault functionality to Hashicorp vault plugin
to avoid class loading issues between the two plugins.



https://github.com/jenkinsci/hashicorp-vault-plugin
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jenkinsci_hashicorp-2Dvault-2Dplugin=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=MKh5FA41q5SP4mD7crrr-wwa49IYO-qRc4QIrDgAYDQ=7SWJ-3IbdzY1fOM4PlWEFCfBsXP5x-6qbF-qoUNTryU=qTA2Npw-qK3ugMS5aqG_TONoGfa7AqlLSG3lxe513AE=>




JCasC vault code:

https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/plugin/src/main/java/io/jenkins/plugins/casc/impl/secrets/VaultSecretSource.java
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jenkinsci_configuration-2Das-2Dcode-2Dplugin_blob_master_plugin_src_main_java_io_jenkins_plugins_casc_impl_secrets_VaultSecretSource.java=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=MKh5FA41q5SP4mD7crrr-wwa49IYO-qRc4QIrDgAYDQ=7SWJ-3IbdzY1fOM4PlWEFCfBsXP5x-6qbF-qoUNTryU=MNs7CLlL4ahaOU-xPQ3sC2sRhADY6jO0K9vCWqhfLRU=>

https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/plugin/src/main/java/io/jenkins/plugins/casc/impl/secrets/vault
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jenkinsci_configuration-2Das-2Dcode-2Dplugin_tree_master_plugin_src_main_java_io_jenkins_plugins_casc_impl_secrets_vault=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=MKh5FA41q5SP4mD7crrr-wwa49IYO-qRc4QIrDgAYDQ=7SWJ-3IbdzY1fOM4PlWEFCfBsXP5x-6qbF-qoUNTryU=eX0fzL77oPWJnRunp5uPe4xq3D8dli21V3rgVAgwo-I=>




Venlig hilsen / Best regards

Joseph Petersen


--

This email has been scanned for spam and viruses by Proofpoint Essentials.
Click here
<https://us3.proofpointessentials.com/index01.php?mod_id=11_option=logitem_id=1564476567-p8M0xiN-wMqS_address=ptierno%40datapipe.com=1>
to report this email as spam.

-- 
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/CAHOoXs2Fj2DKuEqTw4K-Kp0dtE8PYeSmDu4QU9BFBng-Z%3D%2BrZg%40mail.gmail.com.

Re: Adding Atlassian Bitbucket server integration to recommended plugins

[Joseph P]

Excuse me Daniel?

Not actively maintained? Here I am trying to actively maintain 
https://github.com/jenkinsci/bitbucket-branch-source-plugin
Which btw supports both Bitbucket Server and Bitbucket clouid.

At no point did you try and reach out.

On Thursday, November 7, 2019 at 5:41:22 AM UTC+1, Daniel Kjellin wrote:
>
> Hello, 
> Yes indeed it is quite a mess. We are hoping to help clear this up a bit, 
> some of these plugins are not as actively maintained as they perhaps need 
> to be, and lack some features that we expect in modern plugins.
>
> regards
> Daniel
> On 6/11/19 5:09 pm, domi wrote:
>
> Thats great suggestion by Mark! 
> Please also make sure to clearly differentiate the “Bitbucket Server” 
> Plugin landscape form the “Bitbucket Cloud” landscape - its quite a mess 
> and hard to understand what is really needed for what and why.
> e.g. there are plugins like 
> - https://plugins.jenkins.io/bitbucket
> - https://plugins.jenkins.io/bitbucket-approve
> - https://plugins.jenkins.io/cloudbees-bitbucket-branch-source
> - https://plugins.jenkins.io/bitbucket-oauth
> - “Bitbucket for Blue Ocean”
> - https://plugins.jenkins.io/bitbucket-build-status-notifier
> - https://plugins.jenkins.io/stashNotifier
> - https://plugins.jenkins.io/violation-comments-to-stash
> - https://plugins.jenkins.io/bitbucket-pullrequest-builder
> - https://plugins.jenkins.io/bitbucket-approval-filter
> - https://plugins.jenkins.io/bitbucket-filter-project-trait
> - https://plugins.jenkins.io/bitbucket-push-and-pull-request
> - https://plugins.jenkins.io/bitbucket-scm-filter-aged-refs
> - https://plugins.jenkins.io/bitbucket-scm-filter-jira-validator
> - https://plugins.jenkins.io/bitbucket-scm-trait-commit-skip
> - https://plugins.jenkins.io/publish-to-bitbucket
> ...
>
> Some do support “Server” AND “Cloud” others don’t. Some even do the 
> exact/nearly same thing. And most of the plugins probably do not use a 
> common configuration but have to be configured individually to have access 
> to the service.
>
> As I’m a user of "bitbucket cloud” my self, I think this clearly shows a 
> problem: there is no coordination of what kind of plugins are build and how 
> they should work together. I understand this is also the power of Jenkins: 
> something is missing and your free to build a plugin to solve the issue. 
> But with each plugin published, the confusion for users/admins gets bigger. 
> I’m sure this issue is not only about bitbucket, the same thing (probably 
> even bigger) might be with GitHub and other areas.
>
> It would be really great to have some kind of documentation for a 
> topics/area which highlights (and maybe coordinates) the most common use 
> cases one has around different topics. e.g. GitHub Integration, Bitbucket 
> Cloud Integration, Bitbucket Server Integration, Kubernetes Integration, 
> Docker Integration, … some of these might overlap or must work with each 
> other - but sure there are a lot of hidden gems and simplifications which 
> should get better attention. Providing a bigger picture on a specific topic 
> (not just a single plugin) in the context of the whole community, might 
> even help to coordinate plugin creation and feature placing in existing 
> plugins AND deprecation of existing/duplicated plugins. Sure, such an 
> initiative would need someone being responsible, in terms of Bitbucket, I 
> think the best would be if Atlassian could step in.
>
> Sorry for misusing this thread, but the topic just happened to raise this 
> issue for me again and I’m sure I’m not the only one feeling this way...
>
> /Domi
>
>
> On 6 Nov 2019, at 05:24, Mark Waite > 
> wrote:
>
> We don't have a recommended install count, though I think that is a good 
> idea for discussion. 
>
> Would you be willing to join me in a Jenkins Online Meetup 
>  that can highlight the 
> new capabilities and the improvements provided by the Bitbucket Server 
> integration plugin?  
>
> We hosted the next generation Warnings plugin in a Jenkins Online Meetup 
>  and it helped users 
> understand the capabilities of the plugin and how it was improving the 
> experience compared to the previous plugin.  If your'e available in mid 
> December (17, 18, or 19), I could host that session in the same fashion.  
> If that week in December does not work for you, we could host it in early 
> January.
>
> If you're attending DevOps World | Jenkins World 2019 in Lisbon Dec 2-5, 
> we could have you present a lightning talk in the community booth 
> describing the plugin and what it provides.
>
> It would also be very nice to add a "Bitbucket" use case section to the 
> jenkins.io site, similar to the "GitHub 
> " use case section.  The plugin 
> documentation seems like a good start for that use case section.
>
> You might also consider a blog post on the new plugin as another way to 
> encourage users to 

Re: How to consume incrementals?

[Joseph P]

https://github.com/JetBrains/intellij-community/blob/fecfdd52f426cf1b2770edee7dc9d9ecab692441/plugins/maven/maven3-server-common/src/org/jetbrains/idea/maven/server/Maven3ServerEmbedder.java#L80

So close but no cigar 

On Tuesday, November 26, 2019 at 4:26:32 PM UTC+1, Jesse Glick wrote:
>
> On Mon, Nov 25, 2019 at 8:45 PM James Nord  > wrote: 
> >> IntelliJ simply does not read maven.config 
> > 
> > That's a shame. 
>
> Uh, is it not open source (at least the core part)? I fixed this bug 
> for NetBeans. Granted, I had a head start in that case. 
>

-- 
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/66ee9eef-f892-4adf-859d-c2ef2c0ed576%40googlegroups.com.

Re: GitHub Actions in jenkins-infra

[Joseph P]

Here is one PR for feedback: 
https://github.com/jenkins-infra/pipeline-library/pull/117/files

Been waiting an hour for deploy stage to get green build on GitHub.

So ci.jenkins.io is blocking 
I have considered removing the Jenkinsfile on some repos and just use 
GitHub or Travis and forget incremental exist

On Monday, October 7, 2019 at 5:29:00 PM UTC+2, Olblak wrote:
>
> So right now Olbak the ACI agents are failing creating large queue.
>
> ci.jenkins.io must be stable if you want us to continue using it.
>
>
> What I tried to say in my previous answer was, if the issue is 
> ci.jenkins.io then first let try to fix it.
> And if there is a another use case then let's discuss it.
> Regarding ci.j.io I'll probably start a document to collect feedback in 
> the coming days
>
> ---
> -> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
> ---
>
>
>
>
> On Fri, Oct 4, 2019, at 9:07 PM, Victor Martinez wrote:
>
> I do understand the value for using other CI/CD systems. My only concerns 
> are when there are different GitHub checks and some of them are green and 
> some others are red. That particular lack of reliability might imply more 
> steps to troubleshoot to debug logs in different systems. I like the idea 
> of dog-fooding even though when it does imply suffering some issues that 
> other CI/CD systems might not have.
>
> As a consequence of decoupling this from the ci.jenkins.io then it could 
> be more difficult to solve those issues in the ci.jenkins.io. That's 
> something quite valuable no just for us as users but also for other users 
> of the Jenkins project. 
>
> I'd be happy to discuss this in another thread, if it has not been 
> discussed recently,  provide more feedback and gather other's point of view.
>
> Cheers
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkin...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/097e8aff-f133-4bd8-8ca3-2af74488d047%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/3c289e1b-0919-4eb5-8f83-f0bb0ac580a5%40googlegroups.com.

Re: GitHub Actions in jenkins-infra

[Joseph P]

So right now Olbak the ACI agents are failing creating large queue.

ci.jenkins.io must be stable if you want us to continue using it.

On Thursday, October 3, 2019 at 12:18:34 PM UTC+2, Olblak wrote:
>
> While I understand the value of Github Actions, I would not enable it on 
> jenkins-infra unless we have a good reason to do so.
> I understand that ci.jenkins.io has limitations for various reasons and 
> if we have them other people will face the same issues.
> But using ci.jenkins.io is really useful to find, document and fix those 
> issues, so by default I would stick to it
> And depending on your need we may explore other options (or not) as we 
> already did in the past.
>
> ---
> -> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
> ---
>
>
>
>
> On Thu, Oct 3, 2019, at 10:45 AM, Oleg Nenashev wrote:
>
> GitHub Actions is pretty useful for organization automation, e.g. when you 
> want to run Dependabot, Release Drafter or other bot with some custom 
> configurations.
> I do not see how ci.jenkins.io could be used as a replacement for it 
> taking the permission considerations. And I doubt it worth investing in 
> making such use-cases supported on ci,jenkins.io
>
> But this is the only use-case I have in mind ATM.
>
>
> On Thursday, October 3, 2019 at 7:40:21 AM UTC+2, Rick wrote:
>
> Yes, I'm not sure what I want to do in the future. For example, if I don't 
> have the write permissions, I even cannot add a credential for my script. 
> And I know the infra Jenkins is very very important, I don't hope that I 
> mess up it.
>
> On Thu, Oct 3, 2019 at 12:28 PM Gavin  wrote:
>
> But what are you wanting to do? Simple Cron job that runs a script? Script 
> every commit?
>
> Or just want access just in case?
>
> On Wed., Oct. 2, 2019, 9:18 p.m. Rick,  wrote:
>
> Good question. I don't have the permission of infra Jenkins. It's not easy 
> if I want to reuse https://ci.jenkins.io. Plus, I need to consider more 
> things if I want to install a new plugin. For example, security problems 
> and so on.
>
> On Thu, Oct 3, 2019 at 11:22 AM Gavin  wrote:
>
> So I'm going to be the bad guy and ask why you need GitHub actions when 
> there's Jenkins. What steps are you needing done?
>
> On Wed., Oct. 2, 2019, 5:40 p.m. Rick,  wrote:
>
> Hi team,
>
> GitHub Actions is good. I want to try to use it in my repo 
> https://github.com/jenkins-infra/wechat/ 
> . But GitHub Actions 
> only support to enable it from the org level. So if you think that is ok, 
> then please help me to accomplish this. Thanks.
>
> Best regards,
> Rick
>
> -- 
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkin...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTG7X%2B%3DKTtz7VQwsODn1%3DBByPSdXMsnA708ZsZ%2BdeDDu9Q%40mail.gmail.com
>  
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkin...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusjNDd%3DZ81-2yM-HhiFqWBwydz8hjwxWRK%3DYLxZvNbrqA%40mail.gmail.com
>  
> 
> .
>
>
>
> -- 
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkin...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTEgkGAZ7eQ-Umfq5B58vqet2Dxzf95SA_rdW8P_Vq%3DnYw%40mail.gmail.com
>  
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkin...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuQm3ebVp1QL2V%2BwLu8DpUdtwWycVMNy7nZZxw3F%2Br80A%40mail.gmail.com
>  
> 

Re: GitHub Actions in jenkins-infra

[Joseph P]

I prefer the freedom, why restrict as long as it benefits the project and 
does not create any hindrance?

The reason for configuration-as-code to have both GitHub actions, Travis 
and ci.jenkins.io because we have experienced issues with both 
ci.jenkins.io and travis, so useful to being able to rely on more than one 
system.

On Friday, October 4, 2019 at 4:53:24 PM UTC+2, Victor Martinez wrote:
>
> I've seen some repos already using GitHub actions, Travis and some others 
> tools, which from a collaborator point of view doesn't look easy to follow 
> up what GitHub checks are valuable. 
>
> I'd prefer to avoid using GitHub actions as much as possible for the 
> benefit of a more stable ci.jenkins.io and encourage people to use it as 
> much as possible though. 
>
>
>
>

-- 
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/4a6e471f-c3dd-43d6-abd9-22c381a0fce2%40googlegroups.com.

Re: GitHub issues option in HOSTING

[Joseph P]

As a maintainer I find it very difficult that I have to use Jira for inter 
project work.

- Question what username you have on Jira not always the same
- find Jira searching very bothersome compared to some of the logical 
either code searches or be it issue searches.
  - Tim and I have been very thankful to be able to search across JenkinsCI 
org on github.
 Here is a good example of inter project communication: 
https://github.com/jenkinsci/bom/pull/172

- do not find components very useful.
  - Have to ask to be made default assignee
- That means going to IRC and poking people 
  - I might miss someone because only one can be assigned and people do not 
use watchers.
- find it a lot easier to look in the pom.xml or see commit history and 
ping those who might know something on github.
  - Getting these dreaded emails that just keep pilling up in our inbox .
- Prefer github that allows you to subscribe and unsubscribe and their 
web notifications JUST WORKS and even better with the new Notification beta.
  - often forget in Jira on the components that might interest me.
  - You have to be a JQL wizard to find anything again! 慄‍♂️

- Jira is slow compared to GitHub.

- Jira integration is just bad compared to what you can get from 
interlinking issues and pull requests on GitHub.

- Jenkins already has a bad situation of too many systems to handle 
messaging and source configuration management. Case in point being this 
mailing list 
  - Would be awesome to simplify on a single chat platform and a single SCM.

Again finding something again in Jenkins means I have to look either into 
mailing lists, Jira, confluence, IRC, gitter, slack or GitHub.
Perhaps I missed something.

Would be great if we could boil it down to two 勞

For crying out loud I had to ask on GitHub where to find this body of 
work: 
https://github.com/jenkinsci/configuration-as-code-plugin/pull/1264#issuecomment-581144871


On Sunday, February 2, 2020 at 3:10:33 PM UTC+1, Ullrich Hafner wrote:
>
> I don’t think that this is a good idea to support two different issue 
> tracker landing pages. As we encourage every body to host everything in 
> *one* location (i.e., GitHub) we should also enforce (well at least work 
> towards) a unique landing page for issues from our users. Otherwise users 
> are confused where to report issues, where to look for existing issues etc. 
>
> Also it makes inter-project communication for developers more complicated. 
> Very often issues are not only related to one component, and currently it 
> is quite easy to ping the component lead of the other component or to 
> reassign to a different component, etc. For instance, some time ago I 
> reported an incompatibility of a Jenkins plugin with the JCasC plugin: it 
> was very cumbersome to check if I should use GitHub or Jira to report the 
> issue. 
>
> What might make sense to discuss is, if we should replace Jira with GitHub 
> issues for all projects? I doubt that GitHub issues are already a 
> replacement for such a sophisticated tool like Jira, but maybe other 
> developers see that differently. 
>
> On the other hand, maybe we can improve our existing development process 
> so that the missing peaces from your requirements get integrated into Jira:
>
>
>- Easy subscription to issues / pull requests for repositories I 
>maintain / co-maintain
>
>
> This is quite easy in Jira as well.
>
>
>- Much easier to be a co-maintainer, with JIRA only the ‘component 
>lead’ gets notified by default, you _can_ create your own filters and 
>subscriptions, but it’s a lot more effort and most people (including me) 
>don’t do that.
>
>
> I think I don’t get the point here, maybe you need to clarify why Jira is 
> here more complex
>
>
>- Tight integration with SCM, issues are closed when a pull request is 
>merged, and you can click on a commit to see what version it was released 
>in, JIRA on the other hand is very out of sync.
>
>   
> We had that in Jira as well. The service was located on Kohsuke’s server 
> is now not running anymore. I think it would be awesome if we could restore 
> that integration. Maybe we can use the existing Jira Jenkins plugin for 
> that task. 
>
> Am 02.02.2020 um 12:13 schrieb Tim Jacomb  >:
>
> Hi
>
> GitHub issues use is growing in the ecosystem, many plugins are now using 
> it,
>
> Some benefits from my experience in using it:
>
>- Easy subscription to issues / pull requests for repositories I 
>maintain / co-maintain
>- Much easier to be a co-maintainer, with JIRA only the ‘component 
>lead’ gets notified by default, you _can_ create your own filters and 
>subscriptions, but it’s a lot more effort and most people (including me) 
>don’t do that.
>- Tight integration with SCM, issues are closed when a pull request is 
>merged, and you can click on a commit to see what version it was released 
>in, JIRA on the other hand is very out of 

Re: Happy Holiday

[Joseph P]

Here's a crazy thought, use GitHub?

It's a matter of creating appropriate repos and using GitHub issues / pull 
requests.

For announcement see
https://github.com/dotnet/announcements/issues

if you need some structure create a repo with the desired content structure.

GitHub can get pretty chatty.
If your discussing a persisted topic, create pull request, add a review to 
the topic line and let the thread messaging commence 殺

If you need to chat with your team? Create proper team structure and use 
GitHub Team Discussion (which atm is currently disabled in most teams 
https://github.com/orgs/jenkinsci/teams/core )

I do not see a need for a separate channel once GitHub's new notifications 
is out.
Totally loving being in the new notifications beta! 


On Friday, December 27, 2019 at 2:27:40 AM UTC+1, Marky Jackson wrote:
>
> The holidays are upon us and it’s time to relax and look back on the year 
> and at the roadmap for the future.
> With [gitter being down](
> https://twitter.com/gitchat/status/1210326466870882306?s=21) I think the 
> conversation should be had regarding moving off the archaic (gitter/irc) 
> communications used for the community and into a more robust form of 
> unified community bonding. 
> I would love to see the recently nominated board move to standardize, not 
> only our crumbling infrastructure but also the means by which we 
> communicate.
> With the CDF integration in the works I would also love to hear more about 
> how that looks. More so how this community adapts to that new world (and 
> their use of slack as a communication medium).
> We had a lot of emails about the integration and board nominations (along 
> with officers), I personally am eager to hear more about the plans and the 
> way to make rubber meet the road from all newly elected officials and 
> returning ones.
> Happy New Years all and thank you to all the contributors for all the hard 
> work you put in to this project, I for one am immensely thankful. 
>

-- 
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/0a75cf6f-5ebd-4cdd-8c03-89c87889a65e%40googlegroups.com.