Re: Config round trip failures in plugin unit tests?

['Gavin Mogan' via Jenkins Developers]

 I don't know which hasClassName is undefined as your linking to a local
file, and
https://github.com/jenkinsci/jenkins/blob/master/war/src/main/webapp/scripts/hudson-behavior.js#L1382
doesn't have that function being called.

As a side note, its probably to run `s/Element.hasClassName\((\w+)
,/$1.classList.contains/g` on that file and get rid of a bit more prototype

Gavin

On Wed, Nov 25, 2020 at 9:19 PM Mark Waite 
wrote:

> I'm trying to update the git plugin from requiring Jenkins 2.204.1 to
> Jenkins 2.222.x or newer.  The git plugin includes config round trip
> tests.  Those tests fail with a message:
>
> Cannot call method "hasClassName" of undefined (
> http://localhost:45517/jenkins/static/ddaf3eae/scripts/hudson-behavior.js#1382
> )
>
> The failure line matches a line in the hudson-behavior.js file for that
> Jenkins core version.
>
> A minimal example of the failure can be seen in
> https://ci.jenkins.io/job/Plugins/job/git-plugin/view/change-requests/job/PR-1005/2/testReport/
> and will also be visible in
> https://ci.jenkins.io/job/Plugins/job/git-plugin/view/change-requests/job/PR-1005/3/testReport/
>
> The second set of failures adds an example that does not use any git
> plugin features.  Source code for the failing test is available at
> https://github.com/jenkinsci/git-plugin/pull/1005/files
>
> Suggestions for the changes I should make so that the config round trip
> tests will run as expected?
>
> 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/46135ec9-8934-4daf-85b9-909d9e3b8305n%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/CAG%3D_DusABYiCEhxsV%2Bg653Qg8TYLicQ0v%3DE6hpwOSuxVRuxAUQ%40mail.gmail.com.

Config round trip failures in plugin unit tests?

[Mark Waite]

I'm trying to update the git plugin from requiring Jenkins 2.204.1 to 
Jenkins 2.222.x or newer.  The git plugin includes config round trip 
tests.  Those tests fail with a message:

Cannot call method "hasClassName" of undefined (
http://localhost:45517/jenkins/static/ddaf3eae/scripts/hudson-behavior.js#1382
) 

The failure line matches a line in the hudson-behavior.js file for that 
Jenkins core version. 

A minimal example of the failure can be seen 
in 
https://ci.jenkins.io/job/Plugins/job/git-plugin/view/change-requests/job/PR-1005/2/testReport/
 
and will also be visible 
in 
https://ci.jenkins.io/job/Plugins/job/git-plugin/view/change-requests/job/PR-1005/3/testReport/

The second set of failures adds an example that does not use any git plugin 
features.  Source code for the failing test is available 
at https://github.com/jenkinsci/git-plugin/pull/1005/files

Suggestions for the changes I should make so that the config round trip 
tests will run as expected?

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/46135ec9-8934-4daf-85b9-909d9e3b8305n%40googlegroups.com.

Jenkins 3.x

[James Nord]

Hi all,

with the recent weeklies we have a couple of changes (Acegi 
upgrade/table-to-div) that break compatibility in plugins.

Whilst many open source plugins have been updated and made compatible with 
the old and new version by the people making the changes (and compatability 
layers have been added as far as possible), there can be closed source ones 
that we have no sight of that can be broken.

Given this is an API compatibility breakage, I am wondering why don't we 
bump the version number to Jenkins 3.x  to signify the breaking API?

Regards

/James

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

Re: [LAST CALL] - Jenkins 2020 Elections voter registration, deadline on Nov 24

[Oleg Nenashev]

Hello,

Thanks to everyone who registered for the elections! The registration
period is now over, and we have closed the registration form. All new
registrants should have received the ballot emails from CIVS or the
clarification request emails.

The deadline for voting is Nov 27, 11PM UTC. If you do not see the ballot
emails, please follow the guidelines in the previous email.

Best regards,
Oleg Nenashev



On Tue, Nov 24, 2020 at 5:26 PM Oleg Nenashev 
wrote:

> Dear all,
>
> This is the last reminder about voter registration for the 2020 elections.
> The sign-up will be closed in less than 24 hours. If you would like to cast
> your vote during the elections but have not registered yet, please do it as
> soon as possible (voter registration guide
> ,
> registration form ).
>
> For more information about the candidates and the process, see this
> blogpost .
>
> *Already registered? *Thanks to everyone who has already voted! If you
> have registered but not voted yet, the deadline is Nov 27, 11PM UTC. If you
> have not received the ballot, here are notes:
>
>- We have verified all election registrations. If you registered using
>the Google Form or the email, you should have received two voter ballot
>emails OR a clarification request from the Jenkins 2020 election
>committee members. All emails have been sent to the email addresses
>specified during the registration
>- If you have not received the emails yet, check your inbox. Here is
>data for search:
>   - From: Jenkins 2020 Elections Committee (CIVS poll supervisor) <
>   c...@cs.cornell.edu>
>   - Email titles: "Poll: Jenkins 2020 Governance Board Election"
>- If you cannot find the email, please contact jenkins-2020-elections@
>googlegroups.com
>
> Best regards,
> Oleg Nenashev
> Jenkins 2020 Elections Committee
>
>
>

