[JIRA] (JENKINS-21099) Don't give useless build time estimates by considering failed builds' durations

2020-04-23 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-21099  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Don't give useless build time estimates by considering failed builds' durations   
 

  
 
 
 
 

 
 +1 for this. Also related, perhaps needs a separate issue. For pipeline builds, I would like to see estimates take into account what stage the build is in. We use a "queue" stage at the start of a build for the time spent waiting for a machine. Queue time can range from seconds to hours and that really throws off the estimates for the remainder of the build. Even though the remaining stages are generally consistent for execution times.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-60021) Scan all builds only re-scans failed builds

2020-02-21 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-60021  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Scan all builds only re-scans failed builds   
 

  
 
 
 
 

 
 Sorry for the question here, where do I find the "Scan all builds" button?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-56531) org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null

2019-12-02 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau closed an issue as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-56531  
 
 
  org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null   
 

  
 
 
 
 

 
Change By: 
 Adam Brousseau  
 
 
Status: 
 Open Closed  
 
 
Resolution: 
 Fixed  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-59895) SCM Checkout retries aborted/interrupted build

2019-10-22 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59895  
 
 
  SCM Checkout retries aborted/interrupted build   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 workflow-cps-plugin  
 
 
Created: 
 2019-10-22 19:59  
 
 
Environment: 
 Jenkins 2.10.1   
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Adam Brousseau  
 

  
 
 
 
 

 
 In a pipeline scm checkout, when using non-lightweight checkout, and the global setting "SCM checkout retry count" is a non-zero value, if a build is performing the initial scm clone and the build is cancelled, the retry will relaunch the scm step as per the retry count. I believe this is contrary to the pipeline retry step which will not retry if a build is cancelled. Found this  https://issues.jenkins-ci.org/browse/JENKINS-39194 and https://github.com/jenkinsci/workflow-cps-plugin/pull/147  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
  

[JIRA] (JENKINS-58390) Docker cloud provisioning 1 slave behind

2019-07-29 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-58390  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Docker cloud provisioning 1 slave behind   
 

  
 
 
 
 

 
 As a workaround, we wrote a separate job that runs after the first job has started, and asks for the same container, then times out.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





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


[JIRA] (JENKINS-58390) Docker cloud provisioning 1 slave behind

2019-07-08 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58390  
 
 
  Docker cloud provisioning 1 slave behind   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Nicolas De Loof  
 
 
Components: 
 docker-plugin  
 
 
Created: 
 2019-07-08 18:08  
 
 
Environment: 
 Jenkins 2.164.3  Docker Plugin 1.1.6  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Adam Brousseau  
 

  
 
 
 
 

 
 We have multiple docker cloud hosts setup with multiple templates per host. Some templates are duplicated across clouds, some are unique to a host. I'm not sure yet how to reproduce or get into this state but I can help diagnose on my end with some guidance.  After a period of time successfully provisioning docker agents, we'll get into a state whereby a job is waiting for a container that never comes. If another job is launched which requests a container which happens to match the criteria of the already queued job, the new container will provision and the first job will take it. This leaves the new job waiting until another job requests a matching container. If another job requests a unique container, it too will wait indefinitely until another job requests the same container. Restarting master resolves the issue temporarily (few days). I noticed in the logs once we have hit this state and I launch a job requesting container-A the log shows the following and the container will not start until a second job requests a container. 

 

Jul 08, 2019 12:05:24 PM INFO io.jenkins.docker.DockerTransientNode$1 println
Disconnected computer for node 'docker-003jf7ab2t864'.
Jul 08, 2019 12:05:24 PM INFO hudson.remoting.Request$2 run
Failed to send back a reply to the request 

[JIRA] (JENKINS-56531) org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null

