Outreachy update

[Tracy Miranda]

Hi all,

At the last governance meeting I shared an Outreachy update and I will
reshare and add to it here:
   * The last round of Outreachy all concluded successfully, Matt Sicker
wrote a post wrapping it all up
https://jenkins.io/blog/2019/03/28/outreachy-review/
* Thanks to Matt & all mentors, organizers & supporters - plus of course
David & Latha our interns.
* The application period for next round of Outreachy has completed and I am
pleased to share that we have had 2 applicants for the Audit Log plugin
project.
* Matt Sicker will be leading the mentoring and is happy for the project to
take on 2 mentees again this year.
* We have however, only committed to 1 round of funding so far.
* For the last round Outreachy funded our 2nd intern from the general fund.
This round they have had 11 requests for the general fund so will be less
likely to be able to fund a second again.
* I've added this to agenda for tomorrow's governance

meeting so we can discuss and consider options.

Please let me know if any questions/comments beforehand, otherwise join in
at the meeting to discuss.

Tracy

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

CD.Foundation Update

[Tracy Miranda]

Hi all,

I want to share an update on the various CD.Foundation activities
happening.



*1. *Governing Board (GB)
for CDF met for the first time last week. While GB meetings are private I
can share that the main resolution passed was approving the budget for CDF.
Which means we now have high level allocation for various things including
infrastructure, outreach, etc so we can now begin operations in earnest.
Additionally CDF expect to shortly work out the process for electing a
committer/maintainer rep to the GB, we hope to hold the election in May.

*2. *Technical Oversight Committee (TOC)
* – *The TOC is still being formed but
nevertheless TOC meetings are underway and are open to anyone to attend or
view recordings after. Kohsuke Kawaguchi is the representative for Jenkins
and also the TOC chair. The first tasks are to establish TOC principles
 and project acceptance process
.

*a. *TOC mailing list is here: https://lists.cd.foundation/g/cdf-toc

*b. *TOC Github (including calendar) is here: https://github.com/
cdfoundation/toc

*3. *Events – we are actively working towards having a number of CDF
collocated events or presence at any conferences. The first one is a
collocated CD Summit at KubeCon Barcelona
,
details on this page somewhere
https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019/co-located-events/

*4. *Jenkins in CDF – the process of moving Jenkins to CDF is underway
and necessary legal and asset transfer tasks are being worked through.
Additionally, we are doing an audit of infra requirements (for Jenkins and
other projects) and outreach requirements so that we can work out how these
can be supported in CDF in a sustainable way we can build on. Normal
project operations should be unaffected, please keep those pull requests
flowing and those community activities going!

*a. *More concretely, we have a stats site:
https://devstats.cd.foundation/ to capture project stats for CDF projects.
Any feedback welcome!



I’ve tried to capture a snapshot of all the things going on but no doubt
I’ve missed some! Do please let me know if you have any
questions/comments(on or off list).



Regards,

Tracy

-- 
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/CACTaz6rTCrckN%3DvcHdDB8G%2BpAM%2B4ey6HcqHQkj73_%3Dnjy7PvdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: AWS Secrets Manager Credentials Provider plugin

[Chris Kilding]

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 found), and an InterruptedException if the lookup times out.

However the guide also says that if there is already a de-facto standard 
credential type, one’s own credential Provider should use that.

In my case I need to extend BaseStandardCredentials / implement 
StringCredentials, and look up the AWS Secret Value within getSecret(). However 
the StringCredentials interface does not allow IOException or 
InterruptedException to be thrown by implementations.

The guide even acknowledges that this was a design flaw in the standard 
credentials types... but unfortunately it doesn’t say what to do instead, to 
work around this.

So, should an implementation of StringCredentials#getSecret()...

- Throw an unchecked exception?
- Return null?
- Something else?

Chris

