Re: ‘Discard Old Items’ not removing all directories for multi-branch pipeline

[James Robson]

Looking at the timestamps and the logs, most but not all of these
'workflow-fallback' directories get created after reapplying Configuration
as Code not after a restart and it doesn't look like the builds are being
interrupted. Though for some reason there's a large delay between the
original build and the attempt at restarting it. For example one build I
looked at had succeeded at 2023-07-06 13:50 GMT, but the attempt to restart
came on 2023-07-14 despite the configuration as code being applied every
day. I also don't see any log messages that refer to one of the affected
builds between it's completion and the attempt to restart it so I can't see
what changed to trigger the restart attempt.

We are also using 'Max survivability' as the default and don't override
this anywhere.



On Tue, 18 Jul 2023 at 10:59, 'jn...@cloudbees.com' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Looking at the code it appears as though the pipeline was running but when
> Jenkins was restarted it could not find its data. (
> https://github.com/jenkinsci/workflow-cps-plugin/blob/a6ac2775ac1767f68ddabcff14364235a61e8bdf/plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowExecution.java#L659
> )
>
> Perhaps you had some dirty shutdown of Jenkins and are using a non
> survivable performace strategy rather than  MAX_SURVIVABILITY   ?
> https://www.jenkins.io/doc/book/pipeline/scaling-pipeline/
>
> /James
>
>
>
> On Monday, July 10, 2023 at 3:04:21 PM UTC+1 james@secondmind.ai
> wrote:
>
>> I have a multi-branch pipeline with ‘Discard old Items’ set up to get rid
>> of old PRs, but I’ve noticed that the directories aren’t all being removed
>> completely from the controller’s filesystem. These directories have no
>> confg.xml and they disappear from the UI but it leads to warning messages
>> in the log saying the config.xml couldn’t be found for the PR job. They all
>> seem to have the remnants of a single build that wasn’t removed correctly,
>> which includes a directory named ‘workflow-fallback’. What remains looks
>> like:
>>
>>
>> $JENKINS_HOME/jobs//branches//builds//
>>
>> build.xml
>>
>> workflow-fallback/
>>
>>  .xml
>>
>>
>> This workflow-fallback directory doesn’t currently exist for any build of
>> a PR that hasn’t been removed, so I’m unsure where it come from. Given the
>> time stamps of these directories this was happening over a wide span of
>> versions up to and including 2.401.2.
>>
>>
>> Can anyone explain what’s happening and is there anything I can do to
>> prevent this?
>>
> --
> 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/Kf5_PUHFBBM/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/91073651-8d0d-4260-9de2-fac469cbd963n%40googlegroups.com
> 
> .
>

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

Jenkins pipeline jobs being triggered by github webhooks from wrong repository

[James Robson]

 

I have 1 code repo that should be triggering jobs, and a separate repo for 
a jenkins pipeline library. There are 2 jenkins jobs that use the ‘GitHub 
hook trigger for GITScm polling’ build trigger, both are pipeline jobs 
using the ‘Pipeline script from SCM’ with the repository configured to 
point to the code repo and the ‘Branches to build’ set to ‘origin/develop’. 
The pipeline library is used inside the pipelines for these jobs.

I would expect these jobs to have their polling triggered by pushes to the 
code repo, however they are only being triggered by pushes to the jenkins 
pipeline library repo. 


Using a log recorder set to get FINEST logs I can see:

Received PushEvent for https://github.com/ 
Considering to poke 
Skipped  because it doesn't have a matching repository.
...
Received PushEvent for https://github.com/
Considering to poke 
Poked 



So something in jenkins seems to think these jobs do not use the code 
repository, but when a scan is triggered I see the following in the 
‘Polling Log’:

Started by event from 192.30.252.97
...
 > git ls-remote -h https://github.com/ # timeout=10


So the repo poll is using the code repo, and the list of commits that show 
up in the ‘Changes’ list are from the code repo.

