Re: A simple update to pom.xml jenkins and plugin version seems to have created hundreds of changes from Infra in CI changes log?

[Mike Caspar]

Hmm. Thanks for the update Jesse.

My goal was to just keep the plugin at a place were it's still compatible 
(or relatively so) to make it easier should a new developer want to take it 
over.

Therefore, it seems that the default behavior is exactly what I wanted ! :->

In a year or so, when I make the next commit, I'll hunt for this message to 
figure out how the rest of your comments could help next time. For my 
current intended goal, it looks like I might want to do the same thing next 
year if I'm still the maintainer.

Thanks for the quick response. I'm glad I didn't break anything.

Mike



On Wednesday, April 17, 2019 at 12:37:21 PM UTC-7, Jesse Glick wrote:
>
> On Wed, Apr 17, 2019 at 2:33 PM Mike Caspar  > wrote: 
> > I was concerned to see the CI build server think  there are hundreds of 
> infra changes in my commit 
>
> Well, because there probably were: 
>
> https://github.com/jenkins-infra/pipeline-library/commits 
>
> Since any of these could potentially have affected how the build runs 
> compared to the previous build, they are listed. Of course we hope 
> that none of those changes _mattered_ to you and that everything “just 
> works”. 
>
> My longstanding recommendation was to not expose current `master` of a 
> library to the `Jenkinsfile`, and instead make it explicitly import a 
> specific version (which could be managed e.g. via Dependabot), so that 
> a change to infrastructure would always be tied to a specific commit 
> in your repository that could be tested in a PR before merging. But 
> that ship has probably sailed by now! 
>

-- 
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/f49301ce-1b2a-44b4-8cbe-19c22c93d320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any idea what could cause Jenkins console output to be mixed like this in a pipeline job?

[Martin Weber]

Am Dienstag, 16. April 2019, 23:06:34 CEST schrieb Jesse Glick:
> On Tue, Apr 16, 2019 at 12:57 PM Daniel Anechitoaie
> 
>  wrote:
> > This seems too be happening only wen I run Jenkins in a Master/Slave setup
> > (2 servers). If I only have the master it seems there's no problem with
> > the output.
> Yes, this is specific to use of Remoting.

Could this cause JENKINS-55215 https://issues.jenkins-ci.org/browse/
JENKINS-55215 ?

-- 
E-Mails sollten Text sein, Text und nur Text.
Wenn Gott gewollt hätte, dass E-Mails in HTML geschrieben würden,
endeten Gebete traditionell mit .


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

Re: A simple update to pom.xml jenkins and plugin version seems to have created hundreds of changes from Infra in CI changes log?

[Jesse Glick]

On Wed, Apr 17, 2019 at 2:33 PM Mike Caspar  wrote:
> I was concerned to see the CI build server think  there are hundreds of infra 
> changes in my commit

Well, because there probably were:

https://github.com/jenkins-infra/pipeline-library/commits

Since any of these could potentially have affected how the build runs
compared to the previous build, they are listed. Of course we hope
that none of those changes _mattered_ to you and that everything “just
works”.

My longstanding recommendation was to not expose current `master` of a
library to the `Jenkinsfile`, and instead make it explicitly import a
specific version (which could be managed e.g. via Dependabot), so that
a change to infrastructure would always be tied to a specific commit
in your repository that could be tested in a PR before merging. But
that ship has probably sailed by now!

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

Re: A simple update to pom.xml jenkins and plugin version seems to have created hundreds of changes from Infra in CI changes log?

[Mike Caspar]

More info...

Just noticed commits to this project from almost 1 year ago that don't come 
from me in the Blue Ocean interface...

https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fironmq-notifier-plugin/detail/master/24/changes

Mike


