Docker plugin running / failing on 'docker login' command

[No-one]

*Scenario:*
We have Docker ephemeral build agents running on the Linux side via the 
Docker Jenkins plugin and the *docker *declarative pipeline syntax. We want 
to mimic that setup on the Windows side.

*Setup:*

   - Docker engine installed in Windows server 2016
   - Everything locally on that host runs as expected (i.e. we can build 
   and run docker images)

Declarative pipeline syntax
pipeline {
agent {
docker {
image 'testimage'
label 'dockerEnabledWindows'
}
}
stages {
stage('Example Build') {
steps {
sh 'hostname'
}
}
}
}

*Problem:*
Despite the exact same declarative pipeline syntax working for Linux slaves 
the Windows slave throws the following error

Running on Windows  in 
C:/jenkins/workspace/Ephemeral Build Agent PoC/Ephemeral Build Agent PoC v6 
Docker enabled Windows slave[Pipeline] { 
[Pipeline]
 withEnv 
[Pipeline]
 { 
[Pipeline]
 withDockerRegistry 
Using
 the existing docker config file.Removing blacklisted property: auths$ docker 
login -u ** -p  https://index.docker.io/v1/
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://registry-1.docker.io/v2/: unauthorized: 
incorrect username or password[Pipeline] // withDockerRegistry[Pipeline] 
}[Pipeline] // withEnv[Pipeline] }[Pipeline] // node[Pipeline] End of 
PipelineERROR: docker login failed
Finished: FAILURE


This was the error the first time so I setup an account with Docker Hub and 
ran the docker login command to cache the login, hoping that would work.

$ docker login -u *** -p  https://index.docker.io/v1/
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://registry-1.docker.io/v2/: unauthorized: 
incorrect username or password


Running that same image locally on the Windows slave host does not produce 
any kind of login requirements.

*Unclear why the **withDockerRegistry **and docker login pieces are even 
being run, they do not get run on the Linux slaves.  If the login command 
is indeed expected what is the correct way to set this up?*

-- 
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/2966419c-c418-4151-bee3-76f51768fd46%40googlegroups.com.

Clean useless files and directories

[Peter Flanagan]

Hello,
working on Jenkins 2.150 hosted on on AWS-EC2, jenkins_home dir is located 
on an EFS

The space of some Jenkins instances increase dramatically due to folder not 
removed automatically by internal Jenkins storage management.

Using multi-branch jobs I got 2 major issues:
- some branches directories stay on file system despite the branches does 
not exist anymore on GUI
- some workspace__* directories stay also on FS despite the build workspace 
always linked to the last waorkspace (without __ suffix)

I'm wondering how to clean these two useless (according to me) directories 
properly.

Thanks very much for your 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/883a238d-6242-4f14-a3b3-7f1a76081ac5%40googlegroups.com.

Re: 'Include' a shared library pipeline in other pipelines in the same shared library

[Kaliyug Antagonist]

*Note:*

   - The workspace(where the clone stag checks out the code and later 
   stages operate) will be used by awsPipeline etc. In other words, the 
   variables and results from the gradleProjectBranchWrapper should be 
   accessible to the awsPipeline etc.
   - There is a post block in the gradleProjectBranchWrapper, the other 
   pipelines may have their own post blocks


On Monday, September 30, 2019 at 9:35:30 AM UTC+2, Kaliyug Antagonist wrote:
>
> I have several microservices which use the same pipeline from a shared 
> library  which is 
> named *jenkins-shared-pipelines* . The Jenkinsfile for a microservice is 
> as follows:
>
> @Library(['jenkins-shared-pipelines']) _
>
> gradleProjectPrPipeline([buildAgent: 'oc-docker-jdk11', 
> disableIntegrationTestStage: true])
>
> In jenkins-shared-pipelines/vars, the gradleProjectBranchWrapper has the 
> following stages:
>
> /**
>  * gradleProjectPrPipeline is a generic pipeline
>  * @param pipelineProperties map used to pass parameters
>  * @return
>  */
> void call(Map pipelineProperties = [:]) {
> .
> .
> .
>
> pipeline {
> agent {
> node {
> label "${pipelineProperties.buildAgent}"
> }
> }
>
> options {
> skipDefaultCheckout true
> timeout(time: 1, unit: 'HOURS')
> buildDiscarder(logRotator(
> numToKeepStr: '5',
> daysToKeepStr: '7',
> artifactNumToKeepStr: '1',
> artifactDaysToKeepStr: '7'
> ))
> }
>
> stages {
> stage('Clone') {
> steps {
> //clone step
> }
> }
> stage('Compile') {
> steps {
> script {
>/*Some custom logic*/
> }
> runGradleTask([task: 'assemble',
>rawArgs: defaultGradleArgs + " 
> -Pcurrent_version=${releaseTag}"
> ])
> }
> }
> stage('Tests') {
> parallel {
> stage('Unit tests') {
> steps {
> //Unit tests
> }
> }
> stage('Integration tests') {
> steps {
> //Integration tests
> }
> }
> }
> }
> stage('Sonar scan') {
> steps {
> //Sonar scanning
> }
> }
> }
>
> post {
>
> unsuccessful {
> script {
> bitbucketHandler.notifyBuildFail([
> displayName: pipelineName,
> displayMessage: "Build ${env.BUILD_ID} failed at 
> ${env.BUILD_TIMESTAMP}."
> ])
> }
> }
> success {
> script {
> bitbucketHandler.notifyBuildSuccess([
> displayName: pipelineName,
> displayMessage: "Build ${env.BUILD_ID} completed at 
> ${env.BUILD_TIMESTAMP}."
> ])
> }
> }
> }
> }
> }
>
> Now, there will be several more pipelines in 
> jenkins-shared-pipelines(under the same vars directory) e.g: awsPipeline, 
> azurePipeline and so on which will also incorporate the deployment stages. 
> These pipelines will require all the stages in the above 
> gradleProjectBranchWrapper and will also add a few of their own stages. 
> Currently, we simply copy-paste these stages in the new pipelines, then, we 
> invoke these new pipelines from the microservices, so for example:
>
> @Library(['jenkins-shared-pipelines']) _
>
> awsPipeline([buildAgent: 'oc-docker-jdk11', disableIntegrationTestStage: 
> true])
>
> I was wondering if there is a way to include the 
> gradleProjectBranchWrapper in the pipelines like awsPipeline, azurePipeline 
> and so on. Note: There is a post block in the gradleProjectBranchWrapper, 
> the other pipelines may have their own post blocks
>

-- 
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/96537356-8976-4ef3-9327-e11b8be37e19%40googlegroups.com.

Re: 'Include' a shared library pipeline in other pipelines in the same shared library

[Kaliyug Antagonist]

On Monday, September 30, 2019 at 9:35:30 AM UTC+2, Kaliyug Antagonist wrote:
>
> I have several microservices which use the same pipeline from a shared 
> library  which is 
> named *jenkins-shared-pipelines* . The Jenkinsfile for a microservice is 
> as follows:
>
> @Library(['jenkins-shared-pipelines']) _
>
> gradleProjectPrPipeline([buildAgent: 'oc-docker-jdk11', 
> disableIntegrationTestStage: true])
>
> In jenkins-shared-pipelines/vars, the gradleProjectBranchWrapper has the 
> following stages:
>
> /**
>  * gradleProjectPrPipeline is a generic pipeline
>  * @param pipelineProperties map used to pass parameters
>  * @return
>  */
> void call(Map pipelineProperties = [:]) {
> .
> .
> .
>
> pipeline {
> agent {
> node {
> label "${pipelineProperties.buildAgent}"
> }
> }
>
> options {
> skipDefaultCheckout true
> timeout(time: 1, unit: 'HOURS')
> buildDiscarder(logRotator(
> numToKeepStr: '5',
> daysToKeepStr: '7',
> artifactNumToKeepStr: '1',
> artifactDaysToKeepStr: '7'
> ))
> }
>
> stages {
> stage('Clone') {
> steps {
> //clone step
> }
> }
> stage('Compile') {
> steps {
> script {
>/*Some custom logic*/
> }
> runGradleTask([task: 'assemble',
>rawArgs: defaultGradleArgs + " 
> -Pcurrent_version=${releaseTag}"
> ])
> }
> }
> stage('Tests') {
> parallel {
> stage('Unit tests') {
> steps {
> //Unit tests
> }
> }
> stage('Integration tests') {
> steps {
> //Integration tests
> }
> }
> }
> }
> stage('Sonar scan') {
> steps {
> //Sonar scanning
> }
> }
> }
>
> post {
>
> unsuccessful {
> script {
> bitbucketHandler.notifyBuildFail([
> displayName: pipelineName,
> displayMessage: "Build ${env.BUILD_ID} failed at 
> ${env.BUILD_TIMESTAMP}."
> ])
> }
> }
> success {
> script {
> bitbucketHandler.notifyBuildSuccess([
> displayName: pipelineName,
> displayMessage: "Build ${env.BUILD_ID} completed at 
> ${env.BUILD_TIMESTAMP}."
> ])
> }
> }
> }
> }
> }
>
> Now, there will be several more pipelines in 
> jenkins-shared-pipelines(under the same vars directory) e.g: awsPipeline, 
> azurePipeline and so on which will also incorporate the deployment stages. 
> These pipelines will require all the stages in the above 
> gradleProjectBranchWrapper and will also add a few of their own stages. 
> Currently, we simply copy-paste these stages in the new pipelines, then, we 
> invoke these new pipelines from the microservices, so for example:
>
> @Library(['jenkins-shared-pipelines']) _
>
> awsPipeline([buildAgent: 'oc-docker-jdk11', disableIntegrationTestStage: 
> true])
>
> I was wondering if there is a way to include the 
> gradleProjectBranchWrapper in the pipelines like awsPipeline, azurePipeline 
> and so on. *Note:*
>
>- The workspace(where the clone stag checks out the code and later 
>stages operate) will be used by awsPipeline etc. In other words, the 
>variables and results from the gradleProjectBranchWrapper should be 
>accessible to the awsPipeline etc.
>- There is a post block in the gradleProjectBranchWrapper, the other 
>pipelines may have their own post blocks
>
>

-- 
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/bdd51911-c3d3-459d-9434-f5d354bbcbf4%40googlegroups.com.

'Include' a shared library pipeline in other pipelines in the same shared library

[Kaliyug Antagonist]

I have several microservices which use the same pipeline from a shared 
library  which is 
named *jenkins-shared-pipelines* . The Jenkinsfile for a microservice is as 
follows:

@Library(['jenkins-shared-pipelines']) _

gradleProjectPrPipeline([buildAgent: 'oc-docker-jdk11', 
disableIntegrationTestStage: true])

In jenkins-shared-pipelines/vars, the gradleProjectBranchWrapper has the 
following stages:

/**
 * gradleProjectPrPipeline is a generic pipeline
 * @param pipelineProperties map used to pass parameters
 * @return
 */
void call(Map pipelineProperties = [:]) {
.
.
.

pipeline {
agent {
node {
label "${pipelineProperties.buildAgent}"
}
}

options {
skipDefaultCheckout true
timeout(time: 1, unit: 'HOURS')
buildDiscarder(logRotator(
numToKeepStr: '5',
daysToKeepStr: '7',
artifactNumToKeepStr: '1',
artifactDaysToKeepStr: '7'
))
}

stages {
stage('Clone') {
steps {
//clone step
}
}
stage('Compile') {
steps {
script {
   /*Some custom logic*/
}
runGradleTask([task: 'assemble',
   rawArgs: defaultGradleArgs + " 
-Pcurrent_version=${releaseTag}"
])
}
}
stage('Tests') {
parallel {
stage('Unit tests') {
steps {
//Unit tests
}
}
stage('Integration tests') {
steps {
//Integration tests
}
}
}
}
stage('Sonar scan') {
steps {
//Sonar scanning
}
}
}

post {

unsuccessful {
script {
bitbucketHandler.notifyBuildFail([
displayName: pipelineName,
displayMessage: "Build ${env.BUILD_ID} failed at 
${env.BUILD_TIMESTAMP}."
])
}
}
success {
script {
bitbucketHandler.notifyBuildSuccess([
displayName: pipelineName,
displayMessage: "Build ${env.BUILD_ID} completed at 
${env.BUILD_TIMESTAMP}."
])
}
}
}
}
}

Now, there will be several more pipelines in jenkins-shared-pipelines(under 
the same vars directory) e.g: awsPipeline, azurePipeline and so on which 
will also incorporate the deployment stages. These pipelines will require 
all the stages in the above gradleProjectBranchWrapper and will also add a 
few of their own stages. Currently, we simply copy-paste these stages in 
the new pipelines, then, we invoke these new pipelines from the 
microservices, so for example:

@Library(['jenkins-shared-pipelines']) _

awsPipeline([buildAgent: 'oc-docker-jdk11', disableIntegrationTestStage: true])

I was wondering if there is a way to include the gradleProjectBranchWrapper 
in the pipelines like awsPipeline, azurePipeline and so on. Note: There is 
a post block in the gradleProjectBranchWrapper, the other pipelines may 
have their own post blocks

-- 
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/834dd15c-a3a0-4f2b-9ad4-9d85767b4dcc%40googlegroups.com.

Subscribe

[Kaliyug Antagonist]

-- 
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/CAAGmGr8j3jp%3DHy2hq6Yneh6JoWf5tMe8_0D%3Dsh%2BEKOZ5wTCfyQ%40mail.gmail.com.