Publish plugins fails but we are still using the old gcs artifact

[s4kh]

Problem:

1. Publish is triggered: plugin version - 1.0.0
2. GCOM endpoint returns plugin.json schema validation
3. User updates the plugin.json to include the missing properties
4. Since artifact is already present in the {plugin_slug}/v1.0.0 it skips uploading the updated artifact(includes update plugin.json)
5. We pass the old not updated artifacts downlod url to GCOM again
6. Same validation error is returned

Ref run: https://github.com/grafana/grafana-elasticsearch-datasource/actions/runs/22635845161/job/65599089413

[s4kh]

@xnyo @academo @tolzhabayev
Went back & forth with claude.

Current fix #590 is checking if version exists on GCOM if not then allow overwriting the GCS artifacts.
Question:

• User can choose to publish to dev/ops/prod - But we use single bucket on grafanalabs-global for artifact uploads. With the current fix we are always overwriting since the version doesn't exist on GCOM prod. Should we check the version on each env?

Maybe we just compare existing artifacts checksum with newly generated artifact's checksum and decided whether to upload or not?

[xnyo]

@s4kh looked at #590 , code looks good and I think these changes make sense, but thinking about it a bit more carefully I relised we may be able to simplify this even further. iirc, these checks were added for ensuring the ZIP is not overwritten in two scenarios:

1. Provisioned plugins that were installed in Cloud from GCS rather than catalog (provisioned plugins in SSS used to point to integration-artifacts ZIPs directly)
2. When publishing any plugin version (provisioned or not) to the catalog, to ensure the asset used by GCOM for the plugin's download is NEVER changed (otherwise, this would cause provisioned plugins to go stale).

Scenario 1. is not relevant anymore, all provisioned plugins use catalog now.

Important note: plugin-ci-workflows uploads files to the integration-artifacts bucket, which is NOT the bucket used by GCOM.

Due to this, Scenario 2. should also be irrelevant now: the plugin version ZIP files sent to GCOM as URLs are copied from integration-artifacts to its own grafana-plugins-catalog[-dev|-ops] bucket by GCOM (https://github.com/grafana/grafana-com/issues/14289). This was not in place when plugin-ci-workflows was originally built. Due to this, I think we can safely ALWAYS overwrite files in integration-artifacts, so we can skip the exist check completely and always allow overwrite the files (provided the ZIP files are copied to its own, read-only bucket and those files in integration-artifacts are not used anywhere else by GCOM, rather than just for downloading and re-uploading to a different bucket).

With this proposed approach, attempting to publish a plugin version whose version value already exists in the catalog, the file in integration-artifacts file would be overwritten by plugin-ci-workflows, but GCOM will reject the plugin version with "plugin version already exists" error. Provided the integration-artifacts file is not used anywhere else, it should be safe.

However, I may be missing something. cc'ing @academo who worked on the original logic for handling these overwritten ZIP files

[xnyo]

If you think the above is too brittle, I am happy to approve the changes in #590 , I'm just worried the logic inside plugin-ci-workflows is getting a bit too complex

[s4kh]

@xnyo Definitely, making it simpler better. I was also thinking about we always upload