Use parameter releaseType to pass to downstream

[AdamBrousseau]

Rather than hardcoding 'Weekly', use the build parameter.

[github-actions]

Thank you for creating a pull request!

Please check out the information below if you have not made a pull request here before (or if you need a reminder how things work).

Code Quality and Contributing Guidelines

If you have not done so already, please familiarise yourself with our Contributing Guidelines and Code Of Conduct, even if you have contributed before.

Tests

Github actions will run a set of jobs against your PR that will lint and unit test your changes. Keep an eye out for the results from these on the latest commit you submitted. For more information, please see our testing documentation.

In order to run the advanced pipeline tests (executing a set of mock pipelines), it requires an admin to post run tests on this PR.
If you are not an admin, please ask for one's attention in #infrastructure on Slack or ping one here.
To run full set of tests, use "run tests"; a subset of tests on specific jdk version, use "run tests quick 11,21"

[karianna]

If this is the weekly config is it not OK to hard code that?

[smlambert]

If this is the weekly config is it not OK to hard code that?

In #847 we have introduced a new job type for releases, so now there are "nightly", "weekly" and "release" types. The name of the file is now a misnomer, weekly_release_pipeline can be used for weekly runs or release runs and it can take different job types now.

[AdamBrousseau]

If this is the weekly config is it not OK to hard code that?

It is already hardcoded in the build_pipeline_generator.groovy

ci-jenkins-pipelines/pipelines/build/regeneration/build_pipeline_generator.groovy

Line 265 in 833a06d

config.releaseType = "Weekly"

This sets the default param value for the weekly pipelines to releaseType=Weekly. If a build is launched from the weekly pipeline and releaseType param is changed, it has no effect. Perhaps by design? But a little misleading I think.

[adamfarley]

The code looks good. Can we amend the comment about "create a weekly pipeline job" to reflect this change, please?

[sxa]

Can you redo the commit message to include the e in the middle of releaseType please?

[karianna]

If this is the weekly config is it not OK to hard code that?

In #847 we have introduced a new job type for releases, so now there are "nightly", "weekly" and "release" types. The name of the file is now a misnomer, weekly_release_pipeline can be used for weekly runs or release runs and it can take different job types now.

We should probably rename weekly config files to what they really are in that case :-)

[AdamBrousseau]

I'll further explain my use case.
We (IBM) do not publish our nightly/weekly build. So we've always run "nightly without publish" and "weekly without publish". I've reconfigured our regenration code to make the defaults "* without publish". I recently made a change to properly set the config rather than just reordering the drop down list in the build launch (see ibmruntimes#188). In doing so, we're relying on the parameter passed from the weekly build to the regular build, which up until this PR, has been ignored because it takes the hardcoded "Weekly". So, we are not reinventing the weekly build (wrapper job) into something else, we are simply using it "without publish". Arguably, the publish should be a separate boolean and not part of the release type. But that is a different topic.

[smlambert]

For the record, I agree with you on the cleaner design of separate boolean param for 'publish', but as you say, its outside of the scope of this PR.

[adamfarley]

LGTM, thanks for changing the comment. :)