On Wednesday, April 17, 2019 at 11:33:25 AM UTC-7, Mike Caspar wrote:
>
> Hi there.
>
> Today I decided to just get the POM Plugin version updated to something 
> current and test with a new version of Jenkins to keep things at least 
> relatively current
>
> The last time I pushed was more than a year ago.
>
> I was concerned to see the CI build server think  there are hundreds of 
> infra changes in my commit (I only changed the following) in a pom.xml
>
> 
> org.jenkins-ci.plugins
> plugin
> 3.42
> 
> 
>  
> 2.164.2
> 8
>
> I checked the github push.  It only has the push of one changed pom.xml
>
> Yet, the jenkins build shows hundreds of changes  (
> https://ci.jenkins.io/job/Plugins/job/ironmq-notifier-plugin/job/master/changes
> )
>
> ( short sampling)
> ...
> Do not archive build products from nondefault Jenkins versions. — jglick / 
> githubweb
> Use performance-optimized mode for plugin builds — samvanoort / githubweb
> Add JSON files and content type to publishReports — daniel-beck / githubweb
> [INFRA-1489] First implementation — rarabaolaza / githubweb
> [INFRA-1489] Feedback on documentation — rarabaolaza / githubweb
> [INFRA-1489] Address feedback — rarabaolaza / githubweb
> [INFRA-1489] More feedback — rarabaolaza / githubweb
> Pass -Daccess-modifier-checker.failOnError=false when using a custom 
> baseline. — jglick / githubweb
> [JENKINS-50405] Run the entire thing in docker && highmem node — 
> rarabaolaza / githubweb
> [JENKINS-50405] Fix ensureInNode so it can be used with several labels — 
> rarabaolaza / githubweb
> [JENKINS-50405] Make sure the nodes are still overridable via env 
> properties — rarabaolaza / githubweb
> [JENKINS-50405] Fix docs — rarabaolaza / githubweb
>
> 
>
>
> Is this normal for a plugin that hasn't had a commit for a long time ?
>
> If not, could someone who understands this take a look to make sure 
> everything is OK?
>
> Thanks
>
>
>

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

A simple update to pom.xml jenkins and plugin version seems to have created hundreds of changes from Infra in CI changes log?

[Mike Caspar]

Hi there.

Today I decided to just get the POM Plugin version updated to something 
current and test with a new version of Jenkins to keep things at least 
relatively current

The last time I pushed was more than a year ago.

I was concerned to see the CI build server think  there are hundreds of 
infra changes in my commit (I only changed the following) in a pom.xml


org.jenkins-ci.plugins
plugin
3.42


 
2.164.2
8

I checked the github push.  It only has the push of one changed pom.xml

Yet, the jenkins build shows hundreds of changes  (
https://ci.jenkins.io/job/Plugins/job/ironmq-notifier-plugin/job/master/changes
)

( short sampling)
...
Do not archive build products from nondefault Jenkins versions. — jglick / 
githubweb
Use performance-optimized mode for plugin builds — samvanoort / githubweb
Add JSON files and content type to publishReports — daniel-beck / githubweb
[INFRA-1489] First implementation — rarabaolaza / githubweb
[INFRA-1489] Feedback on documentation — rarabaolaza / githubweb
[INFRA-1489] Address feedback — rarabaolaza / githubweb
[INFRA-1489] More feedback — rarabaolaza / githubweb
Pass -Daccess-modifier-checker.failOnError=false when using a custom 
baseline. — jglick / githubweb
[JENKINS-50405] Run the entire thing in docker && highmem node — 
rarabaolaza / githubweb
[JENKINS-50405] Fix ensureInNode so it can be used with several labels — 
rarabaolaza / githubweb
[JENKINS-50405] Make sure the nodes are still overridable via env 
properties — rarabaolaza / githubweb
[JENKINS-50405] Fix docs — rarabaolaza / githubweb




Is this normal for a plugin that hasn't had a commit for a long time ?

If not, could someone who understands this take a look to make sure 
everything is OK?

Thanks


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

Re: Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Jesse Glick]

On Wed, Apr 17, 2019 at 11:53 AM Daniel Anechitoaie
 wrote:
> What's strange is that if I use sh() step it works ok. Isn't sh step also 
> executing on the slave?

Yes but traditionally the _output_ was processed on the master not the
agent. That is still true by default, pending JENKINS-52165 being
reclosed by turning the feature flag back on.

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

Re: Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Matt Sicker]

Latest release is 3.42: https://github.com/jenkinsci/plugin-pom/releases

On Wed, Apr 17, 2019 at 10:53 AM Daniel Anechitoaie
 wrote:
