I want to implement the following notifications in my declarative pipeline:
(regression) → Job has started to fail!
(failure) → Job is still failing.
(fixed) → Job has resumed.
It doesn't seem like post's conditions can do this. Instead, when a build fails, both failure and regression trigger. There's a changed condition, but I think what this task wants is unchanged { failure }, which doesn't exist.
post {
regression {
slackSend message: 'Job has started to fail!'
}
failure {
slackSend message: 'Job is still failing.'
}
fixed {
slackSend message: 'Job has resumed.'
} // no need for 'success' as we don't want a notification while it's working
}
The above config will send the following notifications, if the job previously succeeded:
(job fails)
Job has started to fail!
Job is still failing.
(job fails)
Job is still failing.
(job succeeds)
Job has resumed.
There's that extra "Job is still failing" message when the job first starts to fail. Is there a way around this using post conditions?
Alternatively, how can I implement this behaviour another way? I've made a pass at post { always { // decide which message is appropriate } }, but haven't figured out how to identify the previous build's status.
Related
Specifically this deals with how the upstream subscription is cancelled when an error occurs in the mapping operation.
From my testing it appears that thrown errors cancel the upstream subscription, where as propagated errors like those produced by Flux.error do not cancel the upstream subscription. When the upstream subscription is never cancelled the error is never propagated downstream and any error handlers are never triggered either, additionally no termination signal is propagated and results in a hanging flux.
I would think that a thrown error and a propagated error would be handled identically.
Is there a fundamental issue or concern I am not aware of when handling propagated errors from flatMapDelayError?
Below is also a simple example illustrating the problem on release train 2022.0.2. Thanks in advance for any help.
Flux<Object> thrownFlux = Flux.just(0, 1, 2, 3).log()
.flatMapDelayError(integer -> {
throw new RuntimeException(); // Cancels upstream subscription
}, 1, 1);
// Completes as expected
StepVerifier.create(thrownFlux)
.expectError()
.verify();
Flux<Object> propagatedFlux = Flux.just(0, 1, 2, 3).log()
.flatMapDelayError(integer -> {
return Flux.error(new RuntimeException()); // Does not cancel upstream subscription
}, 1, 1);
// Never completes
StepVerifier.create(propagatedFlux)
.expectError()
.verify();
I am working on a idea where I need to send a mail if certain conditions are met to inform the Team. The condition may continue for 30 minutes or 1 hour. But I do not want to flood the mailbox with continuous mails. As we will be scheduling the job every minute, the mails will be sent every minute. So we are trying to disable the pipeline for specific time once the mail is sent and enable it again automatically.
Thanks in advance.
I tried to put the job on sleep, but as it was scheduled to build every minute, the new jobs were initiated every minute and mails were sent.
//This is scheduled to build every minute * * * * *
`pipeline{
agent {
stages {
stage (check condition){
when
// check conditions
// if everything working fine - ok
else
// send email - this will be sent every minute. I want to avoid mailbox malfunction and just report the issue.
}
}
}
}`
Please help me with the solutions.
I used alternative: Sending below URL in the mail.
To disable the pipeline - $BUILDURL/disable to disable the pipeline.
The recipient will have to click on the link and disable the pipeline himself. This also means that the mail is acknowledged and has not gone unnoticed.
To enable the pipeline - $BUILDURL/enable. Once the issue is fixed, the recipient can enable the pipeline..
Edit:
Adding pipeline sample for reference.
pipeline{
agent any
stages {
stage ('Checkout') {
// checkout git repo
}
stage ('run job') {
// script to run the job
}
stage('email') {
when {
expression(condition to be satisfied)
}
steps {
send email
body - $Build_Url/disable to disable the job.
$Build_Url/enable to enable the job.
}
}
}
I am using the slack notification plugin with Jenkins and I already set the notification settings in Jenkinsfile. I want to preview the job description on the Slack channel, and I am setting it on Jenkinsfile like this: Info: ${currentBuild.description} but I am getting on the slack channel Info: NUll although I already putting a description on the job.
Probably you are not setting the description properly. Log the description before the slack call and check whether you are getting the description correctly. Something like the one below works for me.
currentBuild.description = "This is a Description"
pipeline {
agent any
stages {
stage('Test') {
steps {
echo "${currentBuild.description}"
summary = "The Job ${currentBuild.description} worked"
slackSend(channel: channel, color: colorCode, message: summary)
}
}
}
}
I am seeing an issue that has my requests being popped off a workbox.backgroundSync.Queue queue after 3 unsuccessful requests. I'm also unable to find solid documentation about the expected behavior after 3 unsuccessful sync requests when the lastChance flag has been set to true.
What is supposed to happen next? Is the request supposed to remain in the queue and what can be done to eventually trigger a replay?
The request will remain in the queue until maxRetentionTime is reached.
see maxRetentionTime
If the flag lastChance is set to true, automatic retries will stop but you can trigger a replayRequests by sending a message to the service worker like:
self.addEventListener('message', (event) => {
if (event.data.type === 'replayQueue') {
myQueue.replayRequests();
}
});
I have a Pipeline script written where it triggers a Job A and waits for the confirmation from user to proceed with the next job B. I have an email notification written below which sends email to check the console output in Jenkins and approve or reject
My requirement is would it be possible to send two links in the email one to approve and the other to reject? Would it need a dynamic session ID or Job ID parameter posted in the URL
Script :
mail (to: 'XXXXXXX#.com',
subject: "Job '${env.JOB_BASE_NAME}' (${env.BUILD_NUMBER}) is waiting for input",
body: "Please go to console output of ${env.BUILD_URL} to approve or Reject.");
def userInput = input(id: 'userInput', message: 'Job A Failed do you want to build Job B?', ok: 'Yes')