On Tue, 9 Apr 2019, at 1:41 PM, Stephen Connolly wrote:
> 
> 
> On Tue, 9 Apr 2019 at 11:57, Chris Kilding  > wrote:
>> __
>> Hi Stephen,
>> 
>> When I started building the plugin my basis was a combination of your guide 
>> and the Kubernetes Credentials Provider.
>> 
>> The following sections of your guide were particularly valuable right from 
>> the start of development:
>> 
>> - The caching strategy guide for remote credentials providers (cache 
>> metadata for N minutes, retrieve secret data live).
>> - “Implementing a new Credentials type” (when and how to extend the standard 
>> types properly, when to make a new type).
>> 
>> I’m finding the guide is becoming more understandable (and I can get more 
>> out of it) now I’ve learned the basic architecture of Jenkins plugins. In 
>> the beginning it’s easier to work off an existing plugin’s code, but now I 
>> can read more of your guide and see implementation mistakes that need to be 
>> corrected.
>> 
>> Much like any other technical manual, its utility for the reader increases 
>> with the reader’s knowledge of the subject. Many thanks for writing it :)
> 
> Glad to hear. I wasn't happy moving my focus away from Jenkins plugins 
> without leaving guides to the community for the stuff I believe to be 
> important (credentials and scm-api). I am glad you have found (and are still 
> finding) utility in the content. Feel free to create PRs with any suggested 
> improvements as I am paying attention... just not as frequently ;-)
> 
> - Stephen
> 
>> 
>> 
>> Chris
>> 
>> On Mon, 8 Apr 2019, at 8:00 PM, Stephen Connolly wrote:
>>> It would be great to get any feedback on the docs I left for writing such 
>>> things: 
>>> https://github.com/jenkinsci/credentials-plugin/blob/master/docs/implementation.adoc#implementing-a-new-credentialsprovider
>>> 
>>> On Thu 4 Apr 2019 at 17:10, Chris Kilding >> > wrote:
 __
 Hi,
 
 That sounds good - we’re happy to host in jenkinsci and make the plugin 
 available through the built-in Jenkins plugin manager.
 
 As Jesse suggested we did indeed base our plugin on the Kubernetes 
 credentials provider.
 
 Would we be able to do it all in a single Github repo inside the jenkinsci 
 org? Or would we have to run a separate upstream repo in our own Github 
 account, with a fork under jenkinsci? (We’d prefer to go with the first 
 option and cut out the middleman, if that makes sense.)
 
 On Thu, 4 Apr 2019, at 4:51 PM, Daniel Beck wrote:
> Can't wait to check this out. Thanks for publishing it!
> 
> > On 4. Apr 2019, at 16:21, Chris Kilding  > > wrote:
> > 
> > We’re initially thinking it should be a Github repo under the 
> > ‘jenkinsci’ or ‘aws’ organisations, with our own engineers added to 
> > that repo as external collaborators. (These would seem to be the most 
> > natural homes for the plugin.) But we’re open to other suggestions :)
> 
> We require that plugins distributed by the Jenkins project be hosted in 
> the jenkinsci organization (with some exceptions grandfathered in). So if 
> you want to make it as easy as possible to install with the built-in 
> plugin manager, I would recommend you host in jenkinsci.
> 
> Docs for this (these largely superseded the wiki): 
> https://jenkins.io/doc/developer/publishing/requesting-hosting/
> 
> -- 
> 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 
> 

Re: Jenkins version - minimum dependency in pom vs. test harness required dependency

[Jesse Glick]

On Tue, Apr 23, 2019 at 5:47 AM Ullrich Hafner  wrote:
> Is it possible, to specify a different minimum Jenkins version in a plugin 
> for the runtime and the tests?

Unfortunately it is not.

> Currently my plugin is compatible with Jenkins 2.89.1 (from an API point of 
> view).
>
> However, due to some dependencies in my integration tests (declarative 
> pipeline, etc.) the tests that use Jenkins test harness and the injected 
> tests fail since they want a dependency to a Jenkins version >= 2.150.1.

Then you need to choose. Either update your `jenkins.version` to
something less ancient, which is what I recommend; or adjust your
integration tests to use older versions of dependencies which are
still compatible with 2.89.1.

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

Re: mvn deploy vs mvn release:prepare release:perform

[Jesse Glick]

On Tue, Apr 23, 2019 at 3:19 AM Rajeev Ranjan  wrote:
> do I need to do mvn release againg or mvn deploy only. What's the difference 
> between the two?

`release:perform` internally runs `deploy`, after `release:prepare`
has done a lot of preparation. A naked `mvn deploy` is generally only
good for uploading snapshots, not releases, except for advanced use
cases I will not discuss.


If you were getting permission denied errors releasing, then there may
have been something wrong in

https://github.com/jenkins-infra/repository-permissions-updater/pull/1103

such as a mistyped (LDAP) login ID, or maybe there was something wrong
with GitHub. You did not quote the actual error message so it is not
possible to help you much.

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

Re: Jenkins version - minimum dependency in pom vs. test harness required dependency

[Ullrich Hafner]

Actually I used it as parameter in my Runner configuration in IntelliJ. 
Using it on the command line in maven seems to work indeed! Thanks!

> Am 23.04.2019 um 13:24 schrieb Mark Waite :
> 
> Passing -Djenkins.version=2.164.1 is the technique that many of the plugins 
> now use to test Java 8 and Java 11 compilation and test.  Can you further 
> describe how it fails when you use that argument to maven?  It may be a 
> failure that is familiar to those working on Java 11.
> 
> On Tue, Apr 23, 2019 at 4:47 AM Ullrich Hafner  > wrote:
> Is it possible, to specify a different minimum Jenkins version in a plugin 
> for the runtime and the tests? 
> 
> Currently my plugin is compatible with Jenkins 2.89.1 (from an API point of 
> view). 
> 
> However, due to some dependencies in my integration tests (declarative 
> pipeline, etc.) the tests that use Jenkins test harness and the injected 
> tests fail since they want a dependency to a Jenkins version >= 2.150.1.
> I tried to use -Djenkins.version=2.150.1 when starting the test but this 
> seems not to 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/610AEA80-3D9F-454C-B363-BBA35FA66DDB%40gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> Thanks!
> Mark Waite
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHLkeCaSbSR_g5kzWsWPMTa7L0ZemRCH8JbT%2BT9yavLiw%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: Jenkins Google Season of Docs Special Interest Group

