BT 2.33.0 breaks backward compatibility for vra-ng

[pe1pip]

Description

We have packages packaged with older versions that can't be pushed with 2.33.0:

The error:

Execution default-cli of goal com.vmware.pscoe.maven.plugins:vrealize-package-maven-plugin:2.33.0:push failed: Cannot invoke "com.vmware.pscoe.iac.artifact.model.vrang.VraNgCatalogItemType.getId()" because "this.type" is null

The following code is added to the content source in 2.33 that isn't present in 2.29.1:

  "type": {
    "id": "com.vmw.vro.workflow",
    "link": "/catalog/api/types/com.vmw.vro.workflow",
    "name": "Automation Orchestrator Workflow"
  }

Steps to Reproduce

1. Create a vra-ng package with 2.29.1
2. have a second with BT 2.33.0 package depend on this package
3. see mvn package vrealize:push -Penv fail

Preconditions: [What are the preconditions to reproduce the issue]

one package created with 2.29.1, a second package depend on the first with a pom like:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.vmware.pscoe.vra-ng</groupId>
    <artifactId>vra-ng-package</artifactId>
    <version>2.33.0</version>
  </parent>
  <dependencies>
    <dependency>  <!-- build with 2.29.1 -->
      <groupId>nl.group</groupId>
      <artifactId>demo1</artifactId>
      <version>1.0.14</version>
      <type>vra-ng</type>
    </dependency>

  </dependencies>

  <groupId>nl.group</groupId>
  <artifactId>demo2</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>vra-ng</packaging>
  <scm>
    <developerConnection>${scmDeveloperConnection}</developerConnection>
  </scm>

  <description>
        This is a small demo
  </description>
  <properties>
    <generated.from>package-vra-ng-archetype</generated.from>
  </properties>
</project>

Expected behavior:

vrealize:push not to fail, but come up with sensible defaults for type

Actual behavior:

Reproduces how often:

100%

Component/s: com.vmware.pscoe.iac.artifact.model.vrang.VraNgCatalogItemType

Affects Build/s:

2.33.0

Environment

Client

• Build Tools for VMware Aria Version: 2.33.0
• Visual Studio Code Version: latest
• OS Version: MacOs latest

Server

• vRealize Automation Version: 8.12.1
• vRealize Orchestrator Version: 8.12.1
• vRealize Operations Version: n/a
• vRealize Log Insight Version: n/a

Failure Logs

Related issues and PRs

Additional Context

[Michaelpalacce]

Hey Remco,

This is a 2 fold issue I think.

1. A breaking change in the Aria API between 8.11 and 8.12 which was not supported at the time
2. A change done in the newer BTVA version, which led to that change no longer being breaking.

The target would be that 2.33.0 supports pulling from 8.11 and pushing to 8.12 If that's not the case, then we'll need to assume this is a bug...

Does pulling from 8.11 and pushing to 8.12 with 2.33.0 work?

[pe1pip]

Hi Stefan,

I think it works, pulling from 8.12 and pushing to 8.11, and v.v.. (except for pushing custom forms to 8.12) My main concern is that we have 10’s of vra-ng packages build with older versions of the tools that can’t be deployed when the main package that depends on them is at 2.33.0. I think the breaking change was introduced maybe in 2.32.0 …

[Michaelpalacce]

I understand what you mean. The problem in that case is that the dependent package is being built with the latest version. We will need to investigate how dependencies to other vra-ng packages are handled.

[pe1pip]

Hi,

From what I see the dependencies are unpacked and installed using the BT version of the depending package. That all makes sense, but it just means that you have to be very careful about backward compatibility. Of course, it then helps if the target platform is also very careful about backward compatibility ;-) .

[Michaelpalacce]

@pe1pip sorry for the late reply.

From what I see the dependencies are unpacked and installed using the BT version of the depending package

if this is the case, then again not sure what there is to do. Seems like an issue with Aria to me?

[Michaelpalacce]

Hey @pe1pip, can you provide a minimal reproducible example?

[krasimirr]

Hi @pe1pip I am going ahead and closing the issue after failing to reproduce the error specified. Feel free reopen and provide us with another reproducible example if the issue persists.