v0.3.8 - Introducing flags support in migrator

Introducing an enhancement for Flag support in migration.
You can now provide flags to alter migration behavior using --flags VALUE1,VALUE2
e.g.: harness-upgrade app --all --flags VALUE1,VALUE2

v0.3.7 - Support for more Trigger migration operations

Introducing an enhancement for Trigger migration.
You can now migrate triggers with names instead of id. Using --names flag and separated by commas
e.g: harness-upgrade triggers --names trigger1,trigger2

v0.3.6 - Support granular control of entity scopes

Introducing a powerful enhancement that gives you granular control over scoping individual entities. Previously, all entities adhered to a uniform scope within the project, leaving little room for customization. With this latest update, you now have the freedom to define scoping at an individual level, tailoring it to your specific requirements.

Imagine a scenario where you need specific connectors to be scoped to your org while others should remain confined to the project scope. In the past, achieving this level of differentiation was not possible. However, this new change allows you to dictate each entity's scope precisely.

By utilizing the scope property in the overrides file, which is passed using the --overrides flag, you can fine-tune the scoping of your entities. Here is an example:

overrides:
   - name: 'harness_jenkins'
     identifier: 'jenkins'
     firstGenName: 'Harness Jenkins'
     scope: org
     type: CONNECTOR
   - type: SECRET
     scope: org
     firstGenName: harness_jenkins

In this instance, we're showcasing how you can scope both a connector and a secret to the organization. This flexibility empowers you to tailor your scoping strategy to suit your needs.

For more in-depth insights and guidance on leveraging this feature, please refer to our documentation: Override Names, Identifiers, and Scope.

v0.3.4.5

What's Changed

Support for migrating specific user groups

We now support migrating specific user groups by name or id by providing either --names or --ids as comma-separated values. More details about this are available here - https://harness.github.io/migrator/upgrade/user-groups

Introducing settings

We can now control specific behaviour of migration by providing settings using the overrides files. To provide settings add a settings section in the YAML & add the value of the setting as so -

overrides:
  ...
settings:
  - type: SETTING_1
    value: VALUE
  - type: SETTING_2
    value: VALUE

Once you have configured the desired settings, executing the migration command with the --override flag and appropriate YAML files will seamlessly incorporate your preferences:

harness-upgrade --load load.yaml --override overrides.yaml app --all

Read more about it https://harness.github.io/migrator/advanced/overrides-and-settings/

v0.3.4 - Override Name and Identifiers

What's Changed

1. We have moved the behaviour of passing custom expressions from the --overrides to the --custom-expressions flag.
2. The --overrides flag can now be used to pass custom names & identifiers for specific entities. To override the names and identifiers of a connector when upgrading we would do harness-upgrade --load file.yaml --override override.yaml app --all. Read more about it here in the docs. A quick preview of the contents of the override.yaml file is -

overrides:
  - name: Fetch Release Information    # Name of the entity in NextGen 
    identifier: fetch_release_info     # Identifier of the entity in NextGen
    type: TEMPLATE                     # Type of entity in FirstGen
    firstGenName: Release_Fetch_Info   # Name of entity in FirstGen
  - name: HarnessDockerRegistry
    identifier: Harness_Registry
    type: CONNECTOR
    id: pwrySmUISimoRrJL6Nsvbw         # ID of the entity in FirstGen

3. We now support upgrading specific templates. The commands are as follows -

# Migrate all templates
harness-upgrade --load file.yaml templates --all import

# Migrate specific templates by name
harness-upgrade --load file.yaml templates --names TEMPLATE_NAMES import

# Migrate specific templates by ID
harness-upgrade --load file.yaml templates --ids TEMPLATE_IDS import

v0.3.3

Cross Cluster Installation

In this release, we have introduced support for migration across clusters and installations, enabling new capabilities that were not possible before. The following scenarios are now supported:

• Migration across SaaS Clusters: Previously, data migration was limited to accounts within the same cluster. With this release, we have expanded the functionality to enable migration across different SaaS clusters. For example, you can seamlessly migrate FirstGen data from the Prod1 SaaS cluster to the Prod3 SaaS cluster.

• Migration across Installations: We have also introduced the ability to migrate your SMP (Self-Managed Platform) installation to SaaS. This means you can now effortlessly transition from an SMP installation to our SaaS offering.

You can do so by using the --target-gateway-url flag. Read more about the cross account migration here

v0.3.2 - Provide custom expressions & Skip logs

Important Changes

1. Improved upgrade logs filtering: The upgrade logs have been enhanced to filter out noisy failures such as duplicate identifiers and duplicate folders by default. This improvement makes it easier to find relevant logs. If you still want to see these filtered logs, you can use the --log-level debug flag with the upgrade command.

2. Custom expressions for upgrade: Now you can provide custom expressions for an upgrade by passing a YAML file that contains expressions to be replaced with next-gen syntax. This new feature gives you more flexibility in customizing your upgrade process.

3. Scoped user group creations: You can now scope user group creations to an organization and project, in addition to the default account scope. This enhancement allows for more fine-grained control and organization of user groups.

4. Changes to overrides with expressions command: The command for providing overrides with expressions has been updated. You should now use harness-upgrade --override FILE expressions syntax to specify the overrides file.

5. Updated flag for logging level: The --debug flag has been removed. Instead, a new --log-level flag has been introduced, which allows you to set the logging level. The available log levels are trace, debug, info, warn, error, fatal, and panic. Choose the appropriate log level based on your debugging and logging requirements.

v0.3.1 - Additional expressions

New expressions are added to handle standard Harness expressions & minor bug fixes

v0.3.0: SMP Support, Cross account upgrade & more

What's Changed

• Support cross-account migration of entities
• Support for the upgrade on the SelfManaged Platform
• Support for the upgrade of individual entities such as secrets, connectors, templates, services and environments
• Utility commands to delete pipelines & templates

v0.2.10-beta

What's Changed

• Support deletion of Templates

# To remove all templates
harness-upgrade templates --all rm

More details here in the docs

• Support deletion of Pipelines

# To remove all pipelines
harness-upgrade pipelines --all rm

More details here in the docs

In this process, we have removed the default behaviour of the pipelines command to import pipelines to the import command

harness-upgrade --load FILE pipelines --all import

More details here in the docs