Re: jenkins and slack

['Stuart Cracraft' via Jenkins Users]

Thanks. Will do. 

> On Jun 24, 2019, at 5:02 PM, Andy Coates  wrote:
> 
>> On Tuesday, 25 June 2019 09:09:58 UTC+10, Stuart Cracraft wrote:
>> 
>> There is also the groovy/build-pipeline business of slackSend but that's 
>> pipeline.
>> 
>> As everything in jenkins slack plugin is project/build oriented, I see no 
>> "send a slack message every hour to a given channel", to ensure
>> that there is connectivity.
> 
> Why not just create a job and use a build/run schedule?  (with pipeline it's 
> easy to setup, or just use freestyle if you're not familiar).
> 
> https://jenkins.io/doc/book/pipeline/syntax/#triggers
> 
> The job could just have one step that uses the slack notify and you can 
> configure it run however often you please.
> 
> Andy.
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/jenkinsci-users/wkvAiDVT6YQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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/053dd58c-3d9b-49ea-aab1-1bd35dcc798d%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/3E3D86B8-DBA2-4BED-B3EF-217785AE42D5%40me.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins and slack

[Andy Coates]

On Tuesday, 25 June 2019 09:09:58 UTC+10, Stuart Cracraft wrote:
>
>
> There is also the groovy/build-pipeline business of slackSend but that's 
> pipeline.
>
> As everything in jenkins slack plugin is project/build oriented, I see no 
> "send a slack message every hour to a given channel", to ensure
> that there is connectivity.
>

Why not just create a job and use a build/run schedule?  (with pipeline 
it's easy to setup, or just use freestyle if you're not familiar).

https://jenkins.io/doc/book/pipeline/syntax/#triggers

The job could just have one step that uses the slack notify and you can 
configure it run however often you please.

Andy.

-- 
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/053dd58c-3d9b-49ea-aab1-1bd35dcc798d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jenkins and slack

[Stuart Cracraft]

Hi,

I use jenkins and slack and have jenkins correctly sending builds to slack 
(non-pipeline, traditional project).

But sometimes we go for very long times between builds.

So I would like the best practice, with the least alteration (or no 
alteration) to my jenkins server.

So far I have seen a python program requiring pip and python library 
slacker and base64, etc. which changes the server too much.

There is also the groovy/build-pipeline business of slackSend but that's 
pipeline.

As everything in jenkins slack plugin is project/build oriented, I see no 
"send a slack message every hour to a given channel", to ensure
that there is connectivity.

Anyone know if there is something other than the above approach?

Thanks.

--Stuart

-- 
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/adf6d3e4-bf1b-4b57-a030-16e3c457e0aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: Multiproject repository

[Pierre Lupien]

This is an old thread I have a solution that worked for me so I thought I'd 
share.  I am no Jenkins expert so I don't know if this is some kind of 
horrible hack, but basically the idea is to ignore the scm object provided 
by the multi-branch pipeline and setup your own.

I use this for a multi-project Java repository and so far it is working 
well.  I created one Jenkins multi-branch pipeline for each of my Java 
sub-project and they all point to the same Jenkinsfile.

This solution has 2 restrictions:
  - The Git URL must be in the Jenkinsfile.
  - The name of the Jenkins multi-branch pipeline project must be the same 
as the name of the sub-project directory.

Example Jenkinsfile:

// Git URL 
def projectGitURL = 'https:///' 
def projectGitCredsName = '' 
 
//applicationName is derived from Jenkins project name (which is second to 
last in the full name) 
def jobPathElements = currentBuild.fullProjectName.split('/') 
def applicationName = jobPathElements[jobPathElements.length >= 2? 
jobPathElements.length-2: jobPathElements.length-1] 
 
// Project's POM file 
def projectPom = applicationName + '/pom.xml' 
 
// Git Branch/Paths to check for changes 
def projectGitWatchedPathRegex = applicationName + '/.*' 
def projectGitWatchedBranches = [[name: '*/' + env.BRANCH_NAME]] 
def projectReleaseBranchRegex = 'master.*'  

