-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Jenkins job for Docker Patch jenkins shared library #3937
Conversation
Signed-off-by: Divya Madala <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #3937 +/- ##
=======================================
Coverage 92.05% 92.06%
=======================================
Files 187 187
Lines 5667 5669 +2
=======================================
+ Hits 5217 5219 +2
Misses 450 450 |
|
||
pipeline { | ||
options { | ||
timeout(time: 7, unit: 'HOURS') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need to be 7 hours?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had some confusion on this. Should 5 hrs be sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it needs to be 5 hours?
Max this activity should be 2 hours isnt it?
The most time you take on this is rebuild, and the rebuild does not need more than 1 hour, if not 30min.
I am confused of how this 5hr number coming from.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure Peter, I'll set that to 2 hrs. A bit confused to see that the docker-build job alone has 5 hrs timeout though the build finishes in less than 5 minutes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes @Divyaasm that is particularly set for the release ci image, as that one takes at least 4 hours.
) | ||
string( | ||
name: 'TAG', | ||
description: "Enter tag of the Product", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if version is the right naming here? Also a small nit:
description: "Enter tag of the Product", | |
description: "Enter version tag of the Product", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a tag Sayali, The input would be 1 or 2 for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add an example in the description to be more clear? Also Does this take care to update latest and stuff? Also how many tags can you pass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes @gaiksaya, the latest is updated only when the corresponding version is latest, currently it's for 2.x. And it's completely taken care by the shared library. Currently TAG and PRODUCT are strings. I can change them to list. So we can pass multiple values at a time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Divyaasm I would suggest use a choice param so people can choose the major version.
You did not give any example in the description and it will naturally confuse people.
booleanParam( | ||
name: 'RE_RELEASE', | ||
defaultValue: true, | ||
description: "Forces to create a Docker-Copy if the Docker Build is successful" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This description is not clear, can you please elaborate or be more clear?
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree ^^
assertThat(getCommandExecutions('build', ''), hasItem('{job=docker-build, propagate=true, wait=true, parameters=[null, null, null]}')) | ||
assertThat(getCommandExecutions('build', ''), hasItem('{job=docker-copy, propagate=true, wait=true, parameters=[null, null, null, null]}')) | ||
assertThat(getCommandExecutions('build', ''), hasItem('{job=docker-scan, propagate=true, wait=true, parameters=[null]}')) | ||
assertThat(getCommandExecutions('build', ''), hasItem('{job=docker-promotion, propagate=true, wait=true, parameters=[null, null, null]}')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are the parameters going null
here? Shouldn't they be actual parameters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why the parameters are taken as null though the above lines shows the exact parameter values that are passed. This is the same case when the jenkins job is triggered inside the library checkout previous implementation here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try addParam
instead of binding variable? Binding variables are used for mocking env variables mostly. https://github.com/jenkinsci/JenkinsPipelineUnit#mocking-jenkins-variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of issues observed in this design.
Add some comments.
Thanks.
|
||
pipeline { | ||
options { | ||
timeout(time: 7, unit: 'HOURS') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it needs to be 5 hours?
Max this activity should be 2 hours isnt it?
The most time you take on this is rebuild, and the rebuild does not need more than 1 hour, if not 30min.
I am confused of how this 5hr number coming from.
) | ||
string( | ||
name: 'TAG', | ||
description: "Enter tag of the Product", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Divyaasm I would suggest use a choice param so people can choose the major version.
You did not give any example in the description and it will naturally confuse people.
booleanParam( | ||
name: 'RE_RELEASE', | ||
defaultValue: true, | ||
description: "Forces to create a Docker-Copy if the Docker Build is successful" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree ^^
trim: true | ||
) | ||
booleanParam( | ||
name: 'RE_RELEASE', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure the point of this param if the workflow itself is aimed for re-release already?
What is the point of rebuild but not re-release?
What does it force in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This parameter acts as a buildOption to create a docker-copy after the successful build inside the buildDockerImage()
I will update the description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in which case you do not want to docker-copy?
If not for docker-copy after we can just use docker-build without this workflow tho.
I am still not really sure why we need this at all.
) | ||
choice( | ||
name: 'TAG', | ||
choices: ['1', 'latest'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be 1 and 2, not latest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterzhuamazon Can't this value be 2.9.0, 1.3.11?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I believe this should not be a choice but a string parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this workflow is intended to concentrate only on the latest versions. So tag should do the work and update the major tag and latest images. Or providing the latest version number in each branch be it 1.x or 2.x should do the same some job as per library implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You dont need to be 2.9.0/1.3.11 as we only patch the latest supported version.
And major 1/2 tag already tag to the latest version.
|
||
pipeline { | ||
options { | ||
timeout(time: 7, unit: 'HOURS') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes @Divyaasm that is particularly set for the release ci image, as that one takes at least 4 hours.
trim: true | ||
) | ||
booleanParam( | ||
name: 'RE_RELEASE', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in which case you do not want to docker-copy?
If not for docker-copy after we can just use docker-build without this workflow tho.
I am still not really sure why we need this at all.
@@ -16,14 +16,9 @@ pipeline { | |||
) | |||
choice( | |||
name: 'TAG', | |||
choices: ['1', 'latest'], | |||
choices: ['1', '2'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be going from latest to earliest, as if 2 1
instead of 1 2
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signed-off-by: Divya Madala <[email protected]> Update changes Signed-off-by: Divya Madala <[email protected]> Remove re-release option Signed-off-by: Divya Madala <[email protected]> Change tag options Signed-off-by: Divya Madala <[email protected]>
Description
Add a Jenkins job in build library to call the docker patch functionality
Issues Resolved
#3930
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.