-- 
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/CAPfivLD%3DyrpmqfUr-GiU2iQ_%2BAA26hL8-dRRVHXBWU3oXaTM%3Dg%40mail.gmail.com.

Re: Jenkins Operator (aka kubernetes-operator) Community Project's Governance: Request for Revision

['Paweł Dolega' via Jenkins Developers]

Going to take a look at this right away. Apologies for the misuse of the 
name, we did analyse the trademarks but for some reason apparently 
completely missed that.

On it now, thank you 

On Wednesday, November 25, 2020 at 10:29:34 AM UTC+1 Oleg Nenashev wrote:

> Hi Pawel,
>
> I am looking forward to see the maintenance and development to be revived 
> in the repository. One thing that requires your immediate attention is the 
> Jenkins trademark usage in your product name. The name "Jenkins" is a 
> registered trademark in the USA (#4664929 
> , held by 
> Software 
> in the Public Interest, Inc. ) in order to protect 
> the project and users from confusing use of the term. To reduce the process 
> overhead and uphold our open-source spirit, we adopt the Linux kernel 
> policy on trademark usage. You need to apply for a sublicense 
>  if you are using 
> the term "Jenkins" as part of your own trademark or brand identifier for 
> Jenkins-based software goods or services. You can find more information 
> about the trademark policy here: https://www.jenkins.io/project/trademark/
>  
>
> "Jenkins Operator Service on Azure" does not fit the pre-approved 
> trademark usage patterns defined in the Linux Foundation guidelines 
> , and hence your 
> company needs to go through the trademark approval process to be able to 
> use "Jenkins" in such product name.
>
> Best regards,
> Oleg Nenashev
>
>
> On Tuesday, November 24, 2020 at 6:46:50 PM UTC+1 pdo...@virtuslab.com 
> wrote:
>
>> HI @Oleg 
>>
>> Thanks for your quick reply!
>>
>> So we have just announced Jenkins Operator Service for Azure here: 
>> https://virtuslab.com/jenkins-operator-service-on-azure/
>> This is just the beginning of the road for Jenkins Operator Service for 
>> major cloud providers and platforms. Jenkins Kubernetes Operator is be a 
>> commercial offering, backed by freely available OSS version.
>>
>> Now we have a week or two of breathing space and we are getting back to 
>> planning future interactions and community engagement. 
>>
>> Here are key points:
>> 0. Jenkins Kubernetes Operator is a base for business initiative for 
>> VirtusLab, therefore we are committed to building proper full time team 
>> working on it.
>> 1. OSS version is key part of our strategy and we don't intend to change 
>> that - our business model is based on managed marketplace offerings and 
>> support model (value added comparing to OSS that you can grab and install 
>> yourself).
>> 2. We do agree that current Jenkins Kubernetes Operator is complicated 
>> and not properly modulerized. It worked for our initial version, however 
>> for our future plans this cannot stay. Redesigning / decoupling 
>> architecture is a critical step forward.
>> 3. Given 2, we are now focusing on preparing proper roadmap, governance 
>> model and planning.
>>
>> Indeed point 2 will cause weird situation where there is 
>> simple-jenkins-operator targeting mostly OpenShift (not sure if this is the 
>> intention of @Akram's team, but my impression was that previous 
>> contributions were mostly targeted in this area) and 
>> jenkins-kubernetes-operator targeting wider audience (with eventually 
>> simplified architecture).
>>
>> I think it would be best discuss further cooperation going forward and we 
>> are happy to do that. 
>>
>> On Wednesday, November 18, 2020 at 5:59:52 PM UTC+1 Oleg Nenashev wrote:
>>
>>> Hello,
>>>
>>> Thanks a lot to Virtus Lab for the response! I hope we could revive this 
>>> discussion, all interested parties are welcome to participate.
>>>
>>> For the record, last week there was a hosting request from Red hat for 
>>> starting the new operator: 
>>> https://groups.google.com/g/jenkinsci-dev/c/oAWCXDbgcG4 . This request 
>>> has been approved by the community, hence right now we may end up in a 
>>> situation when there are 2 operators and a community split between them.
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Wednesday, November 18, 2020 at 4:54:38 PM UTC+1 pdo...@virtuslab.com 
>>> wrote:
>>>
 Hi all

 Quick introduction - I am CTO of VirtusLab, original company behind 
 Jenkins Kubernetes Operator.

 --

 First of all, apologies for prolonged time it took us to get back to 
 this. 

 To the point - *it is definitely useful and desirable to have well 
 understood governance rules* (and thanks Akram for submitting this 
 draft proposal  ). Details might need to be discussed but this is 
 definitely good starting point.

 To give you a little bit of background:
 Out step back from the project (in fact not a step back, rather 
 rethinking first principles) resulted due to our internal work related 
 very 
 much to Jenkins Kubernetes Operator.  We wanted to put some public work on 

Re: Jenkins Operator (aka kubernetes-operator) Community Project's Governance: Request for Revision

[Oleg Nenashev]

