Adoption Request for Favorite View Plugin

[Thomas Vincent]

Link to the Plugin to Adopt: https://plugins.jenkins.io/favorite-view/ 

Status of the Plugin: For Adoption

Link(s) to Pull Requests You Want to Deliver: 
https://github.com/jenkinsci/favorite-view-plugin/pull/4
https://github.com/jenkinsci/favorite-view-plugin/pull/5

GitHub Username/ID: thomasvincent 

Jenkins Infrastructure Account ID: tomasvin

Link to the "Repository Permission Updater" PR: 
https://github.com/jenkins-infra/repository-permissions-updater/pull/3886

-- 
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/52d7e5b4-90de-4ef2-af4e-e5547543a554n%40googlegroups.com.

Adopting lucene-search plugin

[Thomas Dräbing]

Hi,

I would like to adopt the lucene-search plugin [1-2], since I am using it 
as a dependency for the gerrit-checks-api plugin. I would like to use it 
with newer Jenkins versions, but my PR to support Java 11 was not reviewed.
I have asked the current maintainers via a GitHub issue [3], whether they 
would add me as a maintainer, but I didn't get a response in over 2 weeks.

Status of the plugin: "abandoned" (inferred due to lack of responses)
Links to PRs: [4-5]
Username on GitHub: tdraebing
Jenkins infrastructure account id: tdraebing
"Repository Permission Updater" PR: [6]

Thanks and best regards,
Thomas

[1] https://github.com/jenkinsci/lucene-search-plugin
[2] https://plugins.jenkins.io/lucene-search/
[3] https://github.com/jenkinsci/lucene-search-plugin/issues/63
[4] https://github.com/jenkinsci/lucene-search-plugin/pull/61
[5] https://github.com/jenkinsci/lucene-search-plugin/pull/57
[6] https://github.com/jenkins-infra/repository-permissions-updater/pull/3282

-- 
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/bf71e2b3-e666-4fd8-ad44-dbd492528651n%40googlegroups.com.

Re: Help maintaining role-strategy-plugin

[Thomas Nemer]

Hello Mark,

Thanks for this nice documentation.
I'll read it entirely soon (and have a look at the videos too), but at 
first glance, it seems I'm already familiar with all the tools and 
practice described.


I already have made this 
<https://github.com/jenkinsci/role-strategy-plugin/pull/154> pull 
request, which motivated the idea of becoming a maintainer for the plugin.


Thomas Nemer

On 29/11/2021 17:52, Mark Waite wrote:



On Monday, November 29, 2021 at 9:42:35 AM UTC-7 Thomas Nemer wrote:

Hello Jenkins Developers,

It seems the role-strategy-plugin could need some help for
maintenance,
and I'm willing to offer my help on that subject.
Oleg Nenashev proposed to discuss that here.

I am globally not familiar with this process, but as I understand,
there
is a permission manager tool that needs to be updated so that it is
possible to push on the binary repository and permissions needed
on the
git repo, but that's about all I know ^^

As I said to Oleg, I'm far from being an experienced plugin
developer,
I've only created a couple of PRs on nested-view plugin and I have
one
PR waiting on role-strategy-plugin which will probably need some
rework
before being acceptable, but I'm using the plugin on a daily
basis, and
would be happy to help making it properly maintained.


Thanks very much for your willingness to contribute to the plugin and 
to become a maintainer.


If one of the maintainers of the plugin is willing to approve you as a 
maintainer, you can be made a maintainer immediately.  If they're not 
ready to do that yet, you can start contributing to the plugin through 
a series of pull requests. The "Contributing to Open Source" workshop 
<https://docs.google.com/document/d/1PKYIpPlRVGsBqrz0Ob1Cv3cefOZ5j2xtGZdWs27kLuw/edit#heading=h.hvd0nm6pz5o4> 
from DevOps World 2021 suggests a series of small steps that help the 
plugin and help a new contributor become familiar with the plugin.  
That document includes links to a five part video series 
<https://docs.google.com/document/d/1PKYIpPlRVGsBqrz0Ob1Cv3cefOZ5j2xtGZdWs27kLuw/edit#heading=h.oz0bxvhyvna5> 
that illustrates many of the steps.


Mark Waite


Thomas Nemer

--
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/dfb11be7-e55e-4b25-9af2-e5c702ccfe40n%40googlegroups.com 
<https://groups.google.com/d/msgid/jenkinsci-dev/dfb11be7-e55e-4b25-9af2-e5c702ccfe40n%40googlegroups.com?utm_medium=email_source=footer>.


--
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/41132edc-aa93-1a97-f2dd-5b27685f0a21%40fortytwo.fr.

Help maintaining role-strategy-plugin

[Thomas Nemer]

Hello Jenkins Developers,

It seems the role-strategy-plugin could need some help for maintenance, 
and I'm willing to offer my help on that subject.

Oleg Nenashev proposed to discuss that here.

I am globally not familiar with this process, but as I understand, there 
is a permission manager tool that needs to be updated so that it is 
possible to push on the binary repository and permissions needed on the 
git repo, but that's about all I know ^^


As I said to Oleg, I'm far from being an experienced plugin developer, 
I've only created a couple of PRs on nested-view plugin and I have one 
PR waiting on role-strategy-plugin which will probably need some rework 
before being acceptable, but I'm using the plugin on a daily basis, and 
would be happy to help making it properly maintained.



Thomas Nemer

--
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/51a751e1-58c7-8b9a-4411-9f430d879d0d%40fortytwo.fr.


OpenPGP_0xDAFF6CA484B77CAA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Terminology Updates

[Thomas de Grenier de Latour]

As a native French speaker too, I fear that "conductor" would be 
difficult to translate in French. With its "musical director" meaning, 
it would be "chef d'orchestre", which is so explicit that it leaves 
little room for a figurative sense (and it's also really long). The word 
"conducteur" exists in French, but not with this meaning (it's either an 
electrical wire, or a car driver; none of which being a good analogy for 
the work Jenkins does).


To stay in the same lexical field, I would rather go with "maestro" (a 
skilled / well-known conductor), because this word would be understood 
as-is at least by Italian (obviously), English, French, and Spanish 
speakers (maybe German speakers too, maybe others). Plus, for people 
used to the historical Jenkins terminology, it gives an etymological 
hint that it is indeed the new word for "master", and not a 
new/different concept.


Now, that being said, you can't go wrong with "controller" I think, so 
it would have my preference too. I don't think the potential confusion 
with k8s controllers is an issue (when writing about Jenkins deployment 
on K8S, use "K8S controller" / "Jenkins controller" to avoid any 
ambiguity). The word is so widely used in IT that we can assume most 
languages already have a well established translation for it. In French, 
it's "contrôleur" (fun fact: the most common meaning for "contrôleur", 
outside of the IT field, is "bus/train conductor").


Anyway, I guess my point here is that picking the new terminology should 
be done with i18n in mind. Maybe double-check with active i18n 
contributors for the most spoken languages that they have no issue with 
the candidate words, or something like that.


Thomas.

Le 15/06/2020 à 17:03, Angélique Jard a écrit :
My preference goes to "controller", "server" make me think somehow to 
the hardware physical machine. "Coordinator" is fine also (in the link 
tools.ietf in previous post) but a bit hard to pronounce.


As a non english native speaker (but french), I have some issue with 
"valet" and "majordomo" which have fix gender in french and are all 
male. I know that it's not like that in english but I think it's better 
to tell it now.


As a music player I also like "conductor" (as musical director) this is 
how I see my Jenkins instance when I use it, that orchestrate agents, 
Jenkinsfile could be the music sheet :) 

On Monday, June 15, 2020 at 4:00:27 PM UTC+2 Antonio Muñiz wrote:

In spanish the term "Master" ("Maestro"), when used in isolation (no
"slave" in the context), has no negative connotations. Its main use
is to describe someone very skilled in some matter (often used for
artisans).
I might be suffering of language bias, just wanted to give some "non
english native speaker" perspective to the conversation.

El lun., 15 jun. 2020 a las 7:56, Justin Harringa
() escribió:

Personally I thank the community for having already starting
down this path.

I tend to like leader or controller from

https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1
but I could also see server working. The difficulty I would see
with primary/active is that folks who run Jenkins would have a
bit of a conflict of terminology there.

Take care all.

-- 
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/3411fed5-7e21-454a-b285-f719f07c1b3ao%40googlegroups.com.



-- 
* Antonio Manuel Muñiz

* amunizmartin.com <http://amunizmartin.com>
* amuniz...@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 jenkinsci-dev+unsubscr...@googlegroups.com 
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com 
<https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com?utm_medium=email_source=footer>.


--
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/f6b87d27-763f-87f6-dfbd-5d77b410af43%40free.fr.

REQ::Power BI Developer _Denver, CO_12 months

[Sam Thomas]

*Requirement details:   *

*Job title:  **Power BI Developer*

*Location: Denver, CO*

*Duration: 12+ months*



*Job Description*:



Very experienced in SQL and Power BI 6+ years

Able to Create Power BI dashboards and reports. Design, build and deploy BI
solutions

Development of visualization tools as part of the dashboard.

Designing and developing tabular cubes/models for optimal performance and
ease of use.

Implement, enhance, triage existing stored procedures and SSIS packages
employed in the overnight or real-time integration with source systems.

Work with business and technical project teams to design/develop
interactive data visualization, using Power BI, based on business needs.

Gather business requirements from the business for data / analytics
reporting.

Design new visualization combining previously disparate data types.

Maintain current BI data model. Develop and administer new data models and
enhancements.

Coordinate with internal stakeholders to determine business reporting and
analysis requirements.

Metrics to track strategic initiatives based on transactional sales data


-- 
*Thanks & Regards,*
Sam Thomas

-- 
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/CAHpqF_bfs6NeWCygB7o%3D%3DaGc0t5Jtw-G%3DQXbkyd5MJvw3AAPrg%40mail.gmail.com.

REQ:: QA Manager/Test Manager _ Chicago, IL _ 12+ Months

[Sam Thomas]

*KINDLY REFER IF YOU HAVE ANY FRIENDS INTERESTED FOR ANY OF THE BELOW
OPENINGS*

*Immediate Interview for Chicago*

*Requirement details:   *

*Job Title: Test Manager/QA Manager*

*Location: Chicago, IL*

*Duration: 12+ Months*

*Start Date: Immediate*



*Job Description*:



Minimum *10 + years* of testing experience is required

2 to 3 years *Test Management/QA Manager* experience at the program level

Hands-on experience in testing with more focus on *Manual testing*,
Automation experience of 2-3 years if fine

Good experience in testing concepts, testing frameworks

Must have experience in *SOAP/REST API Web Services testing, Postman*

Must have experience in Database Concepts, RTM (Requirement Traceability),
Configuration Management

Offshore onsite model exposure


-- 
*Thanks & Regards,*
Sam Thomas

-- 
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/CAHpqF_atVTZiLEsGczynW8X_ZttSXGiZX%3DJrTTgTp6_GmAtq7Q%40mail.gmail.com.

REQ:: QA Tester/Lead(Functional) _ Chicago, IL _ 12+ Months

[Sam Thomas]

*KINDLY REFER IF YOU HAVE ANY FRIENDS INTERESTED FOR ANY OF THE BELOW
OPENINGS*

*Any Visa is fine (NO H4EAD’s & CPT’s )*

*Need 1 recent Project Timesheet and PP number*

*Need consultant whose DOB should 1990 & Below*

*Need consultant who can take Video Interview  7PM CST for Chicago, IL*

*Requirement details: *

*Job title: Sr.QA Tester/Lead(Functional)*

*Location: Chicago, IL/Houston, TX*

*Duration: 12+ Months*

*Start Date: Immediate*





*Job Description*:



Overall 6-8+  Years of Experience in testing with more focus on Manual
testing, and Automation experience of 1-2 years if fine

Strong experience in testing concepts, testing frameworks

Must have experience in SOAP/REST API Web Services testing/ Postman

Must have experience in Database Concepts SQL, RTM (Requirement
Traceability), Configuration Management

Offshore onsite model exposure


-- 
*Thanks & Regards,*
Sam Thomas

-- 
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/CAHpqF_ZE6C4ck7wr%2BWC5gvfET%2BWj80ZpFYuATqH8%3DgJdKWoCOw%40mail.gmail.com.

REQ:: QA Tester/Lead(Functional) _ Chicago, IL/Houston, TX _ 12+ Months

[Sam Thomas]

*KINDLY REFER IF YOU HAVE ANY FRIENDS INTERESTED FOR ANY OF THE BELOW
OPENINGS*

*Any Visa is fine (NO H4EAD’s & CPT’s )*

*Need 1 recent Project Timesheet and PP number*

*Need consultant whose DOB should 1990 & Below*

*have to take  Interviews @ 7PM CST for Chicago, IL*

*Requirement details: *

*Job title: Sr.QA Tester/Lead(Functional)*

*Location: Chicago, IL/Houston, TX*

*Duration: 12+ Months*

*Start Date: Immediate*





*Job Description*:



Overall 6-8+  Years of Experience in testing with more focus on Manual
testing, and Automation experience of 1-2 years if fine

Strong experience in testing concepts, testing frameworks

Must have experience in SOAP/REST API Web Services testing/ Postman

Must have experience in Database Concepts SQL, RTM (Requirement
Traceability), Configuration Management

Offshore onsite model exposure


-- 
*Thanks & Regards,*
Sam Thomas

-- 
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/CAHpqF_Ykm8mQ2vVMgCXkxdCbTgNjtAjzz7MQGf6cVBehBTA59w%40mail.gmail.com.

ExtensionList.lookupSingleton(): Expected 1 instance of org.example.FooStore but got 2

[Thomas Weißschuh]

Hello all,

Recently I encountered the following exception while deploying an plugin to our
acceptance jenkins instance:

java.lang.IllegalStateException: Expected 1 instance of org.example.FooStore 
but got 2
at hudson.ExtensionList.lookupSingleton(ExtensionList.java:450)
at 
org.example.MyFlowExecutionListener.onRunning(MyFlowExecutionListener.java:33)
at 
org.jenkinsci.plugins.workflow.flow.FlowExecutionListener.fireRunning(FlowExecutionListener.java:54)
at 
org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:321)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)

As I am not sure how this could have happened and was so far not able to
reproduce the issue I am asking here, hoping somebody experienced this before
and knows the reason.
Unfortunately the Jenkins instance has been rolled back and I can't provide
more logs.

The duplicate extension is defined and used onlu in this plugin. No other
plugin can provide an extension for this.
After the rollback I tried to lookup the extension via the groovy console and
none was found (technically the class to load itself was missing as expected).

Some information about the system:

* Jenkins version: 2.164.3
* Plugin was dynamically loadable
* Plugin was installed via the "Upload file" functionality of the upload
  center
* The `FooStore` component is *always* looked up via `.lookupSingleton()`
* The `FooStore` component is not part of any class hierarchy and is not
  Describable/has no descriptor
* The plugin was installed in the past (but was uninstalled again) and the
  following leftovers did still exist (these are compatible with the newly
  deployed version):
  * Configuration XML (for another component)
  * Actions attached to builds (No serialized state besides two Strings)
* Builds were executing during the installation
* The plugin has worked hundreds of times while executed with the test harness,
  also so far I was not able reproduce the issue when manually installing it

This looks like a fundamental problem of my plugin structure or a race
condition somewhere in the plugin loading or lookup mechanism.

Any pointers are appreciated.

Thanks,
Thomas

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

Re: Publishing plugin use a bad url

[Thomas POUIT]

Hello,

Thank you slide, you're right: I was missing the whole scm section in my 
pom! Now it's working. It's my first release...
Thank you also Jesse: I see from your link that I can use a netbeans plugin 
for developing Jenkins plugins. I will test it.

Thank you both :-)

-- 
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/51dfed35-82aa-46ec-a292-8bcd6c248197%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Publishing plugin use a bad url

[Thomas POUIT]

Hello,
I'm trying to publish my new plugin, but I get a 
"jenkinsci/plugin-pom.git/ 
is not a valid repository name" error. I do not understand why it is trying 
to publish under plugin-pom.git. Nowhere in my sources I refer to a 
plugin-pom repo!

Here is the exact error message:

[INFO] 
[INFO] --- maven-install-plugin:3.0.0-M1:install (default-install) @ 
castecho ---
[INFO] Installing 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin\target\castecho.hpi 
to 
C:\Users\TPO\.m2\repository\io\jenkins\plugins\castecho\1.0.0\castecho-1.0.0.hpi
[INFO] Installing 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin\pom.xml to 
C:\Users\TPO\.m2\repository\io\jenkins\plugins\castecho\1.0.0\castecho-1.0.0.pom
[INFO] Installing 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin\target\castecho.jar 
to 
C:\Users\TPO\.m2\repository\io\jenkins\plugins\castecho\1.0.0\castecho-1.0.0.jar
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 01:17 min
[INFO] Finished at: 2019-06-11T11:28:11+02:00
[INFO] Final Memory: 85M/1650M
[INFO] 

Checking in modified POMs...
Executing: cmd.exe /X /C "git add -- pom.xml"
Working directory: 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin
Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
Working directory: 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin
Executing: cmd.exe /X /C "git status --porcelain ."
Working directory: 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin
Ignoring unrecognized line: ?? .gitignore
Ignoring unrecognized line: ?? pom.xml.releaseBackup
Ignoring unrecognized line: ?? release.properties
Executing: cmd.exe /X /C "git commit --verbose -F 
C:\Users\TPO\AppData\Local\Temp\maven-scm-1728998852.commit pom.xml"
Working directory: 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin
Executing: cmd.exe /X /C "git symbolic-ref HEAD"
Working directory: 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin
*Executing: cmd.exe /X /C "git push 
ssh:@github.com/jenkinsci/plugin-pom.git/castecho 
refs/heads/master:refs/heads/master"*
Working directory: 
C:\Sources\Jenkins_plugins\Jenkins-plugins\castecho-plugin

BUILD FAILURE

Total time: 01:35 min
Finished at: 2019-06-11T11:28:14+02:00
Final Memory: 23M/289M
Failed 
to execute goal org.apache.maven.plugins: maven-release-plugin: 2.5.3: 
prepare (default-cli) on project castecho: Unable to commit files
Provider message:
The git-push command failed.
Command output:
warning: CRLF will be replaced by LF in pom.xml.
The file will have its original line in your working directory.
*fatal: remote error:*
*  jenkinsci / plugin-pom.git / castecho is not a valid repository name*


-> [Help 1]

To see the full stack of errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.


However I followed what was asked here: 
https://jenkins.io/doc/developer/publishing/releasing/
And my git repo is ready for tag at this location: 
https://github.com/jenkinsci/castecho-plugin

Any help would be welcome to get me out of this mess. :-)

-- 
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/0b3fbd42-e577-4b95-9b3a-7c77f98dbdde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


release.properties
Description: Binary data


pom.xml
Description: XML document

Re: [EXT] Re: Exposing a step as global variable (or calling it implicitly)

[Thomas Weißschuh]

On Wed, Mar 06, 2019 at 12:25:10PM -0500, Jesse Glick wrote:
> On Wed, Mar 6, 2019 at 3:59 AM Thomas Weißschuh wrote:
>>  * (If it can, but it is called without a block, {@link StepContext#hasBody} 
>> will be false.)
>>
>> Also official steps like "stage" accept both forms.
>
> Ah forgot that this was introduced for the `stage` step trick. My
> advice had actually been to keep `stage` as is and introduce
> block-scoped `label`. Best to not use this facility and keep each step
> either exclusively block-scoped or non-block-scoped.

Is there a chance of it breaking in the future, now that it has been published
and documented?

>> The plugin is *very* generic.
>>   (it only looks at the build as a series of nodes/steps, without any
>>   assumptions about their content)
>
> So what is it doing, exactly? This smells like something that (if
> needed at all) should be built into the syntax, not done as a `Step`.

Now that you are asking :-)