>
> What's strange is that if I use sh() step it works ok. Isn't sh step also 
> executing on the slave?
>
> So this works fine:
>
> ---
> node {
> stage('Test') {
> withCodeReviewAssistantGitHubCheckRun(args) {
> sh('ls -alh')
> }
> }
> }
> ---
>
>
> On Wednesday, April 17, 2019 at 6:47:49 PM UTC+3, Daniel Anechitoaie wrote:
>>
>> I'm using
>>
>> 
>> org.jenkins-ci.plugins
>> plugin
>> 3.6
>> 
>> 
>>
>>
>> Is this the latest parent POM? I'm not sure how to check which is the latest 
>> version available.
>>
>> On Wednesday, April 17, 2019 at 6:09:07 PM UTC+3, Jesse Glick wrote:
>>>
>>> On Wed, Apr 17, 2019 at 10:47 AM Daniel Anechitoaie
>>>  wrote:
>>> > So I think the problem might be with serialization and they way I try to 
>>> > capture data in TaskListenerDecorator
>>>
>>> Probably. You should not be attempting to serialize a `StepExecution`
>>> there; it can only be saved in `program.dat`, whereas
>>> `TaskListenerDecorator` is sent to agent JVMs under some conditions
>>> (including your own `XMLLinterStepCallable`). Anyway your code could
>>> not possibly work as written since the `addBodyOutputLine` call would
>>> be made on a _copy_ of the original object, not the one actually used
>>> in the callback. If this output is important, you would need to
>>> explicitly stream it back to the master somehow, as in
>>>
>>> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/5d48ed444cd4041d4b00a2c7197559406d1a2c9a/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java#L255-L336
>>>
>>> (You must be very defensive when writing a `SlaveToMasterCallable`, so
>>> this is not for the faint-hearted, but it seems you have already
>>> gotten into some pretty advanced usage.)
>>>
>>>
>>> There may be some error being printed that you are not seeing
>>> currently—make sure you use the newest parent POM, and call the new
>>> API in
>>>
>>> https://github.com/jenkinsci/jenkins-test-harness/pull/127
>>>
>>> from your tests.
>>>
>>>
>>> BTW pending availability of
>>>
>>> https://github.com/jenkinsci/jenkins/pull/3959
>>>
>>> in your `jenkins.version`, you must override `flush` and `close` as
>>> shown there. Also `XMLLinterStepCallable.invoke` should `flush` before
>>> exiting.
>
> --
> 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/dede9132-120f-4eb5-806e-06a2db04163b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
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/CAEot4oxKActumxcnRQWg2YgLO6-o%2BUmT-ZwbFNvgUoJLqC8zVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Daniel Anechitoaie]

What's strange is that if I use sh() step it works ok. Isn't sh step also 
executing on the slave?

So this works fine:

---
node {
stage('Test') {
withCodeReviewAssistantGitHubCheckRun(args) {
sh('ls -alh')
}
}
}
---


On Wednesday, April 17, 2019 at 6:47:49 PM UTC+3, Daniel Anechitoaie wrote:
>
> I'm using 
>
> 
> org.jenkins-ci.plugins
> plugin
> 3.6
> 
> 
>
>
> Is this the latest parent POM? I'm not sure how to check which is the 
> latest version available.
>
> On Wednesday, April 17, 2019 at 6:09:07 PM UTC+3, Jesse Glick wrote:
>>
>> On Wed, Apr 17, 2019 at 10:47 AM Daniel Anechitoaie 
>>  wrote: 
>> > So I think the problem might be with serialization and they way I try 
>> to capture data in TaskListenerDecorator 
>>
>> Probably. You should not be attempting to serialize a `StepExecution` 
>> there; it can only be saved in `program.dat`, whereas 
>> `TaskListenerDecorator` is sent to agent JVMs under some conditions 
>> (including your own `XMLLinterStepCallable`). Anyway your code could 
>> not possibly work as written since the `addBodyOutputLine` call would 
>> be made on a _copy_ of the original object, not the one actually used 
>> in the callback. If this output is important, you would need to 
>> explicitly stream it back to the master somehow, as in 
>>
>>
>> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/5d48ed444cd4041d4b00a2c7197559406d1a2c9a/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java#L255-L336
>>  
>>
>> (You must be very defensive when writing a `SlaveToMasterCallable`, so 
>> this is not for the faint-hearted, but it seems you have already 
>> gotten into some pretty advanced usage.) 
>>
>>
>> There may be some error being printed that you are not seeing 
>> currently—make sure you use the newest parent POM, and call the new 
>> API in 
>>
>> https://github.com/jenkinsci/jenkins-test-harness/pull/127 
>>
>> from your tests. 
>>
>>
>> BTW pending availability of 
>>
>> https://github.com/jenkinsci/jenkins/pull/3959 
>>
>> in your `jenkins.version`, you must override `flush` and `close` as 
>> shown there. Also `XMLLinterStepCallable.invoke` should `flush` before 
>> exiting. 
>>
>

-- 
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/dede9132-120f-4eb5-806e-06a2db04163b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Daniel Anechitoaie]

I'm using 


org.jenkins-ci.plugins
plugin
3.6




Is this the latest parent POM? I'm not sure how to check which is the 
latest version available.

On Wednesday, April 17, 2019 at 6:09:07 PM UTC+3, Jesse Glick wrote:
>
> On Wed, Apr 17, 2019 at 10:47 AM Daniel Anechitoaie 
> > wrote: 
> > So I think the problem might be with serialization and they way I try to 
> capture data in TaskListenerDecorator 
>
> Probably. You should not be attempting to serialize a `StepExecution` 
> there; it can only be saved in `program.dat`, whereas 
> `TaskListenerDecorator` is sent to agent JVMs under some conditions 
> (including your own `XMLLinterStepCallable`). Anyway your code could 
> not possibly work as written since the `addBodyOutputLine` call would 
> be made on a _copy_ of the original object, not the one actually used 
> in the callback. If this output is important, you would need to 
> explicitly stream it back to the master somehow, as in 
>
>
> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/5d48ed444cd4041d4b00a2c7197559406d1a2c9a/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java#L255-L336
>  
>
> (You must be very defensive when writing a `SlaveToMasterCallable`, so 
> this is not for the faint-hearted, but it seems you have already 
> gotten into some pretty advanced usage.) 
>
>
> There may be some error being printed that you are not seeing 
> currently—make sure you use the newest parent POM, and call the new 
> API in 
>
> https://github.com/jenkinsci/jenkins-test-harness/pull/127 
>
> from your tests. 
>
>
> BTW pending availability of 
>
> https://github.com/jenkinsci/jenkins/pull/3959 
>
> in your `jenkins.version`, you must override `flush` and `close` as 
> shown there. Also `XMLLinterStepCallable.invoke` should `flush` before 
> exiting. 
>

-- 
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/efc88986-b84c-46c9-8caf-5ae313eb8397%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Jesse Glick]

On Wed, Apr 17, 2019 at 10:47 AM Daniel Anechitoaie
 wrote:
> So I think the problem might be with serialization and they way I try to 
> capture data in TaskListenerDecorator

Probably. You should not be attempting to serialize a `StepExecution`
there; it can only be saved in `program.dat`, whereas
`TaskListenerDecorator` is sent to agent JVMs under some conditions
(including your own `XMLLinterStepCallable`). Anyway your code could
not possibly work as written since the `addBodyOutputLine` call would
be made on a _copy_ of the original object, not the one actually used
in the callback. If this output is important, you would need to
explicitly stream it back to the master somehow, as in

https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/5d48ed444cd4041d4b00a2c7197559406d1a2c9a/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java#L255-L336

(You must be very defensive when writing a `SlaveToMasterCallable`, so
this is not for the faint-hearted, but it seems you have already
gotten into some pretty advanced usage.)


There may be some error being printed that you are not seeing
currently—make sure you use the newest parent POM, and call the new
API in

https://github.com/jenkinsci/jenkins-test-harness/pull/127

from your tests.


BTW pending availability of

https://github.com/jenkinsci/jenkins/pull/3959

in your `jenkins.version`, you must override `flush` and `close` as
shown there. Also `XMLLinterStepCallable.invoke` should `flush` before
exiting.

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

Re: Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Daniel Anechitoaie]

Nope. I'm still getting NullPointerException even with 

getContext().newBodyInvoker() .withContexts(environmentExpander, 
taskListenerDecorator) 
.withCallback(BodyExecutionCallback.wrap(getContext())) .start(); 

So something else must be the issue but not sure what.