Hi Pawel,

I am looking forward to see the maintenance and development to be revived 
in the repository. One thing that requires your immediate attention is the 
Jenkins trademark usage in your product name. The name "Jenkins" is a 
registered trademark in the USA (#4664929 
, held by Software 
in the Public Interest, Inc. ) in order to protect 
the project and users from confusing use of the term. To reduce the process 
overhead and uphold our open-source spirit, we adopt the Linux kernel 
policy on trademark usage. You need to apply for a sublicense 
 if you are using the 
term "Jenkins" as part of your own trademark or brand identifier for 
Jenkins-based software goods or services. You can find more information 
about the trademark policy here: https://www.jenkins.io/project/trademark/ 

"Jenkins Operator Service on Azure" does not fit the pre-approved trademark 
usage patterns defined in the Linux Foundation guidelines 
, and hence your company 
needs to go through the trademark approval process to be able to use 
"Jenkins" in such product name.

Best regards,
Oleg Nenashev


On Tuesday, November 24, 2020 at 6:46:50 PM UTC+1 pdo...@virtuslab.com 
wrote:

> HI @Oleg 
>
> Thanks for your quick reply!
>
> So we have just announced Jenkins Operator Service for Azure here: 
> https://virtuslab.com/jenkins-operator-service-on-azure/
> This is just the beginning of the road for Jenkins Operator Service for 
> major cloud providers and platforms. Jenkins Kubernetes Operator is be a 
> commercial offering, backed by freely available OSS version.
>
> Now we have a week or two of breathing space and we are getting back to 
> planning future interactions and community engagement. 
>
> Here are key points:
> 0. Jenkins Kubernetes Operator is a base for business initiative for 
> VirtusLab, therefore we are committed to building proper full time team 
> working on it.
> 1. OSS version is key part of our strategy and we don't intend to change 
> that - our business model is based on managed marketplace offerings and 
> support model (value added comparing to OSS that you can grab and install 
> yourself).
> 2. We do agree that current Jenkins Kubernetes Operator is complicated and 
> not properly modulerized. It worked for our initial version, however for 
> our future plans this cannot stay. Redesigning / decoupling architecture is 
> a critical step forward.
> 3. Given 2, we are now focusing on preparing proper roadmap, governance 
> model and planning.
>
> Indeed point 2 will cause weird situation where there is 
> simple-jenkins-operator targeting mostly OpenShift (not sure if this is the 
> intention of @Akram's team, but my impression was that previous 
> contributions were mostly targeted in this area) and 
> jenkins-kubernetes-operator targeting wider audience (with eventually 
> simplified architecture).
>
> I think it would be best discuss further cooperation going forward and we 
> are happy to do that. 
>
> On Wednesday, November 18, 2020 at 5:59:52 PM UTC+1 Oleg Nenashev wrote:
>
>> Hello,
>>
>> Thanks a lot to Virtus Lab for the response! I hope we could revive this 
>> discussion, all interested parties are welcome to participate.
>>
>> For the record, last week there was a hosting request from Red hat for 
>> starting the new operator: 
>> https://groups.google.com/g/jenkinsci-dev/c/oAWCXDbgcG4 . This request 
>> has been approved by the community, hence right now we may end up in a 
>> situation when there are 2 operators and a community split between them.
>>
>> Best regards,
>> Oleg
>>
>> On Wednesday, November 18, 2020 at 4:54:38 PM UTC+1 pdo...@virtuslab.com 
>> wrote:
>>
>>> Hi all
>>>
>>> Quick introduction - I am CTO of VirtusLab, original company behind 
>>> Jenkins Kubernetes Operator.
>>>
>>> --
>>>
>>> First of all, apologies for prolonged time it took us to get back to 
>>> this. 
>>>
>>> To the point - *it is definitely useful and desirable to have well 
>>> understood governance rules* (and thanks Akram for submitting this 
>>> draft proposal  ). Details might need to be discussed but this is 
>>> definitely good starting point.
>>>
>>> To give you a little bit of background:
>>> Out step back from the project (in fact not a step back, rather 
>>> rethinking first principles) resulted due to our internal work related very 
>>> much to Jenkins Kubernetes Operator.  We wanted to put some public work on 
>>> hold until we have this sorted out. We were hoping for the work to be 
>>> concluded in Oct, but (as is often the case with software development) we 
>>> got some delays and currently aiming at having work concluded next week.
>>>
>>> *We definitely see a case for cooperation and making Jenkins Kubernetes 
>>> Operator more popular e.g. in environments like Open Shift.*  (which I 
>>> believe is 

Crawler for AdoptOpenJDK is not returning all releases

[Mads Mohr Christensen]

Currently the crawler is using the v2 api and this is currently not
returning all releases.

I've created a PR that fixes this by switching to v3 api:
https://github.com/jenkins-infra/crawler/pull/93

https://issues.jenkins.io/browse/JENKINS-62013

Could someone please review and merge this as soon as possible?

Mads.

-- 
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/CALWGXhcCfZ9PhztiWE%3DBDqSY-j1Gy%2BN9ePaGABzm7xjcRAez3w%40mail.gmail.com.