[Mark Waite]

That seems like an even better idea, to formalize the docs special interest
group and let Google Season of Docs operate under that SIG.  I'll modify
the pull request accordingly.

On Mon, Apr 22, 2019 at 11:30 PM Oleg Nenashev 
wrote:

> I do not think we need a GSoD SIG... Docs SIG with a GSoD sub-project
> under its umbrella - 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/96010702-6fb5-4aeb-816a-d17b7a9d1a26%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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

Re: Jenkins version - minimum dependency in pom vs. test harness required dependency

[Mark Waite]

Passing -Djenkins.version=2.164.1 is the technique that many of the plugins
now use to test Java 8 and Java 11 compilation and test.  Can you further
describe how it fails when you use that argument to maven?  It may be a
failure that is familiar to those working on Java 11.

On Tue, Apr 23, 2019 at 4:47 AM Ullrich Hafner 
wrote:

> Is it possible, to specify a different minimum Jenkins version in a plugin
> for the runtime and the tests?
>
> Currently my plugin is compatible with Jenkins 2.89.1 (from an API point
> of view).
>
> However, due to some dependencies in my integration tests (declarative
> pipeline, etc.) the tests that use Jenkins test harness and the injected
> tests fail since they want a dependency to a Jenkins version >= 2.150.1.
> I tried to use -Djenkins.version=2.150.1 when starting the test but this
> seems not to 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/610AEA80-3D9F-454C-B363-BBA35FA66DDB%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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

Jenkins version - minimum dependency in pom vs. test harness required dependency

[Ullrich Hafner]

Is it possible, to specify a different minimum Jenkins version in a plugin for 
the runtime and the tests? 

Currently my plugin is compatible with Jenkins 2.89.1 (from an API point of 
view). 

However, due to some dependencies in my integration tests (declarative 
pipeline, etc.) the tests that use Jenkins test harness and the injected tests 
fail since they want a dependency to a Jenkins version >= 2.150.1.
I tried to use -Djenkins.version=2.150.1 when starting the test but this seems 
not to 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/610AEA80-3D9F-454C-B363-BBA35FA66DDB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backporting for LTS 2.164.3 started

[Oliver Gondža]

Baptiste, thanks for the suggestion but I lean towards skipping this for 
2.164.3.


To the best of my understanding, this issues was present for 6 entire 
LTS lines (possibly without being reported). Given the consequences are 
duplication of a renamed agent after restart, I dare to dispute this is 
a blocker issue to begin with.


Or do I miss something?

On 19/04/2019 09.53, Baptiste Mathus wrote:
Just added lts-candidate on 
https://issues.jenkins-ci.org/browse/JENKINS-56403 merged yesterday.
I think it could be considered given the regression fix PR is fairly 
small and has had dedicated tests added: 
https://github.com/jenkinsci/jenkins/pull/3925


Do you think it would be eligible to backporting in upcoming .3?

Thanks

Le lun. 15 avr. 2019 à 11:54, Oliver Gondža > a écrit :


Backporting has started and the RC is scheduled for 2019-04-24.

Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
Fixed:
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.164.3-fixed
Rejected:
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.164.3-rejected
-- 
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/845a8da6-c20e-1f50-e69e-319fe283b1f7%40gmail.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/CANWgJS5kQG7s-Ex1PQhO%3DUYxC_Hb3fNXtKGjhgrC6k%3Df8afOVA%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.



--
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/2deacef6-a160-936a-3b41-d523f97f2fa2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

mvn deploy vs mvn release:prepare release:perform

[Rajeev Ranjan]

Hi team,
I was trying to release "
https://github.com/jenkinsci/uipath-automation-package-plugin; with "mvn 
release:prepare release:perform -Dusername=...  -Dpassword =... ", however 
I was facing facing permission denied because of credentials.
After that I followed the steps as per the doc to start an ssh-agent and 
import private key, and ran mvn deploy.
After that I can see the plugin in "https://repo.jenkins-ci.org/releases/;. 
I am just curious, do I need to do mvn release againg or mvn deploy only. 
What's the difference between the two?

Also I was under the impression that, plugins will go to "
https://repo.jenkins-ci.org/public/;. What is this reo for?

Regards,
Rajeev Ranjan

-- 
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/1148e8fa-277b-4d50-a7b6-1c048060dbc0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.