...
pipeline { 
 
agent any; 

...
options { 
buildDiscarder logRotator(artifactNumToKeepStr: '5', numToKeepStr: 
'5') 
disableConcurrentBuilds() 
timestamps() 
skipDefaultCheckout() //skip SCM pull before first stage, we'll do 
our own 
} 

...
stages { 
stage('Checkout from SCM') { 
steps { 
//We won't be using the simple "checkout(scm)" here because 
we want 
//to setup our own path restriction and that is not 
supported 
//by the default multibranch git provider. 
//checkout(scm) 
 
checkout([$class: 'GitSCM',  
userRemoteConfigs: [[credentialsId: projectGitCredsName, 
 
 url: projectGitURL]], 
branches: projectGitWatchedBranches,  
extensions: [[$class: 'PathRestriction', //SCM poll 
filter by path 
excludedRegions: '',  
includedRegions: 
projectGitWatchedPathRegex], 
 [$class: 'LocalBranch',  
localBranch: '**']]]) 
} 
} 

...
stage('Build and Deploy') { 
steps { 
withMaven(maven: 'maven') { 
sh(script: "mvn --batch-mode --errors 
--update-snapshots -Dbuild_number=${BUILD_NUMBER} -f ${applicationName} 
clean deploy") 
} 
} 
} 
...
}
}



-- 
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/631f22fa-5dd6-46ca-b3f2-ecb643e74bba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Difficult to softcode credential references in property scripts

[David Karr]

I'm working with someone who has defined a Jenkins job that does some 
sophisticated work to set up choice properties.  Each property has a small 
script that computes the possible values.  It attempts to get the values 
from the same git repository that the Jenkinsfile resides in.  
Unfortunately, it appears that the available context in a property script 
is pretty weak.  We can't use "withCredentials", because this isn't 
executing in the context of a build job.

Someone suggested having a separate job get these credentials and then 
write them to a file using "archiveArtifacts", and then somehow read the 
contents of that artifact in the property script.  Does that seem like it 
would be even possible?

-- 
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/714a-92bd-4465-8253-48ebd6579f24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Declarative pipeline: Somewhat more advanced deployment logic

[Ivan Fernandez Calvo]

about to use declarative or scripted, I'd said declarative, it'd force you 
to be cleaner and use pipeline code only to define the pipeline not to make 
your build process, in any case, you can use script blocks on Declarative 
pipeline by using the script step (
https://jenkins.io/doc/book/pipeline/syntax/#script) or by defining 
functions or by using shared libraries (
https://jenkins.io/doc/book/pipeline/shared-libraries/).
about the buildingTag, you can use the when statement 
https://jenkins.io/doc/book/pipeline/syntax/#when

https://jenkins.io/doc/book/pipeline/syntax/

-- 
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/c10b1d9c-289f-4948-8092-15f73e129b4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Long delays in multibranch pipelines "Seen X remote branches"

[David Resnick]

Hi,

We often see long delays during multibranch pipeline builds. 

The job shows

Branch indexing
 > git rev-parse --is-inside-work-tree # timeout=10
Setting origin to g...@github.com:foo/bar.git
 > git config remote.origin.url g...@github.com:foo/bar.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > git --version # timeout=10
using GIT_SSH to set credentials
 > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
Seen branch in repository origin/branch-1
Seen branch in repository origin/branch-2
...
Seen branch in repository origin/branch-559
Seen 559 remote branches

There is then a long delay before it shows 

Obtained proj/Jenkinsfile from 61b5c00e80eaf221bb354e07ccfb3f56cb657484

Looking at the processes on the Jenkins master machine, it seems that there 
are just a couple of git processes (at 100% CPU) trying to checkout the 
different branches and get the appropriate Jenkinsfile.

Does anyone know why takes so long (the master has more than enough 
resources)? Or how I can improve this?

I'm using Jenkins ver. 2.89.4

Thanks,
David

-- 
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/5e68765d-b6b9-472d-9de5-b0a80e161873%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: safe-shutdown does not wait for jobs to finish

[Remo Meier]

Aha, thx a lot! I would not have connected those two things. Maybe the 
shutdown-related pages could bel linked with the optimization page. In our 
case we just have a single Jenkins server without agents, so Jenkins will 
kill the jobs after all. But we may can work around it.

Regards Remo

-- 
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/622255af-9d70-4ba2-acba-3c0d4bdd1541%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: safe-shutdown does not wait for jobs to finish

[Mark Waite]

It is intentional that pipeline jobs do not prevent a shutdown of the
Jenkins server.  They are allowed to continue running on the agent hosting
them even while the Jenkins server restarts.  They are "durable" across
Jenkins server restarts.

When the Jenkins server restarts and the agent is reconnected, the status
of the job is communicated to the Jenkins server.

Refer to https://jenkins.io/doc/book/pipeline/scaling-pipeline/

for
more details on pipeline durability settings and the compromises that you
may choose to make between pipeline durability and pipeline performance.

On Mon, Jun 24, 2019 at 6:45 AM Remo Meier  wrote:

> Hi
>
> We make use of:
>
> command: ["java", "-jar", "/var/jenkins_home/war/WEB-INF/jenkins-cli.jar", 
> "-s", "http://127.0.0.1:8080/scheduler";, "safe-shutdown"]
>
>
> To shutdown a Jenkins server. According to the documentation
> https://support.cloudbees.com/hc/en-us/articles/216118748-How-to-Start-Stop-or-Restart-your-Instance-
> and
> https://stackoverflow.com/questions/10238604/how-to-shutdown-my-jenkins-safely/13527164
> this should be fine to wait for job completion before shutdown. But the
> command for terminates the server immediately and restarts the Job after.
> Our job is a regular flow/pipeline definition:
>
> 
> 
> 
> 
> false
> 
> 
> 
> 
> 
> 0 3 * * *
> 
> 
> 
> 
> 
>  plugin="workflow-cps@2.55">
> 
> node {
> stage('Run') {
> sh '''
> #!/usr/bin/env bash
>
>
> exec kubectl run ...
>
> ...
> '''
> }
> }
> 
> true
> 
> 
> false
> 
>
>
> It shows log entries like:
>
> Ready to run at Mon Jun 24 11:46:22 GMT 2019
> Resuming build at Mon Jun 24 11:50:56 GMT 2019 after Jenkins restart
> Waiting to resume part of demo-import #71: Finished waiting
>
>
> In this case it runs some shell scripts. The documentation does not
> mention the use of termination signals or anything that would maybe stop
> the job?
>
> Thank you, Regards Remo
>
> --
> 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/c3fece50-f8b2-41e1-a2f3-9f5a7ce1bb38%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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

safe-shutdown does not wait for jobs to finish

[Remo Meier]

Hi

We make use of:

command: ["java", "-jar", "/var/jenkins_home/war/WEB-INF/jenkins-cli.jar", 
"-s", "http://127.0.0.1:8080/scheduler";, "safe-shutdown"]


To shutdown a Jenkins server. According to the documentation 
https://support.cloudbees.com/hc/en-us/articles/216118748-How-to-Start-Stop-or-Restart-your-Instance-
  
and 
https://stackoverflow.com/questions/10238604/how-to-shutdown-my-jenkins-safely/13527164
 
this should be fine to wait for job completion before shutdown. But the 
command for terminates the server immediately and restarts the Job after. 
Our job is a regular flow/pipeline definition:





false





0 3 * * *







node {
stage('Run') {
sh '''
#!/usr/bin/env bash

 
exec kubectl run ...

...
'''
}
}

true


false



It shows log entries like:

Ready to run at Mon Jun 24 11:46:22 GMT 2019
Resuming build at Mon Jun 24 11:50:56 GMT 2019 after Jenkins restart
Waiting to resume part of demo-import #71: Finished waiting


In this case it runs some shell scripts. The documentation does not mention 
the use of termination signals or anything that would maybe stop the job?

Thank you, Regards Remo

-- 
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/c3fece50-f8b2-41e1-a2f3-9f5a7ce1bb38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.