Skip to content

ceph-dev-pipeline: extract matrix stage script bodies into helper funcs#2621

Open
shraddhaag wants to merge 1 commit into
ceph:mainfrom
shraddhaag:refactor-matrix-stage-script
Open

ceph-dev-pipeline: extract matrix stage script bodies into helper funcs#2621
shraddhaag wants to merge 1 commit into
ceph:mainfrom
shraddhaag:refactor-matrix-stage-script

Conversation

@shraddhaag

@shraddhaag shraddhaag commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Description

Problem: We were hitting JVM's 64KB bytecode limit when adding new distros to the matrix stage script. Example: #2612 (comment).

Solution: Add helper functions for each stage in the matrix stage script, such that the original block is significantly reduced, thus ensuring we do not hit the JVM's 64KB limit again. This will also ensure we can keep extending the matrix with more distros without worrying about this issue.

Testing

I have been able to successfully parse the XML using: jenkins-jobs --conf ~/.jenkins_jobs.ini test ceph-dev-pipeline/config/definitions/ceph-dev-pipeline.yml. I am unable to actually test with this as I do not have permissions to update the pipelines: shraddhaag is missing the Job/Configure permission. If someone can help test this out, that would be great!

@djgalloway

Copy link
Copy Markdown
Contributor

I would like to see very obvious comments above each function. Additionally, I think it'd be beneficial for each function to have a number preceding it.

Something like,

// ===============
// 10 - Source Distribution
// ===============
def 10-doSourceDistribution() {
}

// ===============
// 20 - Copy Artifacts
// ===============
def 20-doCopyArtifactsStage() {
}

etc.

@djgalloway

Copy link
Copy Markdown
Contributor

@shraddhaag shraddhaag force-pushed the refactor-matrix-stage-script branch from 978e88f to 58f31e1 Compare June 24, 2026 07:30
@shraddhaag

shraddhaag commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

I would like to see very obvious comments above each function.

done!

Additionally, I think it'd be beneficial for each function to have a number preceding it.

I think function names starting with numbers is not allowed by most languages, including Groovy. I can perhaps do something like stage1DoSourceDistribution if the idea is to explicitly mention in the function name the order in which they are invoked.

If not, could you please help me understand why we want numeric to start the function name?

@djgalloway

Copy link
Copy Markdown
Contributor

I would like to see very obvious comments above each function.

done!

Can you make them more obvious? Include a stage number.

Additionally, I think it'd be beneficial for each function to have a number preceding it.

I think function names starting with numbers is not allowed by most languages, including Groovy. I can perhaps do something like stage1DoSourceDistribution if the idea is to explicitly mention in the function name the order in which they are invoked.

If not, could you please help me understand why we want numeric to start the function name?

Ah, right, fair enough. Good point. Skip it. I think "StageN" is worse. Loud comments should be enough.

@djgalloway

Copy link
Copy Markdown
Contributor

We have a number of very large changes incoming to ceph-dev-pipeline so I would ask that we hold off on merging this until those are sorted. Then we can split the new stages back out.

@zmc

zmc commented Jun 24, 2026

Copy link
Copy Markdown
Member

I very much like the idea behind this PR! One change I would like to see, for readability / maintainability / safety reasons is the new functions taking arguments instead of depending on environment variables to be set.

@shraddhaag

Copy link
Copy Markdown
Contributor Author

We have a number of very large changes incoming to ceph-dev-pipeline so I would ask that we hold off on merging this until those are sorted. Then we can split the new stages back out.

@djgalloway I saw that #2623 was merged which made substantial changes to ceph-dev-pipeline. I've rebased against main and extracted the new added logic into its own contained helper function.

If we could review + test this PR one last time that will be great. I am blocked on this to enable debug builds for noble (#2622).

I very much like the idea behind this PR! One change I would like to see, for readability / maintainability / safety reasons is the new functions taking arguments instead of depending on environment variables to be set.

@zmc Thanks Zack! I definitely like the idea of explicit argument declaration. I went ahead and implemented it but turns out it is quite a major change touching code which seems out of scope of this PR. I've created a new PR with the respective changes: #2635 which we can test + merge once this one is in. If you'd prefer for both commit to land together in this PR itself, please let me know.

@shraddhaag shraddhaag requested a review from zmc June 29, 2026 04:46
Comment thread ceph-dev-pipeline/build/Jenkinsfile
Comment thread ceph-dev-pipeline/build/Jenkinsfile Outdated
Comment thread ceph-dev-pipeline/build/Jenkinsfile Outdated
Problem: We were hitting JVM's 64KB bytecode limit when adding new
distros to the matrix stage script.

Solution: Add helper functions for each stage in the matrix stage
script, such that the original block is significantly reduced, thus
ensuring we do not hit the JVM's 64KB limit again. This will also ensure
we can keep extending the matrix with more distros without worrying
about this issue.
Signed-off-by: Shraddha Agrawal <shraddha.agrawal000@gmail.com>
@shraddhaag shraddhaag force-pushed the refactor-matrix-stage-script branch from bedaaf1 to dd8f6ce Compare June 29, 2026 16:17
@shraddhaag shraddhaag requested a review from djgalloway June 29, 2026 16:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants