Re: jaxen

[Jeff Thompson]

Yes, that’s my proposal.

Jeff


> On Mar 7, 2019, at 4:30 PM, R. Tyler Croy  wrote:
> 
> 
> Archival in GitHub sounds reasonable to me, I presume we won't do anything in
> Artifactory?
> 
> 
> If everybody's fine with this, either an Infra ticket, or one of the other
> github admins can take care of this easily.
> 
> 
> --
> GitHub:  https://github.com/rtyler
> 
> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

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

Re: jaxen

[R. Tyler Croy]

Archival in GitHub sounds reasonable to me, I presume we won't do anything in
Artifactory?


If everybody's fine with this, either an Infra ticket, or one of the other
github admins can take care of this easily.


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

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


signature.asc
Description: OpenPGP digital signature

jaxen

[Jeff Thompson]

Recently while looking to clean up something else I ran across a Jenkins 
specific fork of the jaxen library. The fork is at 
https://github.com/jenkinsci/jaxen 

I haven’t been able to detect any changes in the Jenkins fork. Indeed, the last 
commit in the fork seems to match perfectly to this commit in the official 
repository: 
https://github.com/jaxen-xpath/jaxen/commit/b08dc0a896a3712f636202e020bfcfa98ece4fb7
 


I also cannot find any uses of the fork in Jenkins. The version in the fork is 
the same as the latest standard published one. Most dependency references in 
the Jenkins ecosystem are actually to older versions. (That’s another issue.)

I propose to archive or delete the fork from the Jenkins organization to clean 
things up.

Any concerns or agreement?

Jeff Thompson

-- 
You received this message because you are 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/BA3DD97A-90BA-4807-A98F-1CD88F8CA09A%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

acceptance-test-harness questions

[Julien HENRY]

Hi folks,

In the SonarQube plugin 
, we have developed 
our own WebDriver based framework 

 
to test our plugin, including many Jenkins UI utility methods (create job, 
configure tools, ...). I discovered only "recently" the official 
acceptance-test-harness 
 project that seems 
to aim at the same goal. Maybe it was not existing when we started writing 
ITs but that's not important.

Today I would like to drop our own code, and use the common 
acceptance-test-harness, in order to save us some efforts, but I'm also 
ready to contribute. I have started migrating our test suites but so far I 
faced two issues:

1) location of the gecko driver

On my box, this code 

 
looks wrong, since it ends up configuring gecko driver property to:
which: no geckodriver in ()

Also I tried to force manually the path using the property 
-Dwebdriver.gecko.driver=xxx but it doesn't work, since the same code 
always override the property, without checking first if it was already 
defined. To me it seems the code only work when geckodriver *is* in the 
PATH.

I will try to submit a PR with some improvements, except if you told me I 
missed something.


2) SonarQube Scanner tool automatic installer returns outdated entries

My test was failing because it was not able to configure a SonarQube 
Scanner tool. After debugging, I was surprised to discover that the 
installer metadata are already cached 

 
when the JUT starts (and uses a very old copy). So the real update center 

 
is never called.

Is there any reason to have this hudson.plugins.sonar.SonarRunnerInstaller 
file in the acceptance-test-harness distribution? Can I simply open a PR to 
remove it, or is there a good reason to keep it?


Thanks for any insight

Julien

-- 
You received this message because you are 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/9812d38a-495d-4a1a-99e5-160e4137853a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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: Jenkins extended choice parameter plugin: do you have write permission?

[Oliver Gondža]

On 06/03/2019 17.46, Craig Rodrigues wrote:

Hi,

Do you have write privileges to the Jenkins extended-choice-parameter 
plugin? I notice that you merged this: 
jenkinsci/extended-choice-parameter-plugin#21


I have this patch jenkinsci/extended-choice-parameter-plugin#25 which 
gets Extended Choice Parameter plugin working inside a declarative pipeline.


If you have write privs, can you please merge that and release a new 
version of the plugin?


Hey,

jenkinsci/extended-choice-parameter-plugin#21 was a one time thing[1] as 
the plugin had no CI configured at all. I am adding Vimil into the loop 
to react.


For the record, there is a pending maintainership request from last year[2].

[1] https://groups.google.com/d/topic/jenkinsci-dev/6f_wKvfpESk/discussion
[2] https://groups.google.com/d/topic/jenkinsci-dev/rBi3dhQFfL4/discussion

--
oliver

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

Stage execution time, without node waiting time

[damien . coraboeuf]

Hi,

Is there a way to get the execution time of a stage, while excluding the 
time it has waited for a node to be available? The goal is for us to 
collect accurate metrics about the execution of stages, without taking into 
account the waiting time for nodes.

If using the TimingAction, this total time includes the waiting time for a 
node to be available and is therefore not suitable.

I've been also looking at 
SubTaskTimeInQueueAction#getExecutingDurationMillis, provided by the 
metrics plugin, but I did not test this yet. Since this action is attached 
to the build, I'm not sure I'll get the correct results though.

Thanks for any feedback on this topic.

Thanks,
Damien

-- 
You received this message because you are 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/e1230aa5-ca5d-41e6-8f72-77de037ce99e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.