Unable to update plugins using miactl

[dallas-fletchall]

What product are you having troubles with?

Marketplace

What Console version are you using?

1.112.1

Description

Based on declarative-approach docs, specifically this section, I should be able to update an item's description (at the very least).

We have a working set of github actions, but it refuses to update items. Using a service account with clientId and clientSecret, we are can upload a new item, but are unable to modify an existing item. Below are the relevant sections of the action.

name: 'Apply updates to Mia (Non-Prod) Marketplace'
on:
  workflow_call:
    ...
jobs:
  apply-marketplace:
    container: ghcr.io/mia-platform/miactl:v0.16.0
    steps:
      ...
      - name: miactl set context
        shell: sh
        run: |
          miactl context auth new-auth --client-id ${{ client_id }} --client-secret ${{ client_secret }}
          miactl context set new-context --company-id ${{ company_id }} --endpoint ${{ endpoint }} --auth-name new-auth
          miactl context use new-context
      - name: miactl marketplace apply
        shell: sh
        run: |
          output="$(miactl marketplace apply --file-path "${{ path }}")"          
          echo '```' >> $GITHUB_STEP_SUMMARY
          echo "$output" >> $GITHUB_STEP_SUMMARY
          echo '```' >> $GITHUB_STEP_SUMMARY

Actual Outcome

Taking a previous item that was created using the above github action, we update the .description, and were provided with the output below as the result of miactl marketplace apply --file-path /some/path:

Each instance of the plugin with the same objectId is a version of the plugin.

Expected Outcome

I would expect 1 of 2 possible outcomes.

1. a non-zero exit code w/o any updates to any item inside of /some/path
2. a successful exit code updating all items inside of /some/path, including the updated description

[danielemarostica]

Hi @dallas-fletchall and thank you for reaching out.

Your expectation seems reasonable, but a few validations happen under the hood when updating a versioned marketplace resource.

To better understand the situation here:
Is this error showing up when modifying only the description field?
Could you paste here an example of the manifest and the fields you are trying to update? (feel free to omit any sensitive information from the manifest)

[dallas-fletchall]

We worked through some of the issues that we were having. The conclusion that we came to is that multiple properties retrieved from miactl marketplace get --object-id <id> cannot be put in a file following the declarative approach without modification. It was these properties that were giving us issues, and not the description field.

Having .releaseDate or .isLatest for an existing plugin causes the output of the miactl tool to not show updated

Deleting from the CMS, but not removing from the trash, results in - during upload

Additionally, some items are just disregarded without warning (e.g. _id).

---

Finally, images uploaded with .image.localPath do not show as files in the CMS (you can inspect the HTML to figure out where it is hosted, but no link/name is associated. See below

---

We worked around these issues by implementing steps in the pipeline to validate known issues for our use case based on the schema below. Is there a better schema that we can modify to meet our use case?

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "additionalProperties": true,
    "required": [
        "image",
        "supportedByImage",
        "supportedBy",
        "visibility"
    ],
    "properties": {
        "_id": {
            "not": {}
        },
        "releaseDate": {
            "not": {}
        },
        "isLatest": {
            "not": {}
        },
        "imageUrl": {
            "not": {}
        },
        "supportedByImageUrl": {
            "not": {}
        },
        "visibility": {
            "type": "object",
            "properties": {
                "allTenants": {
                    "type": "boolean"
                },
                "public": {
                    "not": {}
                }
            },
            "required": [
                "allTenants"
            ]
        },
        "supportedBy": {
            "type": "string"
        },
        "supportedByImage": {
            "type": "object",
            "properties": {
                "localPath": {
                    "type": "string"
                }
            },
            "required": [
                "localPath"
            ]
        },
        "image": {
            "type": "object",
            "properties": {
                "localPath": {
                    "type": "string"
                }
            },
            "required": [
                "localPath"
            ]
        }
    }
}

---

Ultimately, my original expectation still holds. If a property is supplied that cannot be accepted, a non-zero response should be returned (erroring on unknown and unexpected properties would make sense as well).