Re: Jenkins Plugin for custom email notification

[Fabian Cenedese]

At 15:42 18.07.2020, Slide wrote:

>There are two email plugins available for Jenkins, Mailer 
>(https://plugins.jenkins.io/mailer/) and 
>the Extended Email Plugin 
>(https://plugins.jenkins.io/email-ext/).
> You can look at those two and see if one meets your needs.

If you can capture your output into a file then the Extended Mail
can read the file and add it to the mail body like this:

$DEFAULT_CONTENT
${FILE, path="yourfile.log"}

I don't know about catching the output without a file but check the
Extended Mail docs.

bye  Fabi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/20200720063357.B23D4412F4D9%40macserver.private.

Re: Upgrading Jenkins using MSI file

[Mark Waite]

I thought that replacing one of the files tracked by the MSI package would
confuse the MSI package management facilities so that future upgrades using
the MSI installer won't be allowed because one of the binary files managed
by the MSI installer has been changed.

If future upgrades are always done by replacing the war file, that may be
OK, but I would expect confusion or problems if a newer MSI installer is
run after the jenkins.war file had been upgraded without using the MSI
installer to do the upgrade.

On Sun, Jul 19, 2020 at 8:07 PM Slide  wrote:

> The method should be ok, the data for the jobs and such are not stored in
> the same location as the "executable." I would definitely recommend always
> backing up your JENKINS_HOME before installing new versions.
>
> On Sun, Jul 19, 2020, 18:49 PersonFirst PersonLast <
> personandfri...@gmail.com> wrote:
>
>> Hello,
>> I would like to check if what I did for upgrading existing Jenkins
>> installation was OK/acceptable. I realize though it is not the documented
>> method of upgrading Jenkins per my research after I performed the upgrade.
>>
>> 1. I have previously installed Jenkins using MSI file at Windows server a
>> while ago. So, Jenkins runs as a service there. I performed many changes
>> (new jobs provisioned, customized settings, installed various plugins) at
>> this Jenkins installation since then.
>> 2. I recently downloaded latest available LTS release (for Windows) of
>> Jenkins from https://www.jenkins.io/download/ and installed Jenkins to
>> the same location where existing Jenkins installation exists (e.g.,
>> indicated same path: C:\Program Files (x86)\Jenkins\).
>>
>> I didn’t see any issues so far with the above method but wanted to check
>> if this method could have caused data loss (overwriting previous Jenkins
>> settings, etc.) or the above method works just fine.
>>
>> Please let me know know if anyone has any questions or need additional
>> information.
>> Thank you
>> PF
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/CAKnF1n_GzUXHw5FkvgQhs7jjAoDmxtYVV0aEZBU192C01-ESjQ%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVd9iD6OoD5voGxbe7qvsO5tXV%3D%2BPx01MiGYtZkvG0i4NA%40mail.gmail.com
> 
> .
>

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

Re: Upgrading Jenkins using MSI file

[Slide]

The method should be ok, the data for the jobs and such are not stored in
the same location as the "executable." I would definitely recommend always
backing up your JENKINS_HOME before installing new versions.

On Sun, Jul 19, 2020, 18:49 PersonFirst PersonLast <
personandfri...@gmail.com> wrote:

> Hello,
> I would like to check if what I did for upgrading existing Jenkins
> installation was OK/acceptable. I realize though it is not the documented
> method of upgrading Jenkins per my research after I performed the upgrade.
>
> 1. I have previously installed Jenkins using MSI file at Windows server a
> while ago. So, Jenkins runs as a service there. I performed many changes
> (new jobs provisioned, customized settings, installed various plugins) at
> this Jenkins installation since then.
> 2. I recently downloaded latest available LTS release (for Windows) of
> Jenkins from https://www.jenkins.io/download/ and installed Jenkins to
> the same location where existing Jenkins installation exists (e.g.,
> indicated same path: C:\Program Files (x86)\Jenkins\).
>
> I didn’t see any issues so far with the above method but wanted to check
> if this method could have caused data loss (overwriting previous Jenkins
> settings, etc.) or the above method works just fine.
>
> Please let me know know if anyone has any questions or need additional
> information.
> Thank you
> PF
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAKnF1n_GzUXHw5FkvgQhs7jjAoDmxtYVV0aEZBU192C01-ESjQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVd9iD6OoD5voGxbe7qvsO5tXV%3D%2BPx01MiGYtZkvG0i4NA%40mail.gmail.com.

Upgrading Jenkins using MSI file

[PersonFirst PersonLast]

Hello,
I would like to check if what I did for upgrading existing Jenkins
installation was OK/acceptable. I realize though it is not the documented
method of upgrading Jenkins per my research after I performed the upgrade.

1. I have previously installed Jenkins using MSI file at Windows server a
while ago. So, Jenkins runs as a service there. I performed many changes
(new jobs provisioned, customized settings, installed various plugins) at
this Jenkins installation since then.
2. I recently downloaded latest available LTS release (for Windows) of
Jenkins from https://www.jenkins.io/download/ and installed Jenkins to the
same location where existing Jenkins installation exists (e.g., indicated
same path: C:\Program Files (x86)\Jenkins\).

I didn’t see any issues so far with the above method but wanted to check if
this method could have caused data loss (overwriting previous Jenkins
settings, etc.) or the above method works just fine.

Please let me know know if anyone has any questions or need additional
information.
Thank you
PF

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

Re: Unit tests fail in Jenkins, but pass everywhere else

[Slide]

Take a look at this article on how to enable a service to interact with the
desktop.

https://www.ibm.com/support/knowledgecenter/SSGR73_7.5.1/com.ibm.wci.live.doc/Secure_Connector/enablinginteractivemodeforwindowsservices.html

On Sun, Jul 19, 2020, 09:58 TC  wrote:

> Yes, Jenkins is running as a service. However, I have created a user
> account named Jenkins and I run the service on that account. I have
> verified that the Jenkins user account can run the unit tests successfully.
> I don't know what else is required to "give the service the ability to
> interact with the desktop". I have scoured the DCOM and service
> configurations, and I've experimented with all settings that seem possibly
> relevant, yet nothing works.
>
> Actually, one thing works: In the DCOM configuration, there is a way to
> tell the system to always run Microsoft Excel applications as a specific
> user. I have told it to always run Excel as the Jenkins user. I don't know
> why this makes a difference because the Jenkins service is already running
> everything as the Jenkins user, yet this somehow suppresses the error. I am
> using this workaround for now, but I regard it as a kludge, and not as an
> acceptable long-term solution.
>
> With a little speculation, I think I can answer my own original question:
>
> Q: What does Jenkins do differently when it executes a Windows batch
> command that could explain the failure?
>
> A: Jenkins doesn't do anything differently, per se, but is running as a
> service, and when Windows decides what is allowed to happen on a computer,
> it doesn't just consider the user privileges; it also considers whether or
> not the commands were issued by a service. Microsoft Excel and other COM
> applications, in particular, seem to be off-limits to service-issued
> commands even when fully accessible to the user issuing the commands.
>
> Thank you, Slide, for your reply, and thanks to all others who read and
> considered my question. I am going to set this problem aside for now and
> come back to it later when I have spare time and possibly a fresh
> perspective.
>
> -TC
>
>
> On Sunday, July 19, 2020 at 7:10:39 AM UTC-7, slide wrote:
>>
>> Is your Jenkins running as a service? If it has to open Excel and is
>> running as a service, this can be an issue. You need to give the service
>> the ability to interact with the desktop. I believe this is in the service
>> settings, but you can Google and find information if it is not right there.
>>
>> On Sun, Jul 19, 2020, 06:45 TC  wrote:
>>
>>> I am new to Jenkins. I installed it today on a Windows 10 computer to
>>> automatically build (using the MSBuild plugin) and run unit tests (using
>>> NUnit Console as a batch command) on my .NET solution. Almost everything
>>> works perfectly, but I have been unable to solve one frustrating problem,
>>> despite working on it for hours:
>>>
>>> One unit test project fails, but only when run from Jenkins. I can run
>>> the same unit tests from anywhere, logged-in as anybody, and they pass.
>>>
>>> In an attempt to debug the problem, I created a new account called
>>> "Jenkins" and configured the Jenkins service to run under that account. I
>>> have configured my Jenkins project to execute "whoami" as a Windows batch
>>> command, and verified that Jenkins is running as the "Jenkins" user. I have
>>> verified that the "Jenkins" user can run the unit tests without error. I
>>> have logged-in as myself, used "runas" to impersonate the "Jenkins" user,
>>> and verified that the unit tests pass under those conditions also. Yet
>>> somehow when Jenkins runs the same tests as the same user, the tests fail.
>>>
>>> So my question is: What does Jenkins do differently when it executes a
>>> Windows batch command that could explain the failure? Because the unit
>>> tests run successfully outside of Jenkins, and only fail inside Jenkins, I
>>> think I can crack this problem if I just know more about the runtime
>>> environment Jenkins creates.
>>>
>>> About the error itself:The failing tests all automate Excel. The error
>>> reported by Excel is "Microsoft Excel cannot open or save any more
>>> documents because there is not enough available memory or disk space".
>>> Posts on the internet generally say this message indicates a DCOM security
>>> problem (and has nothing to do with memory or disk space). Giving the user
>>> sufficient privileges to launch, activate, and access Microsoft Excel
>>> applications should solve the problem. I've done that, giving the "Jenkins"
>>> user full permission on Excel applications, yet the error persists.
>>>
>>> All advice is appreciated.
>>>
>>>
>>> -TC
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkins...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/db1129ea-84dd-41

Re: SSH Agent, z/OS USS, and git authentication problems

[Randall Becker]

I'm going to try the ibm.system.encoding property to see whether that makes 
a difference. It would almost make sense to have the encoding externalized 
as a plugin property available in a pipeline. I think part of our issue is 
that we run multi-platform and multi-encoding, which seems out of scope for 
the change. The ibm.system.encoding seems to be coming from the agent 
without explicit action from the controller. I'm wondering whether starting 
the agent with -Dibm.system.encoding=ISO8859-1 might fix our situation (or 
make it worse). Will try this. The bigger issue is that this is a more 
pervasive situation than just the GitSCM but really applies to any String 
instantiated by the agent.

On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
>
>
> https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411
>  has 
> specific code for z/OS.  I do not have access to z/OS so cannot test that 
> code.  It was merged based on a submission from people that said it works.  
>
> You're welcome to suggest improvements in that area with the understanding 
> that I can only evaluate that code by inspection, not by execution.
>
> Mark Waite
>
> On Thu, Jul 16, 2020 at 7:49 AM Randall Becker  > wrote:
>
>> That's what we were trying to do originally. There is a problem. When 
>> GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded 
>> as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even 
>> though the original private key and passphrase are coming from a 
>> UTF8/US-ASCII controller. When this goes to git and then SSH, the file is 
>> still encoded as IBM1047 and is when it hits the KEX code, fails. When we 
>> use the SSH Agent, this problem does not occur. I want to use the correct 
>> using GitSCM credential ID, but it does not work. I do not have a decent 
>> debug environment that would clearly demonstrate this, isolate the section 
>> of code where this is (not) happening, or allow me to easily fix this. The 
>> most important bit is that the private key should be encoded in UTF8 or 
>> US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the 
>> SSH Agent Plugin does this correctly.
>>
>> On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
>>>
>>> If the operation you're performing is a checkout, why use the ssh-agent 
>>> wrapper?  Why not use the same credentials ID as an argument to checkout 
>>> rather than wrapping checkout in ssh-agent?
>>>
>>> On Mon, Jul 13, 2020 at 8:45 AM Randall Becker  
>>> wrote:
>>>
 I wish it was that simple. The issue definitely appears to be the 
 encoding of the private key during a key exchange. When using SSH-Agent 
 and 
 git commands from within a shell in the pipeline, the authentication works 
 fine. So this is likely an interaction with the GitSCM plugin not being 
 aware of IBM-1047 encodings.

 On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>
> I think that this is the reason why it does not work 
> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>
> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker 
> escribió:
>>
>> I'm having issues trying to get an agent to authenticate using the 
>> SSH Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins 
>> controller. 
>> The goal is to convince GitSCM to actually fetch properly. We get SSH 
>> authentication errors no matter what happens. This is using Pipelines.
>>
>> I've tried 
>> sshagent (credentials: ['mvs-randall']) {
>> checkout([$class: 'GitSCM',
>> branches: [[name: '*/development']],
>> extensions: [
>> [$class: 'CleanBeforeCheckout'],
>> [$class: 'SubmoduleOption', 
>> disableSubmodules: false, parentCredentials: true,
>> recursiveSubmodules: true, 
>> reference: '', trackingSubmodules: false]],
>> 
>> doGenerateSubmoduleConfigurations: false, submoduleCfg: [],
>> userRemoteConfigs: [[url: 
>> 'g...@xx.xxx.xxx.xxx:proj/repo.git'']]])
>> }
>> and
>> checkout([$class: 'GitSCM',
>> branches: [[name: '*/development']],
>> extensions: [
>> [$class: 'CleanBeforeCheckout'],
>> [$class: 'SubmoduleOption', 
>> disableSubmodules: false, parentCredentials: true,
>> recursiveSubmo

Re: Unit tests fail in Jenkins, but pass everywhere else

[TC]

Yes, Jenkins is running as a service. However, I have created a user 
account named Jenkins and I run the service on that account. I have 
verified that the Jenkins user account can run the unit tests successfully. 
I don't know what else is required to "give the service the ability to 
interact with the desktop". I have scoured the DCOM and service 
configurations, and I've experimented with all settings that seem possibly 
relevant, yet nothing works.

Actually, one thing works: In the DCOM configuration, there is a way to 
tell the system to always run Microsoft Excel applications as a specific 
user. I have told it to always run Excel as the Jenkins user. I don't know 
why this makes a difference because the Jenkins service is already running 
everything as the Jenkins user, yet this somehow suppresses the error. I am 
using this workaround for now, but I regard it as a kludge, and not as an 
acceptable long-term solution.

With a little speculation, I think I can answer my own original question:

Q: What does Jenkins do differently when it executes a Windows batch 
command that could explain the failure?

A: Jenkins doesn't do anything differently, per se, but is running as a 
service, and when Windows decides what is allowed to happen on a computer, 
it doesn't just consider the user privileges; it also considers whether or 
not the commands were issued by a service. Microsoft Excel and other COM 
applications, in particular, seem to be off-limits to service-issued 
commands even when fully accessible to the user issuing the commands.

Thank you, Slide, for your reply, and thanks to all others who read and 
considered my question. I am going to set this problem aside for now and 
come back to it later when I have spare time and possibly a fresh 
perspective.

-TC


On Sunday, July 19, 2020 at 7:10:39 AM UTC-7, slide wrote:
>
> Is your Jenkins running as a service? If it has to open Excel and is 
> running as a service, this can be an issue. You need to give the service 
> the ability to interact with the desktop. I believe this is in the service 
> settings, but you can Google and find information if it is not right there.
>
> On Sun, Jul 19, 2020, 06:45 TC > wrote:
>
>> I am new to Jenkins. I installed it today on a Windows 10 computer to 
>> automatically build (using the MSBuild plugin) and run unit tests (using 
>> NUnit Console as a batch command) on my .NET solution. Almost everything 
>> works perfectly, but I have been unable to solve one frustrating problem, 
>> despite working on it for hours:
>>
>> One unit test project fails, but only when run from Jenkins. I can run 
>> the same unit tests from anywhere, logged-in as anybody, and they pass.
>>
>> In an attempt to debug the problem, I created a new account called 
>> "Jenkins" and configured the Jenkins service to run under that account. I 
>> have configured my Jenkins project to execute "whoami" as a Windows batch 
>> command, and verified that Jenkins is running as the "Jenkins" user. I have 
>> verified that the "Jenkins" user can run the unit tests without error. I 
>> have logged-in as myself, used "runas" to impersonate the "Jenkins" user, 
>> and verified that the unit tests pass under those conditions also. Yet 
>> somehow when Jenkins runs the same tests as the same user, the tests fail.
>>
>> So my question is: What does Jenkins do differently when it executes a 
>> Windows batch command that could explain the failure? Because the unit 
>> tests run successfully outside of Jenkins, and only fail inside Jenkins, I 
>> think I can crack this problem if I just know more about the runtime 
>> environment Jenkins creates.
>>
>> About the error itself:The failing tests all automate Excel. The error 
>> reported by Excel is "Microsoft Excel cannot open or save any more 
>> documents because there is not enough available memory or disk space". 
>> Posts on the internet generally say this message indicates a DCOM security 
>> problem (and has nothing to do with memory or disk space). Giving the user 
>> sufficient privileges to launch, activate, and access Microsoft Excel 
>> applications should solve the problem. I've done that, giving the "Jenkins" 
>> user full permission on Excel applications, yet the error persists.
>>
>> All advice is appreciated.
>>
>>
>> -TC
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/db1129ea-84dd-41ea-8349-8a887fa85853o%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this grou

Re: Unit tests fail in Jenkins, but pass everywhere else

[Slide]

Is your Jenkins running as a service? If it has to open Excel and is
running as a service, this can be an issue. You need to give the service
the ability to interact with the desktop. I believe this is in the service
settings, but you can Google and find information if it is not right there.

On Sun, Jul 19, 2020, 06:45 TC  wrote:

> I am new to Jenkins. I installed it today on a Windows 10 computer to
> automatically build (using the MSBuild plugin) and run unit tests (using
> NUnit Console as a batch command) on my .NET solution. Almost everything
> works perfectly, but I have been unable to solve one frustrating problem,
> despite working on it for hours:
>
> One unit test project fails, but only when run from Jenkins. I can run the
> same unit tests from anywhere, logged-in as anybody, and they pass.
>
> In an attempt to debug the problem, I created a new account called
> "Jenkins" and configured the Jenkins service to run under that account. I
> have configured my Jenkins project to execute "whoami" as a Windows batch
> command, and verified that Jenkins is running as the "Jenkins" user. I have
> verified that the "Jenkins" user can run the unit tests without error. I
> have logged-in as myself, used "runas" to impersonate the "Jenkins" user,
> and verified that the unit tests pass under those conditions also. Yet
> somehow when Jenkins runs the same tests as the same user, the tests fail.
>
> So my question is: What does Jenkins do differently when it executes a
> Windows batch command that could explain the failure? Because the unit
> tests run successfully outside of Jenkins, and only fail inside Jenkins, I
> think I can crack this problem if I just know more about the runtime
> environment Jenkins creates.
>
> About the error itself:The failing tests all automate Excel. The error
> reported by Excel is "Microsoft Excel cannot open or save any more
> documents because there is not enough available memory or disk space".
> Posts on the internet generally say this message indicates a DCOM security
> problem (and has nothing to do with memory or disk space). Giving the user
> sufficient privileges to launch, activate, and access Microsoft Excel
> applications should solve the problem. I've done that, giving the "Jenkins"
> user full permission on Excel applications, yet the error persists.
>
> All advice is appreciated.
>
>
> -TC
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/db1129ea-84dd-41ea-8349-8a887fa85853o%40googlegroups.com
> 
> .
>

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

Unit tests fail in Jenkins, but pass everywhere else

[TC]

I am new to Jenkins. I installed it today on a Windows 10 computer to 
automatically build (using the MSBuild plugin) and run unit tests (using 
NUnit Console as a batch command) on my .NET solution. Almost everything 
works perfectly, but I have been unable to solve one frustrating problem, 
despite working on it for hours:

One unit test project fails, but only when run from Jenkins. I can run the 
same unit tests from anywhere, logged-in as anybody, and they pass.

In an attempt to debug the problem, I created a new account called 
"Jenkins" and configured the Jenkins service to run under that account. I 
have configured my Jenkins project to execute "whoami" as a Windows batch 
command, and verified that Jenkins is running as the "Jenkins" user. I have 
verified that the "Jenkins" user can run the unit tests without error. I 
have logged-in as myself, used "runas" to impersonate the "Jenkins" user, 
and verified that the unit tests pass under those conditions also. Yet 
somehow when Jenkins runs the same tests as the same user, the tests fail.

So my question is: What does Jenkins do differently when it executes a 
Windows batch command that could explain the failure? Because the unit 
tests run successfully outside of Jenkins, and only fail inside Jenkins, I 
think I can crack this problem if I just know more about the runtime 
environment Jenkins creates.

About the error itself:The failing tests all automate Excel. The error 
reported by Excel is "Microsoft Excel cannot open or save any more 
documents because there is not enough available memory or disk space". 
Posts on the internet generally say this message indicates a DCOM security 
problem (and has nothing to do with memory or disk space). Giving the user 
sufficient privileges to launch, activate, and access Microsoft Excel 
applications should solve the problem. I've done that, giving the "Jenkins" 
user full permission on Excel applications, yet the error persists.

All advice is appreciated.


-TC

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/db1129ea-84dd-41ea-8349-8a887fa85853o%40googlegroups.com.

certificate error on lts 2.235.2 (centos/red hat)

[Amit Dar]

While trying to download  the 
2.235.2 version of jenkins, I received the following error:

 

*Error 503 certificate has expired*

certificate has expired

*Guru Mediation:*

Details: cache-hhn4070-HHN 1595144217 4048092794
--

Varnish cache server

 

This happened on several devices, which means it is a server problem.

 

Am I doing something wrong?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/153b137b-9f4d-4a50-b203-69f3788c41eco%40googlegroups.com.