2019-06-10 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau edited a comment on  JENKINS-56531  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null   
 

  
 
 
 
 

 
 I think this is resolved in 3.2.4 via  [  HAP-1167 |https://www.jfrog.com/jira/browse/HAP-1167]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.198140.1552421627000.24622.1560185400095%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-56531) org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null

2019-06-10 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-56531  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null   
 

  
 
 
 
 

 
 I think this is resolved in 3.2.4 via [HAP-1167|https://www.jfrog.com/jira/browse/HAP-1167]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.198140.1552421627000.24618.1560185340216%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-56531) org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null

2019-06-10 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau edited a comment on  JENKINS-56531  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null   
 

  
 
 
 
 

 
 I think this is resolved in 3.2.4 via  [[ HAP-1167 |https://www.jfrog.com/jira/browse/HAP-1167]|[https://www.jfrog.com/jira/browse/HAP-1167]]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.198140.1552421627000.24620.1560185340245%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54735) Pipeline retry clause: optionally delay between retries

2019-03-25 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-54735  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Pipeline retry clause: optionally delay between retries   
 

  
 
 
 
 

 
 in response to the workaround, what about this...? 

 

ret = false
retry(5) {
    if (ret) {
    sleep time: 30, unit: 'SECONDS'
} else {
ret = true
}
sh 'some-failure-prone-script'     
    }
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-56512) Add function for Artifactory Version to org.jfrog.hudson.pipeline.common.types.ArtifactoryServer

2019-03-13 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-56512  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add function for Artifactory Version to org.jfrog.hudson.pipeline.common.types.ArtifactoryServer   
 

  
 
 
 
 

 
 The first few times I tried to publish build info on my OSS server it failed. A few days later it appears to work fine. I still cannot see build or artifact properties on the UI and the retention doesn't seem to work but at least now its allowing me to publish it without failing. I no longer require this feature so feel free to close.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-56531) org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null

2019-03-12 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-56531  
 
 
  org.jfrog.hudson.pipeline.common.types.ArtifactoryServer getCredentialsId() returns null   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Eyal Ben Moshe  
 
 
Components: 
 artifactory-plugin  
 
 
Created: 
 2019-03-12 20:13  
 
 
Environment: 
 Plugin version 3.2.1  Jenkins version 2.150.3  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Adam Brousseau  
 

  
 
 
 
 

 
 As a workaround for https://issues.jenkins-ci.org/browse/JENKINS-56512 I am attempting to retrieve the stored credentials for the Artifactory server. After I create the server I call the getCredentialsId() method but it always returns null. Other methods like getUrl() seem to work fine. I have tried on 2 different servers, one PRO and one OSS.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

   

[JIRA] (JENKINS-56512) Add function for Artifactory Version to org.jfrog.hudson.pipeline.common.types.ArtifactoryServer

2019-03-11 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-56512  
 
 
  Add function for Artifactory Version to org.jfrog.hudson.pipeline.common.types.ArtifactoryServer   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Eyal Ben Moshe  
 
 
Components: 
 artifactory-plugin  
 
 
Created: 
 2019-03-11 21:51  
 
 
Environment: 
 Artifacotry plugin 3.2.1  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Adam Brousseau  
 

  
 
 
 
 

 
 Different Artifactory versions (Licence) support different features. Particularly, I have a "Pro" server which supports buildInfo and an OSS server which does not. I want to be able to determine which server version I am uploading to in my pipeline in order to determine whether or not I can publish buildInfo. I could not find a method on org.jfrog.hudson.pipeline.common.types.ArtifactoryServer. I did see isArtifactoryPro() on org.jfrog.hudson.ArtifactoryServer but I couldn't find how to use it.   As a workaround, I'm currently calling the Artifactory API GET /api/system/version which returns a license field of either 'Artifactory OSS' or a long license string.  
 

  
 
 
 
 

 
 
 

 
 
 Add 

[JIRA] (JENKINS-45439) Can't use "props" in spec file with artifactory-plugin 2.12

2019-02-08 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-45439  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Can't use "props" in spec file with artifactory-plugin 2.12   
 

  
 
 
 
 

 
 Can this be closed?  I came across this issue when looking for Doc on how to attach properties to artifacts in Jenkins pipeline code. Neither https://www.jfrog.com/confluence/display/RTF5X/Working+With+Pipeline+Jobs+in+Jenkins nor https://www.jfrog.com/confluence/display/RTF/Properties had the info I needed. I added the props field to my uploadSpec and it appears to be working. Have not tried in a downloadSpec, which is what the issue may be referring to. Plugin version 3.0.0 Jenkins 2.150.1  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54680) Compressed build logs not rendering with update to workflow-job plugin >= 2.26

2018-11-16 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-54680  
 
 
  Compressed build logs not rendering with update to workflow-job plugin >= 2.26   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Daniel Beck  
 
 
Components: 
 compress-build-log-plugin  
 
 
Created: 
 2018-11-16 21:09  
 
 
Environment: 
 Jenkins 2.138.3  Compress log plugin 1.2  Pipeline: job plugin 2.29  
 
 
Labels: 
 regression  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Adam Brousseau  
 

  
 
 
 
 

 
 We started using the compress build log plugin right before the revamp to how the pipeline logs were stored in JEP-210 I believe. Before we upgraded the Pipeline: job plugin we had the main log being compressed, and able to be rendered on the console UI. Once we upgraded from 2.25 to 2.29 the console is no longer rendered on the UI. Not sure if this issue is with the compress plugin or the pipeline job plugin.  
 

  
 
 
 
 

 
 
 

 
 
 Add 

[JIRA] (JENKINS-54612) Reference repo not used for Git clones on Windows SSH agents

2018-11-13 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-54612  
 
 
  Reference repo not used for Git clones on Windows SSH agents   
 

  
 
 
 
 

 
Change By: 
 Adam Brousseau  
 

  
 
 
 
 

 
 We use a reference repo on all our agents to speed up our clones. This seems to work on all agents we have except for our Windows nodes. I first noticed that the fetch times were slower on the Windows nodes. I then confirmed by checking the size of the .git folder on each machine after the clone. All non-windows nodes were 11MB whereas the .git folder on Windows was 1.9GB.Our Windows agents are connected over ssh (Cygwin). The Remote Root is on C:\ (windows style path) and the reference repository is also on C:\. We use the Checkout/SCM pipeline step in order to take advantage of extra options not available using the Git step.This is a simplified snippet of what we use I pulled from the Syntax generator.{code:none}checkout([ $class: 'GitSCM', branches: [[name: '$BRANCH']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CloneOption', depth: 0, noTags: false, reference: '$REFERENCE_REPO', shallow: false]], gitTool: 'Default', submoduleCfg: [], userRemoteConfigs: [[url: '$REPO']]]){code}The console output tries to convince me it's using the reference repo but it appears it isn't (3:20 to fetch).{code:none}00:41:39.279 Cloning the remote Git repository00:41:39.355 Cloning repository https://github.com/***/***.git00:41:39.368  > git init C:\Users\jenkins\workspace\Build # timeout=1000:41:39.574 Using reference repository: C:\repo_cache00:41:39.574 Fetching upstream changes from https://github.com/***/***.git00:41:39.574  > git --version # timeout=1000:41:39.606  > git fetch --tags --progress https://github.com/***/***.git +refs/heads/*:refs/remotes/origin/* # timeout=3000:45:00.369  > git config remote.origin.url https://github.com/***/***.git # timeout=1000:45:00.431  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=1000:45:00.603  > git config remote.origin.url https://github.com/***/***.git # timeout=1000:45:00.775 Fetching upstream changes from https://github.com/***/***.git00:45:00.776  > git fetch --tags --progress https://github.com/***/***.git +refs/heads/*:refs/remotes/origin/* # timeout=3000:45:02.416  > git rev-parse "origin/master^{commit}" # timeout=1000:45:02.448 Checking out Revision *** (origin/master)00:45:02.588  > git config core.sparsecheckout # timeout=1000:45:02.619  > git checkout -f *** # timeout=3000:46:45.479 Commit message: "Merge pull request #63 from ***/***"{code}I've tried various things like using Windows Git to populate the reference repo, using a Jenkins git step to populate the repo, using cygwin style paths for both the ref repo location and/or the remote root dir for the agent. Not sure what else I can try but I assume its going to be something related to windows vs cygwin vs path styles vs line-endings.  Edit: I can use an sh step to clone using the ref repo successfully.  
 

[JIRA] (JENKINS-54612) Reference repo not used for Git clones on Windows SSH agents

2018-11-13 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-54612  
 
 
  Reference repo not used for Git clones on Windows SSH agents   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Mark Waite  
 
 
Components: 
 git-plugin  
 
 
Created: 
 2018-11-13 20:15  
 
 
Environment: 
 Jenkins 2.138.2  Git Plugin 3.9.1  Windows 2012r2  Cygwin Git 2.17.0  
 
 
Labels: 
 windows git  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Adam Brousseau  
 

  
 
 
 
 

 
 We use a reference repo on all our agents to speed up our clones. This seems to work on all agents we have except for our Windows nodes. I first noticed that the fetch times were slower on the Windows nodes. I then confirmed by checking the size of the .git folder on each machine after the clone. All non-windows nodes were 11MB whereas the .git folder on Windows was 1.9GB. Our Windows agents are connected over ssh (Cygwin). The Remote Root is on C:\ (windows style path) and the reference repository is also on C:\. We use the Checkout/SCM pipeline step in order to take advantage of extra options not available using the Git step. This is a simplified snippet of what we use I pulled from the Syntax generator. 

 

checkout([
 $class: 'GitSCM',
 branches: [[name: '$BRANCH']],
 doGenerateSubmoduleConfigurations: false,
 extensions: [[$class: 'CloneOption',
 depth: 0,
 noTags: false,
 reference: '$REFERENCE_REPO',
 shallow: false]],
 gitTool: 'Default',
 submoduleCfg: [],
 

[JIRA] (JENKINS-49179) Add queue duration for how long stages are wait for a build node to become available

2018-11-08 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-49179  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add queue duration for how long stages are wait for a build node to become available   
 

  
 
 
 
 

 
 Also would like to see this. As a workaround we have added a "Queue" stage around our node block (which basically wraps the entire build). The side effect is that it breaks the Blue Ocean view by only displaying the Queue stage for the build. The classic view still shows all the stages.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54225) Using disableDeferredWipeout within pipeline job results in no deleted workspace

2018-11-01 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau edited a comment on  JENKINS-54225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using disableDeferredWipeout within pipeline job results in no deleted workspace   
 

  
 
 
 
 

 
 Also seeing this issue. Seems to leave behind the workspace (and .git folder) but the Git repository is "corrupt" so the next build will fail.{quote} fatal:  Running shell script+ git clean -ffxd fatal: Not a git repository (or any parent up to mount point /home/jenkins)Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).{quote}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54225) Using disableDeferredWipeout within pipeline job results in no deleted workspace

2018-11-01 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-54225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using disableDeferredWipeout within pipeline job results in no deleted workspace   
 

  
 
 
 
 

 
 Also seeing this issue. Seems to leave behind the workspace (and .git folder) but the Git repository is "corrupt" so the next build will fail. {{fatal: Running shell script + git clean -ffxd Not a git repository (or any parent up to mount point /home/jenkins) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).}}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54225) Using disableDeferredWipeout within pipeline job results in no deleted workspace

2018-11-01 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau edited a comment on  JENKINS-54225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using disableDeferredWipeout within pipeline job results in no deleted workspace   
 

  
 
 
 
 

 
 Also seeing this issue. Seems to leave behind the workspace (and .git folder) but the Git repository is "corrupt" so the next build will fail.{ { quote} fatal: Running shell script+ git clean -ffxdNot a git repository (or any parent up to mount point /home/jenkins)Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). {quote } }  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-24824) Asynchronous cleanup not removing renamed workspace directories on slaves

2018-08-21 Thread adam.broussea...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Adam Brousseau commented on  JENKINS-24824  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Asynchronous cleanup not removing renamed workspace directories on slaves   
 

  
 
 
 
 

 
 We also have this issue but only on Windows slaves (connected through Cygwin SSH).  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.