It seems to be only these 2 jobs that are affected, no other job is being 
triggered by pushes to the pipeline library repo. 



Is there anyway to resolve this, or something I can do to gather more 
information?

-- 
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/c987cc4c-3a40-44e1-9d62-045bf0df47cf%40googlegroups.com.

Re: Git scm fails to check the expected branch when another branch has the target branch name as a suffix

[James Robson]

Using the `checkout` command directly does work. Using that I can specify
'origin/develop' as the branch, and the job is triggering as expected.
Thank You.

On Thu, 16 May 2019 at 15:33, Mark Waite  wrote:

> I don't know if it will help, but you could try replacing the "syntactic
> sugar" command `git` with the `checkout` command.  Pipeline Syntax link on
> the Pipeline pages will help get the correct syntax for the details of the
> checkout command.
>
> On Thu, May 16, 2019 at 7:25 AM James Robson 
> wrote:
>
>>
>>
>> On Wednesday, 15 May 2019 21:28:52 UTC+1, Mark Waite wrote:
>>>
>>>
>>> You can often avoid the guessing by naming the branch precisely, as in
>>> 'origin/develop'.
>>>
>>
>> I attempted to use 'origin/develop' as the branch name, but that causes
>> the job to fail the checkout with "ERROR: Couldn't find any revision to
>> build. Verify the repository and branch configuration for this job". Here's
>> the pipeline I'm testing this with:
>>
>> node('linux') {
>> stage('checkout') {
>> git branch: 'origin/develop', ...
>> }
>> }
>>
>> The last line of output before the failure is a 'git fetch' call which is
>> identical to a run using a branch name of 'develop' which will then
>> checkout successfully.
>>
>> --
>> 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/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> 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/oCeXFei3bZ8/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/CAO49JtG%3D8AgjqrXmZpAHBsKPr6Ep7A-ZV%2BEfTGroc46VZB%3DvVg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtG%3D8AgjqrXmZpAHBsKPr6Ep7A-ZV%2BEfTGroc46VZB%3DvVg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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/CAD10zustnzcfjORTPBaR%2BSVdsvFbpSzzfJZVAhNED98eWhZrwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git scm fails to check the expected branch when another branch has the target branch name as a suffix

[James Robson]

On Wednesday, 15 May 2019 21:28:52 UTC+1, Mark Waite wrote:
>
>
> You can often avoid the guessing by naming the branch precisely, as in 
> 'origin/develop'.
>

I attempted to use 'origin/develop' as the branch name, but that causes the 
job to fail the checkout with "ERROR: Couldn't find any revision to build. 
Verify the repository and branch configuration for this job". Here's the 
pipeline I'm testing this with:

node('linux') {
stage('checkout') {
git branch: 'origin/develop', ...
}
}

The last line of output before the failure is a 'git fetch' call which is 
identical to a run using a branch name of 'develop' which will then 
checkout successfully.

-- 
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/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Git scm fails to check the expected branch when another branch has the target branch name as a suffix

[James Robson]

 

I have a repo with a branch called ‘develop’ and another branch called 
‘kassandra/develop’. I have created a pipeline job that is building on 
‘develop’, set to trigger with the ‘GitHub hook trigger for GITScm 
polling’. 


I expect this job to run only when ‘develop’ is changed, however it is 
running on every commit to the repo. This seems to be because the scm 
polling logic is comparing the last built git hash to the git hash on 
‘kassandra/develop’ (see excerpt of the polling log below). 


Is this behaviour expected? Is there a way to prevent these unwanted runs?


Setup:

Git plugin: 3.9.3

git client plugin: 2.7.6


Git poll log:

[poll] Last Built Revision: Revision 576aad8bdbfbf422d6a98899fafe78cc095ebb81
 (refs/remotes/origin/develop)

[poll] Latest remote head revision on refs/heads/kassandra/develop is: 
a9b4791c65f1ed2f1dc5669501fbeee58323e11e

-- 
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/b3d3df79-0ab9-4fd8-aeb7-1e70bc2e87ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.