Rmv blue-green plugin for native builds

[srinikitha09]

This plugin has not been updated since ages and moreover, it uses the deprecated cf api v2. As we want to use cf api v3, either the plugin should be updated accordingly or we should get rid of the dependency on it.

[o-liver]

Before we merge this we should add an error to the cloudFoundryDeploy step in Piper that fails the step at the beginning if it is misconfigured: i.e. if cf push (maven and npm) is used instead of cf deploy (mta). That way we have a clean error message, rather than letting the deployment fail with something cryptic from the cf cli.

[anilkeshav27]

Before we merge this we should add an error to the cloudFoundryDeploy step in Piper that fails the step at the beginning if it is misconfigured: i.e. if cf push (maven and npm) is used instead of cf deploy (mta). That way we have a clean error message, rather than letting the deployment fail with something cryptic from the cf cli.

could we also announce this in the community meeting, before rolling out a breaking change in the cf cli docker image . we would need to gracefully remove this parameter : https://www.project-piper.io/steps/cloudFoundryDeploy/#deploytype and its functionality from the step and the alternative could be the rolling deployment https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html via the piper parameter https://www.project-piper.io/steps/cloudFoundryDeploy/#cfnativedeployparameters . but we would need to give time to existing users to make this switch

[o-liver]

Before we merge this we should add an error to the cloudFoundryDeploy step in Piper that fails the step at the beginning if it is misconfigured: i.e. if cf push (maven and npm) is used instead of cf deploy (mta). That way we have a clean error message, rather than letting the deployment fail with something cryptic from the cf cli.

could we also announce this in the community meeting, before rolling out a breaking change in the cf cli docker image . we would need to gracefully remove this parameter : https://www.project-piper.io/steps/cloudFoundryDeploy/#deploytype and its functionality from the step and the alternative could be the rolling deployment https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html via the piper parameter https://www.project-piper.io/steps/cloudFoundryDeploy/#cfnativedeployparameters . but we would need to give time to existing users to make this switch

The deployType parameter is still relevant for mta deployments though. Is it enough to change the documentation? We could also describe the rolling deployment as an alternative in the deployType documentation.

Of course it's good to announce this in a community meeting. How much time would you propose for users to make the switch? 3 months?

[anilkeshav27]

Of course it's good to announce this in a community meeting. How much time would you propose for users to make the switch? 3 months?

yes 3 months is a good time. along with the announcement about rolling deployment . after 3 months we should carve out this piece of code from the cf deploy step and not support the functionality , parallely also remove the plugin from the docker image

if we remove the plugin today from the docker image and keep the code and the functionality in the cf deploy step, then we end up with a call to cf blue-green-deploy which will fail saying the plugin is not available .

i would like to avoid this as a breaking change for native cf users.

[o-liver]

Of course it's good to announce this in a community meeting. How much time would you propose for users to make the switch? 3 months?

yes 3 months is a good time. along with the announcement about rolling deployment . after 3 months we should carve out this piece of code from the cf deploy step and not support the functionality , parallely also remove the plugin from the docker image

if we remove the plugin today from the docker image and keep the code and the functionality in the cf deploy step, then we end up with a call to cf blue-green-deploy which will fail saying the plugin is not available .

i would like to avoid this as a breaking change for native cf users.

I also discussed the option of keeping the plugin in the image, as the plugin still works but just runt into a rate limit if one uses it too heavily, with @1084565. We still want to remove it finally, as this plugin is not maintained and will give us trouble sooner or later wrt compliance.

Then the task is now to show a deprecation warning in the cloudFoundryDeploy step, if somebody has this setup. In that message we should refer to the rolling update possibility and how to configure that in the cloudFoundryDeploy step. Additionally we will also add this information into the documentation of this step. @srinikitha09 Could you do this with the ongoing task?

I will block this PR for the next 3 months.

[o-liver]

Blocked until end of January 2024

[srinikitha09]

@o-liver any update on this?

[o-liver]

@o-liver any update on this?

Thanks for the reminder. We will work on this ASAP. FYI @kaylinche we should plan this accordingly. As mentioned by @anilkeshav27 we should simultaneously remove this.

[srinikitha09]

Do we still have any issues from merging this PR?

[kaylinche]

The changes are fine with me. The announcement time for the deprecation is also over.

[o-liver]

Is the Piper code adjusted? Because Piper uses the latest tag for this docker image and might fail if we have not adjusted the cloudFoundryDeploy step beforehand.

[srinikitha09]

Any objections to merge this PR now? The due date is already over.

[kaylinche]

Any objections to merge this PR now? The due date is already over.

No objections from my end.

[o-liver]

ready to merge