Re: Two separate GitHub Organizations used with same GitHub Branch Source Plugin configuration results in only one job getting triggered per PR

[Ian Vernon]

I'll hold off until it is released to the plugin center before downloading 
it.

>  If github receives a duplicate context label it just replaces the 
existing one, so this is helpful if you are doing more than one kind of 
build for a repo.

That explains it! That's so frustrating :( . Thanks for your help!


On Thursday, January 4, 2018 at 11:24:39 AM UTC-8, Steven Foster wrote:
>
> Here is the repo for the custom github context plugin 
> https://github.com/steven-foster/github-scm-trait-notification-context
> I still need to actually release it to the plugin center, hopefully that's 
> not too arduous.
>
> It lets you specify a context label for a multibranch project's github 
> notifications. If github receives a duplicate context label it just 
> replaces the existing one, so this is helpful if you are doing more than 
> one kind of build for a repo.
>
> On Thursday, January 4, 2018 at 7:07:01 PM UTC, Ian Vernon wrote:
>>
>> > What do you mean “appears on GitHub”? Do you mean as a second status 
>>> check mark?
>>>
>> Yes, that is correct. Only one check mark appears despite there being two 
>> GitHub Organizations set up. If I change the aforementioned settings, two 
>> check marks appear on GitHub, but I want to have the same behavior with the 
>> plugin. 
>>
>>  > FYI: This plugin is completely ignored by multibranch.
>>
>> Is a GitHub Organization multibranch? 
>>
>> Regarding the custom notification context, is this what you are referring 
>> to? https://issues.jenkins-ci.org/browse/JENKINS-36574
>>
>> Thanks for the quick reply!
>>
>

-- 
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/666ca13d-b037-431d-893f-86084d364548%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Trusting a new CA

[Josh Harshman]

I have a pipeline library that needs to talk to my Vault server over 
https.  Problem is that Jenkins doesn't trust the CA the vault server 
certificate was signed with so I get errors like the following.

```

sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target 

  at 
sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
 

  at 
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)

  at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)

  at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)

Caused: sun.security.validator.ValidatorException: PKIX path building failed

... snip ...  

Caused: javax.net.ssl.SSLHandshakeException

```

Following the instructions outlined 
here: 
https://support.cloudbees.com/hc/en-us/articles/203821254-How-to-install-a-new-SSL-certificate-
 
I add the CA to to the keystore and instruct Jenkins to use it. However, 
now when I run the pipeline, the library can't fetch it's dependancies

```

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:

General error during conversion: Error grabbing Grapes -- [unresolved 
dependency: org.codehaus.groovy.modules.http-builder#http-builder;0.7: not 
found]

java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: 
org.codehaus.groovy.modules.http-builder#http-builder;0.7: not found

  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

```

Any help debugging this would be greatly appreciated!

Thanks in advance!
- Josh

-- 
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/63ef5aec-0715-47fa-bff4-061dc5dde44d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Add Trusted CA

[Josh Harshman]

I have a pipeline library that needs to communicate over https to Vault in 
order to read secrets.  Only problem is that Vault's SSL certificate is 
signed by a CA that is not trusted by Jenkins.  This results in the 
following error.

sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target
at 
sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at 
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
Caused: sun.security.validator.ValidatorException: PKIX path building failed


Following the instructions here: 
https://support.cloudbees.com/hc/en-us/articles/203821254-How-to-install-a-new-SSL-certificate-
 I added the CA to the keystore then configured and restarted Jenkins.  When 
the pipeline tries to run, it now can't fetch it's dependencies.


org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during conversion: Error grabbing Grapes -- [unresolved 
dependency: org.codehaus.groovy.modules.http-builder#http-builder;0.7: not 
found]

java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: 
org.codehaus.groovy.modules.http-builder#http-builder;0.7: not found]


Any help on this would be much appreciated.


Thanks in advance!

- Josh

-- 
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/e850dc92-7979-4d8e-ba29-12b7445c9670%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins plugin to perform UI search

[Stephen Connolly]

How would you do this outside of Jenkins from the command line?

It will be much easier to test and debug if you can use a command sequence
to do the test.

Try not to encode the How of your build in Jenkins... let Jenkins be the
coordinator that decides Which of the Hows to invoke

On Thu 4 Jan 2018 at 19:00, Vk  wrote:

> Hi,
> I am currently using Jenkins to perform sanity check of my application
> post the CI
>
> To do that I need to search for specific characters and output in an UI.
>
> For example " Search for the character "WELCOME" in a  web page. Could you
> please suggest options or Plugins for the same ?
>
> Thanks in advance.
>
> Regards,
> Venki
>
> --
> 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/e6356177-125f-45f1-8aaa-d68053908ac3%40googlegroups.com
> 
> .
> 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 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/CA%2BnPnMxp5hMZUMkwG8S0_VLe%3DAZiA%3DgHobhXFL%3DGpbQf2V0NBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic Parameter to Build without Active Choices Plugin

[Ioannis Moutsatsos]

Note that Active Choices v2.1 is again available from the Jenkins update 
center. It no longer has a mandatory dependency on Scriptler. As a result 
it is secure and functional. Just read the most recent release notes for 
the Jenkins version requirements

On Wednesday, May 17, 2017 at 1:51:36 PM UTC-4, Tim Downey wrote:
>
> Hi,
>
> I have some builds that use the Active Choices plugin to call a REST api 
> to build a list of parameter choices at the time the job runs.  Now that 
> Active Choices and Scriptler have been removed from the Update Center, I'm 
> wondering if there are any more secure alternatives?  I've been looking 
> through the Job DSL apis and don't see any other way to produce a dynamic 
> list of parameters, but I hope that I'm missing something.
>
> Can anyone respond if there's another way to do this?
>
> Thanks,
> Tim
>
>

-- 
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/a5a00bf3-5367-49b1-90c3-79f6f785037b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two separate GitHub Organizations used with same GitHub Branch Source Plugin configuration results in only one job getting triggered per PR

[Steven Foster]

Here is the repo for the custom github context 
plugin https://github.com/steven-foster/github-scm-trait-notification-context
I still need to actually release it to the plugin center, hopefully that's 
not too arduous.

It lets you specify a context label for a multibranch project's github 
notifications. If github receives a duplicate context label it just 
replaces the existing one, so this is helpful if you are doing more than 
one kind of build for a repo.

On Thursday, January 4, 2018 at 7:07:01 PM UTC, Ian Vernon wrote:
>
> > What do you mean “appears on GitHub”? Do you mean as a second status 
>> check mark?
>>
> Yes, that is correct. Only one check mark appears despite there being two 
> GitHub Organizations set up. If I change the aforementioned settings, two 
> check marks appear on GitHub, but I want to have the same behavior with the 
> plugin. 
>
>  > FYI: This plugin is completely ignored by multibranch.
>
> Is a GitHub Organization multibranch? 
>
> Regarding the custom notification context, is this what you are referring 
> to? https://issues.jenkins-ci.org/browse/JENKINS-36574
>
> Thanks for the quick reply!
>

-- 
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/1365ea2f-3b57-4335-8c0b-7bdb2d13ba0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two separate GitHub Organizations used with same GitHub Branch Source Plugin configuration results in only one job getting triggered per PR

[Ian Vernon]

>
> > What do you mean “appears on GitHub”? Do you mean as a second status 
> check mark?
>
Yes, that is correct. Only one check mark appears despite there being two 
GitHub Organizations set up. If I change the aforementioned settings, two 
check marks appear on GitHub, but I want to have the same behavior with the 
plugin. 

 > FYI: This plugin is completely ignored by multibranch.

Is a GitHub Organization multibranch? 

