-
Notifications
You must be signed in to change notification settings - Fork 278
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
Jenkinsfile change to support branching #2559
Jenkinsfile change to support branching #2559
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2559 +/- ##
============================================
- Coverage 94.41% 94.28% -0.14%
Complexity 28 28
============================================
Files 219 213 -6
Lines 4462 4357 -105
Branches 29 10 -19
============================================
- Hits 4213 4108 -105
Misses 243 243
Partials 6 6 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Hi @prudhvigodithi, can you check this issue? #1606 |
There are too many stash unstash and I wonder is there a way to load a common lib like @gaiksaya suggested. |
The problem I see is git checkout, yes can be added to shared library, still that shared library function has to be called in jenkinsfile, but I dont see a way we can escape the unstash line, as jenkins expects for every stage to have that unstash method so that it can re-use those cloned files, will do some more research here. |
c3f312c
to
da67b1a
Compare
Even to load the shared library we need to add a stage/line to checkout and stash, I dont see a huge difference here to add 2 line in the jenkinsfile itself that does the git checkout and stash the files, also to unstash I dont see any other way to declare globally other then to have |
description: "Build repo branch to use.", | ||
defaultValue: "main", | ||
trim: true | ||
) |
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 feels very wrong. This job itself lives in this repo in a branch. If I am running the job out branch X, I would not expect the job to check out build tools from branch Y.
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 is done for the fact Jenkinsfiles cannot be branched, they has to reside in main
and jenkins job git SCM configuration uses single branch to pull the jenkinsfile, once jenkinsfile is pulled, depending on the branch passed as input using BUILD_BRANCH
, then the checkout happens with right branch and all the stages are executed as per the flow.
I think you want to model this after GitHub actions. The .yml jobs for GHA live in a branch (e.g. 1.2.3) and run from that branch (1.2.3) checking out source code by default from the same branch (1.2.3). This it's never a parameter to the job, the only time you care about which branch to use is when you import the job into Jenkins. |
Hey @dblock, assume the build repo is branched as |
75ddc56
to
4594eb6
Compare
Signed-off-by: prudhvigodithi <[email protected]>
4594eb6
to
2345581
Compare
Signed-off-by: prudhvigodithi <[email protected]>
We can go with this PR until the Branching Strategy Implementation is finalized, I dont see any harm that would break the existing distribution functionality. This input value |
I think this is the wrong implementation for an otherwise good idea. As an example, your I think you want to extract the python tooling into a new repo, then hard-code the branch to use from that repo in the manifests, not take a parameter in build. This would make it reproducible and configurable in 1 place. |
Hey @dblock I like the idea to separate the python tooling and pull the right tooling from manifest using the branch (or version), but its just not python tooling, we have some scripts here as well https://github.com/opensearch-project/opensearch-build/tree/main/scripts that needs to be focused for branching.
@dblock Jenkinsfile cannot be branched, hence the are only part of How about we get this merged, observe with If no then I will close this PR and start focusing on python workflow separation and consider branching(or versioning) on those separated repos. :) Once done then some versioning has to be done for those scripts as well https://github.com/opensearch-project/opensearch-build/tree/main/scripts, but this can be later, we can start with workflow separation and learn as we observe. @bbarani @peterzhuamazon @gaiksaya |
I recommend closing and focusing on branching those new repos, because this is a step in the wrong direction. |
Closing this PR. More details #2549 (comment), #2549 (comment) |
Signed-off-by: prudhvigodithi [email protected]
Description
Jenkinsfile change to support branching, starting with daily used jenkins jobs of OpenSearch and OpenSearch dashboard.
Issues Resolved
Part of: #2549
Related: #2558
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.