The plugin exposes the internal processes of Jenkins
(runs, queues, workflows) to a general distributed tracing system.
The goal is to have a complete, end-to-end linked trace over the whole CI/CD 
pipeline,
including the SCM system, all the different steps inside Jenkins, all the steps
of the build systems executed by Jenkins, asynchronous processes triggered by
the build, executors spun up for the build, etc...

You may remember our discussion on this list about having per step environment
variables and the resulting implementation of the StepEnvironmentContributor
Extensionpoint. This was for the same plugin and allows the plugin to
communicate with other plugins in maven, SonarQube, docker etc.

The goal is to have increased transparency for the users, better monitoring and 
accounting.

Currently inside Jenkis Pipelines all Steps are recorded (in addition to the
other parts), enriched with information from within Jenkins and added to the
tracing system.
For this reason it keeps a database of currently running steps and their
associated tracing datastructure
(care is taken not to leak memory references to core Jenkins objects).

However there are cases where the information available out of the box is not
sufficient.

For this usecase the custom step provides two functionalities, when called with
or without a block.

It can be used to "synthesize" a step for the tracing system, which is useful
if there is no native step with the desired scope available at the moment.
For example when a new stage is not desired, or for use in a global
pipeline library, as steps from libraries do not end up as new FlowNodes and so
are not traced explicitly out of the box.

trace(tags: ["command.type": "something"]) {
sh '...'
}

The other syntax (without a block) allows users and pipeline library authors to
enrich the currently active tracing scope with custom information.
This helps to keep the amount of tracing scopes smaller, also it allows for a
better search experience.

# all nested steps modify the tags of the "stage" scope
stage("someStage") {
# same way as above
trace(tags: ["foo": 1])

# it also returns an object that can be used from groovy
trace().setTag("foo", 1)
trace().tags["bar"] = 2
}

For this last part I wanted to implement a shorthand syntax without the
required braces.

Can you elaborate on "building something into the syntax"?
Is it something I can already do?

>> What do you think of having steps (optionally, decided by the step author)
>> available as something like global variables?
>> This would allow plugin authors to provide this functionality
>> (for which they currently do implement GlobalVariables)
>> without the disadvantages and without a tight dependency on Cps.

> Even if there were not a literal compile-and-link dependency on
> `workflow-cps` the semantics would be inherently tied to details of
> that model.

As it would only be syntactic sugar, this would be fine for my particular
usecase. If it does not fit the general semantics then I will have to do
without.

The other case I mentioned, where GlobalVariables override Steps during lookup
does actually match the behaviour of normal Groovy. Somehow I got my previous
tests there wrong.

So as for the triply overloaded symbol, I will have to do with the current 
state.

-- 
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/20190307142921.GB6280%40fralrnd0033.fra.amadeus.net.
For more options, visit https://groups.google.com/d/optout.

Re: Exposing a step as global variable (or calling it implicitly)

[Thomas Weißschuh]

Hi Jesse,

thanks for the quick response!

On Tue, Mar 05, 2019 at 02:21:03PM -0500, Jesse Glick wrote:
> On Tue, Mar 5, 2019 at 1:07 PM  wrote:
> > The step can be used with our without a body
> 
> Huh? That is not possible. I given `StepDescriptor` specifies whether
> it `takesImplicitBlockArgument` or not. If you want two syntaxes, you
> need two step names.

I think it is:

>From the docs of StepDescriptor:

/**
 * Return true if this step can accept an implicit block argument.
 * (If it can, but it is called without a block, {@link StepContext#hasBody} 
will be false.)
 * @see StepContext#newBodyInvoker()
 */

Also official steps like "stage" accept both forms.
(Yes, the form without step is deprecated, but for other reasons)

Also this part of the plugin already works quite well.

>> # applies the config to the current block
> There is no such concept in Pipeline.

To be more precise it refers to the datastructure associated with
the current FlowNode.
(I can elaborate on the specifics if wanted)

>> I would like to increase the ergonomics of the syntax
>>
>> # desired syntax
>> stage("s") {
>> foo.setting = 1
>
> This is not possible using steps.
>
>> implement it with a global variable
>
> As noted in the `GlobalVariable` Javadoc, you should avoid this API.

Yes, I would like to avoid it.

OTOH I don't think it is *that* bad in case of this specific plugin:

* The plugin is *very* generic.
  (it only looks at the build as a series of nodes/steps, without any
  assumptions about their content)
* It does not have to be compatible with declarative pipeline.
  (It would be better for its ergonomics to implement a dedicated
  extensionpoint for declarative pipelines)
* The variable is only syntactic sugar that is meant to save two braces in Cps
  pipelines.
* The groovy code it executes is literally:

  public Object getValue(@Nonnull CpsScript script) throws Exception {
  return script.evaluate("steps.foo()");
  }

>> Do you think this functionality would be in scope of Jenkins?
>
> No. I would stick to the block-scoped step and leave it at that.

What do you think of having steps (optionally, decided by the step author)
available as something like global variables?
This would allow plugin authors to provide this functionality
(for which they currently do implement GlobalVariables)
without the disadvantages and without a tight dependency on Cps.

Thanks,
Thomas

-- 
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/20190306085912.GA6280%40fralrnd0033.fra.amadeus.net.
For more options, visit https://groups.google.com/d/optout.

Exposing a step as global variable (or calling it implicitly)

[thomas . weissschuh]

Hi all,

I have written a custom step (let's call it "foo") that allows pipeline 
authors
to configure aspects of their build. The step can be used with our without a
body:

# applies the config to the executed block
foo(config: ...) {
}



# applies the config to the current block
stage("s") {
def config = foo()
config.setting = 1

# or
foo().setting = 1
}



This works very nicely.
The configuration is expected to be called many times in a pipeline 
definition
and for this reason I would like to increase the ergonomics of the syntax
(even more).

# desired syntax
stage("s") {
foo.setting = 1
}



The logic in the "foo" step needs access to the current StepContext, so I 
can't
implement it completely as a global variable, as those don't have access to 
the
context.

Ideas:
a) implement it with a global variable, that directly call the step via the 
CpsScript.
   However the CPS engine always resolves symbol look-ups by looking at 
global
   variables, so my global variable calls itself.
   (I have a PoC that allows GlobalVariables to be exempt from method 
look-ups)
b) Allow steps to declare that they also want to be exposed as a global
   variable, which when accessed will call the Step without arguments?


Do you think this functionality would be in scope of Jenkins?

Thanks,
Thomas

-- 
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/ab64b91e-262d-4b25-9408-9e90493bd271%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Hi,

thank you. Its working now.

Greetings,
Thomas

Am Samstag, 8. Dezember 2018 00:48:06 UTC+1 schrieb Oleg Nenashev:
>
> Hi,
>
> It should be fixed now.
> It seems we have an issue with the ChatOps bot OR with the developer group.
> It had read-only permissions due to whatever reason
>
> BR, Oleg
>
> On Fri, Dec 7, 2018 at 4:56 PM Thomas Döring  > wrote:
>
>> Hi Oleg again,
>>
>> maybe a stupid question: The write access is setup for the GitHub user 
>> "thomas-dee" (https://github.com/thomas-dee), right? Or do I have to 
>> login with another account?
>>
>> Greetings,
>> Thomas
>>
>> Am Freitag, 7. Dezember 2018 14:48:14 UTC+1 schrieb Oleg Nenashev:
>>>
>>> Hi Thomas,
>>>
>>> Once you accept the invitation to the jenkinsci org, everybody should be 
>>> set.
>>> Please check your inbox, you should have received it on Dec 4
>>>
>>> BR, Oleg
>>>
>>>
>>> On Fri, Dec 7, 2018 at 2:46 PM Thomas Döring  wrote:
>>>
>>>> Hi Olge,
>>>>
>>>> is there anything else I need to do to get write permissions for the 
>>>> embeddable-build-status-plugin?
>>>>
>>>> Greetings,
>>>> Thomas
>>>>
>>>> Am Mittwoch, 5. Dezember 2018 07:53:34 UTC+1 schrieb Oleg Nenashev:
>>>>>
>>>>> Thanks for the response, Marius!
>>>>>
>>>>> Hi Thomas,
>>>>>
>>>>> I have granted you the write permissions to the repo and made you a 
>>>>> default assignee in JIRA.
>>>>> Thanks again for your interest, and welcome aboard!
>>>>>
>>>>> To get the release permissions, please submit a pull request to 
>>>>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-embeddable-build-status.yml
>>>>>
>>>>> Best regards,
>>>>> Oleg
>>>>>
>>>>> On Tuesday, December 4, 2018 at 3:39:45 PM UTC+1, Thomas Döring wrote:
>>>>>>
>>>>>>
>>>>>> Oh. I forgot: My GitHub username is "thomas-dee". My Jenkins-ID is 
>>>>>> "thomas_dee".
>>>>>>
>>>>>> Am Montag, 3. Dezember 2018 20:13:26 UTC+1 schrieb Thomas Döring:
>>>>>>>
>>>>>>> Hello again,
>>>>>>>
>>>>>>> Well then: I hereby request adoption for the 
>>>>>>> embeddable-build-status-plugin.
>>>>>>> And Marius: There will be no new release until January.
>>>>>>>
>>>>>>> Greetings,
>>>>>>> Thomas.
>>>>>>>
>>>>>>> Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas:
>>>>>>>>
>>>>>>>> Hi! 
>>>>>>>>
>>>>>>>> I have no interest in maintaining embeddable-build-status-plugin, 
>>>>>>>> so if 
>>>>>>>> my opinion matters, anyone else is welcome to step up! 
>>>>>>>>
>>>>>>>> (I have some slight interest in having the plugin continue working, 
>>>>>>>> and 
>>>>>>>> in having it produce badges in the common shields.io style, until 
>>>>>>>> end of 
>>>>>>>> December, when I plan to shut down my Jenkins instance.) 
>>>>>>>>
>>>>>>>> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: 
>>>>>>>> > Added [1]Marius Gedminas to Cc. 
>>>>>>>> > Since Jesse Glick says he is not a maintainer, Marius is the last 
>>>>>>>> contributor 
>>>>>>>> > to release 2 versions of the plugin before Jesse. 
>>>>>>>> > 
>>>>>>>> > Let's set a standard 2-week timeout. 
>>>>>>>> > 
>>>>>>>> > BR, Oleg 
>>>>>>>> > 
>>>>>>>> > 
>>>>>>>> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net> 
>>>>>>>> wrote: 
>>>>>>>> > 
>>>>>>>> > Is there any way to "adopt" the plugin if there is no current 
>>>>>>>> maintainer 
>>>>

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Hi Oleg again,

maybe a stupid question: The write access is setup for the GitHub user 
"thomas-dee" (https://github.com/thomas-dee), right? Or do I have to login 
with another account?

Greetings,
Thomas

Am Freitag, 7. Dezember 2018 14:48:14 UTC+1 schrieb Oleg Nenashev:
>
> Hi Thomas,
>
> Once you accept the invitation to the jenkinsci org, everybody should be 
> set.
> Please check your inbox, you should have received it on Dec 4
>
> BR, Oleg
>
>
> On Fri, Dec 7, 2018 at 2:46 PM Thomas Döring  > wrote:
>
>> Hi Olge,
>>
>> is there anything else I need to do to get write permissions for the 
>> embeddable-build-status-plugin?
>>
>> Greetings,
>> Thomas
>>
>> Am Mittwoch, 5. Dezember 2018 07:53:34 UTC+1 schrieb Oleg Nenashev:
>>>
>>> Thanks for the response, Marius!
>>>
>>> Hi Thomas,
>>>
>>> I have granted you the write permissions to the repo and made you a 
>>> default assignee in JIRA.
>>> Thanks again for your interest, and welcome aboard!
>>>
>>> To get the release permissions, please submit a pull request to 
>>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-embeddable-build-status.yml
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Tuesday, December 4, 2018 at 3:39:45 PM UTC+1, Thomas Döring wrote:
>>>>
>>>>
>>>> Oh. I forgot: My GitHub username is "thomas-dee". My Jenkins-ID is 
>>>> "thomas_dee".
>>>>
>>>> Am Montag, 3. Dezember 2018 20:13:26 UTC+1 schrieb Thomas Döring:
>>>>>
>>>>> Hello again,
>>>>>
>>>>> Well then: I hereby request adoption for the 
>>>>> embeddable-build-status-plugin.
>>>>> And Marius: There will be no new release until January.
>>>>>
>>>>> Greetings,
>>>>> Thomas.
>>>>>
>>>>> Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas:
>>>>>>
>>>>>> Hi! 
>>>>>>
>>>>>> I have no interest in maintaining embeddable-build-status-plugin, so 
>>>>>> if 
>>>>>> my opinion matters, anyone else is welcome to step up! 
>>>>>>
>>>>>> (I have some slight interest in having the plugin continue working, 
>>>>>> and 
>>>>>> in having it produce badges in the common shields.io style, until 
>>>>>> end of 
>>>>>> December, when I plan to shut down my Jenkins instance.) 
>>>>>>
>>>>>> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: 
>>>>>> > Added [1]Marius Gedminas to Cc. 
>>>>>> > Since Jesse Glick says he is not a maintainer, Marius is the last 
>>>>>> contributor 
>>>>>> > to release 2 versions of the plugin before Jesse. 
>>>>>> > 
>>>>>> > Let's set a standard 2-week timeout. 
>>>>>> > 
>>>>>> > BR, Oleg 
>>>>>> > 
>>>>>> > 
>>>>>> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net> 
>>>>>> wrote: 
>>>>>> > 
>>>>>> > Is there any way to "adopt" the plugin if there is no current 
>>>>>> maintainer 
>>>>>> > (since I can ask no one to approve). 
>>>>>> > 
>>>>>> > Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse 
>>>>>> Glick: 
>>>>>> > 
>>>>>> > On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev <
>>>>>> o.v.ne...@gmail.com> 
>>>>>> > wrote: 
>>>>>> > > I will ask the maintainers 
>>>>>> > 
>>>>>> > I do not know if there _are_ any maintainers. Not me. 
>>>>>>
>>>>>> Marius Gedminas 
>>>>>> -- 
>>>>>> Q:  How many IBM CPU's does it take to execute a job? 
>>>>>> A:  Four; three to hold it down, and one to rip its head off. 
>>>>>>
>>>>> -- 
>> 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/BXZUKKEQWQk/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/d76ec08a-9937-4340-8203-12c925d5d94e%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/d76ec08a-9937-4340-8203-12c925d5d94e%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/f91d7b9e-7877-413c-a564-8cc3b1087ed2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Hi Oleg,

Yes, on GitHub I got that invitation and accepted it. And it (GitHub) says 
that I am member of jenkinsci. However, I still have no write access to the 
plugin repo... :-(

Greetings,
Thomas

Am Freitag, 7. Dezember 2018 14:48:14 UTC+1 schrieb Oleg Nenashev:
>
> Hi Thomas,
>
> Once you accept the invitation to the jenkinsci org, everybody should be 
> set.
> Please check your inbox, you should have received it on Dec 4
>
> BR, Oleg
>
>
> On Fri, Dec 7, 2018 at 2:46 PM Thomas Döring  > wrote:
>
>> Hi Olge,
>>
>> is there anything else I need to do to get write permissions for the 
>> embeddable-build-status-plugin?
>>
>> Greetings,
>> Thomas
>>
>> Am Mittwoch, 5. Dezember 2018 07:53:34 UTC+1 schrieb Oleg Nenashev:
>>>
>>> Thanks for the response, Marius!
>>>
>>> Hi Thomas,
>>>
>>> I have granted you the write permissions to the repo and made you a 
>>> default assignee in JIRA.
>>> Thanks again for your interest, and welcome aboard!
>>>
>>> To get the release permissions, please submit a pull request to 
>>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-embeddable-build-status.yml
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Tuesday, December 4, 2018 at 3:39:45 PM UTC+1, Thomas Döring wrote:
>>>>
>>>>
>>>> Oh. I forgot: My GitHub username is "thomas-dee". My Jenkins-ID is 
>>>> "thomas_dee".
>>>>
>>>> Am Montag, 3. Dezember 2018 20:13:26 UTC+1 schrieb Thomas Döring:
>>>>>
>>>>> Hello again,
>>>>>
>>>>> Well then: I hereby request adoption for the 
>>>>> embeddable-build-status-plugin.
>>>>> And Marius: There will be no new release until January.
>>>>>
>>>>> Greetings,
>>>>> Thomas.
>>>>>
>>>>> Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas:
>>>>>>
>>>>>> Hi! 
>>>>>>
>>>>>> I have no interest in maintaining embeddable-build-status-plugin, so 
>>>>>> if 
>>>>>> my opinion matters, anyone else is welcome to step up! 
>>>>>>
>>>>>> (I have some slight interest in having the plugin continue working, 
>>>>>> and 
>>>>>> in having it produce badges in the common shields.io style, until 
>>>>>> end of 
>>>>>> December, when I plan to shut down my Jenkins instance.) 
>>>>>>
>>>>>> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: 
>>>>>> > Added [1]Marius Gedminas to Cc. 
>>>>>> > Since Jesse Glick says he is not a maintainer, Marius is the last 
>>>>>> contributor 
>>>>>> > to release 2 versions of the plugin before Jesse. 
>>>>>> > 
>>>>>> > Let's set a standard 2-week timeout. 
>>>>>> > 
>>>>>> > BR, Oleg 
>>>>>> > 
>>>>>> > 
>>>>>> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net> 
>>>>>> wrote: 
>>>>>> > 
>>>>>> > Is there any way to "adopt" the plugin if there is no current 
>>>>>> maintainer 
>>>>>> > (since I can ask no one to approve). 
>>>>>> > 
>>>>>> > Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse 
>>>>>> Glick: 
>>>>>> > 
>>>>>> > On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev <
>>>>>> o.v.ne...@gmail.com> 
>>>>>> > wrote: 
>>>>>> > > I will ask the maintainers 
>>>>>> > 
>>>>>> > I do not know if there _are_ any maintainers. Not me. 
>>>>>>
>>>>>> Marius Gedminas 
>>>>>> -- 
>>>>>> Q:  How many IBM CPU's does it take to execute a job? 
>>>>>> A:  Four; three to hold it down, and one to rip its head off. 
>>>>>>
>>>>> -- 
>> 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/BXZUKKEQWQk/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/d76ec08a-9937-4340-8203-12c925d5d94e%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/d76ec08a-9937-4340-8203-12c925d5d94e%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/a34a6d08-42c6-4805-8925-1173d6f4a1a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Hi Olge,

is there anything else I need to do to get write permissions for the 
embeddable-build-status-plugin?

Greetings,
Thomas

Am Mittwoch, 5. Dezember 2018 07:53:34 UTC+1 schrieb Oleg Nenashev:
>
> Thanks for the response, Marius!
>
> Hi Thomas,
>
> I have granted you the write permissions to the repo and made you a 
> default assignee in JIRA.
> Thanks again for your interest, and welcome aboard!
>
> To get the release permissions, please submit a pull request to 
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-embeddable-build-status.yml
>
> Best regards,
> Oleg
>
> On Tuesday, December 4, 2018 at 3:39:45 PM UTC+1, Thomas Döring wrote:
>>
>>
>> Oh. I forgot: My GitHub username is "thomas-dee". My Jenkins-ID is 
>> "thomas_dee".
>>
>> Am Montag, 3. Dezember 2018 20:13:26 UTC+1 schrieb Thomas Döring:
>>>
>>> Hello again,
>>>
>>> Well then: I hereby request adoption for the 
>>> embeddable-build-status-plugin.
>>> And Marius: There will be no new release until January.
>>>
>>> Greetings,
>>> Thomas.
>>>
>>> Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas:
>>>>
>>>> Hi! 
>>>>
>>>> I have no interest in maintaining embeddable-build-status-plugin, so if 
>>>> my opinion matters, anyone else is welcome to step up! 
>>>>
>>>> (I have some slight interest in having the plugin continue working, and 
>>>> in having it produce badges in the common shields.io style, until end 
>>>> of 
>>>> December, when I plan to shut down my Jenkins instance.) 
>>>>
>>>> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: 
>>>> > Added [1]Marius Gedminas to Cc. 
>>>> > Since Jesse Glick says he is not a maintainer, Marius is the last 
>>>> contributor 
>>>> > to release 2 versions of the plugin before Jesse. 
>>>> > 
>>>> > Let's set a standard 2-week timeout. 
>>>> > 
>>>> > BR, Oleg 
>>>> > 
>>>> > 
>>>> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net> 
>>>> wrote: 
>>>> > 
>>>> > Is there any way to "adopt" the plugin if there is no current 
>>>> maintainer 
>>>> > (since I can ask no one to approve). 
>>>> > 
>>>> > Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse Glick: 
>>>> > 
>>>> > On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev <
>>>> o.v.ne...@gmail.com> 
>>>> > wrote: 
>>>> > > I will ask the maintainers 
>>>> > 
>>>> > I do not know if there _are_ any maintainers. Not me. 
>>>>
>>>> Marius Gedminas 
>>>> -- 
>>>> Q:  How many IBM CPU's does it take to execute a job? 
>>>> A:  Four; three to hold it down, and one to rip its head off. 
>>>>
>>>

-- 
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/d76ec08a-9937-4340-8203-12c925d5d94e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Oh. I forgot: My GitHub username is "thomas-dee". My Jenkins-ID is 
"thomas_dee".

Am Montag, 3. Dezember 2018 20:13:26 UTC+1 schrieb Thomas Döring:
>
> Hello again,
>
> Well then: I hereby request adoption for the 
> embeddable-build-status-plugin.
> And Marius: There will be no new release until January.
>
> Greetings,
> Thomas.
>
> Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas:
>>
>> Hi! 
>>
>> I have no interest in maintaining embeddable-build-status-plugin, so if 
>> my opinion matters, anyone else is welcome to step up! 
>>
>> (I have some slight interest in having the plugin continue working, and 
>> in having it produce badges in the common shields.io style, until end of 
>> December, when I plan to shut down my Jenkins instance.) 
>>
>> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: 
>> > Added [1]Marius Gedminas to Cc. 
>> > Since Jesse Glick says he is not a maintainer, Marius is the last 
>> contributor 
>> > to release 2 versions of the plugin before Jesse. 
>> > 
>> > Let's set a standard 2-week timeout. 
>> > 
>> > BR, Oleg 
>> > 
>> > 
>> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net> 
>> wrote: 
>> > 
>> > Is there any way to "adopt" the plugin if there is no current 
>> maintainer 
>> > (since I can ask no one to approve). 
>> > 
>> > Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse Glick: 
>> > 
>> > On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev <
>> o.v.ne...@gmail.com> 
>> > wrote: 
>> > > I will ask the maintainers 
>> > 
>> > I do not know if there _are_ any maintainers. Not me. 
>>
>> Marius Gedminas 
>> -- 
>> Q:  How many IBM CPU's does it take to execute a job? 
>> A:  Four; three to hold it down, and one to rip its head off. 
>>
>

-- 
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/b7f0d860-5589-4f9d-afa7-1c1a8f0aeb84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Hello again,

Well then: I hereby request adoption for the embeddable-build-status-plugin.
And Marius: There will be no new release until January.

Greetings,
Thomas.

Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas:
>
> Hi! 
>
> I have no interest in maintaining embeddable-build-status-plugin, so if 
> my opinion matters, anyone else is welcome to step up! 
>
> (I have some slight interest in having the plugin continue working, and 
> in having it produce badges in the common shields.io style, until end of 
> December, when I plan to shut down my Jenkins instance.) 
>
> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: 
> > Added [1]Marius Gedminas to Cc. 
> > Since Jesse Glick says he is not a maintainer, Marius is the last 
> contributor 
> > to release 2 versions of the plugin before Jesse. 
> > 
> > Let's set a standard 2-week timeout. 
> > 
> > BR, Oleg 
> > 
> > 
> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net 
> > wrote: 
> > 
> > Is there any way to "adopt" the plugin if there is no current 
> maintainer 
> > (since I can ask no one to approve). 
> > 
> > Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse Glick: 
> > 
> > On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev <
> o.v.ne...@gmail.com> 
> > wrote: 
> > > I will ask the maintainers 
> > 
> > I do not know if there _are_ any maintainers. Not me. 
>
> Marius Gedminas 
> -- 
> Q:  How many IBM CPU's does it take to execute a job? 
> A:  Four; three to hold it down, and one to rip its head off. 
>

-- 
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/7ee266bb-f808-4b87-aab2-61add37c5d41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Thats what we do.

Thank you and greetings,
Thomas

Am Montag, 3. Dezember 2018 08:39:26 UTC+1 schrieb Oleg Nenashev:
>
> Added Marius Gedminas <https://github.com/mgedmin> to Cc.
> Since Jesse Glick says he is not a maintainer, Marius is the last 
> contributor to release 2 versions of the plugin before Jesse.
>
> Let's set a standard 2-week timeout. 
>
> BR, Oleg
>
>
> On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring  > wrote:
>
>> Is there any way to "adopt" the plugin if there is no current maintainer 
>> (since I can ask no one to approve).
>>
>> Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse Glick:
>>>
>>> On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev  
>>> wrote: 
>>> > I will ask the maintainers 
>>>
>>> I do not know if there _are_ any maintainers. Not me. 
>>>
>> -- 
>> 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/BXZUKKEQWQk/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/40d20b77-0125-4811-a368-bedb8f8b9e58%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/40d20b77-0125-4811-a368-bedb8f8b9e58%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/a0667200-c67b-447b-8cd0-125b79032ae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Is there any way to "adopt" the plugin if there is no current maintainer 
(since I can ask no one to approve).

Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse Glick:
>
> On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev  > wrote: 
> > I will ask the maintainers 
>
> I do not know if there _are_ any maintainers. Not me. 
>

-- 
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/40d20b77-0125-4811-a368-bedb8f8b9e58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [cppcheck-plugin] Unable to compile (missing sources)

[Thomas Döring]

I'm actually using VS Code + Maven plugin on Windows (and I'm a newbie on 
that front) to build the plugin.

If I do a "clean" before every "compile" it works... a bit inconvenient, 
but it works.

Thanks for your help.


Am Freitag, 30. November 2018 10:32:25 UTC+1 schrieb Daniel Beck:
>
> Configure your IDE to include the generated sources directory in the 
> sources (or just build with Maven). 
>
>
> https://github.com/jenkinsci/cppcheck-plugin/blob/c81b79534602f258216096170c091ad31f8b7e60/pom.xml#L154
>  
>
>
> > On 30. Nov 2018, at 10:10, Thomas Döring > 
> wrote: 
> > 
> > Hi everyone, 
> > 
> > I'm trying to compile the cppcheck-plugin with the GitHub sources. The 
> build fails because the `org.jenkinsci.plugins.cppcheck.model.*` sources 
> are missing. 
> > 
> > [ERROR] 
> /d:/Projects/GitHub/thomas-dee/cppcheck-plugin/src/main/java/com/thalesgroup/hudson/plugins/cppcheck/parser/CppcheckParser.java:[28,44]
>  
> package org.jenkinsci.plugins.cppcheck.model does 
> > not exist 
> > 
> > Any ideas what I'm doing wrong here? 
> > 
> > Thanks and greetings, 
> > Thomas 
> > 
> > -- 
> > 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/fedb0392-e125-4dbd-ac9e-87aabed70274%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/cf3ab602-e472-49f5-aef8-170f9c5a9614%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cppcheck-plugin] Unable to compile (missing sources)

[Thomas Döring]

Hi everyone,

I'm trying to compile the cppcheck-plugin with the GitHub sources. The 
build fails because the `org.jenkinsci.plugins.cppcheck.model.*` sources 
are missing.

[ERROR] /d:/Projects/GitHub/thomas-dee/cppcheck-plugin/src/main/java/com/
thalesgroup/hudson/plugins/cppcheck/parser/CppcheckParser.java:[28,44] 
package org.jenkinsci.plugins.cppcheck.model does
not exist

Any ideas what I'm doing wrong here?

Thanks and greetings,
Thomas

-- 
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/fedb0392-e125-4dbd-ac9e-87aabed70274%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas Döring]