Regarding the custom notification context, is this what you are referring 
to? https://issues.jenkins-ci.org/browse/JENKINS-36574

Thanks for the quick reply!

-- 
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/b0414d64-b2ab-402c-ae9a-afb49c03d3df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins plugin to perform UI search

[Vk]

Hi, 
I am currently using Jenkins to perform sanity check of my application post 
the CI 

To do that I need to search for specific characters and output in an UI. 

For example " Search for the character "WELCOME" in a  web page. Could you 
please suggest options or Plugins for the same ?

Thanks in advance. 

Regards,
Venki

-- 
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/e6356177-125f-45f1-8aaa-d68053908ac3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two separate GitHub Organizations used with same GitHub Branch Source Plugin configuration results in only one job getting triggered per PR

[Stephen Connolly]

On Thu 4 Jan 2018 at 18:11, Ian Vernon  wrote:

> I had asked previously about getting two jobs triggered from GitHub when a
> PR is opened. Each job uses a distinct Jenkinsfile. This is so multiple
> sets of tests can be triggered as separate jobs when a PR is opened. That
> thread can be found here:
> https://groups.google.com/forum/#!topic/jenkinsci-users/RXZykkWy8PQ . I
> was able to get it set up, but the behavior isn't exactly what I want. I
> have looked all over for how to fix this :(
>
> However, it appears that the GitHub Organization configuration for each
> job must be different for me to achieve having two jobs appear on GitHub
> that are linked to Jenkins. The configuration of the GitHub Organization
> that runs the first job is attached as 'jenkins1_config.png'. This is set
> up using the GitHub Branch Source Plugin
> .
>
>
> The fields that are in play here are the following. For both jobs, I want
> the following configuration:
>
> * Discover Branches
>   Strategy: Exclude Branches that are also filed as PRs
> * Discover Pull Requests from Origin
>   Strategy: The current pull request revision
>
> In order for the second organization's job to appear in GitHub, I have to
> change these two options. If the configuration is the same, it doesn't even
> show up, and only the first job shows up on GitHub. How can I get the same
> behavior for each GitHub Organization on Jenkins so that it appears on
> GitHub?
>

What do you mean “appears on GitHub”? Do you mean as a second status check
mark?

You may want to use a custom notifications context if that is the case.
There’s a plugin Steve F wrote that uses a new extension point in GitHub
Branch Source (look at the changelog and you might be able to find it
mentioned... or maybe Steve will chime in)


> One thing I have noticed is that it seems like it is not possible to
> change the names of these jobs on a per-GitHub organization basis, and that
> this is only configurable via global Jenkins configuration. Attached is the
> configuration for the GitHub Pull Request Builder
>

FYI: This plugin is completely ignored by multibranch.

that we have set up for that Jenkins instance as 'ghprb_configuration.png'.
>
> Please let me know if I need to provide more information. Thanks!
>
>
>
> --
> 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/c8a800c6-2a7a-4ad3-a3cb-fa6fa7940568%40googlegroups.com
> 
> .
> 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 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/CA%2BnPnMzOPuBX6h9D3%2B7hEjXPHrS1KrQf2hspKo-JOMgqO0X8rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Kubernetes plugin ( want to run slave as pod )

[Carlos Sanchez]

kubectl logs your_pod_slave has to print something, with that we could
probably help you better

Please stop hijacking jira issues and other email threads to enter
unrelated comments.


On Tue, Jan 2, 2018 at 8:29 PM, Vamsi krishna 
wrote:

>
>
> On Saturday, December 30, 2017 at 10:29:58 AM UTC-8, Carlos Sanchez wrote:
>>
>> what logs and events are you getting when you run
>>
>> * kubectl logs your_pod_slave
>> * kubectl describe your_pod_slave
>>
>> are you getting "failed to open log file" there? if you do it looks like
>> a kubernetes issue, like https://github.com/kubern
>> etes/kubernetes/issues/45911 that points to your container running out
>> of memory
>>
>
>
> my pod is runnning fine in kubernetes  but jenkins not able to take
> that  container to run the job.. is this issue with backend service.. i
> mean when pod is running succesfull then kubernetes assigns the pod to
> jenkins to run the job its concept wise. but my issue is, in that pod
> jenkins not able to run the job..
> pods logs showing nothing my reverse jnlp slave port should be 5
> or i can put any fixed port number??
>
> --
> 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/ms
> gid/jenkinsci-users/ad262af9-5a79-444c-86f6-6a2ae5a7f2fe%
> 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 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/CALHFn6MXnJ3ifm-gO%2B7vvCmePGs7pgFnH_sYycAv7nnDDqxyPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to use podTemplate in a declarative pipeline with the kubernetes-plugin.

[Vamsi krishna]

Hello all

Local headers refused by remote: Authorization failure 
Jan 04, 2018 6:13:25 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Protocol JNLP4-connect encountered an unexpected exception

whats this error means...  this is the logs error i am getting in my pod.. 
can anyone have idea.. i am thinking remote jnlp-4 is not accepting that 
container and the jnlp port issue i am guessing but not sure? any idea
On Wednesday, January 3, 2018 at 9:38:52 AM UTC-8, Carlos Sanchez wrote:
>
> I don't think it is possible, a volumes field would need to be added to 
> KubernetesDeclarativeAgent
>
> https://github.com/jenkinsci/kubernetes-plugin/blob/master/src/main/java/org/csanchez/jenkins/plugins/kubernetes/pipeline/KubernetesDeclarativeAgent.java
>
> On Wed, Jan 3, 2018 at 4:46 PM, Tim Zhukov  > wrote:
>
>> Hey All,
>>
>> Is volume support still in development? I would like to use declarative 
>> syntax with k8s plugin, but our agent containers share persistence across 
>> pod with volume mounts.
>>
>> --
>> Best 
>> Tim Zhukov 
>>
>>
>> On Friday, September 22, 2017 at 12:11:28 PM UTC-4, Vincent Heet wrote:
>>>
>>> Hi Chris,
>>>
>>> No I didn't. I ended up rewriting my Jenkinsfile in the non-declarative 
>>> Groovy format which worked like a charm.
>>>
>>> Greetings, Vincent
>>>
>>> On Friday, September 22, 2017 at 11:29:40 AM UTC+2, Chris Willmore wrote:

 Hey Vincent - did you ever give this a try? I'm looking at doing this 
 now and was wondering if you ran into any blockers.
 -Chris

 On Thursday, August 10, 2017 at 1:03:46 PM UTC+3, Vincent Heet wrote:
>
> Ok so maybe i'm able to add this myself next week. I looked at the 
> class you mentioned but would adding the PodTemplate class as a property 
> there fix my issue? And I'm not sure why you mention volumes, volumes 
> would 
> then be supported from the PodTemplate if I understand this correctly?
>
>
> On Thursday, August 10, 2017 at 10:27:14 AM UTC+2, Carlos Sanchez 
> wrote:
>>
>> It is not yet possible. Volumes would need to be added to the class 
>> https://github.com/jenkinsci/kubernetes-plugin/blob/master/src/main/java/org/csanchez/jenkins/plugins/kubernetes/pipeline/KubernetesDeclarativeAgent.java
>>
>> On Thu, Aug 10, 2017 at 9:22 AM, Vincent Heet  
>> wrote:
>>
>>> Hi,
>>>
>>> I configured a declarative pipeline with the kubernetes-plugin to 
>>> start a jenkins job's in a k8s cluster. This is working great but now I 
>>> want to use volumes for secrets and need to specify a podTemplate. I'm 
>>> not 
>>> sure how to configure a podTemplate for a declarative pipeline. The 
>>> pipeline that is working:
>>>
>>>
>>> pipeline {
>>> agent {
>>> kubernetes {
>>> label 'jenkins-demo'
>>> containerTemplate {
>>> name 'dind-jdk8-maven3'
>>> image 'eu.gcr.io/jenkins-demo/dind-jdk8-maven3:v4'
>>> ttyEnabled true
>>> command 'cat'
>>> }
>>> }
>>> }
>>> stages {
>>> }
>>> }
>>>
>>>
>>> The above I would like to extend with a podTemplate containing 
>>> volumes and a secretVolume. The issue is that I don't know the correct 
>>> syntax for specifying a podTemplate in the declarative pipeline. So I 
>>> came 
>>> up with this:
>>>
>>>
>>> pipeline {
>>> agent {
>>> kubernetes {
>>> label 'jenkins-demo'
>>> podTemplate {
>>> volumes {
>>> secretVolume(secretName: 'some-secret', 
>>> mountPath: '/some-secret')
>>> }
>>> containerTemplate {
>>> name 'dind-jdk8-maven3'
>>> image '
>>> eu.gcr.io/jenkins-demo/dind-jdk8-maven3:v4'
>>> ttyEnabled true
>>> command 'cat'
>>> }
>>> }
>>> }
>>> }
>>> stages {
>>> }
>>> }
>>>
>>>
>>> Ofcourse this doesn't work an throws an error. Can anyone help me 
>>> out with specifying a podTemplate so I can use k8s secrets?
>>>
>>> Thanks,
>>> Vincent
>>>
>>> -- 
>>> 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-use...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/a69efdfc-7c1c-4e4f-a909-0b43ad95868b%40googlegroups.com
>>>  
>>> 

Re: Jenkins says: The SDK directory '/Users/jpratik/Library/Android/sdk' does not exist but it does

[iamisathya]

It's due to permission problem. So it can be fixed by 2 ways

   1. 
   
1. Run below commands in ~/Library/ path by using terminal
   
   chmod 777
   
at /Users/username/Library/. Check permission by execute ls -s 
   command
   
So /Users/username/Library/ should now show the permission like 
   this drwxr-xr-x@
   2. 
   
2. Second way
   
  Run below command on Terminal to unhide library inside File explorer
   
   chflags nohidden ~/Library/
   
   So now navigate & right click on Library folder -> Get info -> 
   Scroll down -> change permission on permission in dialog
   
   Setting permission for Library directory 
   
   
Now run jerkin, it should be able to access the sdk directory inside Library

On Saturday, August 8, 2015 at 4:33:40 AM UTC+5:30, Pratik Jaiswal wrote:
>
> Log:
>
> Started by user anonymous 
>
> [EnvInject] - Loading node environment variables.
> Building in workspace /Users/Shared/Jenkins/Home/jobs/Automated Testing 
> Check/workspace
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://github.com/jpratik21/Testing # 
> timeout=10
> Fetching upstream changes from https://github.com/jpratik21/Testing
>  > git --version # timeout=10
> using .gitcredentials to set credentials
>  > git config --local credential.helper store 
> --file=/Users/Shared/Jenkins/tmp/git6483021201942154298.credentials # 
> timeout=10
>  > git -c core.askpass=true fetch --tags --progress 
> https://github.com/jpratik21/Testing +refs/heads/*:refs/remotes/origin/*
>  > git config --local --remove-section credential # timeout=10
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 3a3c7825ebf737c3193903368914a4b3c9528a4f 
> (refs/remotes/origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 3a3c7825ebf737c3193903368914a4b3c9528a4f
>  > git rev-list 3a3c7825ebf737c3193903368914a4b3c9528a4f # timeout=10
> [Gradle] - Launching build.
> [workspace] $ "/Users/Shared/Jenkins/Home/jobs/Automated Testing 
> Check/workspace/gradlew" clean build
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> A problem occurred configuring project ':app'.
> > The SDK directory '/Users/jpratik/Library/Android/sdk' does not exist.
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output.
> BUILD FAILED
> Total time: 9.163 secs
>
> Build step 'Invoke Gradle script' changed build result to FAILURE
> Build step 'Invoke Gradle script' marked build as failure
> [android-lint] Skipping publisher since build result is FAILURE
> Archiving artifacts
> Recording test results
>
> ERROR: Publisher 'Publish JUnit test result report' failed: No test report 
> files were found. Configuration error?Finished 
> : FAILURE
>
>
>
> My screenshot attached says that the android SDK does exist but jenkins says 
> it doesn't. Tried with ENV var:ANDROID_HOME too / ski.dir=pathtosdk...Any 
> help ??
>
>
>

-- 
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/11b692e0-43de-426c-84b5-9dd2ec10cccb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: github quota limit when scanning with the addition of tags

[Stephen Connolly]

On 4 January 2018 at 16:43,  wrote:

> Ok, than I think I misunderstand what the scan is doing.
> During the scan, Jenkins creates a list in memory of all branches, tags,
> PRs. It does it from a single api call? Or from an api call for each type?
>

At least one API call for each requested (or implied requested) type.

e.g. If there are more than 100 branches then it will take more than one
request to get all branches as the page size is 100
e.g. If you request to build branches that are not also filed as pull
requests, then that implies we need the list of pull requests (even if you
didn't select Discover Pull Requests)


> And then while iterating over that list, for each entity Jenkins makes an
> api call to get the Jenkinsfile (or to find out it doesn't exist)?
>

Correct.


>
> If that's the case, it doesn't sound like there is much to be done in the
> current setup.
>

A quick win might be to maintain a secondary state file that tracks the
hash of the XML config for the SCMSourceCriteri and the hash of the XML of
each revision for each discovered "head". If the hashes are the same, then
we can assume no need to recheck.


>
> This is a problem though, because as more and more tags come, there is no
> logical way to keep adding them to the filter if Jenkins is the only source
> of truth on if the tag has already been built. As in, those few tags that
> don't reference a commit with a Jenkinsfile could just be deleted from
> github, but it doesn't fix the problem, just delays it a couple weeks.
>
>
> On Thursday, 4 January 2018 15:27:37 UTC+1, Stephen Connolly wrote:
>>
>> If you know those tags will never match, you could add a filter to
>> exclude them from discovery.
>>
>> Part of the issue here is that Multibranch doesn't know if the
>> SCMCriteria has changed from the last time it saw that revision (because
>> Jenkins config is a filesystem, who knows what was restored, edited with
>> vi, etc)... on top of that, this is a tag that was not discovered, so it
>> doesn't actually have a place to store the revision.
>>
>> Consequently, it will check for the Jenkinsfile every time you do a full
>> scan.
>>
>> On 4 January 2018 at 14:13,  wrote:
>>
>>> I do want tags. I want tags very much. I'm very happy this feature is
>>> finally available.
>>> There just happens to be some tags in that repo that reference commits
>>> in which no Jenkinsfile exists, and I happened to copy those examples.
>>>
>>> Here is a better example:
>>>
>>>   Checking tag v1.1.0 
>>> 
>>>   ‘Jenkinsfile’ found
>>> Met criteria
>>> No changes detected: v1.1.0 (still at 
>>> d11d5c94130db1b43dea147091c2cfc2d260b2c1)
>>> 19:05:09 GitHub API Usage: Current quota has 677 remaining (0 under 
>>> budget). Next quota of 5000 in 6 min 50 sec
>>>
>>> Checking tag v1.1.1 
>>> 
>>>   ‘Jenkinsfile’ found
>>> Met criteria
>>> No changes detected: v1.1.1 (still at 
>>> 20b7a9ccd47f9e10165268ccc252bc4b793a61fc)
>>> 19:05:09 GitHub API Usage: Current quota has 675 remaining (2 over budget). 
>>> Next quota of 5000 in 6 min 50 sec. Sleeping for 26 sec.
>>> 19:05:36 GitHub API Usage: Current quota has 675 remaining (26 under 
>>> budget). Next quota of 5000 in 6 min 23 sec
>>>
>>>
>>>
>>>
>>>
>>> On Thursday, 4 January 2018 15:02:11 UTC+1, Stephen Connolly wrote:



 On 4 January 2018 at 13:27,  wrote:

> @Stephen
> You mention that caching the responses would "save about 50% of the
> requests." That seems like a significant savings to me.
>
> I'm also wondering, I'm seeing a lot of things like this in the scan
> log:
>
> Checking tag v0.28.1 
> 
>   ‘Jenkinsfile’ not found
> Does not meet criteria
> 19:01:38 GitHub API Usage: Current quota has 901 remaining (4 under 
> budget). Next quota of 5000 in 10 min
>
> Checking tag v0.28.2 
> 
>   ‘Jenkinsfile’ not found
> Does not meet criteria
> 19:01:38 GitHub API Usage: Current quota has 897 remaining (0 under 
> budget). Next quota of 5000 in 10 min
>
> Checking tag v0.28.3 
> 
>   ‘Jenkinsfile’ not found
> Does not meet criteria
> 19:01:38 GitHub API Usage: Current quota has 894 remaining (3 over 
> budget). Next quota of 5000 in 10 min. Sleeping for 27 sec.
> 19:02:06 GitHub API Usage: Current quota has 894 remaining (26 under 
> budget). Next quota of 5000 in 9 min 53 sec
>
>
>
> That seems to me like each tag invokes an api request? And with 500+
> tags, that seems like a lot of unneeded calls (most especially when 
> Jenkins

Re: github quota limit when scanning with the addition of tags

[j . knurek]

Ok, than I think I misunderstand what the scan is doing. 
During the scan, Jenkins creates a list in memory of all branches, tags, 
PRs. It does it from a single api call? Or from an api call for each type?
And then while iterating over that list, for each entity Jenkins makes an 
api call to get the Jenkinsfile (or to find out it doesn't exist)?

If that's the case, it doesn't sound like there is much to be done in the 
current setup. 

This is a problem though, because as more and more tags come, there is no 
logical way to keep adding them to the filter if Jenkins is the only source 
of truth on if the tag has already been built. As in, those few tags that 
don't reference a commit with a Jenkinsfile could just be deleted from 
github, but it doesn't fix the problem, just delays it a couple weeks.


On Thursday, 4 January 2018 15:27:37 UTC+1, Stephen Connolly wrote:
>
> If you know those tags will never match, you could add a filter to exclude 
> them from discovery.
>
> Part of the issue here is that Multibranch doesn't know if the SCMCriteria 
> has changed from the last time it saw that revision (because Jenkins config 
> is a filesystem, who knows what was restored, edited with vi, etc)... on 
> top of that, this is a tag that was not discovered, so it doesn't actually 
> have a place to store the revision.
>
> Consequently, it will check for the Jenkinsfile every time you do a full 
> scan.
>
> On 4 January 2018 at 14:13,  
> wrote:
>
>> I do want tags. I want tags very much. I'm very happy this feature is 
>> finally available. 
>> There just happens to be some tags in that repo that reference commits in 
>> which no Jenkinsfile exists, and I happened to copy those examples.
>>
>> Here is a better example:
>>
>>   Checking tag v1.1.0 
>> 
>>   ‘Jenkinsfile’ found
>> Met criteria
>> No changes detected: v1.1.0 (still at 
>> d11d5c94130db1b43dea147091c2cfc2d260b2c1)
>> 19:05:09 GitHub API Usage: Current quota has 677 remaining (0 under budget). 
>> Next quota of 5000 in 6 min 50 sec
>>
>> Checking tag v1.1.1 
>> 
>>   ‘Jenkinsfile’ found
>> Met criteria
>> No changes detected: v1.1.1 (still at 
>> 20b7a9ccd47f9e10165268ccc252bc4b793a61fc)
>> 19:05:09 GitHub API Usage: Current quota has 675 remaining (2 over budget). 
>> Next quota of 5000 in 6 min 50 sec. Sleeping for 26 sec.
>> 19:05:36 GitHub API Usage: Current quota has 675 remaining (26 under 
>> budget). Next quota of 5000 in 6 min 23 sec
>>
>>
>>
>>
>>
>> On Thursday, 4 January 2018 15:02:11 UTC+1, Stephen Connolly wrote:
>>>
>>>
>>>
>>> On 4 January 2018 at 13:27,  wrote:
>>>
 @Stephen
 You mention that caching the responses would "save about 50% of the 
 requests." That seems like a significant savings to me.

 I'm also wondering, I'm seeing a lot of things like this in the scan 
 log:

 Checking tag v0.28.1 
 
   ‘Jenkinsfile’ not found
 Does not meet criteria
 19:01:38 GitHub API Usage: Current quota has 901 remaining (4 under 
 budget). Next quota of 5000 in 10 min

 Checking tag v0.28.2 
 
   ‘Jenkinsfile’ not found
 Does not meet criteria
 19:01:38 GitHub API Usage: Current quota has 897 remaining (0 under 
 budget). Next quota of 5000 in 10 min

 Checking tag v0.28.3 
 
   ‘Jenkinsfile’ not found
 Does not meet criteria
 19:01:38 GitHub API Usage: Current quota has 894 remaining (3 over 
 budget). Next quota of 5000 in 10 min. Sleeping for 27 sec.
 19:02:06 GitHub API Usage: Current quota has 894 remaining (26 under 
 budget). Next quota of 5000 in 9 min 53 sec



 That seems to me like each tag invokes an api request? And with 500+ 
 tags, that seems like a lot of unneeded calls (most especially when 
 Jenkins 
 doesn't even track/build the tag). 

>>>
>>> Why are you discovering tags if you don't want tags?
>>>
>>> Every branch/tag/PR you discover needs at least one request to verify 
>>> that the marker file is present.
>>>
>>> If you don't want tags, don't discover them and you will save a lot of 
>>> requests.
>>>   
>>>
 Or am I reading the logs incorrectly? If that is the case then a cache 
 might save over 90% of the requests in this case. 
 Should I create a Jira ticket for this? 


 On Wednesday, 3 January 2018 16:52:03 UTC+1, j.kn...@travelaudience.com 
 wrote:
>
> There are only two good reasons to scan periodically:
>> 1. To recover from missed events (keep in mind that follow-up commits 
>> will typically recover anyway, so the only case here is a 

Re: Jenkins in docker ... pipeline script from SCM ... sh 'adb devices...' not working

[Victor Martinez]

You might get some benefits of adding some -x debug traces in the script 
'./start_environment_new.sh' to know what it does under the hood.

Besides of that, did you check whether those docker images should be attach 
to a particular version? it might be related to the usage of 'latest' by 
default and maybe there were some releases recently.

Cheers

-- 
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/eb750762-001c-4ad9-8e5a-8f8d465fdbd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins in docker ... pipeline script from SCM ... sh 'adb devices...' not working

[Cepin]

Hi all,
machine with centos 7
Docker version 17.12.0-ce, build c97c6d6
Jenkins ver. 2.60.3
all plugins updated

situation:
Jenkins (running in container Alpine linux) is configured to download 
Jenkins file from gitlab and the start some containers (based on 
debian:stretch-slim) and run there some scriptsthe Jenkins file looks 
like:

node {
stage('Git fetch') {
git poll: false, changelog: false, url: 
'https://XXX/gitlab/test.git', credentialsId: 'DOL', branch: 'master'
}
def appium_ready = false
withDockerServer([uri: "tcp://localhost:2376"]) {
parallel Cucumber: {
stage ('Starting Cucumber')
{
try {
docker.image('docker_ruby').inside('--user root:root 
--net=host') {
echo 'Waiting for Appium'
waitUntil {
  sleep 2
  return (appium_ready == true)
}
try {


//  Show start HERE 
sh 'cucumber -t @add_unread -t ~@wip'


}
catch ( error ) {
cucumber 'report.json'
}
cucumber 'report.json'
}
}
catch ( error ) {
sh 'curl 
http://localhost:/lifecycle-manager/LifecycleServlet?action=shutdown || 
echo "Selenium server unreachable";exit 1' //shutdown selenium & fail
}
sh 'curl 
http://localhost:/lifecycle-manager/LifecycleServlet?action=shutdown || 
echo "Selenium server unreachable"'
}
},
Appium: {
stage ('Starting Appium')
{
*docker.image('docker_appium').inside('--user root:root 
--net=host') {*
*sh 'adb devices; cd scripts && 
./start_environment_new.sh 2>&1 >/dev/null'*
appium_ready = true
sh 'PID_SEL=`cat /tmp/selenium.pid`; while( ps -p 
$PID_SEL > /dev/null ); do sleep 5;done' // wait doesn't work
}
}
}
}
}


Everything works fine but when it is in the "*sh 'adb devices; cd scripts 
&& ./start_environment_new.sh 2>&1 >/dev/null'*" then it will timeout and 
say "*Shell Script script returned exit code -2*"
The shell script starts with usual: "#!/bin/bash"

All this approach was working fine until most probably something was 
updated ... docker, Jenkins plugins, some host OS stuff. 

Please don't you anybody have same issue a ideally fix for it? I found some 
hints on google but nothing was working for me :(.

Here is the CLI output:

[Pipeline] }[Pipeline] // stage[Pipeline] withDockerServer[Pipeline] 
{[Pipeline] parallel[Pipeline] [Cucumber] { (Branch: Cucumber)[Pipeline] 
[Appium] { (Branch: Appium)[Pipeline] [Cucumber] stage[Pipeline] [Cucumber] { 
(Starting Cucumber)[Pipeline] [Appium] stage[Pipeline] [Appium] { (Starting 
Appium)[Pipeline] [Cucumber] sh[Cucumber] [voicemail_ta_android] Running shell 
script[Pipeline] [Appium] sh[Cucumber] + docker inspect -f . docker_ruby
[Appium] [voicemail_ta_android] Running shell script
[Appium] + docker inspect -f . docker_appium
[Cucumber] .
[Appium] .[Pipeline] [Cucumber] withDockerContainer[Cucumber] Jenkins seems to 
be running inside container 
9350a6f58ccb1db7fcac229dee8079a191aed4452b1403e3ee4b43f92c63
[Cucumber] $ docker run -t -d -u 1000:1000 --user root:root --net=host -w 
/var/jenkins_home/workspace/voicemail_ta_android --volumes-from 
9350a6f58ccb1db7fcac229dee8079a191aed4452b1403e3ee4b43f92c63 -e  -e 
 -e  -e  -e  -e  -e  -e 
 -e  -e  -e  -e  -e  -e 
 -e  -e  -e  -e  -e  -e 
 -e  -e  -e  -e  --entrypoint cat 
docker_ruby[Pipeline] [Cucumber] {[Pipeline] [Appium] 
withDockerContainer[Appium] Jenkins seems to be running inside container 
9350a6f58ccb1db7fcac229dee8079a191aed4452b1403e3ee4b43f92c63
[Appium] $ docker run -t -d -u 1000:1000 --user root:root --net=host -w 
/var/jenkins_home/workspace/voicemail_ta_android --volumes-from 
9350a6f58ccb1db7fcac229dee8079a191aed4452b1403e3ee4b43f92c63 -e  -e 
 -e  -e  -e  -e  -e  -e 
 -e  -e  -e  -e  -e  -e 
 -e  -e  -e  -e  -e  -e 
 -e  -e  -e  -e  --entrypoint cat 
docker_appium[Pipeline] [Appium] {[Pipeline] [Cucumber] echo[Cucumber] Waiting 
for Appium[Pipeline] [Cucumber] waitUntil[Pipeline] [Cucumber] {[Pipeline] 
[Appium] sh[Appium] [voicemail_ta_android] Running shell script[Pipeline] 
[Cucumber] sleep[Cucumber] 

Re: github quota limit when scanning with the addition of tags

[Stephen Connolly]

If you know those tags will never match, you could add a filter to exclude
them from discovery.

Part of the issue here is that Multibranch doesn't know if the SCMCriteria
has changed from the last time it saw that revision (because Jenkins config
is a filesystem, who knows what was restored, edited with vi, etc)... on
top of that, this is a tag that was not discovered, so it doesn't actually
have a place to store the revision.

Consequently, it will check for the Jenkinsfile every time you do a full
scan.

On 4 January 2018 at 14:13,  wrote:

> I do want tags. I want tags very much. I'm very happy this feature is
> finally available.
> There just happens to be some tags in that repo that reference commits in
> which no Jenkinsfile exists, and I happened to copy those examples.
>
> Here is a better example:
>
>   Checking tag v1.1.0 
>   ‘Jenkinsfile’ found
> Met criteria
> No changes detected: v1.1.0 (still at 
> d11d5c94130db1b43dea147091c2cfc2d260b2c1)
> 19:05:09 GitHub API Usage: Current quota has 677 remaining (0 under budget). 
> Next quota of 5000 in 6 min 50 sec
>
> Checking tag v1.1.1 
> 
>   ‘Jenkinsfile’ found
> Met criteria
> No changes detected: v1.1.1 (still at 
> 20b7a9ccd47f9e10165268ccc252bc4b793a61fc)
> 19:05:09 GitHub API Usage: Current quota has 675 remaining (2 over budget). 
> Next quota of 5000 in 6 min 50 sec. Sleeping for 26 sec.
> 19:05:36 GitHub API Usage: Current quota has 675 remaining (26 under budget). 
> Next quota of 5000 in 6 min 23 sec
>
>
>
>
>
> On Thursday, 4 January 2018 15:02:11 UTC+1, Stephen Connolly wrote:
>>
>>
>>
>> On 4 January 2018 at 13:27,  wrote:
>>
>>> @Stephen
>>> You mention that caching the responses would "save about 50% of the
>>> requests." That seems like a significant savings to me.
>>>
>>> I'm also wondering, I'm seeing a lot of things like this in the scan log:
>>>
>>> Checking tag v0.28.1 
>>> 
>>>   ‘Jenkinsfile’ not found
>>> Does not meet criteria
>>> 19:01:38 GitHub API Usage: Current quota has 901 remaining (4 under 
>>> budget). Next quota of 5000 in 10 min
>>>
>>> Checking tag v0.28.2 
>>> 
>>>   ‘Jenkinsfile’ not found
>>> Does not meet criteria
>>> 19:01:38 GitHub API Usage: Current quota has 897 remaining (0 under 
>>> budget). Next quota of 5000 in 10 min
>>>
>>> Checking tag v0.28.3 
>>> 
>>>   ‘Jenkinsfile’ not found
>>> Does not meet criteria
>>> 19:01:38 GitHub API Usage: Current quota has 894 remaining (3 over budget). 
>>> Next quota of 5000 in 10 min. Sleeping for 27 sec.
>>> 19:02:06 GitHub API Usage: Current quota has 894 remaining (26 under 
>>> budget). Next quota of 5000 in 9 min 53 sec
>>>
>>>
>>>
>>> That seems to me like each tag invokes an api request? And with 500+
>>> tags, that seems like a lot of unneeded calls (most especially when Jenkins
>>> doesn't even track/build the tag).
>>>
>>
>> Why are you discovering tags if you don't want tags?
>>
>> Every branch/tag/PR you discover needs at least one request to verify
>> that the marker file is present.
>>
>> If you don't want tags, don't discover them and you will save a lot of
>> requests.
>>
>>
>>> Or am I reading the logs incorrectly? If that is the case then a cache
>>> might save over 90% of the requests in this case.
>>> Should I create a Jira ticket for this?
>>>
>>>
>>> On Wednesday, 3 January 2018 16:52:03 UTC+1, j.kn...@travelaudience.com
>>> wrote:

 There are only two good reasons to scan periodically:
> 1. To recover from missed events (keep in mind that follow-up commits
> will typically recover anyway, so the only case here is a commit before
> bedtime not being built by morning because that event was not delivered by
> GitHub)
>
 From my experience working with developers, that isn't the only use
 case. The more common use case (when a missed event happens) is that they
 pushed a commit and are waiting for it to proceed through the pipeline and
 notify them. Fast notification is a key to good CI/CD. So while missed
 events are not a frequent occurrence, waiting 7 days isn't an option, and
 the only other solution for a developer is to have an in-depth knowledge of
 Jenkins and know that this issue exists.


> 2. To run the orphaned item strategies (which is probably fine at once
> per week for most people)

 Totally agree, that's fine


 As we already have a few repos with over 500 tags (and mind you these
 are still new repos), I expect that this issue will impact others as they
 begin to implement the ability to scan tags even with a 24 hour interval.

 

Re: github quota limit when scanning with the addition of tags

[j . knurek]

I do want tags. I want tags very much. I'm very happy this feature is 
finally available. 
There just happens to be some tags in that repo that reference commits in 
which no Jenkinsfile exists, and I happened to copy those examples.

Here is a better example:

  Checking tag v1.1.0 
  ‘Jenkinsfile’ found
Met criteria
No changes detected: v1.1.0 (still at d11d5c94130db1b43dea147091c2cfc2d260b2c1)
19:05:09 GitHub API Usage: Current quota has 677 remaining (0 under budget). 
Next quota of 5000 in 6 min 50 sec

Checking tag v1.1.1 
  ‘Jenkinsfile’ found
Met criteria
No changes detected: v1.1.1 (still at 20b7a9ccd47f9e10165268ccc252bc4b793a61fc)
19:05:09 GitHub API Usage: Current quota has 675 remaining (2 over budget). 
Next quota of 5000 in 6 min 50 sec. Sleeping for 26 sec.
19:05:36 GitHub API Usage: Current quota has 675 remaining (26 under budget). 
Next quota of 5000 in 6 min 23 sec





On Thursday, 4 January 2018 15:02:11 UTC+1, Stephen Connolly wrote:
>
>
>
> On 4 January 2018 at 13:27,  
> wrote:
>
>> @Stephen
>> You mention that caching the responses would "save about 50% of the 
>> requests." That seems like a significant savings to me.
>>
>> I'm also wondering, I'm seeing a lot of things like this in the scan log:
>>
>> Checking tag v0.28.1 
>> 
>>   ‘Jenkinsfile’ not found
>> Does not meet criteria
>> 19:01:38 GitHub API Usage: Current quota has 901 remaining (4 under budget). 
>> Next quota of 5000 in 10 min
>>
>> Checking tag v0.28.2 
>> 
>>   ‘Jenkinsfile’ not found
>> Does not meet criteria
>> 19:01:38 GitHub API Usage: Current quota has 897 remaining (0 under budget). 
>> Next quota of 5000 in 10 min
>>
>> Checking tag v0.28.3 
>> 
>>   ‘Jenkinsfile’ not found
>> Does not meet criteria
>> 19:01:38 GitHub API Usage: Current quota has 894 remaining (3 over budget). 
>> Next quota of 5000 in 10 min. Sleeping for 27 sec.
>> 19:02:06 GitHub API Usage: Current quota has 894 remaining (26 under 
>> budget). Next quota of 5000 in 9 min 53 sec
>>
>>
>>
>> That seems to me like each tag invokes an api request? And with 500+ 
>> tags, that seems like a lot of unneeded calls (most especially when Jenkins 
>> doesn't even track/build the tag). 
>>
>
> Why are you discovering tags if you don't want tags?
>
> Every branch/tag/PR you discover needs at least one request to verify that 
> the marker file is present.
>
> If you don't want tags, don't discover them and you will save a lot of 
> requests.
>   
>
>> Or am I reading the logs incorrectly? If that is the case then a cache 
>> might save over 90% of the requests in this case. 
>> Should I create a Jira ticket for this? 
>>
>>
>> On Wednesday, 3 January 2018 16:52:03 UTC+1, j.kn...@travelaudience.com 
>> wrote:
>>>
>>> There are only two good reasons to scan periodically:
 1. To recover from missed events (keep in mind that follow-up commits 
 will typically recover anyway, so the only case here is a commit before 
 bedtime not being built by morning because that event was not delivered by 
 GitHub)

>>> From my experience working with developers, that isn't the only use 
>>> case. The more common use case (when a missed event happens) is that they 
>>> pushed a commit and are waiting for it to proceed through the pipeline and 
>>> notify them. Fast notification is a key to good CI/CD. So while missed 
>>> events are not a frequent occurrence, waiting 7 days isn't an option, and 
>>> the only other solution for a developer is to have an in-depth knowledge of 
>>> Jenkins and know that this issue exists. 
>>>  
>>>
 2. To run the orphaned item strategies (which is probably fine at once 
 per week for most people)
>>>
>>> Totally agree, that's fine
>>>
>>>
>>> As we already have a few repos with over 500 tags (and mind you these 
>>> are still new repos), I expect that this issue will impact others as they 
>>> begin to implement the ability to scan tags even with a 24 hour interval. 
>>>
>>> 
>>>
>>> Also, the recommendation in the UI for the interval setting is:
>>> Subsequent commits should trigger indexing anyway and result in the 
>>> commit being picked up, so most people will pick between *4 hours and 1 
>>> day*
>>>
>>>
>>>
>>> On Wednesday, 3 January 2018 15:42:15 UTC+1, Stephen Connolly wrote:

 This is the limitation of 5000 requests per hour.

 Ideally we would look into caching the github responses so that 
 duplicate requests could be eliminated... but my preliminary analysis 
 shows 
 that would basically save about 50% of the requests.

 The recommendation for "*Scan Organization Triggers* -> *Periodically 
 

Re: github quota limit when scanning with the addition of tags

[Stephen Connolly]

On 4 January 2018 at 13:27,  wrote:

> @Stephen
> You mention that caching the responses would "save about 50% of the
> requests." That seems like a significant savings to me.
>
> I'm also wondering, I'm seeing a lot of things like this in the scan log:
>
> Checking tag v0.28.1 
>   ‘Jenkinsfile’ not found
> Does not meet criteria
> 19:01:38 GitHub API Usage: Current quota has 901 remaining (4 under budget). 
> Next quota of 5000 in 10 min
>
> Checking tag v0.28.2 
> 
>   ‘Jenkinsfile’ not found
> Does not meet criteria
> 19:01:38 GitHub API Usage: Current quota has 897 remaining (0 under budget). 
> Next quota of 5000 in 10 min
>
> Checking tag v0.28.3 
> 
>   ‘Jenkinsfile’ not found
> Does not meet criteria
> 19:01:38 GitHub API Usage: Current quota has 894 remaining (3 over budget). 
> Next quota of 5000 in 10 min. Sleeping for 27 sec.
> 19:02:06 GitHub API Usage: Current quota has 894 remaining (26 under budget). 
> Next quota of 5000 in 9 min 53 sec
>
>
>
> That seems to me like each tag invokes an api request? And with 500+ tags,
> that seems like a lot of unneeded calls (most especially when Jenkins
> doesn't even track/build the tag).
>

Why are you discovering tags if you don't want tags?

Every branch/tag/PR you discover needs at least one request to verify that
the marker file is present.

If you don't want tags, don't discover them and you will save a lot of
requests.


> Or am I reading the logs incorrectly? If that is the case then a cache
> might save over 90% of the requests in this case.
> Should I create a Jira ticket for this?
>
>
> On Wednesday, 3 January 2018 16:52:03 UTC+1, j.kn...@travelaudience.com
> wrote:
>>
>> There are only two good reasons to scan periodically:
>>> 1. To recover from missed events (keep in mind that follow-up commits
>>> will typically recover anyway, so the only case here is a commit before
>>> bedtime not being built by morning because that event was not delivered by
>>> GitHub)
>>>
>> From my experience working with developers, that isn't the only use case.
>> The more common use case (when a missed event happens) is that they pushed
>> a commit and are waiting for it to proceed through the pipeline and notify
>> them. Fast notification is a key to good CI/CD. So while missed events are
>> not a frequent occurrence, waiting 7 days isn't an option, and the only
>> other solution for a developer is to have an in-depth knowledge of Jenkins
>> and know that this issue exists.
>>
>>
>>> 2. To run the orphaned item strategies (which is probably fine at once
>>> per week for most people)
>>
>> Totally agree, that's fine
>>
>>
>> As we already have a few repos with over 500 tags (and mind you these are
>> still new repos), I expect that this issue will impact others as they begin
>> to implement the ability to scan tags even with a 24 hour interval.
>>
>> 
>>
>> Also, the recommendation in the UI for the interval setting is:
>> Subsequent commits should trigger indexing anyway and result in the
>> commit being picked up, so most people will pick between *4 hours and 1
>> day*
>>
>>
>>
>> On Wednesday, 3 January 2018 15:42:15 UTC+1, Stephen Connolly wrote:
>>>
>>> This is the limitation of 5000 requests per hour.
>>>
>>> Ideally we would look into caching the github responses so that
>>> duplicate requests could be eliminated... but my preliminary analysis shows
>>> that would basically save about 50% of the requests.
>>>
>>> The recommendation for "*Scan Organization Triggers* -> *Periodically
>>> if not otherwise run*" is *at least 8 hours* more likely somewhere
>>> between 24h and 7 days *depending on how long you are willing to wait* for
>>> a failure to deliver an event from GitHub.
>>>
>>> There are only two good reasons to scan periodically:
>>>
>>> 1. To recover from missed events (keep in mind that follow-up commits
>>> will typically recover anyway, so the only case here is a commit before
>>> bedtime not being built by morning because that event was not delivered by
>>> GitHub)
>>> 2. To run the orphaned item strategies (which is probably fine at once
>>> per week for most people)
>>>
>>> The only other reason to scan periodically is a bad one, namely
>>>
>>> * You cannot set up push notification from GitHub
>>>
>>>
>>>
>>> On 3 January 2018 at 14:19,  wrote:
>>>
 Now that we've added *Discover tags*[1
 ] and a *Build
 everything*[2
 ]
 strategy, we're running into Github quota limits quite frequently.

 18:58:09 GitHub API Usage: Current quota has 1110 remaining (5 over 
 budget). Next quota of 5000 in 13 min. Sleeping for 

Re: github quota limit when scanning with the addition of tags

[j . knurek]

@Stephen
You mention that caching the responses would "save about 50% of the 
requests." That seems like a significant savings to me.

I'm also wondering, I'm seeing a lot of things like this in the scan log:

Checking tag v0.28.1 
  ‘Jenkinsfile’ not found
Does not meet criteria
19:01:38 GitHub API Usage: Current quota has 901 remaining (4 under budget). 
Next quota of 5000 in 10 min

Checking tag v0.28.2 

  ‘Jenkinsfile’ not found
Does not meet criteria
19:01:38 GitHub API Usage: Current quota has 897 remaining (0 under budget). 
Next quota of 5000 in 10 min

Checking tag v0.28.3 

  ‘Jenkinsfile’ not found
Does not meet criteria
19:01:38 GitHub API Usage: Current quota has 894 remaining (3 over budget). 
Next quota of 5000 in 10 min. Sleeping for 27 sec.
19:02:06 GitHub API Usage: Current quota has 894 remaining (26 under budget). 
Next quota of 5000 in 9 min 53 sec



That seems to me like each tag invokes an api request? And with 500+ tags, 
that seems like a lot of unneeded calls (most especially when Jenkins 
doesn't even track/build the tag). Or am I reading the logs incorrectly? If 
that is the case then a cache might save over 90% of the requests in this 
case. 
Should I create a Jira ticket for this? 


On Wednesday, 3 January 2018 16:52:03 UTC+1, j.kn...@travelaudience.com 
wrote:
>
> There are only two good reasons to scan periodically:
>> 1. To recover from missed events (keep in mind that follow-up commits 
>> will typically recover anyway, so the only case here is a commit before 
>> bedtime not being built by morning because that event was not delivered by 
>> GitHub)
>>
> From my experience working with developers, that isn't the only use case. 
> The more common use case (when a missed event happens) is that they pushed 
> a commit and are waiting for it to proceed through the pipeline and notify 
> them. Fast notification is a key to good CI/CD. So while missed events are 
> not a frequent occurrence, waiting 7 days isn't an option, and the only 
> other solution for a developer is to have an in-depth knowledge of Jenkins 
> and know that this issue exists. 
>  
>
>> 2. To run the orphaned item strategies (which is probably fine at once 
>> per week for most people)
>
> Totally agree, that's fine
>
>
> As we already have a few repos with over 500 tags (and mind you these are 
> still new repos), I expect that this issue will impact others as they begin 
> to implement the ability to scan tags even with a 24 hour interval. 
>
> 
>
> Also, the recommendation in the UI for the interval setting is:
> Subsequent commits should trigger indexing anyway and result in the commit 
> being picked up, so most people will pick between *4 hours and 1 day*
>
>
>
> On Wednesday, 3 January 2018 15:42:15 UTC+1, Stephen Connolly wrote:
>>
>> This is the limitation of 5000 requests per hour.
>>
>> Ideally we would look into caching the github responses so that duplicate 
>> requests could be eliminated... but my preliminary analysis shows that 
>> would basically save about 50% of the requests.
>>
>> The recommendation for "*Scan Organization Triggers* -> *Periodically if 
>> not otherwise run*" is *at least 8 hours* more likely somewhere between 
>> 24h and 7 days *depending on how long you are willing to wait* for a 
>> failure to deliver an event from GitHub.
>>
>> There are only two good reasons to scan periodically:
>>
>> 1. To recover from missed events (keep in mind that follow-up commits 
>> will typically recover anyway, so the only case here is a commit before 
>> bedtime not being built by morning because that event was not delivered by 
>> GitHub)
>> 2. To run the orphaned item strategies (which is probably fine at once 
>> per week for most people)
>>
>> The only other reason to scan periodically is a bad one, namely
>>
>> * You cannot set up push notification from GitHub
>>
>>
>>
>> On 3 January 2018 at 14:19,  wrote:
>>
>>> Now that we've added *Discover tags*[1 
>>> ] and a *Build 
>>> everything*[2 
>>> ]
>>>  
>>> strategy, we're running into Github quota limits quite frequently.
>>>
>>> 18:58:09 GitHub API Usage: Current quota has 1110 remaining (5 over 
>>> budget). Next quota of 5000 in 13 min. Sleeping for 29 sec.
>>>
>>>
>>> We've had to extend the *Scan Organization Triggers* -> *Periodically 
>>> if not otherwise run *setting to be 8 hours, to help limit the amount 
>>> of scans, but that hasn't completely solved  this issue, nor is it the goal 
>>> we want to achieve. 
>>>
>>>
>>> There's an open bug about the time setting and github quota limits  
>>> (*JENKINS-47154*[3] 

[ANN] Basic Branch Build Strategies plugin

[Stephen Connolly]

If you are using Multibranch, you may be interested in:

https://github.com/jenkinsci/basic-branch-build-strategies-plugin

Checkout the documentation:

https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc

This extension plugin will enable things like:

* Not rebuilding PRs if only the target branch changed

* Automatically building tags that were "created" within a specific time
window

If somebody wants to take their hand at implementing
https://issues.jenkins-ci.org/browse/JENKINS-48792 this would be very
welcome. Until there is an implementation of JENKINS-48792 we cannot kill
off https://issues.jenkins-ci.org/browse/JENKINS-47859 and I am not sure
when I will next get a window to code stuff up...

But anyway!

Enjoy (once the release is synced)

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

Advanced / Deprecated plugins

[James Green]

Within the "Sample Step" drop-down we have an end listing Advanced /
Deprecated plugins.

How can I tell which ones are Advanced, and which are Deprecated?

I am, in particular, very confused concerning our use of docker private
registries which I'm reading we may be using the wrong plugin for.

Thanks,

James

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

Re: Releasing with declarative pipeline

[Ari Maniatis]

On 4 January 2018 at 7:19:53pm, Stephen Connolly (
stephen.alan.conno...@gmail.com) wrote:

* the multibranch plugin (which I use already) is pretty flaky. I find it
> will sometimes reset all the branches to be enabled even though I try to
> disable old branches to get them out of the view
>

You shouldn’t be manually disabling branches. The disabled state should be
controlled by the multibranch folder.

Or could you explain what you are doing?


I’m using the old deprecated multibranch plugin (not the pipeline version)
and as we finish with each branch I press the “disable project” button for
that job. Which works until some upgrade of the plugin enables them all
again. I don’t know how to control the disabled state in any other way. But
perhaps that’s a feature of the pipeline version of this plugin.


(The enabled state should be updated to its “correct” value during a full
scan)

There should be no flakey (but there may be a bug whereby you can disable
the branch by the UI... which we should fix)

I’ve always been able to press ‘disable project’ per branch and thought
that was supposed to work like that.


* if you create a lot of branches you end up with a huge number of
> workspaces and disk space which never goes away. In svn the solution to
> that is to create an 'archived' folder and move old branches/tags there.
> You can't do that in git though since it is more rigid in how it handles
> tags/branches.
>

Well one thing I do is have my pipeline empty the workspace at the end.
This does mean a slower checkout, but I branch a lot, so I get a slower
checkout anyway on a new branch.


> * The UI gets cluttered in Jenkins
>
> But I love the idea of a tag driving the release process and the version
> naming is embedded in the tag name itself.
>

Tags should be on a separate tab, so the UI shouldn’t be so bad (granted
BlueOcean doesn’t use the SCMCategory information yet and has hard-coded
its tabs - against my advice - so yes the BO UI would be cluttered)


I have to say that I find Blue Ocean very hard to understand. Fixed width,
non-responsive CSS.  Headings like branches and pull requests when you have
none. Very little clarity about what things are links and what aren’t.
Projects listed in random order. No sense of where in the page hierarchy
you are.


You can write a SCMFilter that only discovers “recent” tags - would work
best for annotated tags - so that would limit the clutter to only those
tags created (or worst case with last commit) say in the last week (or
whatever you configure)


That’s really interesting.


Probably the biggest deal breaker of the tag-to-release approach for me is
that on one project I’ve got a rather unusual structure with multiple
projects inside one SCM root. So I have 10 jenkinsfiles in different
folders for each project I want to build separately. It works great for
what we want, but it means that I can’t easily tag each project separately.

We still name our releases with different versions per project and we don’t
want to release and tag them all at once. So either we restructure our code
completely, or we have some trick with naming tags like projectA-10.2.3 to
identify which one should be released.

Thanks for your ideas. I think Jenkins could do more to make releasing a
really first class concept in the UI and pipeline. But there are still
pieces missing (eg. being able to set a build to keep forever from the
pipeline).

Ari

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

Re: location of email-ext template file

[slmpskece]

Hi, 
I also getting same error.


Jelly file [managed:EmailTemplate] was not found in 
$JENKINS_HOME/email-templates.

I already installed 
Config File Provider Plugin 
 but i 
dont't know how to refer in my email template.



in email text 


   ${JELLY_SCRIPT, template="managed:EmailTemplate.jelly"}



I also tried 


   ${JELLY_SCRIPT, template="managed:EmailTemplate"}



can anyone please help to solve this issue


-- 
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/e55c3dd8-5f94-44df-b786-89f8ab13abf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Releasing with declarative pipeline

[Stephen Connolly]

On Thu 4 Jan 2018 at 06:57, Ari Maniatis 
wrote:

> I think that's a great idea. The main downsides I see are:
>
> * the multibranch plugin (which I use already) is pretty flaky. I find it
> will sometimes reset all the branches to be enabled even though I try to
> disable old branches to get them out of the view
>

You shouldn’t be manually disabling branches. The disabled state should be
controlled by the multibranch folder.

Or could you explain what you are doing?

(The enabled state should be updated to its “correct” value during a full
scan)

There should be no flakey (but there may be a bug whereby you can disable
the branch by the UI... which we should fix)


> * if you create a lot of branches you end up with a huge number of
> workspaces and disk space which never goes away. In svn the solution to
> that is to create an 'archived' folder and move old branches/tags there.
> You can't do that in git though since it is more rigid in how it handles
> tags/branches.
>

Well one thing I do is have my pipeline empty the workspace at the end.
This does mean a slower checkout, but I branch a lot, so I get a slower
checkout anyway on a new branch.


> * The UI gets cluttered in Jenkins
>
> But I love the idea of a tag driving the release process and the version
> naming is embedded in the tag name itself.
>

Tags should be on a separate tab, so the UI shouldn’t be so bad (granted
BlueOcean doesn’t use the SCMCategory information yet and has hard-coded
its tabs - against my advice - so yes the BO UI would be cluttered)

You can write a SCMFilter that only discovers “recent” tags - would work
best for annotated tags - so that would limit the clutter to only those
tags created (or worst case with last commit) say in the last week (or
whatever you configure)


>
> On Thursday, 4 January 2018 16:11:14 UTC+11, Steven Foster wrote:
>>
>> I have been using the multibranch project's tag build functionality to
>> achieve this. An environment variable is provided when running a tag build,
>> so the pipeline can have a stage which checks for the presence of that
>> variable.
>> Using multibranch to build a single branch seems a little counter
>> intuitive, but the branch api provides convenience in other areas and
>> allows other branches to be added later with ease.
>>
>> The release process becomes something like:
>> Push a tag -> Multibranch project detects tag and creates a job for that
>> tag -> Manually run that tag job to perform a release (somewhat like a
>> button on a build but a little more clear and structured imo)
>>
>>
> --
> 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/13b94c91-3864-4a1e-acd8-f450bfb87078%40googlegroups.com
> 
> .
> 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 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/CA%2BnPnMxYg%3D3ENSuTHTenARv%3D3JkZyQ1R3O8vw67Vd0HGmHjuZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.