[epic] Migration Tasks for Plugin-arched PipeCD

[t-kikuc]

What would you like to be added:

This issue tracks ALL tasks for migrating to the pipedv1. When a new task or PR emerges, please add/link it to this PR.

Why is this needed:

• To make existing applications available in pipedv1
• To complete the migration without omission
• To make it easier to migrate for users (both Control Plane owners and Piped managers)

Tasks

DB in Control Plane

• [x] migrate Application's PlatformProvider to the set of plugins and deployTargets (ref: https://github.com/pipe-cd/pipecd/blob/master/pkg/model/application.proto#L55)

  • [x] Application.Kind -> deploy_targets_by_plugin key
  • [x] Application.PlatformProvider -> deploy_targets_by_plugin value[0]

• [x] ~(Filestore) migrate from analysisResultStore to the new applicationSharedObjectStore https://github.com/pipe-cd/pipecd/pull/6040~

  • -> [ ] Ignore this pattern. Add to the guide

Config files

• [ ] Piped Config: Manual edit. TODO: Add to guide

  • [x] analysisProvider: Move to under plugins of Analysis
  • [x] convert PlatformProvider to deployTargets
    • PlatformProvider.type → plugin name
    • PlatformProvider.name → deployTarget name

• [x] Application Config

  • [x] skipOn: Update indent of skipOn
  • [x] timeout: Update indent of timeout in stages

Docs

• [ ] TBA

Recommended migration flow

1. Update app.pipecd.yaml for v1 (commands will be provided) <- Perform Config files change (Application Config migate task)
2. Execute DB Migration commands <- Perform DB in ControlPlane task
3. Update piped version

[t-kikuc]

There are some tasks AFTER the migration to clean the codebase.

e.g.

• https://github.com/pipe-cd/pipecd/pull/5968 (Remove stageName condition)
  • This will affect all deployments that are made while the server does not inject availableOperation

[t-kikuc]

[Copied to the head thread] +1 task.

we need to migrate from analysisResultStore the new applicationSharedObjectStore

ref. https://github.com/pipe-cd/pipecd/pull/6040

[t-kikuc]

[Copied to the head thread] +1 task.

We need to migrate from scriptRunStageOptions.Timeout and waitApprovalStageOptions.Timeout to stage.Timeout.

(stage.Timeout already exists in pipedv0. Let's merge the timeouts to it.)

cf. #6075

[t-kikuc]

[Copied to the head thread] +1 task.

In the piped-config, analysisProviders should be moved to plugins.analysis.config.analysisProviders

-> Ignore this pattern. Add to the guide

[khanhtc1202]

Note: After #6171, the pipedv0 works with plugin-arch piped managed application config.

Once edge case: v1 application config without spec.plugins configuration will not be handled/converted to v0 application config, since the current Kind converter logic based on plugin name.

[khanhtc1202]

Migrate test flow

• [x] Start pipedv0 and register a v0 format app (1)
• [x] Convert to v1 format with pipectl migrate app-config and deploy (2)
• [x] Obtain the pipectl API key from the UI (3)
• [x] Update the database with pipectl migrate database (4)
• [x] Prepare pipedv1 settings and update to pipedv1 (5)
• [x] Deploy a v1 format app (6)
• [x] Downgrade from pipedv1 to pipedv0 (7)
• [x] Deploy a v1 format app (8)

Note

• After (4), UI changed as expected in the Application detail page
  • PlatformProvider -> DeployTargets
  • Livestate is not showing <- need fix
• After (8), UI changed as expected in the Application detail page
  • DeployTargets could change back to PlatformProvider <- need fix
  • In Deployment detail page, the pipeline showing rollback stage all the time <- need fix

The above issues had occurred due to the current UI logic based on application model deployTarget field to decide its v1 or v0 model, which is not right because after pipectl migrate database command, model will contain both platformProvider and deployTargets values.