Hi Oleg,

Thank you. That would be great.

Greetings,
Thomas


Am Donnerstag, 29. November 2018 21:33:47 UTC+1 schrieb Oleg Nenashev:
> Hi,
> 
> 
> The plugin is not officially marked for adoption, but there was no activity 
> there for a while.
> I will ask the maintainers
> 
> 
> 
> BR, Oleg
> 
> 
> On Thursday, November 29, 2018 at 9:25:17 AM UTC+1, Thomas Döring wrote:I’m 
> asking this, because I’d like to contribute (see PR #31).

-- 
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/8ed4823b-2f81-43a0-a5e7-d442d280e526%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: embeddable-build-status-plugin orphaned?

[Thomas D.]

I’m asking this, because I’d like to contribute (see PR #31).

-- 
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/9DA4FA10-F617-445A-8299-A214E4F3DB6D%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

embeddable-build-status-plugin orphaned?

[Thomas Döring]

Hi everyone,

I noticed that the plugin was long time not updated despite some really 
interesting feature requests.
Is there a "current" maintainer of this plugin?

Greetings,
Thomas

-- 
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/b020be87-6681-4d4e-8169-d719d41279ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modifying Environment variables for each workflow step from a plugin

[Thomas Weißschuh]

On Fri, May 04, 2018 at 11:39:12AM -0400, Jesse Glick wrote:
> By “variable” here I mean “environment variable”: to include the value
> of the node ID in `context.get(EnvVars.class)`.

Ok, makes sense.

>> If this feature has a chance of being merged
> 
> @svanoort & @abayer could speak to that.

I mentioned them on the ticket.

>> I would like to take a stab at
>> implementing it.
>> Should I open a proper ticket to discuss the details or are concrete 
>> prototypes
>> preferred?

> Both.

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

-- 
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/20180507072808.GA4693%40fralrnd0033.fra.amadeus.net.
For more options, visit https://groups.google.com/d/optout.

Re: Modifying Environment variables for each workflow step from a plugin

[Thomas Weißschuh]

On Thu, May 03, 2018 at 02:27:32PM -0400, Jesse Glick wrote:
> Well, at least for `sh` steps you can identify the command line (in
> most cases) via `ArgumentsAction`.

Thanks for the hint. I would prefer to have proper IDs for correlation, but if
nothing else works this will probably have to do.

> Note that my suggestion about defining environment variables in a
> custom block-scoped step may not fit your needs since the environment
> variables need to be defined before the body starts, so you could not
> include timing information about this step itself.

Yes this is the case. Unfortunately currently it is not possible to create the
timer in a non-started state.

> From my (again, weak) understanding of your goals, it might work
> better to use the `STAGE_NAME` environment variable from inside
> external processes to see where you are in the build, which can then
> be mapped back to build metadata via the flow graph. Or scripts could
> be amended slightly to just use `withEnv` to specify some arbitrary
> ID, accessible of course to external processes via environment,
> correlatable to the flow graph via `ArgumentsAction`.

It would have to be a custom step, because the environment variable has to be
computed by the library. But otherwise, this is what I have currently.

> I suppose we could also amend `DefaultStepContext.get` to include a
> special variable bound to the current `FlowNode.id`;

This is actually currently implemented in `CpsStepContext`,
and exposed via the generic `StepContext.get`.
It includes the complete FlowNode.
This is currently used by my mentioned custom step.

> and/or more
> generally introduce an `ExtensionPoint` similar to
> `EnvironmentExpander` but accepting a `StepContext` argument (to be
> called from a new overload of `getEffectiveEnvironment`), so you could
> bind such a variable yourself. The latter would be an Enhancement with
> `api` label in `workflow-step-api-plugin` + `workflow-support-plugin`.

I assume it should be similar to `EnvironmentContributor`, right?

Something like this would be great.

If this feature has a chance of being merged I would like to take a stab at
implementing it.
Should I open a proper ticket to discuss the details or are concrete prototypes
preferred?

-- 
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/20180504072209.GA9643%40fralrnd0033.fra.amadeus.net.
For more options, visit https://groups.google.com/d/optout.

Re: [EXT] Re: Modifying Environment variables for each workflow step from a plugin

[Thomas Weißschuh]

Hi Jesse,

thanks again for the fast response!

On Wed, May 02, 2018 at 06:20:34PM -0400, Jesse Glick wrote:
> On Wed, May 2, 2018 at 10:50 AM,   wrote:
> > The goal I am trying to achieve is a deep insight into the CI/build/etc
> > pipeline.
> > So if for example a user of the platform complains about slow builds, we can
> > see exactly where time is spent.
> > Waiting for executors, running a certain shell script, a single maven step
> > and
> > so on.
> > And all of this would be stored in a uniform way for queries and analysis.
> 
> All of that metadata is already available via `workflow-api` metadata
> calls. It is unclear to me why it would need to be made available to
> steps inside the build itself as environment variables, as opposed to
> via REST endpoints on the build URL or something (akin to what Blue
> Ocean uses).

The steps are supposed to report their own internal information too.
By exposing the id of the current state from Jenkins to the build step both
executions can be correlated and an end-to-end trace of the complete
build-infrastructure can be shown.
For this it is important that each single step has its own identity, that can
be accessed from within the step (eg maven in the `sh` step).
I am honestly not sure how it would be possible to get information for a
specific step from the REST API without having a way of knowing the identity of
the current step in the first place.

By passing this identity via environment variables I hoped to keep the changes
to the code of the users of build-infrastructure minimal to non-existent.
At the same time it would provide optional extensibility for the users to also
instrument their own code and hook it up to the existing information about the
Jenkins build.

The whole data collection can be extended far before and after the build 
pipeline,
including the original trigger of the build, external message queues, 
non-Jenkins
resource provisioning etc.

> > As everything goes through a shell fair enough.
> > I somehow thought `sh` would be like plain `execve`
> 
> There is JENKINS-44231, though the most straightforward implementation
> would not handle prohibited environment variables.

The restriction is not an issue. It was a problem of understanding on my part.

Thanks for the pointer though, as I personally much prefer executing things
without having the mess of a shell in between.
(Except in the many valid cases where it is necessary)

-- 
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/20180503063845.GA17451%40fralrnd0033.fra.amadeus.net.
For more options, visit https://groups.google.com/d/optout.

Re: Modifying Environment variables for each workflow step from a plugin

[thomas . weissschuh]

Hi Jesse,

thanks for the quick response!

On Tuesday, May 1, 2018 at 3:14:48 PM UTC+2, Jesse Glick wrote:
On Mon, Apr 30, 2018 at 10:09 AM,   wrote:

>> Is there a way to modify the value of an environment variable for a 
single
>> step
>> or block in Pipeline from a GraphListener?
>> The value would have to change for each node.

> I do not think so. As of JENKINS-42499, an `EnvironmentContributor`
> could change a value dynamically. This is not scoped to a step; it
> just means that if and when a step requests access to environment
> variables, your plugin will be asked anew for contributions.

Thanks for the hint I will take a look at it.


>> before
>> each build in AbstractBuild.getEnvironment().
>
> `Run.getEnvironment` I guess you mean. Pipeline builds are not 
`AbstractBuild`s.

Yes.

>> I also tried EnvActionImpl.forRun((Run) 
flowNode.getExection().getOwner().getExecutable())

> I am not sure what you are trying to accomplish here, but stop. Do not
> declare a (`compile`-scoped) dependency on `workflow-cps` at all. You
> may use `workflow-step-api` and, if necessary, `workflow-api` as
> dependencies.

Thanks for the hint. The dependency on `workflow-api` was enough for all 
other
ways forward I tried.

>> Now the issue is to propagate the tracing context from within Jenkins to 
the
>> executed steps. in this case Maven for which a similar plugin was 
created.
>> The probably best way of propagating this information is via environment
>> variables.
>> Obviously the value of this environment variable will have to change 
often
>> during the course of a single build.
>
> Just define a step which would provide the current tracing context
> (whatever that is) as its return value. That will work fine in
> Scripted. If you require Declarative compatibility, your best bet is
> to define a block-scoped step which would define some environment
> variable(s) for its nested steps. That is my best recommendation based
> on my very limited grasp of what it is you are trying to do.

This worked best so far, only a few issues remain.
There seems to be a slight API-assumption mismatch between Jenkins and the
component I am trying to integrate it with, which I have to deal with.

The fact that this requires explicit adaptions to the pipeline definition 
is a
bit unfortunate, though.

The goal I am trying to achieve is a deep insight into the CI/build/etc
pipeline.
So if for example a user of the platform complains about slow builds, we can
see exactly where time is spent.
Waiting for executors, running a certain shell script, a single maven step 
and
so on.
And all of this would be stored in a uniform way for queries and analysis.

>> it seems the usage of env vars with a dash ("-") in their keys is
>> broken.
>> Even when set directly via the Java APIs, they don't show up in the "sh"
>> pipeline step.

> https://unix.stackexchange.com/a/23714/26736 

As everything goes through a shell fair enough.
I somehow thought `sh` would be like plain `execve` which was quite far
fetched.

Thanks again.

-- 
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/2bed4fdc-63c6-43c7-9e11-944d3e50b162%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Modifying Environment variables for each workflow step from a plugin

[thomas . weissschuh]

Is there a way to modify the value of an environment variable for a single 
step
or block in Pipeline from a GraphListener?
The value would have to change for each node. (For the background read on)

So far I have tried to add a custom EnvironmentContributingAction in
GraphListener.onNewHead(). But those actions seem to be only evaluated 
before
each build in AbstractBuild.getEnvironment().

I also tried EnvActionImpl.forRun((Run) 
flowNode.getExection().getOwner().getExecutable())
in GraphListener.onNewHead() which only changes it for the *next* step, as
apparently the StepContext has already been set up.
(It is probably also not great in case of parallel jobs)

EnvironmentContributor is also documented to affect the whole build.

The best way forward seems to somehow get hold of the StepContext from
GraphListener.onNewHead() but so far I could not find a way to do so.


I would be grateful for any pointers.


Background:

I am trying to integrate an OpenTracing [0] tracer into Jenkins.
It will record executions for all Pipeline runs / queueing processes etc...
The tracing inside Jenkins works (mostly) fine so far.
Now the issue is to propagate the tracing context from within Jenkins to the
executed steps. in this case Maven for which a similar plugin was created.
The probably best way of propagating this information is via environment
variables.
Obviously the value of this environment variable will have to change often
during the course of a single build.
It would also be nice if the plugin could work without any changes to the
Pipeline definition itself.
(It is planned to add optional custom steps/methods)

PS: it seems the usage of env vars with a dash ("-") in their keys is 
broken.
Even when set directly via the Java APIs, they don't show up in the "sh"
pipeline step.

Thanks,
Thomas

[0] http://opentracing.io/

-- 
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/0da82c0f-c885-4093-9469-6abb9bb134c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fixing bug where git project is built twice when changes are pushed

[thomas]

en scheduled and 
it has started executing, but it has not decided yet what git sha or indeed 
even what git branch to build? Does that leave a window where a second git 
push triggers the job to be queued again?

I hope you can help me.

Thomas

-- 
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/514bb6df-6afc-4136-abfe-624f73a00dec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins crawler does not update Sonarqube scanner for MSBuild versions

[Thomas Vérin]

Hi, 
We've released new versions of the Sonarqube scanner for msbuild, they are 
available as versions in github.
https://github.com/SonarSource/sonar-scanner-msbuild/releases

But the json file generated by the crawler does not get the updates:
https://updates.jenkins-ci.org/updates/hudson.plugins.sonar.MsBuildSonarQubeRunnerInstaller.json

We've checked that the crawler code works, no issue.
https://github.com/jenkins-infra/crawler/blob/master/sonarqubescannermsbuild.groovy

Can you check that the crawler is running?

Thanks
Tom

-- 
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/e23423f8-e8a9-4073-8533-d64cea53f92a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: release of new version of a plugin already built by ci.jenkins.io

[Thomas Max]

Thanks for the information. So I'll stick to 
the release:prepare release:perform mechanism.

Best regards,
   Thomas

Am Donnerstag, 7. September 2017 14:08:59 UTC+2 schrieb slide:
>
> The versions built in the ci infra are SNAPSHOT versions and there is no 
> tagging done for the release. The release:prepare and release:perform do 
> several additional steps for a release that are not done in a normal build.
>
> On Thu, Sep 7, 2017, 04:51 Thomas Max <thoma...@qf-software.com 
> > wrote:
>
>> Hello Daniel,
>>
>> this sounds promising. Is there any issue ticket I can watch to get 
>> information about changes on this topic ?
>>
>> Best regards,
>>Thomas
>>
>> Am Donnerstag, 7. September 2017 12:42:04 UTC+2 schrieb Daniel Beck:
>>
>>>
>>> > On 7. Sep 2017, at 11:46, Thomas Max <thoma...@qf-software.com> 
>>> wrote: 
>>> > 
>>> > Why is there no way to publish a new version of a plugin since it was 
>>> already built there. It makes no sense to built it on the ci if I need to 
>>> build it manually on my machine once again anyway. 
>>>
>>> We still need to figure out a way to implement authorization. This was 
>>> actually discussed at the contributor summit last week around Jenkins 
>>> World, so we may be closer to a solution now (at least in theory) than we 
>>> were before. 
>>>
>>> -- 
>> 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/7d682c64-b6fc-448e-aeaf-c40b224bfdcd%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/7d682c64-b6fc-448e-aeaf-c40b224bfdcd%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/ce78f5cd-9659-4d45-bf25-67c74676194e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: release of new version of a plugin already built by ci.jenkins.io

[Thomas Max]

Hello Daniel,

this sounds promising. Is there any issue ticket I can watch to get 
information about changes on this topic ?

Best regards,
   Thomas

Am Donnerstag, 7. September 2017 12:42:04 UTC+2 schrieb Daniel Beck:
>
>
> > On 7. Sep 2017, at 11:46, Thomas Max <thoma...@qf-software.com 
> > wrote: 
> > 
> > Why is there no way to publish a new version of a plugin since it was 
> already built there. It makes no sense to built it on the ci if I need to 
> build it manually on my machine once again anyway. 
>
> We still need to figure out a way to implement authorization. This was 
> actually discussed at the contributor summit last week around Jenkins 
> World, so we may be closer to a solution now (at least in theory) than we 
> were before. 
>
>

-- 
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/7d682c64-b6fc-448e-aeaf-c40b224bfdcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: release of new version of a plugin already built by ci.jenkins.io

[Thomas Max]

Hello Aled,

thanks for the information. After some hustling I managed to upload a new 
version. Still waiting to show up in update-center.

What I'm wondering about the ci.jenkins.io integration. Why is there no way 
to publish a new version of a plugin since it was already built there. It 
makes no sense to built it on the ci if I need to build it manually on my 
machine once again anyway.

Best regards,
   Thomas

Am Mittwoch, 6. September 2017 14:17:22 UTC+2 schrieb slide:
>
> Hi Thomas,
>
> For the plugin to be available in the plugin manager, you need to use the 
> release procedure described on the wiki. This uploads the plugin file to 
> the Jenkins infrastructure so that it can be downloaded by the plugin 
> manager.
>
> Regards,
>
> Aled
>
> On Wed, Sep 6, 2017, 03:05 Thomas Max <thoma...@qf-software.com 
> > wrote:
>
>> Hello,
>>
>> I'm maintainer of a Jenkins plugin and tried to release a new version of 
>> my plugin. 
>> I have a Jenkinsfile in my repo so my plugin is automatically built by 
>> ci.jenkins.io.
>> I've alse created a new release directly in my github repo using "Draft a 
>> new release".
>>
>> Is this enough or do I need to build the plugin manually on my machine 
>> and use the release procedure described in the jenkins wiki ?
>>
>> Best regards,
>>Thomas
>>
>> -- 
>> 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/5d1f15a8-bf18-400e-bc8f-c888f7ac3ca2%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/5d1f15a8-bf18-400e-bc8f-c888f7ac3ca2%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/00bd175e-d0fd-4a32-a574-8cd1def65632%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

release of new version of a plugin already built by ci.jenkins.io

[Thomas Max]

Hello,

I'm maintainer of a Jenkins plugin and tried to release a new version of my 
plugin. 
I have a Jenkinsfile in my repo so my plugin is automatically built 
by ci.jenkins.io.
I've alse created a new release directly in my github repo using "Draft a 
new release".

Is this enough or do I need to build the plugin manually on my machine and 
use the release procedure described in the jenkins wiki ?

Best regards,
   Thomas

-- 
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/5d1f15a8-bf18-400e-bc8f-c888f7ac3ca2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Deterministic xml for configuration files

[Dirk Thomas]

Hi,

I ran into the following problem (filled by someone else already): 
https://issues.jenkins-ci.org/browse/JENKINS-41177
Basically Jenkins seems to store the job configuration differently when 
editing the config using the web ui vs. using the api (e.g. from a remote 
Python script). Since the priority was chosen as "minor" I don't expect it 
to be address "automagically". If anyone could provide a pointer which two 
code paths are being used I would be more than happy to look into it and 
try to come up with a patch.

Thank you,
- Dirk

PS: I asked the question in the IRC chat but was redirected to try it on 
the dev mailing list.

-- 
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/d522fa87-f7aa-48f9-868a-a638f1e578e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem during plugin release

[Thomas Fürer]

Sorry, my bad. This is not what I want to say.
I just want to note that it was very hard to find the solution for my
problem(s).
When I do a recap, it was probably better to read all the documentation
top down.

Don't get me wrong, I joined the community some years ago, because I
think jenkins was/is great and I want to do what I could do to make it a
little bit greater. But as always in software projects the documentation
sometimes not covers the things in a structure that all kinds of
problems are in place for all types of persons.

To make long story short, in my case I have troubles with releasing
plugins. IMHO What about using our own infrastructure at
https://jenkins.ci.cloudbees.com or https://ci.jenkins-ci.org to release
the plugins?

Thomas


Am 26.11.2016 um 21:00 schrieb Daniel Beck:
>
>> On 26.11.2016, at 20:54, Baptiste Mathus <m...@batmat.net> wrote:
>>
>> This is a wiki. Please feel free to fix outdated things. Or please, please, 
>> tell us what is outdated. I'm curious which one is. 
>> I think many pages should just be wiped out, or heavily shortened to keep 
>> the really important things, but doing that takes time. If things are 
>> outdated then it's just to be deleted, and we save time if you show us 
>> obviously outdated things...
> This.
>
> We also have a new mailing list for collaborating on documentation now:
>
> https://groups.google.com/forum/#!forum/jenkinsci-docs
>


-- 
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/bea5dfd5-7d7a-0f9d-ee27-1508a9fde7bb%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Problem during plugin release

[Thomas Fürer]

jep, but it is very hard to read the wiki, because lot of information is
outdated and I could not find this post you linked; and I was able to
release this plugin in the past and dont want to do the whole
configuration again. Nevertheless I did it again and found the pices I
need between alot of data at this page
https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins. Hope the
configuration will be stable for now.

tom


Am 26.11.2016 um 16:24 schrieb Daniel Beck:
> So basically, what you did is what's described in 
> https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plugintutorial-SettingUpEnvironment
>  as merely 'helpful', with parts 'probably unnecessary'? Without this file, 
> it didn't work?
>
>> On 26.11.2016, at 09:17, Thomas Fürer <tfuerer.java...@gmail.com> wrote:
>>
>> finally i did it. v1.8.0 of thinBackup is out now.
>>
>> Well, thot took some doing.
>>
>> What I've done:
>> * upgrade to parent pom 2.11 (-> look at thinBackup @ github)
>> * update the settings.xml temporary for this release and it looks like this 
>> one
>>
>> 
>> org.jenkins-ci.tools
>>   
>>
>>   
>> 
>> 
>>   jenkins
>>   
>> true 
>>   
>>   
>> 
>>   repo.jenkins-ci.org
>>   https://repo.jenkins-ci.org/public/
>> 
>>   
>>   
>> 
>>   repo.jenkins-ci.org
>>   https://repo.jenkins-ci.org/public/
>> 
>>   
>> 
>>   
>>   
>> 
>>   repo.jenkins-ci.org
>>   https://repo.jenkins-ci.org/public/
>>   m.g.o-public
>> 
>>   
>>
>>
>> hope this will help
>>
>> Tom
>> Am 24.11.2016 um 22:48 schrieb Baptiste Mathus:
>>> 401 or 403? Read Daniel's answer about it above if 401. You're probably 
>>> missing something in your settings.xml or so.
>>>
>>> If possible, come over to IRC right now to get a bit more interactive. Ping 
>>> batmat
>>>
>>> 2016-11-24 22:41 GMT+01:00 Martin Reinhardt <reinhardt.mar...@gmail.com>:
>>> having the same error
>>>
>>> Am Mittwoch, 23. November 2016 19:26:26 UTC+1 schrieb Thomas Fuerer:
>>> No, sorry.
>>>
>>> I still get the error
>>> [INFO] [ERROR] Failed to execute goal 
>>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on 
>>> project thinBackup: Failed to deploy artifacts: Could not transfer artifact 
>>> org.jvnet.hudson.plugins:thinBackup:hpi:1.8 from/to maven.jenkins-ci.org 
>>> (https://repo.jenkins-ci.org/releases/): Failed to transfer file: 
>>> https://repo.jenkins-ci.org/releases/org/jvnet/hudson/plugins/thinBackup/1.8/thinBackup-1.8.hpi.
>>>  Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
>>>
>>> Any idea?
>>>
>>> Thomas
>>>
>>> Am 21.11.2016 um 20:15 schrieb Peter Tierno:
>>>> On Wednesday, November 9, 2016 at 12:41:38 PM UTC-5, Thomas Fuerer wrote:
>>>> it seams that I'm still not authorized to release thinBackup plugin. 
>>>>
>>>> I hadded the missing information to the yaml file some days ago, but 
>>>> still get the same error. 
>>>>
>>>> have you resolved this? if so, how? im experiencing the same issue.
>>>> -- 
>>>> 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/8e0449bf-221a-48be-9099-b9c8efd4f39c%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/4e33e958-3db9-4935-aa6b-8c9669cd0ea0%40googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> &q

Re: Problem during plugin release

[Thomas Fürer]

finally i did it. v1.8.0 of thinBackup is out now.

Well, thot took some doing.

What I've done:
* upgrade to parent pom 2.11 (-> look at thinBackup @ github)
* update the settings.xml temporary for this release and it looks like
this one


org.jenkins-ci.tools
  

  


  jenkins
  
true 
  
  

  repo.jenkins-ci.org
  https://repo.jenkins-ci.org/public/

  
  

  repo.jenkins-ci.org
  https://repo.jenkins-ci.org/public/

  

  
  

  repo.jenkins-ci.org
  https://repo.jenkins-ci.org/public/
  m.g.o-public

  


hope this will help

Tom

Am 24.11.2016 um 22:48 schrieb Baptiste Mathus:
> 401 or 403? Read Daniel's answer about it above if 401. You're
> probably missing something in your settings.xml or so.
>
> If possible, come over to IRC right now to get a bit more interactive.
> Ping batmat
>
> 2016-11-24 22:41 GMT+01:00 Martin Reinhardt
> <reinhardt.mar...@gmail.com <mailto:reinhardt.mar...@gmail.com>>:
>
> having the same error
>
> Am Mittwoch, 23. November 2016 19:26:26 UTC+1 schrieb Thomas Fuerer:
>
> No, sorry.
>
> I still get the error
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
> (default-deploy) on project thinBackup: Failed to deploy
> artifacts: Could not transfer artifact
> org.jvnet.hudson.plugins:thinBackup:hpi:1.8 from/to
> maven.jenkins-ci.org <http://maven.jenkins-ci.org>
> (https://repo.jenkins-ci.org/releases/
> <https://repo.jenkins-ci.org/releases/>): Failed to transfer
> file:
> 
> https://repo.jenkins-ci.org/releases/org/jvnet/hudson/plugins/thinBackup/1.8/thinBackup-1.8.hpi
> 
> <https://repo.jenkins-ci.org/releases/org/jvnet/hudson/plugins/thinBackup/1.8/thinBackup-1.8.hpi>.
> Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
>
> Any idea?
>
> Thomas
>
> Am 21.11.2016 um 20:15 schrieb Peter Tierno:
>> On Wednesday, November 9, 2016 at 12:41:38 PM UTC-5, Thomas
>> Fuerer wrote:
>>
>> it seams that I'm still not authorized to release
>> thinBackup plugin.
>>
>> I hadded the missing information to the yaml file some
>> days ago, but
>> still get the same error.
>>
>> have you resolved this? if so, how? im experiencing the
>> same issue.
>>
>> -- 
>> 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/8e0449bf-221a-48be-9099-b9c8efd4f39c%40googlegroups.com
>> 
>> <https://groups.google.com/d/msgid/jenkinsci-dev/8e0449bf-221a-48be-9099-b9c8efd4f39c%40googlegroups.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout
>> <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
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/jenkinsci-dev/4e33e958-3db9-4935-aa6b-8c9669cd0ea0%40googlegroups.com
> 
> <https://groups.google.com/d/msgid/jenkinsci-dev/4e33e958-3db9-4935-aa6b-8c9669cd0ea0%40googlegroups.com?utm_medium=email_source=footer>.
>
>
> For more options, visit https://groups.google.com/d/optout
> <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
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6Sz7Lz29%2BrhRB0-vpuuyDDzaAFmhK46vf2S%2BayA49Vzg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6Sz7Lz29%2BrhRB0-vpuuy

Re: Problem during plugin release

[Thomas Fürer]

it seams that I'm still not authorized to release thinBackup plugin.

I hadded the missing information to the yaml file some days ago, but
still get the same error.

Thomas


Am 06.11.2016 um 11:05 schrieb Fritz Elfert:
> Hi,
>
> You do not have permissions to release thinBackup (actually NOBODY has).
> You can fix this yourself. Read the README here:
> https://github.com/jenkins-infra/repository-permissions-updater/
>
> Cheers
>  -Fritz
>
> On 06.11.2016 10:14, Thomas Fürer wrote:
>> Hi,
>>
>> I'm the maintainer of thinBackup-plugin and I want to release several
>> commits.
>> I tried it several time now with
>>
>> mvn release:prepare release:perform -Dusername=tofuatjava -Dpassword=...
>>
>> but I finally I get the error message
>>
>> [INFO] [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy)
>> on project thinBackup: Failed to deploy artifacts: Could not transfer
>> artifact org.jvnet.hudson.plugins:thinBackup:hpi:1.8 from/to
>> maven.jenkins-ci.org (https://repo.jenkins-ci.org/releases/): Failed to
>> transfer file:
>> https://repo.jenkins-ci.org/releases/org/jvnet/hudson/plugins/thinBackup/1.8/thinBackup-1.8.hpi.
>> Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
>>
>> I tried to update my credentials at accounts.jenkins-ci.io, but nothing
>> changes.
>> So, please could anyone check my credentials on the plugin hosting
>> repository or verify my settings in the pom?
>>
>> thomas
>>
>> PS: I found several posts in the wiki, most of them are in my opinion
>> outdate and it is not easy to find the relevant things.
>>
>>
>


-- 
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/af402a88-563a-1864-3a9d-4d63fdc96598%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Problem during plugin release

[Thomas Fürer]

I have tried to execute these script but get an NullPointerException.

I also have filed an Pull Request for my change.

Maybe anyone from the infrastructure crew can add this.


Thanks

Thomas


Am 06.11.2016 um 11:05 schrieb Fritz Elfert:
> Hi,
>
> You do not have permissions to release thinBackup (actually NOBODY has).
> You can fix this yourself. Read the README here:
> https://github.com/jenkins-infra/repository-permissions-updater/
>
> Cheers
>  -Fritz
>
> On 06.11.2016 10:14, Thomas Fürer wrote:
>> Hi,
>>
>> I'm the maintainer of thinBackup-plugin and I want to release several
>> commits.
>> I tried it several time now with
>>
>> mvn release:prepare release:perform -Dusername=tofuatjava -Dpassword=...
>>
>> but I finally I get the error message
>>
>> [INFO] [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy)
>> on project thinBackup: Failed to deploy artifacts: Could not transfer
>> artifact org.jvnet.hudson.plugins:thinBackup:hpi:1.8 from/to
>> maven.jenkins-ci.org (https://repo.jenkins-ci.org/releases/): Failed to
>> transfer file:
>> https://repo.jenkins-ci.org/releases/org/jvnet/hudson/plugins/thinBackup/1.8/thinBackup-1.8.hpi.
>> Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
>>
>> I tried to update my credentials at accounts.jenkins-ci.io, but nothing
>> changes.
>> So, please could anyone check my credentials on the plugin hosting
>> repository or verify my settings in the pom?
>>
>> thomas
>>
>> PS: I found several posts in the wiki, most of them are in my opinion
>> outdate and it is not easy to find the relevant things.
>>
>>
>


-- 
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/d37fb7fc-a767-592b-f83f-523625b9450e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Problem during plugin release

[Thomas Fürer]

Hi,

I'm the maintainer of thinBackup-plugin and I want to release several
commits.
I tried it several time now with

mvn release:prepare release:perform -Dusername=tofuatjava -Dpassword=...

but I finally I get the error message

[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy)
on project thinBackup: Failed to deploy artifacts: Could not transfer
artifact org.jvnet.hudson.plugins:thinBackup:hpi:1.8 from/to
maven.jenkins-ci.org (https://repo.jenkins-ci.org/releases/): Failed to
transfer file:
https://repo.jenkins-ci.org/releases/org/jvnet/hudson/plugins/thinBackup/1.8/thinBackup-1.8.hpi.
Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]

I tried to update my credentials at accounts.jenkins-ci.io, but nothing
changes.
So, please could anyone check my credentials on the plugin hosting
repository or verify my settings in the pom?

thomas

PS: I found several posts in the wiki, most of them are in my opinion
outdate and it is not easy to find the relevant things.


-- 
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/80b2a6d1-76c0-9b1e-297f-0e680f638ee4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: thinBackup: link to issues

[Thomas Fürer]

thank you Slide


Am 15.09.2016 um 18:00 schrieb Slide:
> I renamed thinBackup to thinbackup-plugin.
>
> On Thu, Sep 15, 2016 at 8:54 AM Thomas Fürer
> <tfuerer.java...@gmail.com <mailto:tfuerer.java...@gmail.com>> wrote:
>
> Hi Heiko,
>
> It's not possible for me to fix this issue, because the Confluence
> component adds automatically '-plugin' to the name but the
> component in JIRA is still 'thinBackup'.
>
> Maybe some admin could fix that...
>
> Thomas
>
>
>
>  Weitergeleitete Nachricht 
> Betreff:  thinBackup: link to issues
> Datum:Thu, 15 Sep 2016 05:46:42 -0400
> Von:  Nardmann, Heiko (Contractor) <heiko.nardm...@stryker.com>
> <mailto:heiko.nardm...@stryker.com>
> An:   'tfuerer.java...@gmail.com
> <mailto:tfuerer.java...@gmail.com>' <tfuerer.java...@gmail.com>
> <mailto:tfuerer.java...@gmail.com>
>
>
>
> Hi,
>
>  
>
> it looks like the link to /Open Issues/ on
> https://wiki.jenkins-ci.org/display/JENKINS/thinBackup is wrong?
>
>  
>
> Could you confirm this and maybe fix it?
>
>  
>
>  
>
> /Kind regards,/
>
>  
>
>   Heiko Nardmann
>
> -- 
> 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
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/jenkinsci-dev/0a5ee248-7d4a-b044-7b73-e609926a1e9a%40gmail.com
> 
> <https://groups.google.com/d/msgid/jenkinsci-dev/0a5ee248-7d4a-b044-7b73-e609926a1e9a%40gmail.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
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVf%2B%2BgX-fckFkXDsAeps1hnZQm3z_6TK%2BzS0wHmTOf-gxA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVf%2B%2BgX-fckFkXDsAeps1hnZQm3z_6TK%2BzS0wHmTOf-gxA%40mail.gmail.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/08451049-2087-de31-7349-9d747571b310%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fwd: thinBackup: link to issues

[Thomas Fürer]

Hi Heiko,

It's not possible for me to fix this issue, because the Confluence
component adds automatically '-plugin' to the name but the component in
JIRA is still 'thinBackup'.

Maybe some admin could fix that...

Thomas



 Weitergeleitete Nachricht 
Betreff:thinBackup: link to issues
Datum:  Thu, 15 Sep 2016 05:46:42 -0400
Von:Nardmann, Heiko (Contractor) <heiko.nardm...@stryker.com>
An: 'tfuerer.java...@gmail.com' <tfuerer.java...@gmail.com>



Hi,

 

it looks like the link to /Open Issues/ on
https://wiki.jenkins-ci.org/display/JENKINS/thinBackup is wrong?

 

Could you confirm this and maybe fix it?

 

 

/Kind regards,/

 

  Heiko Nardmann

-- 
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/0a5ee248-7d4a-b044-7b73-e609926a1e9a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Merge PR and release of requeue plugin

[Dirk Thomas]

Hi,

I recently made a pull request for the `requeue` plugin (
https://github.com/jenkinsci/jobrequeue-plugin/pull/3). Since the
maintainer is not responsive I would like to ask for either of the
following two:

* someone with commit access merge the PR and do a release
* grant me access to do the above (I have never done a Jenkins plugin
release though)
  * My GitHub name: dirk-thomas
  * My Jenkins account: dthomas

Thank you,
- Dirk

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

Re: How to enable Travis CI for jenkins plugin repo

[Thomas Zoratto]

The doc was only updated one week ago.

As Arnaud pointed out, this property is available for a long time I think. You 
can find a reference about it in a old 2009 article 
(http://www.sonarqube.org/using-quality-profiles-in-sonar/)

> Le 22 juil. 2016 à 16:54, Kanstantsin Shautsou  a 
> écrit :
> 
> http://docs.sonarqube.org/display/SONAR/Analysis+Parameters 
> 

-- 
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/49CDC5E5-9DC6-45EE-9F92-EA8DDC29A75B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable Travis CI for jenkins plugin repo

[Thomas Zoratto]

I’m not sure if this is what you mean by 'missing stats per branche' or not but 
you can have different reports for each branch in SonarQube (see sonar.branch 
property http://docs.sonarqube.org/display/SONAR/Analysis+Parameters)

> Le 22 juil. 2016 à 00:27, Kanstantsin Shautsou  a 
> écrit :
> 
> Good question, AFAIR we discussed few times to have SonarQube and Coverity 
> specially for Jenkins, but end with unability to do something in INFRA.
> According to email answer, public sonarqube (nemo instance?) has no “service” 
> feature where people can manage themselves configuration. 
> Codecov.io  is only about coverage based on jacoco 
> results (sonar seems is more powerful, but missing stats per branche).
> 
> Pushing automatically from jenkinsci will work. Jenkinsfile should work for 
> custom envs, but what could be done with env internals is under question. 
> With travis it is possible to run any SW/daemons internally. Ans is 
> Jenkinsfile already available for plugins?
> 
>> On Jul 21, 2016, at 22:52, Arnaud Héritier > > wrote:
>> 
>> codecov is a competitor of SonarQube ?
>> 
>> ex : https://sonarqube.com/overview?id=org.jenkins-ci.main%3Apom 
>> 
>> 
>> On Thu, Jul 21, 2016 at 8:18 PM, Gavin Mogan > > wrote:
>> I asked the same question late last year.
>> 
>> I have heard rumors that the cloudbees templates are being updated to use 
>> Jenkinsfile, which would be awesome.
>> 
>> Right now we've forked and done development on our own repo so we can 
>> trigger a build that does codecov and a few other minor things, but it would 
>> be amazing to use jenkins full time and be able to provide secure 
>> credentials somewhow.
>> 
>> Short term though, I'd love codecov ('cause thats what I'm using too)
>> 
>> Gavin
>> 
>> On Wednesday, July 20, 2016 at 1:51:14 PM UTC-7, Kohsuke Kawaguchi wrote:
>> So in this case the motivation is to activate Codecov.io 
>>  on plugins. On 
>> https://jenkins.ci.cloudbees.com/job/plugins/ 
>>  we use templating so that we 
>> only need to change the setting once to impact every plugin.
>> 
>> If we make that change across the board, would that make you happy enough to 
>> stop the use of Travis? It seems like it's a relatively easy change to make 
>> it happen, and I think it'd benefit everyone.
>> 
>> I'm asking because I think it sends a wrong signal when we are using Travis 
>> for something Jenkins does just as well.
>> 
>> On Wed, Jul 6, 2016 at 2:12 AM Andrey Pohilko > wrote:
>> Hi,
>> 
>> I'm the maintainer for performance-plugin repo.
>> 
>> I'm trying to use my typical approach with controlling the project quality 
>> using GitHub+TravisCI+Codecov integration, which proven its value for me. 
>> However, I'm missing the admin right on repo to enable TravisCI for it. Can 
>> anybody help me enabling it? I don't need the admin rights per se, just need 
>> to enable TravisCI for it.
>> 
>> https://travis-ci.org/jenkinsci/performance-plugin 
>> 
>> 
>> --
>> Andrey
>> 
>> -- 
>> 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/d43f9a06-568c-4d29-995f-e182f093a703%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/2a7e33bc-c9cf-403c-8e8c-a9eb53629bac%40googlegroups.com
>>  
>> .
>> 
>> For more options, visit https://groups.google.com/d/optout 
>> .
>> 
>> 
>> 
>> -- 
>> -
>> Arnaud Héritier
>> http://aheritier.net 
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this 

Re: [Blue Ocean] Build Error

[Thomas Zoratto]

Another process is listening on this port.

> Le 24 juin 2016 à 22:10, Andrew Gray  a écrit :
> 
> Hey Cliff,
> 
> I was able to get further. I installed a newer version of Maven... however 
> now after running the following command:
> 
> mvn -f blueocean-plugin/pom.xml hpi:run
> I receive this error:
> 
> FAILED ServerConnector@7b4aa08d{HTTP/1.1}{0.0.0.0:8080}: 
> java.net.BindException: Address already in use
> 
> Any help is appreciated.
> 
> Thanks,
> Andrew
> 
> 
> On Thursday, June 23, 2016 at 4:35:20 PM UTC-4, Andrew Gray wrote:
> I tried to follow the github instructions for building/running Blue Ocean... 
> however I encountered some errors I was hoping someone could help me resolve:
> Any help is appreciated.
> 
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building (Alpha) BlueOcean :: Aggregator 1.0-alpha-1-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] >>> maven-hpi-plugin:1.117:run (default-cli) @ blueocean >>>
> [WARNING] The POM for 
> io.jenkins.blueocean:blueocean-web:jar:1.0-alpha-1-SNAPSHOT is missing, no 
> dependency information available
> [WARNING] The POM for 
> io.jenkins.blueocean:blueocean-dashboard:jar:1.0-alpha-1-SNAPSHOT is missing, 
> no dependency information available
> [WARNING] The POM for 
> io.jenkins.blueocean:blueocean-rest:jar:1.0-alpha-1-SNAPSHOT is missing, no 
> dependency information available
> [WARNING] The POM for 
> io.jenkins.blueocean:blueocean-rest-impl:jar:1.0-alpha-1-SNAPSHOT is missing, 
> no dependency information available
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 4.095s
> [INFO] Finished at: Thu Jun 23 16:31:50 EDT 2016
> [INFO] Final Memory: 24M/309M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project blueocean: Could not resolve 
> dependencies for project 
> io.jenkins.blueocean:blueocean:hpi:1.0-alpha-1-SNAPSHOT: The following 
> artifacts could not be resolved: 
> io.jenkins.blueocean:blueocean-web:jar:1.0-alpha-1-SNAPSHOT, 
> io.jenkins.blueocean:blueocean-dashboard:jar:1.0-alpha-1-SNAPSHOT, 
> io.jenkins.blueocean:blueocean-rest:jar:1.0-alpha-1-SNAPSHOT, 
> io.jenkins.blueocean:blueocean-rest-impl:jar:1.0-alpha-1-SNAPSHOT: Failure to 
> find io.jenkins.blueocean:blueocean-web:jar:1.0-alpha-1-SNAPSHOT in 
> http://repo.jenkins-ci.org/public/  was 
> cached in the local repository, resolution will not be reattempted until the 
> update interval of repo.jenkins-ci.org  has 
> elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal on project blueocean: Could not resolve dependencies for project 
> io.jenkins.blueocean:blueocean:hpi:1.0-alpha-1-SNAPSHOT: The following 
> artifacts could not be resolved: 
> io.jenkins.blueocean:blueocean-web:jar:1.0-alpha-1-SNAPSHOT, 
> io.jenkins.blueocean:blueocean-dashboard:jar:1.0-alpha-1-SNAPSHOT, 
> io.jenkins.blueocean:blueocean-rest:jar:1.0-alpha-1-SNAPSHOT, 
> io.jenkins.blueocean:blueocean-rest-impl:jar:1.0-alpha-1-SNAPSHOT: Failure to 
> find io.jenkins.blueocean:blueocean-web:jar:1.0-alpha-1-SNAPSHOT in 
> http://repo.jenkins-ci.org/public/  was 
> cached in the local repository, resolution will not be reattempted until the 
> update interval of repo.jenkins-ci.org  has 
> elapsed or updates are forced
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> 

Re: Jenkins and Docker pull

[Zoratto Thomas]

Btw, the users mailing list is better suited for this kind of question 

> Le 13 juin 2016 à 16:30, Glen Millard  a écrit :
> 
> Hello everyone;
> 
> I want to include a Docker pull of several containers using a Jenkins job.
> 
> Questions:
> 
> is there/are they recommended plugins - I see a few - this one looks like 
> overkill - 
> https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Docker+Build+and+Publish+plugin
>  - has anyone used it?
> if not this plugin, do you recommend another?
> if not a plugin, recommend another way?
> 
> I'm new at CI so go easy on me please!
> 
> Thanks much.
> 
> Glen
> -- 
> 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/CAE5GgxjL91jxsnXU%3DPj7F0dErM27twYdDi1R7fk%2B-Rn543Cstw%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/47FCBF5E-FA74-4284-B803-E9F7D812495D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins and Docker pull

[Zoratto Thomas]

Hey,

Could you be more specific regarding your needs ? 

I use the plugin you mentioned but its goal is to build a docker image based on 
a dockerfile and then push it to docker hub for example. I'm not sure you're 
looking for something like that, am I wrong ?



> Le 13 juin 2016 à 16:30, Glen Millard  a écrit :
> 
> Hello everyone;
> 
> I want to include a Docker pull of several containers using a Jenkins job.
> 
> Questions:
> 
> is there/are they recommended plugins - I see a few - this one looks like 
> overkill - 
> https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Docker+Build+and+Publish+plugin
>  - has anyone used it?
> if not this plugin, do you recommend another?
> if not a plugin, recommend another way?
> 
> I'm new at CI so go easy on me please!
> 
> Thanks much.
> 
> Glen
> -- 
> 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/CAE5GgxjL91jxsnXU%3DPj7F0dErM27twYdDi1R7fk%2B-Rn543Cstw%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/E71EABBC-9CCF-46FF-9581-30FC964806C6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to publish plugin release?

[Zoratto Thomas]

Hi,

Actually you can rollback a release with the maven release plugin. See 
http://maven.apache.org/maven-release/maven-release-plugin/examples/rollback-release.html

Thomas

> Le 6 juin 2016 à 14:22, Mads Nielsen <m...@praqma.net> a écrit :
> 
> Hi Mark,
> 
> I'm affraid we do it the way you describe...all other options involve git 
> reset --hard and force pushing changes...so we will end up with a new release 
> with an extra version number bump, it would be nice if the maven release 
> plugin could handle this more gracefully, but like you i'm not sure on how to 
> do this the correct way. 
> 
> Best regards,
> Mads
> 
> 
> 
>  
> 
> 
> 
> Mads Nielsen
> Consultant
> m...@praqma.net
> +45 50 98 18 09
> Skype: inkspotPraqma
> www.praqma.com
> DK: CPH, Aarhus, Allerod
> NO: OSL
> SE: STHLM
> +45 36 PRAQMA
> 
> 
>> On Mon, Jun 6, 2016 at 2:09 PM, Mark Waite <mark.earl.wa...@gmail.com> wrote:
>> Thanks for confirming that I'm not the only one!  I assume R. Tyler Croy or 
>> one of the other infrastructure experts will need to be involved.
>> 
>> While waiting for that help, is there a recommendation of the best way to 
>> handle a "failure to release"?  
>> 
>> The release commit has been created, the release tag has been placed.  Once 
>> the infrastructure is able to accept a login, is it as simple as "mvn deploy 
>> -Dusername=MarkEWaite -Dpassword=my-actual-password"?
>> 
>> If it is not that simple, then is the next best to just "lose a version 
>> number" and use "mvn release:prepare release:perform" to release 
>> 2.0.0-beta2, rather than attempting to undo the partial release?  I know 
>> that I can't delete commits from the github.com repo (and I like that I 
>> can't delete commits).
>> 
>> Mark Waite
>> 
>>> On Mon, Jun 6, 2016 at 5:45 AM Mads Nielsen <m...@praqma.net> wrote:
>>> Hi Mark
>>> 
>>> You're not the only one...i failed to release our plugin yesterday, i even 
>>> updated it after the password reset. I use the older pom though.
>>> 
>>> Doesn't work :)
>>> 
>>> Best regards,
>>> Mads
>>> 
>>> 
>>> 
>>> Mads Nielsen
>>> Consultant
>>> m...@praqma.net
>>> +45 50 98 18 09
>>> Skype: inkspotPraqma
>>> www.praqma.com
>>> DK: CPH, Aarhus, Allerod
>>> NO: OSL
>>> SE: STHLM
>>> +45 36 PRAQMA
>>> 
>>> 
>>>> On Mon, Jun 6, 2016 at 6:07 AM, Mark Waite <mark.earl.wa...@gmail.com> 
>>>> wrote:
>>>> I completed a series of tests of git client plugin 2.0.0-beta1 and wanted 
>>>> to release it.  Unfortunately, the command which worked before is now 
>>>> failing.
>>>> 
>>>> This is the first time I'm trying to release the git client plugin using 
>>>> the new parent pom (version 2.9).  This is the first time I'm trying to 
>>>> release a plugin version in over a month.
>>>> 
>>>> Are others able to release new versions of their plugins?
>>>> 
>>>> The commands I use to release are:
>>>> 
>>>> 
>>>> $ java -version
>>>> java version "1.7.0_80"
>>>> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>>>> 
>>>> $ mvn -version
>>>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
>>>> 2015-11-10T09:41:47-07:00)
>>>> Maven home: /home/mwaite/tools/apache-maven-3.3.9
>>>> Java version: 1.7.0_80, vendor: Oracle Corporation
>>>> Java home: /usr/lib/jvm/java-7-oracle/jre
>>>> Default locale: en_US, platform encoding: UTF-8
>>>> OS name: "linux", version: "4.2.0-36-generic", arch: "amd64", family: 
>>>> "unix"
>>>> 
>>>> $ mvn release:prepare release:perform
>>>> ... Lost the text from my buffer while experimenting, but think it was 
>>>> "ReasonPhrase: Unauthorized" as at the end of this message
>>>> 
>>>> I then to deploy just the build:
>>>> $ git checkout git-client-2.0.0-beta1
>>>> HEAD is now at 36cb042... [maven-release-plugin] prepare release 
>>>> git-client-2.0.0-beta1
>>>> 
>>>> $ mvn deploy -Dusername=MarkEWaite 
>>>> -Dpassword=inserted-my-actual-jenkins-ci-password
>>>

Re: Account creation and recovery not sending email

[Suckow, Thomas J]

It is being really funky. I requested a password reset days ago and never got 
it. Then this morning I tried requesting with my email instead of username and 
it came after a few minutes.

Then just now I got the one from yesterday. Looking at the headers it appears 
to be getting stuck inside hemlock.osuosl.org

Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt0Msz+00C61 for
 ; Wed, 25 May 2016 18:23:17 + (UTC)
Received: from eggplant.jenkins-ci.org (hudson-java.osuosl.org
 [140.211.15.101]) by hemlock.osuosl.org (Postfix) with ESMTPS id B82CFBEED2
for ; Wed, 25 May 2016 00:02:10 + (UTC)

--
Thomas Suckow

From: <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> 
on behalf of Dietmar Scheidl 
<didi.sche...@gmail.com<mailto:didi.sche...@gmail.com>>
Reply-To: 
"jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Date: Tuesday, May 24, 2016 at 12:53 AM
To: Jenkins Developers 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Subject: Account creation and recovery not sending email

Hi,

I tried to create a account to access Jira but the email never arrives.

Also triggering password recovery does not send an email (tried several times).

Thanks in advance.


--
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<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/bcd85959-730a-44aa-b5f8-a50ed44c054b%40googlegroups.com<https://groups.google.com/d/msgid/jenkinsci-dev/bcd85959-730a-44aa-b5f8-a50ed44c054b%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/D36B3E8C.2E523%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Potential regressions re SECURITY-170

[Rob Thomas]

I believe there are some pretty serious regressions with SECURITY-170

I originally reported https://issues.jenkins-ci.org/browse/JENKINS-34865 
and was thinking 'this is a pretty obvious and serious bug.. Surely someone 
else would have noticed this' I then had a look through some of the recent 
bug reports.

Sadly, yes. A lot of them are having the same (or similar) problem:

JENKINS-34864:MultiJob predefined parameters no longer passed to phase 
project (Open) https://issues.jenkins-ci.org/browse/JENKINS-34864
JENKINS-34851:Strange quote rules for parameters (Closed) 
https://issues.jenkins-ci.org/browse/JENKINS-34851
JENKINS-34858:Listed Parameters should reflect what was used when the build 
ran (Open) https://issues.jenkins-ci.org/browse/JENKINS-34858

That was with a 10 minute browse of recent issues in your Jira.  Several 
other subjects hinted that they could be related, but I didn't investigate 
too much after that.

It was suggested that I post here, after mentioning it in your IRC channel.

--Rob

-- 
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/3990223a-fe6f-4324-91d2-62faf71b15c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Meet jenkins.io

[Thomas Fürer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

+1

really cool

tom

Am 24.03.2016 um 07:02 schrieb R. Tyler Croy:
> I finished up the final work for migration from https://jenkins-ci.org
 to
> https://jenkins.io today. The final step of the switchover was to redi
rect
> non-mapped URLs from jenkins-ci.org over to jenkins.io.
> 
> 
> This project has been a tremendous amount of work with Gus Reiber, Bap
tiste
> Mathaus, James Dumay, Daniel Beck, Oleg Nenashev  and a number of othe
r
> contributors filling in the new website with CSS, Haml, and most impor
tantly
> AsciiDoc (for documentation!)
> 
> 
> Some of the features of jenkins.io that are important to me, I'd like 
to share:
> 
>  * Visual priority given to the LTS release line (yay)
>  * Built-in support for three layers of documentation: solution pages,
 getting
>started guides and the "handbook".
>  * Visual elements to highlight upcoming events
>  * Certificates automated via letsencrypt.org (this is my favorite ;))
> 
> The site is statically generated and contributions are welcome here:
> 
> 
> 
> As I mentioned in our last project meeting, migration of other propert
ies such
> as wiki.jenkins-ci.org to the jenkins.io domain will take a bit more t
ime. This
> is an important first step however!
> 
> 
> 
> Cheers
> - R. Tyler Croy
> 
> --
>  Code: 
>   Chatter: 
> 
>   % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
> --
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW9C8cAAoJEMcwZAIehXs1l1IP/1jN8RFnHPUcGSjKtkDjdgl3
wy0LnvO15LR0LdMTmHNynMxuRX3kd3ngOhAHD8WL/gxAI6+3N7OkpOVU0Gl97Jkn
oWmCDV/OaUOUZMgtXfngmaS80lBqGqcan0M/77GzuIuBmdBRBJaF7WVPApXydZSp
Jt1MW8queIHnC3i27L7brjvdAw8SW+r4u92m57ghjyJnmWCUMde3TycDPolMCvZ4
spFYNIJhBCgcw1rRDy2FFh11Y6kcPlvEM5ZixgIHG3SlRh+3s1OmVXfVP8Em681B
oTlGen8QcWe4j6rQts0ExEOYg1K/hyIDECXmrkSIum5RpDxU3wvmgilOt2pJ7b2/
pA6GjhYGMbpSj1/cmK4KP8LC4HvjYnnXLu8pIUx7Qowa5BgkN76GeGHWzRE7+PhN
EkhquUe0zis1qvmUjbjONi76iRCrqQo06oW2LOrV79ly0+9P2LZwd9oAJ5g6X2Gc
0c4682v9Vs6Wa3afgFcxaf4/KUsHr7+3mFtvWLI4mfe86Jkg1N40RpHEjgsUqtUO
CKdaQ/JU7GFlNsgRE20flMyrlBYgT3xqbXfVnnNh+nDWKdeTzedzd3rXUkfgy8Bk
iEO3GbVA+r3GdqxJuBJJYaUzgdwxcRqUhenAL67+Qlw22A2pQKOJeEbxA8LMo6l7
avLLaGPi7PwOJCeBZApL
=zBwG
-END PGP SIGNATURE-

-- 
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/56F42F22.2080802%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: One-Shot Executors

[Suckow, Thomas J]

It would be an interesting feature if a build could be returned to the queue. I 
would actually like that in the case the slave disappeared during the build, 
I've had that happen a couple times over the last few years. Could also be 
interesting if you are shutting down jenkins and don't wan't to wait for a 
build to complete you could abort it and return it to the queue.

I think in the race condition case, as long as only a handful make it into the 
run state you won't be pounding the server saying "give me a slice." We have 
some large (to us) matrix builds and it probably isn't good to have 20-30 jobs 
all trying to get a cut of the pie.

From: <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> 
on behalf of nicolas de loof 
<nicolas.del...@gmail.com<mailto:nicolas.del...@gmail.com>>
Reply-To: 
"jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Date: Thursday, March 10, 2016 at 1:46 AM
To: "jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Subject: Re: One-Shot Executors

please see 
https://github.com/jenkinsci/one-shot-executor-plugin/commit/86c632091391e3204432a8c7d1a18bb48b3a66e3

basically, this on let the provisionner keep a task in the Queue when it can 
determine it hasn't enough resources to run extra slaves.
this can be used to prevent overload, or allocate some extra physical nodes.

2016-03-09 23:32 GMT+01:00 nicolas de loof 
<nicolas.del...@gmail.com<mailto:nicolas.del...@gmail.com>>:
"
I do agree that certain issues should fail immediately (image not found). 
Certain other issues should perform exponential backoff (Cloud infrastructure 
down). Provisioning limits could be annoying though, would be interesting if 
they could be left in the queue until Jenkins side provisioning limits are not 
violated. I am not sure how to handle an environment like Kubernetes though 
where other entities may be utilizing resources and you have to "share".
"

This is something we have in mind. Provisioner could wait for available 
resources before it creates a Slave, leaving the task in the queue with a 
LabelAssignment waiting for matching executor. Would anyway need to let the Run 
start then create the slave, which means some race condition could appear and 
the required resources aren't available for this Slave to start even they were, 
few ms before - or we need some way to reserve resources on the infra, which 
then would significantly limit the available implementations. Maybe then we 
could cancel the Run, as we run early in it's lifecycle, and re-schedule it as 
a task in the Queue, claiming the Run never existed ?

2016-03-09 21:40 GMT+01:00 Jesse Glick 
<jgl...@cloudbees.com<mailto:jgl...@cloudbees.com>>:
On Wed, Mar 9, 2016 at 11:52 AM, Suckow, Thomas J
<thomas.suc...@pnnl.gov<mailto:thomas.suc...@pnnl.gov>> wrote:
> Certain other issues should perform exponential backoff (Cloud
> infrastructure down).

Or just fail the build and the next one should work.

> It could also handle the logic of some users wanting to configure slaves on
> a per job basis.

If you mean “configure Docker images on a per-job basis”, this is
addressed by both the Docker Custom Build Environment and Docker
Pipeline plugins, both of which ought to move toward using this new
infrastructure.

--
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<mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3ycEVavhfm2Kuj5pOB5fkPF6vaOJfb6Zu-89y%2BQRm95g%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<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DQNuogSJvuUMWR9RbjczW1fAd8pAJD9aa0Lk0H5aFwAQ%40mail.gmail.com<https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DQNuogSJvuUMWR9RbjczW1fAd8pAJD9aa0Lk0H5aFwAQ%40mail.gmail.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 i

Re: One-Shot Executors

[Suckow, Thomas J]

On 3/9/16, 12:40 PM, "jenkinsci-dev@googlegroups.com on behalf of Jesse
Glick" 
wrote:
>
>Or just fail the build and the next one should work.

I just don't want to have to kick builds when a normal slave would "just
wait". Our cloud is also far from 99.9% uptime.

-- 
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/D30701C3.2858A%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: forbid direct commits to master for core

[Suckow, Thomas J]

Not being an iCLA signer I have experienced the loop of death and that’s fine. 
I do not however wish it on iCLA signers.

Would an acceptable compromise be that people with push access are allowed to 
optionally "skip" the human review portion of the PR? It would still require 
that Jenkins is able to build the PR before they are allowed to merge.

1. Submit PR
2. Wait for Jenkins to verify
3. If PR is no-longer mergable, or needs fix-up due to other PRs merged, Then 
fix up PR and Goto 2
4. Merge PR

Since it was a PR, people could still review it after the fact. I would also 
encourage them leaving it for review. But I imagine the biggest annoyance would 
be for bug fixes which should be lower risk and there is a high desire to get 
merged quickly.

-
Thomas

From: <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> 
on behalf of Stephen Connolly 
<stephen.alan.conno...@gmail.com<mailto:stephen.alan.conno...@gmail.com>>
Reply-To: 
"jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Date: Tuesday, March 8, 2016 at 12:29 PM
To: "jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Subject: Re: Proposal: forbid direct commits to master for core

I think I am now against this proposal. At least without an agreed mechanism to 
make large cross-cutting changes without ending up in the:

1. Submit PR
2. Request review
3. Wait
4. If PR is no-longer mergable, or needs fix-up due to other PRs merged, Then 
fix up PR and Goto 2
5. Merge PR

steps 2-4 loop of death.

Especially with a change that is open to debate, every time it is resubmitted 
for review, you will run the gauntlet of trying to get everyone to agree 
*again*.

There are some changes which are not well suited to either a PR or a feature 
branch.

Find a process that can enable those changes and I am all for that process... 
But blanket banning direct commits without enabling movement on fixes to core 
issues such as the idiotic forcing all plugins to change from getInstance to 
getActiveInstance because <5% of the callers in core have a need to work 
outside of the lifecycle of the singleton and some plugins want to break things 
by dragging the Jenkins class over to the remote class loaders... That will 
just drag the code base into the tarpit of dispair

On Tuesday 8 March 2016, Kanstantsin Shautsou 
<kanstantsin@gmail.com<mailto:kanstantsin@gmail.com>> wrote:
Keeping just for logging of this topic to save future time during searching 
examples
https://github.com/jenkinsci/jenkins/commit/bb7c8fcedbcc9b51c5b1bb5b32810af5ac6b1ffb

--
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<javascript:_e(%7B%7D,'cvml','jenkinsci-dev%2bunsubscr...@googlegroups.com');>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/851cc3bd-5d6b-46db-acc9-d1f04874ae8e%40googlegroups.com<https://groups.google.com/d/msgid/jenkinsci-dev/851cc3bd-5d6b-46db-acc9-d1f04874ae8e%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<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwsYad6nVBK8pp5de6Z%2BezyXpPbRMrDXZzZZY3Zm7Jttw%40mail.gmail.com<https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwsYad6nVBK8pp5de6Z%2BezyXpPbRMrDXZzZZY3Zm7Jttw%40mail.gmail.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/D305962B.282AE%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: One-Shot Executors

[Suckow, Thomas J]

I like that this moves the provisioning to the build log.

I do agree that certain issues should fail immediately (image not found). 
Certain other issues should perform exponential backoff (Cloud infrastructure 
down). Provisioning limits could be annoying though, would be interesting if 
they could be left in the queue until Jenkins side provisioning limits are not 
violated. I am not sure how to handle an environment like Kubernetes though 
where other entities may be utilizing resources and you have to "share".

You mention using labels to pick the slave. I'm wondering if it would be 
feasible and worthwhile to make such a plugin generic to be the middle layer 
for the Jenkins hooks to the cloud specific implementation (Docker, Kubernetes, 
AWS).

It could also handle the logic of some users wanting to configure slaves on a 
per job basis. Would be interesting if could also be integrated into cloudbees 
folder level. If the later could work then I wouldn't need to run my own 
Jenkins install at work for using containers and instead could use the company 
cloudbees Jenkins.

-
Thomas

From: <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> 
on behalf of nicolas de loof 
<nicolas.del...@gmail.com<mailto:nicolas.del...@gmail.com>>
Reply-To: 
"jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Date: Friday, March 4, 2016 at 3:08 AM
To: "jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" 
<jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>>
Subject: One-Shot Executors

Hi folks,

Yoann and I have extracted from our docker-slaves hack-ish pet project a stable 
sub-component so a plugin can manage slaves that are dedicated to a Build, not 
relying on Cloud API, and get them tied to a Build. i.e Slave and Build share a 
common lifecycle. If Slave fails to start, Build will fail as well. If slave is 
slow to start (maybe pulling a huge docker image), build log will report the 
progress.
etc.

design and use-case : 
https://wiki.jenkins-ci.org/display/JENKINS/One-Shot+Executor
code : https://github.com/jenkinsci/one-shot-executor-plugin

the current code base do rely on hacks, our goal is to demonstrate this use 
case (can be tested reusing 
sample<https://github.com/jenkinsci/one-shot-executor-plugin/blob/master/src/sample/java/org/jenkinsci/plugins/dockerprovisioner/DemoOneShotProvisioner.java>)
 so we can get the adequate hooks introduced in jenkins-core and later 
re-implement same API on a cleaner basis.




--
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<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznmnydODNX%2BYXmh0ujnJXsoZWcPT%2BpJCWwdR0_wUpfDTQ%40mail.gmail.com<https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznmnydODNX%2BYXmh0ujnJXsoZWcPT%2BpJCWwdR0_wUpfDTQ%40mail.gmail.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/D305926F.28292%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Release not listed for download

[Thomas Fürer]

Hi,

I have done a release of my plugin thinbackup the other day. On github
it is marked as release as expected
(https://github.com/jenkinsci/thin-backup-plugin). but in the
updatecenter of jenkins it is not available. is there something I need
to change in the release process?

Thomas

-- 
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/56D860D2.9070104%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

I am not a robot - I have been told

[Thomas S]

I could not create a jenkins account and need verification!
User: homaxto
Version: 1.645

Thanks in advance,
Thomas

-- 
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/fb08958a-27fb-4fe8-ac8d-08b99fdb17ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Hosting request for Silk Performer plugin

[Thomas Krupa]

Oleg,

I changed it to silk-performer-plugin

Here is the updated plugin’s info

- GitHub url: https://github.com/SilkPerformer/jenkins-silkperformer-executor/
- Name of plugin: silk-performer-plugin
- GitHub username: SilkPerformer
- Jenkins-ci.org username: silk
- Plugin description: This plugin provides a simple way to run a Silk Performer 
script on Jenkins


What about silkperformer-builder-plugin or just silk-performer-plugin. The 
latter one may be useful if you consider adding extra functionality like report 
publihers

понедельник, 14 декабря 2015 г., 13:02:34 UTC+3 пользователь Thomas Krupa 
написал:

-- 
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/7EC142638AF2FC498019B01847F0BA6E0134883E7C%40NWB-EXCHANGE2.microfocus.com.
For more options, visit https://groups.google.com/d/optout.

RE: Hosting request for Silk Performer plugin

[Thomas Krupa]

hi oleg,

I’d prefer silk-performer-plugin.

thanks
thomas

From: Oleg Nenashev [mailto:o.v.nenas...@gmail.com]
Sent: Montag, 14. Dezember 2015 18:26
To: Jenkins Developers
Cc: Thomas Krupa
Subject: Re: Hosting request for Silk Performer plugin

What about silkperformer-builder-plugin or just silk-performer-plugin. The 
latter one may be useful if you consider adding extra functionality like report 
publihers

понедельник, 14 декабря 2015 г., 13:02:34 UTC+3 пользователь Thomas Krupa 
написал:
Dear Team,

I would like to host new plugin on Jenkins community repository.

- GitHub url: https://github.com/SilkPerformer/jenkins-silkperformer-executor/
- Name of plugin: silkperformer-executor
- GitHub username: SilkPerformer
- Jenkins-ci.org username: silk
- Plugin description: This plugin provides a simple way to run a Silk Performer 
script on Jenkins


Thanks,
Thomas Krupa



Click 
here<https://www.mailcontrol.com/sr/LerJusUiy!jGX2PQPOmvUqs4kYhz3KDrRTSCJM0cHChfPXfsYOskZHAJPte9EuoTMcZaGkGEvSmDL!bKPtQR4w==>
 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/7EC142638AF2FC498019B01847F0BA6E0134883BB4%40NWB-EXCHANGE2.microfocus.com.
For more options, visit https://groups.google.com/d/optout.

Re: Guidance on how far SECURITY fixes should go

[Suckow, Thomas J]

What about a screen in Jenkins Admin that lists all the "breaking"
security fixes since the release of the LTS. By default after an update
any new security fixes are in "Unacknowledged mode". Having any
unacknowledged items adds a banner to the entire application.

You can then either "Accept the risk" and leave it unfixed or plug the
hole understanding that it might break christmas. If you are really fancy
you can track the callstacks of users of the api.

Pros:
* User consciously acts on breaking changes.
* User can probably determine outdated plugins and bug them to update.

Cons:
* A lot of work for the Core Jenkins team
* Something will inevitably happen where this pattern won't work


Just a thought. Though I don't use LTS and am used to Jenkins breaking on
a weekly basis because the world hates me.

-Thomas

On 9/15/15, 3:39 AM, "jenkinsci-dev@googlegroups.com on behalf of Stephen
Connolly" <jenkinsci-dev@googlegroups.com on behalf of
stephen.alan.conno...@gmail.com> wrote:

>Those of us who are on the jenkins-cert list have probably seen my
>comments about how there needs to be some guidance from the community
>on how far SECURITY issue fixes can go.
>
>I am starting this thread to try and start compiling that guidance.
>
>The general problem (as I cannot share the specifics outside of the
>jenkins-cert list) is as follows:
>
>* User raises a SECURITY issue from noticing some implicitly defined
>API of Jenkins has a hole of some sort
>* We have to fix the issue, but fixing it will involve changing the
>implicitly defined API and thus risking breaking existing "users" of
>the implicitly defined API
>* Much heated debate around should we leave the old API present and
>try and redirect to the new one (thereby leaving the hole open) or
>break existing plugins and close the hole.
>
>In some cases it is possible to use a system property to re-enable the
>hole for those users who are accepting of the risk... but other cases
>require changing class structures (this can range from encapsulating
>fields to completely reworking the java class that gets returned)
>
>My view is that a hole is a hole until it is fully plugged, and if
>plugging the hole means that some plugins break, well sorry but
>SECURITY... now by all means we should seek to minimize that breakage
>*while closing the hole*... and where possible we should provide a
>System property based switch to re-open the hole for those users who
>upgrade and are ok with the risk.
>
>Let's take a semi-concrete example:
>
>In order to fix SECURITY-144 we had to change the interface of
>h.r.Callable to include the role checking... being pre-java 8 we
>cannot use default methods, so this was a backwards incompatible
>change... any plugin that does not implement the role checking method
>would potentially be broken... as a result - and after much debate -
>it was decided that a majority of people implicitly trust their slaves
>as much as the master and so the role checking is likely not required
>for maybe 60-70% of installations. Thus the role checking ships off by
>default and we implemented a way to whitelist plugins that are
>compiled without role-checking support. Thus if you have slaves that
>are less trusted than the master you can opt-in to the higher security
>requirements... if there are plugins that you need that get broken,
>you can white-list those specific plugins if you absolutely need to.
>
>The point here is that we closed the hole. We felt the risk of plugins
>being broken was sufficiently high that the hole would not be closed
>by default (The plan is to measure the plugins with support for roles
>and once above a threshold then turn on secure by default) but when
>the security is turned on it is on.
>
>So what kind of things do we need guidance on:
>
>* Some methods of some objects allow you to discover information about
>other objects that you do not have permission to discover.
>- Do we just protect the ways that we know about and leave the
>original method present with a @Restricted(DoNotUse.class) so that
>when plugins upgrade their core version they are forced to switch to
>the new method; or
>- Do we change the contract of the current method (so it now
>returns maybe a null or throws an exception or omits entries from a
>collection) so that the method does what it was originally supposed to
>do but didn't... this may break existing plugins in fun and exciting
>ways
>
>* Some objects have public fields that are either mutable or of a type
>that needs to be changed in order to remove the hole.
>- Do we leave the field as is and just introduce the new accessor
>methods - leaves the hole as is... so we have to rely on adding a
>stapler action method (since t

Re: Commit access to jenkinsci/SCTMExecutor-plugin

[Thomas Fürer]

you are my hero of the day,

godfather of permissions ;-)

thanks again,
thomas

Am 08.09.2015 um 05:05 schrieb Daniel Beck:
> 
>> On 07.09.2015, at 08:53, Thomas Fürer <tfuerer.java...@gmail.com> wrote:
>>
>> Are you sure you add tofuatgit or tofuatjava to the admin group?
> 
> I did, but this specific "admin" group only gave write permissions. m( Fixed 
> now.
> 
> Did I mention permissions are a mess?
> 

-- 
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/55EF04F1.3010905%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Commit access to jenkinsci/SCTMExecutor-plugin

[Thomas Fürer]

thanks oleg and daniel,

I do not know how you want to do the permission stuff. however currently
I have no admin permissions to sctmexecutor but to thin-backup-plugin.
both repositories belongs to me!

Are you sure you add tofuatgit or tofuatjava to the admin group?

regards,
thomas

Am 07.09.2015 um 15:45 schrieb Daniel Beck:
> The permissions we have on GitHub are a complete mess.
> 
> We have the 'Everyone' group (which does _not_ contain everyone) that gives 
> push access to almost every repo. This is basically the 'default' permission 
> given by some project admins (my theory: the command requires less typing :-) 
> ). So you may well have commit access to your plugin repo, like almost 
> everyone else, but not be able to administer it (which is the case here). 
> OTOH you also get commit access to a thousand repos you don't care about (and 
> whose maintainers would well object to that). Cool, right?
> 
> Then we have per-repo 'foo-plugin Developers' groups, which gives admin 
> access for the one repo. This is what I assign most of the time. 
> Unfortunately, if you're given that permission, can use it to create new 
> repos and completely mess up the repo/group permission system we use. (Also, 
> most plugins probably shouldn't track their issues on GitHub when the users 
> are expecting that to be on the Jenkins JIRA.)
> 
> With this explanation out of the way, I made Thomas a member of 
> 'SCTMExecutor-plugin Developers'. Don't create new repos!
> 
>> On 06.09.2015, at 12:47, Oleg Nenashev <o.v.nenas...@gmail.com> wrote:
>>
>> I have no permissions to check your permissions :(
>> CC'ed Daniel Beck, he should be able to do it.
>>
>> 2015-09-06 21:55 GMT+03:00 Thomas Fürer <tfuerer.java...@gmail.com>:
>> Hi Oleg,
>>
>> thanks for helping, but why do I not have permissions to change
>> settings. I'm the founder, owner an maintainer of this plugin? I also
>> have a different plugin for jenkins (thinbackup) and here I'm able to
>> change the settings.
>>
>> Regards,
>> Thomas
>>
>> Am 06.09.2015 um 20:07 schrieb Oleg Nenashev:
>>> In GitHub the right approach to the contribution is to create pull
>>> requests from forks to the master repo. In such case the plugin
>>> developers will be able to review and accept the pull request.
>>>
>>> Anyway I've granted the commit permissions to Sebastian. He dhould get
>>> an invitation to the jenkinsci org soon.
>>>
>>> BR, Oleg
>>>
>>> суббота, 5 сентября 2015 г., 13:50:30 UTC+3 пользователь Thomas Fuerer
>>> написал:
>>>
>>> Hi seb,
>>>
>>> I'm wondering, because I'm not able to set ownership or commit
>>> rights on
>>> this project, even I'm the maintainer and owner of this project.
>>>
>>> So maybe one of the jenkins staff can help us.
>>>
>>> Meanwhile I saw you allready forked the project, but I'm not sure if in
>>> this case the release worflow will work?
>>>
>>> thanks,
>>> Thomas
>>>
>>> Am 21.08.2015 um 12:23 schrieb Sebastian Kornexl:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > when the source was on SVN I already had permissions to commit.
>>> >
>>> >
>>> >
>>> > Can I have these permission on GitHub too?
>>> >
>>> >
>>> >
>>> > Rep: https://github.com/jenkinsci/SCTMExecutor-plugin
>>> <https://github.com/jenkinsci/SCTMExecutor-plugin>
>>> >
>>> > GitHub account: donkaes
>>> >
>>> >
>>> >
>>> > Time for a new release of this plugin.
>>> >
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Sebastian
>>> >
>>> >
>>> >
>>> > --
>>> > 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 
>>> > <mailto:jenkinsci-dev+unsubscr...@googlegroups.com >.
>>> > To view this discussion on the web visit
>>> >
>>> 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/BDD6AE160CFA944A9A8A16488252F26C013466B7FD%40NWB-EXCHA

Re: Commit access to jenkinsci/SCTMExecutor-plugin

[Thomas Fürer]

Hi Oleg,

thanks for helping, but why do I not have permissions to change
settings. I'm the founder, owner an maintainer of this plugin? I also
have a different plugin for jenkins (thinbackup) and here I'm able to
change the settings.

Regards,
Thomas

Am 06.09.2015 um 20:07 schrieb Oleg Nenashev:
> In GitHub the right approach to the contribution is to create pull
> requests from forks to the master repo. In such case the plugin
> developers will be able to review and accept the pull request.
> 
> Anyway I've granted the commit permissions to Sebastian. He dhould get
> an invitation to the jenkinsci org soon.
> 
> BR, Oleg
> 
> суббота, 5 сентября 2015 г., 13:50:30 UTC+3 пользователь Thomas Fuerer
> написал:
> 
> Hi seb,
> 
> I'm wondering, because I'm not able to set ownership or commit
> rights on
> this project, even I'm the maintainer and owner of this project.
> 
> So maybe one of the jenkins staff can help us.
> 
> Meanwhile I saw you allready forked the project, but I'm not sure if in
>     this case the release worflow will work?
> 
> thanks,
> Thomas
> 
> Am 21.08.2015 um 12:23 schrieb Sebastian Kornexl:
> > Hi,
> >
> >  
> >
> > when the source was on SVN I already had permissions to commit.
> >
> >  
> >
> > Can I have these permission on GitHub too?
> >
> >  
> >
> > Rep: https://github.com/jenkinsci/SCTMExecutor-plugin
> <https://github.com/jenkinsci/SCTMExecutor-plugin>
> >
> > GitHub account: donkaes
> >
> >  
> >
> > Time for a new release of this plugin.
> >
> >  
> >
> > Thanks,
> >
> > Sebastian
> >
> >  
> >
> > --
> > 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 
> > <mailto:jenkinsci-dev+unsubscr...@googlegroups.com >.
> > To view this discussion on the web visit
> >
> 
> https://groups.google.com/d/msgid/jenkinsci-dev/BDD6AE160CFA944A9A8A16488252F26C013466B7FD%40NWB-EXCHANGE2.microfocus.com
> 
> <https://groups.google.com/d/msgid/jenkinsci-dev/BDD6AE160CFA944A9A8A16488252F26C013466B7FD%40NWB-EXCHANGE2.microfocus.com>
> 
> >
> 
> <https://groups.google.com/d/msgid/jenkinsci-dev/BDD6AE160CFA944A9A8A16488252F26C013466B7FD%40NWB-EXCHANGE2.microfocus.com?utm_medium=email_source=footer
> 
> <https://groups.google.com/d/msgid/jenkinsci-dev/BDD6AE160CFA944A9A8A16488252F26C013466B7FD%40NWB-EXCHANGE2.microfocus.com?utm_medium=email_source=footer>>.
> 
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/e9ef07c6-c05d-4fd5-8293-ce64c9ab47b4%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/e9ef07c6-c05d-4fd5-8293-ce64c9ab47b4%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/55EC8C0A.8030508%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Commit access to jenkinsci/SCTMExecutor-plugin

[Thomas Fürer]

Hi seb,

I'm wondering, because I'm not able to set ownership or commit rights on
this project, even I'm the maintainer and owner of this project.

So maybe one of the jenkins staff can help us.

Meanwhile I saw you allready forked the project, but I'm not sure if in
this case the release worflow will work?

thanks,
Thomas

Am 21.08.2015 um 12:23 schrieb Sebastian Kornexl:
> Hi,
> 
>  
> 
> when the source was on SVN I already had permissions to commit.
> 
>  
> 
> Can I have these permission on GitHub too?
> 
>  
> 
> Rep: https://github.com/jenkinsci/SCTMExecutor-plugin
> 
> GitHub account: donkaes
> 
>  
> 
> Time for a new release of this plugin.
> 
>  
> 
> Thanks,
> 
> Sebastian
> 
>  
> 
> -- 
> 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
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/BDD6AE160CFA944A9A8A16488252F26C013466B7FD%40NWB-EXCHANGE2.microfocus.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/BDD6AE160CFA944A9A8A16488252F26C013466B7FD%40NWB-EXCHANGE2.microfocus.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/55EAC906.6020006%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for hosting a plugin for QF-Test integration

[Thomas Max]

Hello Daniel,

thanks for you help.
I've added the original content of the wiki page again.

How can I add my plugin to the 
https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Buildtools

page.

Best regards,
 Thomas


 Original Message 


On 13.08.2015, at 16:25, Thomas Max thomas@qfs.de wrote:


I've added the wiki page as described. Could you guide me how to make it 
available again? Should I republish the wiki page or can you fix the DB issue ?


It's like the page never existed, the data has been lost. See: 
https://jenkins-ci.org/content/update-wiki-and-issue-tracker-outage

I recreated it with a very short description to make the plugin available 
during the next update center generator run. It's probably best if you just add 
the content to it again. I archived the cached text before I recreated it, 
contact me directly and I'll send it to you.



--
Thomas Max
Development  Support

E: thomas@qfs.de
T: +49 8171 38648-22
F: +49 8171 38648-16

Quality First Software GmbH | www.qfs.de
Tulpenstr. 41 | 82538 Geretsried | Germany
GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer
HRB München 140833

--
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/55CDB354.70808%40qfs.de.
For more options, visit https://groups.google.com/d/optout.

Re: Request for hosting a plugin for QF-Test integration

[Thomas Max]

Hello Chris,

well there are a lot of test tool connectors in the build tool 
category. A test tools category would fit best I believe.


Thanks for your help.

Best regards,
 Thomas


 Original Message 

This plugin doesn't seem to be a build tool, so it doesn't seem like
adding it to that section makes sense?

There probably should be a test tools category on that page, but I
don't believe that exists (yet).

In any case, plugins are shown on that page (and categorised in the
Jenkins Update Centre) based on the labels the wiki page has — take a
look at the other plugins in the relevant category.

Regards,
Chris


On 14/08/15 11:22, Thomas Max wrote:

Hello Daniel,

thanks for you help.
I've added the original content of the wiki page again.

How can I add my plugin to the
https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Buildtools
page.

Best regards,
  Thomas


 Original Message 


On 13.08.2015, at 16:25, Thomas Max thomas@qfs.de wrote:


I've added the wiki page as described. Could you guide me how to make
it available again? Should I republish the wiki page or can you fix
the DB issue ?


It's like the page never existed, the data has been lost. See:
https://jenkins-ci.org/content/update-wiki-and-issue-tracker-outage

I recreated it with a very short description to make the plugin
available during the next update center generator run. It's probably
best if you just add the content to it again. I archived the cached
text before I recreated it, contact me directly and I'll send it to you.







--
Thomas Max
Development  Support

E: thomas@qfs.de
T: +49 8171 38648-22
F: +49 8171 38648-16

Quality First Software GmbH | www.qfs.de
Tulpenstr. 41 | 82538 Geretsried | Germany
GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer
HRB München 140833

--
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/55CDBEA7.5070005%40qfs.de.
For more options, visit https://groups.google.com/d/optout.

Re: Request for hosting a plugin for QF-Test integration

[Thomas Max]

Hello Daniel,

I've added the wiki page as described. Could you guide me how to make it 
available again? Should I republish the wiki page or can you fix the DB 
issue ?


Best regards,
 Thomas


 Original Message 


On 12.08.2015, at 18:54, Christopher Orr ch...@orr.me.uk wrote:


This is happening because your wiki page (mysteriously) does not exist:
https://wiki.jenkins-ci.org/display/JENKINS/QF-Test+Plugin

It looks like it's there, but if you add something to the end of the URL
to bypass the cache, you can see that it's missing (possibly deleted,
but I think that shows a different message if so):
https://wiki.jenkins-ci.org/display/JENKINS/QF-Test+Plugin?foo

Since a wiki page is required, and you currently don't have one, that's
why your plugin isn't appearing in the Update Centre.


Could this be a victim of the DB issue? Judging from the earlier email's date, 
the wiki page may well have been created between 15th and 17th of July.



--
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/55CCA8DF.7060109%40qfs.de.
For more options, visit https://groups.google.com/d/optout.

Re: Request for hosting a plugin for QF-Test integration

[Thomas Max]

Hello Oleg,

the plugin appears in the 
repo http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/qftest/1.0.0/

but I cannot find it in the installable plugins yet. 
Unfortunately the build log from jenkins is not available right now 
(https://ci.jenkins-ci.org/view/Infrastructure/job/infra_update_center_v3/lastSuccessfulBuild/consoleText)
 
so I cannot check what is wrong.

Could you assist me on that issue.

Best regards,
 Thomas


Am Mittwoch, 15. Juli 2015 22:22:11 UTC+2 schrieb Oleg Nenashev:

 Hi Thomas,

 The repository has been forked to 
 https://github.com/jenkinsci/qftest-plugin 
 Welcome aboard, it's nice to see a plugin with additional integrations for 
 QF-Test

 Best regards,
 Oleg

 среда, 15 июля 2015 г., 12:56:20 UTC+3 пользователь Thomas Max, QFS 
 написал:

 Hello jenkins team, 

 we want to publish our plugin for Jenkins. 

 Here is the requested data : 


 URL:  https://github.com/qfs/qftest-plugin 
 Name: qftest-plugin 
 Github-ID: qfs 
 jenkins-ci.org username: qfs 
 Description: This plugin allows you to run QF-Test test-suites as a part 
 of the build step. http://www.qfs.de/en/index.html 

 Best regards, 
   Thomas 


 -- 
 Thomas Max 

 E: q...@qfs.de 
 T: +49 8171 38648-00 
 F: +49 8171 38648-16 

 Quality First Software GmbH | www.qfs.de 
 Tulpenstr. 41 | 82538 Geretsried | Germany 
 GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer 
 HRB München 140833 

 -- 
 Thomas Max 
 Development  Support 

 E: thoma...@qfs.de 
 T: +49 8171 38648-22 
 F: +49 8171 38648-16 

 Quality First Software GmbH | www.qfs.de 
 Tulpenstr. 41 | 82538 Geretsried | Germany 
 GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer 
 HRB München 140833 



 -- 
 Thomas Max 

 E: q...@qfs.de 
 T: +49 8171 38648-00 
 F: +49 8171 38648-16 

 Quality First Software GmbH | www.qfs.de 
 Tulpenstr. 41 | 82538 Geretsried | Germany 
 GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer 
 HRB München 140833 



-- 
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/d8256409-0234-46f0-a742-dfc9377ae227%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reviving Office Hours

[Suckow, Thomas J]

I've never tried it with a large meeting, but maybe it is worth trying
https://talky.io/ ?

-
Thomas

On 7/29/15, 12:56 PM, jenkinsci-dev@googlegroups.com on behalf of Daniel
Beck jenkinsci-dev@googlegroups.com on behalf of m...@beckweb.net wrote:


On 29.07.2015, at 20:12, Manuel Jesús Recena Soto rec...@gmail.com
wrote:

 The limit of Google Hangout (Office Hours) is reached!

I'm really sorry about that! I was under the impression that the hangout
supported ~15 people and when ~8 showed up thought that there was plenty
of space. I learned my lesson, and the next office hour will definitely
be a Hangout on Air.

Most of the office hour was my presentation on Stapler, and I'll annotate
and upload those slides so you'll have them at least. I'm also available
on IRC much of the time, so if you have questions on those, feel free to
ask me there.

Thanks for everyone who attended, and again, my apologies to everyone who
couldn't -- the next office hour will be better.

-- 
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/4BC7175A-78A5-44B4-8713-CB
307077F1D0%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

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

Re: UI changes branch progress report Day 1

[Suckow, Thomas J]

Nevermind, working now.

From: Thomas Suckow thomas.suc...@pnnl.govmailto:thomas.suc...@pnnl.gov
Subject: Re: UI changes branch progress report Day 1

Getting The party is over

From: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Subject: UI changes branch progress report Day 1

We'll be on hangout from 1pm-5pm pacific time at http://bit.ly/1RSkY1i if 
anyone else is interested in chiming in.

--
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/D1D6966A.18C00%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: How to jenkins interact with tests carried out with Karma via ssh

[Suckow, Thomas J]

You need a plugin like xUnit. Then you need to configure karma to output in a 
format it understands. I have traditionally saved all test output in junit 
format

From: Erick Macedo erickfmac...@gmail.commailto:erickfmac...@gmail.com
Reply-To: 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Date: Thursday, May 28, 2015 at 2:21 PM
To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Subject: How to jenkins interact with tests carried out with Karma via ssh

hi,

After much difficulty I can carry out the project for a transfer windowns 
server via ssh and run the grunt test.

Now my problem is the implementation of these test, the grunt performs 
functional tests with karma and stores it in an xml, the jenkins displays the 
result on the console.

But even if the test failed it builds successfully build.

How can I make jenkins interact with these tests to break the build on failure?

thank

--
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.commailto:jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6938fcf1-9a1c-42d8-a2b6-a9b9a52870bc%40googlegroups.comhttps://groups.google.com/d/msgid/jenkinsci-dev/6938fcf1-9a1c-42d8-a2b6-a9b9a52870bc%40googlegroups.com?utm_medium=emailutm_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/D18CE7F2.15577%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: How to jenkins interact with tests carried out with Karma via ssh

[Suckow, Thomas J]

Also, don't cross post. This should have only been asked on the jenkins-users 
list.

From: Erick Macedo erickfmac...@gmail.commailto:erickfmac...@gmail.com
Reply-To: 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Date: Thursday, May 28, 2015 at 2:21 PM
To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Subject: How to jenkins interact with tests carried out with Karma via ssh

hi,

After much difficulty I can carry out the project for a transfer windowns 
server via ssh and run the grunt test.

Now my problem is the implementation of these test, the grunt performs 
functional tests with karma and stores it in an xml, the jenkins displays the 
result on the console.

But even if the test failed it builds successfully build.

How can I make jenkins interact with these tests to break the build on failure?

thank

--
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.commailto:jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6938fcf1-9a1c-42d8-a2b6-a9b9a52870bc%40googlegroups.comhttps://groups.google.com/d/msgid/jenkinsci-dev/6938fcf1-9a1c-42d8-a2b6-a9b9a52870bc%40googlegroups.com?utm_medium=emailutm_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/D18CE918.1557E%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Changelog li's

[Suckow, Thomas J]

The changelog li's should really have /li, instead the browser has to figure 
it out

Just a thought...

-
Thomas

-- 
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/D189E618.151A0%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Changelog li's

[Suckow, Thomas J]

I did not know that.
I am going to pretend today is Monday and shut up now.


-
Thomas

On 5/26/15, 10:38 AM, Daniel Beck m...@beckweb.net wrote:


On 26.05.2015, at 17:58, Suckow, Thomas J thomas.suc...@pnnl.gov wrote:

 The changelog li's should really have /li, instead the browser has to
figure it out

This appears to be valid HTML, so any browser that fails to figure this
out should probably be avoided.

Quoting http://www.w3.org/TR/html401/intro/sgmltut.html:

 Some HTML element types allow authors to omit end tags (e.g., the P and
LI element types).


(I'm not saying the changelog has no problems -- it nests an entire
html document within another for example -- but this isn't one.)

-- 
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/EFBBB6BA-6F61-4AEC-A5D7-50
65C3C2CAE9%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

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

Re: Proposal : Jenkins to require Java 8

[Suckow, Thomas J]

 Didn't you just configured a JDK installation and select it from your job 
 configuration ?
Ya. Once I know how that works. I didn't expect it to be a global jenkins 
configuration when I only have that setup on a single slave. Maybe I am a bit 
slow. I also configured the slave to start with the desired jdk and was 
surprised when the job didn't use that same slave.




But we shouldn't stay at Java6 forever. I am seeing a lot of hints at
making some radical changes/improvements. Should we really be talking of a
Jenkins2 and not expect people to auto-update to it? We could offer 1 or 2
more LTS on the 1.x track.

What would change in 3/ 6 months ?
Lot's of people will still run RHEL 5 and build legacy Java 1.3 applications.

Ok, maybe 10 LTS's then. We need to have a plan for supporting the past and the 
future.  If we do have so many people wanting the java6 branch, then they 
should be able to support it. It sounds like we have a large number of people 
interested in java8 and I don't think such a transition will be ready for quite 
some time. I imagine we will also have people using both and maintaining both. 
I still have RHEL5 and a SPARC and I will do what I have to with those as long 
as I need to. But I also have bleeding edge items and I'd like to see Jenkins 
continue to push that envelope. This is a community, I can't imagine that if 
the mainline moved on to Java8 we wouldn't still help those who are still using 
the current mainline.

-
Thomas

-- 
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/D13733B8.11501%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal : Jenkins to require Java 8

[Suckow, Thomas J]

 What prevent you to get JDK8 on slave to run the remoting agent, but use
JDK installer to build your legacy JDK 1.1 application ?

In many cases this is possible. I don't think this is documented all that
well though (I've done it once and it took me a while to get it right). I
would imagine this is something that should be in an upgrade guide. If you
can't run JDK8, then you get to run a legacy Jenkins install.


 Sorry, but rhel5 is not something that we should care about, AFAIR it on
extended support. You can still use ancient jenkins version and ask RHEL
support to do patches for jenkins. RHEL6 and RHEL7 were released long
time ago - update your infra.

I don't think we should be making sure NEW release cycles support RHEL5.
It is in extended support, people in that environment should be
comfortable dealing with tools from that era. That said, there are ways to
make it work, but it shouldn't be blessed.


 And it's simply not possible to update Jenkins (master) in isolation,
the remoting model requires that all slaves use similar JREs, and satisfy
the minimum requirements.

But we shouldn't stay at Java6 forever. I am seeing a lot of hints at
making some radical changes/improvements. Should we really be talking of a
Jenkins2 and not expect people to auto-update to it? We could offer 1 or 2
more LTS on the 1.x track.

-
Thomas

-- 
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/D1372128.11495%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

[JENKINS-27034][#1569] Request for review/assistance of core PR

[Suckow, Thomas J]

I was hoping someone could critique my pull request for core. I am perplexed by 
the unit test failing as it succeeds on my system. I can't figure out how my 
test differs from some of the other similar tests.

I would also appreciate any critiques in general that would make this a better 
PR.


https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/2267/testReport/junit/hudson.model/JobQueueTest/projectLabelUsesEquals/
https://issues.jenkins-ci.org/browse/JENKINS-27034
https://github.com/jenkinsci/jenkins/pull/1569

-
Thomas

-- 
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/D135C47D.11346%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to get Remote build trigger working

[Suckow, Thomas J]

You probably need -X POST
https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API

From: Vinoth raj vinoth@gmail.commailto:vinoth@gmail.com
Reply-To: 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Date: Thursday, March 19, 2015 at 10:38 PM
To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Subject: Unable to get Remote build trigger working

I know this post applies to user group but I haven't have found any response 
there.
I believe the developers will be prudent to spot my issue and propose a 
solution instantly.

I need to use curl to remotely trigger build for a project.

Jenkins ver. 1.580.3
Following setting is done:
In Configure Global Security section:
- Jenkins' own user database set is enabled
- Project based matrix authorization strategy is enabled
There is one user who has all rights enabled here.

Project settings:
Trigger builds remotely is enabled (gave token a value '123abc')
Also, API token for the user is retrieved from user configure page.

Tried different versions of post from curl.

curl -user username:apiToken 
http://[jenkins:port]/job/projectname/build?token=123abc

I always get:
Authentication required
You are authenticated as: anonymous
Groups that you are in:
Permission you need to have (but didn't): hudson.model.Hudson.Read


Not sure what is causing this authentication fail. Please help!

--
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.commailto:jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/1f71a2fc-8ba9-4792-a6ab-56e79de2deef%40googlegroups.comhttps://groups.google.com/d/msgid/jenkinsci-dev/1f71a2fc-8ba9-4792-a6ab-56e79de2deef%40googlegroups.com?utm_medium=emailutm_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/D1318489.1107F%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Pull Requests Jenkins Core

[Suckow, Thomas J]

Dear all,

I am trying to figure out the best way to get a pull request accepted. This is 
a very community run organization and as such there are many updates and weekly 
releases. Though it appears (with the exception of translations) the last month 
has been only people with commiter access get their changes in core. So what 
is the best way to move forward with getting a change in the Core when you are 
not a commiter?

Any feedback is welcome. Even Your PR sucks because of X, because then I know 
what needs to be fixed.


The issue I am trying to get fixed: 
https://issues.jenkins-ci.org/browse/JENKINS-27034

--
Thomas

PS: I would ask this on IRC if it wasn't blocked/banned from our corporate 
network. If I really need to discuss this on IRC, I can join from home sometime.

-- 
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/D119CF99.FE47%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Are Labels truly singletons?

[Suckow, Thomas J]

Done.
https://issues.jenkins-ci.org/browse/JENKINS-27034

Thank you for your responses.

-
Thomas

From: Stephen Connolly 
stephen.alan.conno...@gmail.commailto:stephen.alan.conno...@gmail.com
Reply-To: 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Date: Wednesday, February 18, 2015 at 10:40 PM
To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 
jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com
Subject: Re: Are Labels truly singletons?



On Wednesday, February 18, 2015, Suckow, Thomas J 
thomas.suc...@pnnl.govmailto:thomas.suc...@pnnl.gov wrote:
Alright, I have made a pull request resolving a number of label equality
issues.
https://github.com/jenkinsci/jenkins/pull/1569


Should I make a formal JIRA issue and cross reference them?

Yes

-
Thomas

On 2/18/15, 12:40 PM, Jesse Glick jgl...@cloudbees.comjavascript:; wrote:

On Mon, Feb 9, 2015 at 7:29 PM, Suckow, Thomas J 
thomas.suc...@pnnl.govjavascript:;
wrote:
 The question becomes, are Labels singletons? Do I make a PR changing ==
to equals?

Should use equals(), as implied by the comment on Jenkins.labels and
the existing of the equals override.

--
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.comjavascript:;.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1UCyfCmvUCBY%2ByfCN
UmXr-jKDRG1L%3DNc_PttiWnjNtMg%40mail.gmail.comhttp://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.comjavascript:;.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/D10A5580.F542%25thomas.suckow%40pnnl.gov.
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.commailto:jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxmYfH3XA1hO%2B%2BbMQm%3DHbFGGF%3DH0XuptCXaFS9bYW6XEw%40mail.gmail.comhttps://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxmYfH3XA1hO%2B%2BbMQm%3DHbFGGF%3DH0XuptCXaFS9bYW6XEw%40mail.gmail.com?utm_medium=emailutm_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/D10B4D05.F5B5%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Are Labels truly singletons?

[Suckow, Thomas J]

Alright, I have made a pull request resolving a number of label equality
issues.
https://github.com/jenkinsci/jenkins/pull/1569


Should I make a formal JIRA issue and cross reference them?

-
Thomas

On 2/18/15, 12:40 PM, Jesse Glick jgl...@cloudbees.com wrote:

On Mon, Feb 9, 2015 at 7:29 PM, Suckow, Thomas J thomas.suc...@pnnl.gov
wrote:
 The question becomes, are Labels singletons? Do I make a PR changing ==
to equals?

Should use equals(), as implied by the comment on Jenkins.labels and
the existing of the equals override.

-- 
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/CANfRfr1UCyfCmvUCBY%2ByfCN
UmXr-jKDRG1L%3DNc_PttiWnjNtMg%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/D10A5580.F542%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Cloud slave never provisioned (sometimes)

[Suckow, Thomas J]

Looking into this further I come across this interesting nugget:

println( 
Jenkins.getInstance().unlabeledNodeProvisioner.stat.computeQueueLength() )
println( Label.get(mylabel).nodeProvisioner.stat.computeQueueLength() )

Gives:
1
0

Meaning, it is on a queue as unlabeled. Yet, the only job in the queue
states: pending‹All nodes of label Œmylabel¹ are offline


Anyone have ideas about how this might occur?

-
Thomas




From:  Suckow, Thomas Suckow
Subject:  Re: Cloud slave never provisioned (sometimes)


I am not convinced that the durable task plugin is to blame.

I am seeing a long line of:
FINE hudson.slaves.NodeProvisioner
Queue length 0 is less than the idle capacity 0. No provisioning strategy
required

Yet I have 8 jobs in the build queue. Something is afoot. I'l keep digging
when I have
 time. Any input on where I should look next is appreciated.


From: Stephen Connolly
Subject: Re: Cloud slave never provisioned (sometimes)


Note there was another deadlock found. There is an open pull request
pending to fix that one


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

Are Labels truly singletons?

[Suckow, Thomas J]

I have come across an issue where Queue uses == to compare Labels. This is fine 
if they are truly singletons. However, somehow [and I don't know why] I am 
getting an item in the queue with a Label that is not a singleton.

The question becomes, are Labels singletons? Do I make a PR changing == to 
equals? Or somehow attempt to find where this rogue Label is coming from (It is 
intermittent, and nothing was obvious in my suspect plugins)?

-
Thomas

-- 
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/D0FE9102.ED7B%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Cloud slave never provisioned (sometimes)

[Suckow, Thomas J]

The erroneous 1 is caused by a change in 2013.
https://github.com/jenkinsci/jenkins/pull/742

Now to track down the 0.

-
Thomas

On 2/9/15, 9:44 AM, Suckow, Thomas J thomas.suc...@pnnl.gov wrote:

Looking into this further I come across this interesting nugget:

println( 
Jenkins.getInstance().unlabeledNodeProvisioner.stat.computeQueueLength() )
println( Label.get(mylabel).nodeProvisioner.stat.computeQueueLength()
)

Gives:
1
0

Meaning, it is on a queue as unlabeled. Yet, the only job in the queue
states: pending‹All nodes of label Œmylabel¹ are offline


Anyone have ideas about how this might occur?

-
Thomas




From:  Suckow, Thomas Suckow
Subject:  Re: Cloud slave never provisioned (sometimes)


I am not convinced that the durable task plugin is to blame.

I am seeing a long line of:
FINE hudson.slaves.NodeProvisioner
Queue length 0 is less than the idle capacity 0. No provisioning strategy
required

Yet I have 8 jobs in the build queue. Something is afoot. I'l keep digging
when I have
 time. Any input on where I should look next is appreciated.


From: Stephen Connolly
Subject: Re: Cloud slave never provisioned (sometimes)


Note there was another deadlock found. There is an open pull request
pending to fix that one



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

Re: Cloud slave never provisioned (sometimes)

[Suckow, Thomas J]

I am not convinced that the durable task plugin is to blame.

I am seeing a long line of:

FINE hudson.slaves.NodeProvisioner

Queue length 0 is less than the idle capacity 0. No provisioning strategy 
required

Yet I have 8 jobs in the build queue. Something is afoot. I'l keep digging when 
I have time. Any input on where I should look next is appreciated.


From: Stephen Connolly
Subject: Re: Cloud slave never provisioned (sometimes)

Note there was another deadlock found. There is an open pull request pending to 
fix that one

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

Re: Cloud slave never provisioned (sometimes)

[Suckow, Thomas J]

Even with an up-to-date durable-task plugin, it happened again :(

I pulled the thread stack traces with the queued builds not building and then 
restarted jenkins. Comparing the threads, they are nearly identical.

I've added fine logging for the NodeProvisioner, hopefully that will show 
something, but it looks like it scrolls quicker than the GUI shows and I don't 
believe it gets logged to disk.

-
Thomas

From: Nigel Magnay
Subject: Re: Cloud slave never provisioned (sometimes)

The API is certainly problematic. For example, on the latest in-dev versions, I 
can generate (occasionally) a deadlock.

You may wish to try upgrading your durable-task plugin
Version 1.2 (Jan 13 2015)

  *   issue #26380http://issues.jenkins-ci.org/browse/JENKINS-26380 
Occasional deadlocks when running against Jenkins 1.592+.


-- 
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/D0ED4BA0.E0A3%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Re: Cloud slave never provisioned (sometimes)

[Suckow, Thomas J]

I have updated it. So far I haven't seen the issue, but the job also does not 
often get triggered. I'll keep an eye on it.

From: Nigel Magnay

The API is certainly problematic. For example, on the latest in-dev versions, I 
can generate (occasionally) a deadlock.

You may wish to try upgrading your durable-task 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/D0E7FF94.DE0C%25thomas.suckow%40pnnl.gov.
For more options, visit https://groups.google.com/d/optout.

Cloud slave never provisioned (sometimes)

[thomas . suckow]

 

I am trying to track down an issue where a cloud slave is never provisioned 
for a job that is scheduled. The annoying part is that it doesn't always 
happen, I would estimate about 1 in 4 times. I am specifically using the 
docker-plugin and the job is triggered by gerrit. Only one job appears to 
be affected and there are many other similar jobs that are similar (docker 
slave with a gerrit trigger)

I have added more debug logging to the docker-plugin to monitor how 
provisioning occurs. Sure enough provision() is never called, though 
canProvision is and returns true for the label expression.


I am not sure how I can inspect more into how Jenkins provisions cloud 
slaves and figure out why it never does. If another job comes along, it 
will provision for that job and leave this one.


Log snippet:

Jan 16, 2015 4:23:11 PM 
com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener
 
onTriggered   

INFO: Project [redacted-project] triggered by Gerrit: [PatchsetCreated: 
Change-Id for #1126: [redacted] PatchSet: 1]

Jan 16, 2015 4:23:11 PM 
com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.GerritTrigger 
schedule 

INFO: Project [redacted-project] Build Scheduled: true By event: 1126/1
 

Jan 16, 2015 4:23:17 PM com.nirima.jenkins.plugins.docker.DockerCloud 
canProvision  

INFO: Docker can provision 'centos6redacted'? true



Any thoughts appreciated,

Thomas

-- 
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/cd8d7e9e-ccf8-47e5-9c09-1bd06d95cef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Failure Using the Gradle JPI Plugin

[Thomas Goeppel]

Hello developers community!

I'd like to experiment with Jenkins plugins written in Groovy, and to get 
started I'm trying to build a Groovy Jenkins plugin demo from Shiran 
Rubin's talk at the 2014 Jenkins conference in Israel (video 
https://www.youtube.com/watch?v=h_epgCWJ8lE, slides 
https://www.cloudbees.com/sites/default/files/juc_presentation.pdf, my fork 
of the github-repository https://github.com/TG9541/frogballs-plugin).

The build fails with the following error message: 

 
:compileGroovy
:processResources UP-TO-DATE
:classes
:jpi FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jpi'.
 java/util/HashMap$Entry

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

I'm using Ubuntu 14.04, and since I couldn't find tool version 
requirements, I installed most things from packages. 

gradle -version prints the following versions: 

Gradle 1.4


Gradle build time: Monday, September 9, 2013 8:44:25 PM UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.3 compiled on April 8 2014
JVM: 1.7.0_65 (Oracle Corporation 24.65-b04)
OS: Linux 3.13.0-44-generic amd64


I tried the following, without seeing the error message change:


   - build with the --debug option, and Gradle prior to 2.0 had issues 
   with Java1.8 
   
http://forums.gradle.org/gradle/topics/gradle_fails_on_jdk8_with_java_lang_classnotfoundexception_java_util_hashmap_entry
 
   - I downgraded to Java/JDK1.7 * changed the gradle-jpi-plugin dependency 
   from version 0.5.0 to 0.7.2
   - used the dependencies I found in the job-dsl-plugin 
   https://github.com/jenkinsci/job-dsl-plugin/blob/master/build.gradle 
   (e.g. gradleVersion = '1.12') 


A generally recommendation in the Gradle forums is upgrading Gradle, and 
Groovy, to version 2.x. I do that, since it's not clear to me how the 
Groovy version used in Jenkins relates to the version used by the build 
tools (e.g. version of groovyc in the environment).

It would be nice if someone with more experience could have a look at it, 
and could shed some light on the Groovy version tool/build dependencies!

Thanks in advance!

-- 
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/2092c5b5-1d1d-475e-a251-c0d690720601%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

envinject plugin pull request #33

[Thomas Sondergaard]

Hi, 

I made the following pull request a few weeks ago and I was hoping someone 
here could do a review of it. 

https://github.com/jenkinsci/envinject-plugin/pull/33 

The bug I filed prior to the pull request: 

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

Pull request message (also git commit comment): 

For multi-configuration jobs the BUILD_CAUSE passed in the environment 
to build scripts is always UPSTREAMTRIGGER. Introduce ROOT_BUILD_CAUSE 
that expands UpstreamCause to the root causes. 

Update required jenkins version to 1.482 to get 
Cause.UpstreamCause.getUpstreamCauses(). 


Thanks, 
Thomas

Note: This is a repost - I originally posted via 
gmane.comp.java.hudson.devel and it turned up in the 
gmane.comp.java.hudson.devel group, but apparently it didn't make it back 
to google groups.

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

Commit access

[Thomas Sondergaard]

Hello,

I filed this bug on the 20th of September:

https://issues.jenkins-ci.org/browse/JENKINS-24785?focusedCommentId=211146#comment-211146

Made this pull request for it

https://github.com/jenkinsci/envinject-plugin/pull/33

I've asked on the mailing list for a code review and I have contacted a 
two of the most active committers for the envinject-plugin. I haven't 
heard anything. I'd like to request commit access


Repository name: jenkinsci/envinject-plugin
GitHub account name: tsondergaard

Regards,
Thomas

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

Re: envinject plugin pull request #33

[Thomas Sondergaard]

Ping.

On 29-09-2014 13:03, Thomas Sondergaard wrote:

Hi,

I made the following pull request a week ago and I was hoping someone
here could do a review of it.

https://github.com/jenkinsci/envinject-plugin/pull/33

The bug I filed prior to the pull request:

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

Pull request message (also git commit comment):


For multi-configuration jobs the BUILD_CAUSE passed in the environment
to build scripts is always UPSTREAMTRIGGER. Introduce ROOT_BUILD_CAUSE
that expands UpstreamCause to the root causes.

Update required jenkins version to 1.482 to get
Cause.UpstreamCause.getUpstreamCauses().


Thanks,
Thomas




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

envinject plugin pull request #33

[Thomas Sondergaard]

Hi,

I made the following pull request a week ago and I was hoping someone 
here could do a review of it.


https://github.com/jenkinsci/envinject-plugin/pull/33

The bug I filed prior to the pull request:

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

Pull request message (also git commit comment):


For multi-configuration jobs the BUILD_CAUSE passed in the environment
to build scripts is always UPSTREAMTRIGGER. Introduce ROOT_BUILD_CAUSE
that expands UpstreamCause to the root causes.

Update required jenkins version to 1.482 to get
Cause.UpstreamCause.getUpstreamCauses().


Thanks,
Thomas

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