On Wednesday, April 17, 2019 at 4:54:53 PM UTC+3, Daniel Anechitoaie wrote:
>
> I suspect my problem is with .withCallback(new 
> WithCheckRunStepExecutionCallback(this)) ?
> But then if I use ".withCallback(BodyExecutionCallback.wrap(getContext()))" 
> instead, how will I be able to read a variable from within StepExecution 
> class?
>
>
>
> On Wednesday, April 17, 2019 at 4:18:28 PM UTC+3, Daniel Anechitoaie wrote:
>>
>> I have a pipeline step plugin that wraps other steps and captures the 
>> output and for some reason this causes a Null Pointer Exception when I try 
>> to do logger.println() from the step plugin that is wrapped.
>>
>> *So with this pipeline:*
>> ---
>> node {
>> stage('Test') {
>> withCodeReviewAssistantGitHubCheckRun(args) {
>> codeReviewAssistantXMLLint()
>> }
>> }
>> }
>> ---
>>
>>
>> *withCodeReviewAssistantGitHubCheckRun having a:*
>> ---
>> private static class 
>> WithCheckRunStepExecutionTaskListenerDecorator extends 
>> TaskListenerDecorator {
>> private static final long serialVersionUID = 1;
>> private WithCheckRunStepExecution withCheckRunStepExecution;
>>
>> 
>> WithCheckRunStepExecutionTaskListenerDecorator(WithCheckRunStepExecution 
>> withCheckRunStepExecution) {
>> this.withCheckRunStepExecution = 
>> withCheckRunStepExecution;
>> }
>>
>> @Nonnull
>> @Override
>> public OutputStream decorate(@Nonnull final OutputStream 
>> outputStream) {
>> return new LineTransformationOutputStream() {
>> @Override
>> protected void eol(byte[] b, int len) throws 
>> IOException {
>> synchronized (outputStream) {
>> 
>> withCheckRunStepExecution.addBodyOutputLine(b, len);
>> outputStream.write(b, 0, len);
>> }
>> }
>> };
>> }
>> }
>> ---
>>
>>
>> *that's used like:*
>> ---
>> EnvironmentExpander environmentExpander = 
>> EnvironmentExpander.merge(
>> getContext().get(EnvironmentExpander.class),
>> new WithCheckRunStepExecutionEnvironmentExpander(new 
>> EnvVars())
>> );
>>
>> TaskListenerDecorator taskListenerDecorator = 
>> TaskListenerDecorator.merge(
>> getContext().get(TaskListenerDecorator.class),
>> new 
>> WithCheckRunStepExecutionTaskListenerDecorator(this)
>> );
>>
>> getContext().newBodyInvoker()
>> .withContexts(environmentExpander, 
>> taskListenerDecorator)
>> .withCallback(new 
>> WithCheckRunStepExecutionCallback(this))
>> .start();
>> ---
>>
>>
>>
>> *And codeReviewAssistantXMLLint is basically:*
>> ---
>> public class XMLLinterStep extends Step {
>> @Override
>> public StepExecution start(StepContext context) {
>> return new XMLLinterStepExecution(this, context);
>> }
>>
>> private static class XMLLinterStepExecution extends 
>> SynchronousNonBlockingStepExecution {
>> private static final long serialVersionUID = 1L;
>> private transient final XMLLinterStep step;
>>
>> XMLLinterStepExecution(XMLLinterStep step, StepContext context) {
>> super(context);
>> this.step = step;
>> }
>>
>> @Override
>> protected Void run() throws IOException, InterruptedException {
>> TaskListener taskListener = 
>> getContext().get(TaskListener.class);
>> Objects.requireNonNull(taskListener, "Failed to get 
>> TaskListener.class");
>>
>> FilePath filePath = getContext().get(FilePath.class);
>> Objects.requireNonNull(filePath, "Failed to get 
>> FilePath.class");
>>
>> if (!filePath.exists()) {
>> filePath.mkdirs();
>> }
>>
>> filePath.act(new XMLLinterStepCallable(taskListener));
>> return null;
>> }
>> }
>>
>> private static class XMLLinterStepCallable extends 
>> MasterToSlaveFileCallable {
>> private static final long serialVersionUID = 1L;
>> private final TaskListener taskListener;
>>
>> XMLLinterStepCallable(TaskListener taskListener) {
>> this.taskListener = taskListener;
>> }
>>
>> @Override
>> public Void invoke(File dir, VirtualChannel channel) throws 
>> IOException {
>> PrintStream logger = taskListener.getLogger();
>> logger.println("Test"); *//THIS LINE 

Re: Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Daniel Anechitoaie]

I suspect my problem is with .withCallback(new 
WithCheckRunStepExecutionCallback(this)) ?
But then if I use ".withCallback(BodyExecutionCallback.wrap(getContext()))" 
instead, how will I be able to read a variable from within StepExecution 
class?



On Wednesday, April 17, 2019 at 4:18:28 PM UTC+3, Daniel Anechitoaie wrote:
>
> I have a pipeline step plugin that wraps other steps and captures the 
> output and for some reason this causes a Null Pointer Exception when I try 
> to do logger.println() from the step plugin that is wrapped.
>
> *So with this pipeline:*
> ---
> node {
> stage('Test') {
> withCodeReviewAssistantGitHubCheckRun(args) {
> codeReviewAssistantXMLLint()
> }
> }
> }
> ---
>
>
> *withCodeReviewAssistantGitHubCheckRun having a:*
> ---
> private static class 
> WithCheckRunStepExecutionTaskListenerDecorator extends 
> TaskListenerDecorator {
> private static final long serialVersionUID = 1;
> private WithCheckRunStepExecution withCheckRunStepExecution;
>
> 
> WithCheckRunStepExecutionTaskListenerDecorator(WithCheckRunStepExecution 
> withCheckRunStepExecution) {
> this.withCheckRunStepExecution = withCheckRunStepExecution;
> }
>
> @Nonnull
> @Override
> public OutputStream decorate(@Nonnull final OutputStream 
> outputStream) {
> return new LineTransformationOutputStream() {
> @Override
> protected void eol(byte[] b, int len) throws 
> IOException {
> synchronized (outputStream) {
> withCheckRunStepExecution.addBodyOutputLine(b, 
> len);
> outputStream.write(b, 0, len);
> }
> }
> };
> }
> }
> ---
>
>
> *that's used like:*
> ---
> EnvironmentExpander environmentExpander = 
> EnvironmentExpander.merge(
> getContext().get(EnvironmentExpander.class),
> new WithCheckRunStepExecutionEnvironmentExpander(new 
> EnvVars())
> );
>
> TaskListenerDecorator taskListenerDecorator = 
> TaskListenerDecorator.merge(
> getContext().get(TaskListenerDecorator.class),
> new 
> WithCheckRunStepExecutionTaskListenerDecorator(this)
> );
>
> getContext().newBodyInvoker()
> .withContexts(environmentExpander, 
> taskListenerDecorator)
> .withCallback(new 
> WithCheckRunStepExecutionCallback(this))
> .start();
> ---
>
>
>
> *And codeReviewAssistantXMLLint is basically:*
> ---
> public class XMLLinterStep extends Step {
> @Override
> public StepExecution start(StepContext context) {
> return new XMLLinterStepExecution(this, context);
> }
>
> private static class XMLLinterStepExecution extends 
> SynchronousNonBlockingStepExecution {
> private static final long serialVersionUID = 1L;
> private transient final XMLLinterStep step;
>
> XMLLinterStepExecution(XMLLinterStep step, StepContext context) {
> super(context);
> this.step = step;
> }
>
> @Override
> protected Void run() throws IOException, InterruptedException {
> TaskListener taskListener = 
> getContext().get(TaskListener.class);
> Objects.requireNonNull(taskListener, "Failed to get 
> TaskListener.class");
>
> FilePath filePath = getContext().get(FilePath.class);
> Objects.requireNonNull(filePath, "Failed to get 
> FilePath.class");
>
> if (!filePath.exists()) {
> filePath.mkdirs();
> }
>
> filePath.act(new XMLLinterStepCallable(taskListener));
> return null;
> }
> }
>
> private static class XMLLinterStepCallable extends 
> MasterToSlaveFileCallable {
> private static final long serialVersionUID = 1L;
> private final TaskListener taskListener;
>
> XMLLinterStepCallable(TaskListener taskListener) {
> this.taskListener = taskListener;
> }
>
> @Override
> public Void invoke(File dir, VirtualChannel channel) throws 
> IOException {
> PrintStream logger = taskListener.getLogger();
> logger.println("Test"); *//THIS LINE THROWS Null Pointer 
> Exception*
> return null;
> }
> }
> }
> ---
>
>

-- 
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/cb9bae17-d56b-46a2-b53a-6d4d9e65b8f0%40googlegroups.com.
For more options, visit 

Any idea why a TaskListenerDecorator could cause logger.println() to throw null pointer exception

[Daniel Anechitoaie]

I have a pipeline step plugin that wraps other steps and captures the 
output and for some reason this causes a Null Pointer Exception when I try 
to do logger.println() from the step plugin that is wrapped.

*So with this pipeline:*
---
node {
stage('Test') {
withCodeReviewAssistantGitHubCheckRun(args) {
codeReviewAssistantXMLLint()
}
}
}
---


*withCodeReviewAssistantGitHubCheckRun having a:*
---
private static class WithCheckRunStepExecutionTaskListenerDecorator 
extends TaskListenerDecorator {
private static final long serialVersionUID = 1;
private WithCheckRunStepExecution withCheckRunStepExecution;


WithCheckRunStepExecutionTaskListenerDecorator(WithCheckRunStepExecution 
withCheckRunStepExecution) {
this.withCheckRunStepExecution = withCheckRunStepExecution;
}

@Nonnull
@Override
public OutputStream decorate(@Nonnull final OutputStream 
outputStream) {
return new LineTransformationOutputStream() {
@Override
protected void eol(byte[] b, int len) throws 
IOException {
synchronized (outputStream) {
withCheckRunStepExecution.addBodyOutputLine(b, 
len);
outputStream.write(b, 0, len);
}
}
};
}
}
---


*that's used like:*
---
EnvironmentExpander environmentExpander = 
EnvironmentExpander.merge(
getContext().get(EnvironmentExpander.class),
new WithCheckRunStepExecutionEnvironmentExpander(new 
EnvVars())
);

TaskListenerDecorator taskListenerDecorator = 
TaskListenerDecorator.merge(
getContext().get(TaskListenerDecorator.class),
new WithCheckRunStepExecutionTaskListenerDecorator(this)
);

getContext().newBodyInvoker()
.withContexts(environmentExpander, 
taskListenerDecorator)
.withCallback(new 
WithCheckRunStepExecutionCallback(this))
.start();
---



*And codeReviewAssistantXMLLint is basically:*
---
public class XMLLinterStep extends Step {
@Override
public StepExecution start(StepContext context) {
return new XMLLinterStepExecution(this, context);
}

private static class XMLLinterStepExecution extends 
SynchronousNonBlockingStepExecution {
private static final long serialVersionUID = 1L;
private transient final XMLLinterStep step;

XMLLinterStepExecution(XMLLinterStep step, StepContext context) {
super(context);
this.step = step;
}

@Override
protected Void run() throws IOException, InterruptedException {
TaskListener taskListener = 
getContext().get(TaskListener.class);
Objects.requireNonNull(taskListener, "Failed to get 
TaskListener.class");

FilePath filePath = getContext().get(FilePath.class);
Objects.requireNonNull(filePath, "Failed to get 
FilePath.class");

if (!filePath.exists()) {
filePath.mkdirs();
}

filePath.act(new XMLLinterStepCallable(taskListener));
return null;
}
}

private static class XMLLinterStepCallable extends 
MasterToSlaveFileCallable {
private static final long serialVersionUID = 1L;
private final TaskListener taskListener;

XMLLinterStepCallable(TaskListener taskListener) {
this.taskListener = taskListener;
}

@Override
public Void invoke(File dir, VirtualChannel channel) throws 
IOException {
PrintStream logger = taskListener.getLogger();
logger.println("Test"); *//THIS LINE THROWS Null Pointer 
Exception*
return null;
}
}
}
---

-- 
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/b716ba9a-e24a-4792-ac8b-7ce5862cfe9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: When using the dir step in a Jenkins pipeline is there any way to get that value from a step within?

[Daniel Anechitoaie]

Yep, works as expected. Thanks

On Wednesday, April 17, 2019 at 2:09:10 PM UTC+3, Daniel Anechitoaie wrote:
>
> This makes sense. Not sure why I was confused about this.
> I'm in the process of migrating it from "extends Builder implements 
> SimpleBuildStep" to "extends Step".
>
> I'll post back how it goes.
>
> Thank you for clarification.
>
> On Wednesday, April 17, 2019 at 2:01:41 PM UTC+3, Robert Sandell wrote:
>>
>> I'm not sure I understand the question completely. But the FilePath 
>> object in the step context will be what the current working directory is. 
>> So if your step is called inside a dir step then the FilePath will be that 
>> directory otherwise it will be the workspace, or null if the step gets 
>> called outside of a node step.
>> So you don't need to know if you are inside a dir step, just that there 
>> is a FilePath to use.
>>
>> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java#L90-L93
>>
>> /B
>>
>> Den ons 17 apr. 2019 kl 12:22 skrev Daniel Anechitoaie <
>> danie...@gmail.com>:
>>
>>> I'm working on Jenkins pipeline plugin that generates some paths 
>>> relative to the workspace at the moment.
>>> But sometimes I need to wrap my plugin with dir - 
>>> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java
>>>  step.
>>> Is there any way from within my plugin to know if it was wrapped by the 
>>> "dir" step plugin so I can use that dir as a relative path vs if it was not 
>>> in which case I should use the workspace as a relative path?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/5ce71f78-8765-4471-b9b1-31d118c43e83%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> *Robert Sandell*
>> Software Engineer
>> CloudBees, Inc.
>> [image: CloudBees-Logo.png] 
>> E: rsan...@cloudbees.com
>> Twitter: robert_sandell
>>
>

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

Re: When using the dir step in a Jenkins pipeline is there any way to get that value from a step within?

[Daniel Anechitoaie]

This makes sense. Not sure why I was confused about this.
I'm in the process of migrating it from "extends Builder implements 
SimpleBuildStep" to "extends Step".

I'll post back how it goes.

Thank you for clarification.

On Wednesday, April 17, 2019 at 2:01:41 PM UTC+3, Robert Sandell wrote:
>
> I'm not sure I understand the question completely. But the FilePath object 
> in the step context will be what the current working directory is. So if 
> your step is called inside a dir step then the FilePath will be that 
> directory otherwise it will be the workspace, or null if the step gets 
> called outside of a node step.
> So you don't need to know if you are inside a dir step, just that there is 
> a FilePath to use.
>
> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java#L90-L93
>
> /B
>
> Den ons 17 apr. 2019 kl 12:22 skrev Daniel Anechitoaie  >:
>
>> I'm working on Jenkins pipeline plugin that generates some paths relative 
>> to the workspace at the moment.
>> But sometimes I need to wrap my plugin with dir - 
>> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java
>>  step.
>> Is there any way from within my plugin to know if it was wrapped by the 
>> "dir" step plugin so I can use that dir as a relative path vs if it was not 
>> in which case I should use the workspace as a relative path?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/5ce71f78-8765-4471-b9b1-31d118c43e83%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> *Robert Sandell*
> Software Engineer
> CloudBees, Inc.
> [image: CloudBees-Logo.png] 
> E: rsan...@cloudbees.com 
> Twitter: robert_sandell
>

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

Re: When using the dir step in a Jenkins pipeline is there any way to get that value from a step within?

[Robert Sandell]

I'm not sure I understand the question completely. But the FilePath object
in the step context will be what the current working directory is. So if
your step is called inside a dir step then the FilePath will be that
directory otherwise it will be the workspace, or null if the step gets
called outside of a node step.
So you don't need to know if you are inside a dir step, just that there is
a FilePath to use.
https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java#L90-L93

/B

Den ons 17 apr. 2019 kl 12:22 skrev Daniel Anechitoaie <
daniels0...@gmail.com>:

> I'm working on Jenkins pipeline plugin that generates some paths relative
> to the workspace at the moment.
> But sometimes I need to wrap my plugin with dir -
> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java
>  step.
> Is there any way from within my plugin to know if it was wrapped by the
> "dir" step plugin so I can use that dir as a relative path vs if it was not
> in which case I should use the workspace as a relative path?
>
> --
> 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/5ce71f78-8765-4471-b9b1-31d118c43e83%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
*Robert Sandell*
Software Engineer
CloudBees, Inc.
[image: CloudBees-Logo.png] 
E: rsand...@cloudbees.com
Twitter: robert_sandell

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

When using the dir step in a Jenkins pipeline is there any way to get that value from a step within?

[Daniel Anechitoaie]

I'm working on Jenkins pipeline plugin that generates some paths relative 
to the workspace at the moment.
But sometimes I need to wrap my plugin with dir - 
https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/PushdStep.java
 step.
Is there any way from within my plugin to know if it was wrapped by the 
"dir" step plugin so I can use that dir as a relative path vs if it was not 
in which case I should use the workspace as a relative path?

-- 
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/5ce71f78-8765-4471-b9b1-31d118c43e83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.