Major updates should be performed by a person pushing a new style of the plugin component or some such

What major updates are you thinking about?

What about deletions of plugins from a registry - How would that work?

Or do we restrict what plugins we know about by templating that part like it is right now, we DON'T allow pushing a plugin that does NOT exist like the above flow thus currently

I think this should be the way. If a new plugin is introduced, it should also be added to the template. Otherwise it feels like an exploitable vulnerability.

Going to make a decision here, and generate the plugins list dynamically.

So... flow is as follows:

• check if the pushed plugin already exist with the same version, if yes, we error. we never overwrite a version
• load the template
• if registry exists
  • update the template's componentReferences list from the registry
  • it doesn't, create an empty list
• add the new plugin to the list of componentReferences

Done. Much simpler flow.

This is how it looks like when a new plugin is released and then another plugin is released with a new version:

- component:
    componentReferences:
    - componentName: ocm.software/plugins/helminput
      digest:
        hashAlgorithm: SHA-256
        normalisationAlgorithm: jsonNormalisation/v4alpha1
        value: 4a3c1303bfbbc01090375e3ffc73bc8b7bbfcf6e3d4f682eaa8634df3462375b
      name: helminput
      version: 3.0.8
    - componentName: ocm.software/plugins/helminput
      digest:
        hashAlgorithm: SHA-256
        normalisationAlgorithm: jsonNormalisation/v4alpha1
        value: bfc01fc6eccf571864ef6ebe24ff476ae3019d42178ab5e7998a22bd848139a6
      name: helminput
      version: 3.1.0
    name: ocm.software/plugin-registry
    provider: ocm.software
    repositoryContexts: null
    resources: null
    sources: null
    version: v0.1.1
  meta:
    schemaVersion: v2
- component:
    componentReferences:
    - componentName: ocm.software/plugins/helminput
      digest:
        hashAlgorithm: SHA-256
        normalisationAlgorithm: jsonNormalisation/v4alpha1
        value: 4a3c1303bfbbc01090375e3ffc73bc8b7bbfcf6e3d4f682eaa8634df3462375b
      name: helminput
      version: 3.0.8
    name: ocm.software/plugin-registry
    provider: ocm.software
    repositoryContexts: null
    resources: null
    sources: null
    version: v0.1.0
  meta:
    schemaVersion: v2

This is how it looks like when a new plugin is released and then another plugin is released with a new version:

Puh, this will be endlessly redundant. Not sure if this is maintainable after v0.123.0. But I don't have any idea how to do that better right now :D

Yeah. 🤔 I don't know. We don't want to overwrite versions... So... I don't know. :D

The plugin registry file will be large. very large in fact. but thats okay :)

The plugin registry file will be large. very large in fact. but thats okay :)

maybe in a later iteration we find a way to split it more - like nexus handles dependencies (folder structure, etc)

I'm simplifying this even further.

Run actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd
Preparing registry constructor for helminput v3.1.6
Error: Plugin with name helminput and version 3.1.6 already exists in reference list

plugin exists check is working 🎉

Right now, there is no hashing of the component reference or the plugin registry. This will be added in a follow-up.

Do we have a follow up for this already?

Right now, the plugin checking itself and the updates and such are agnostic of the plugin's name and such that is being pushed. However, this presents and interesting problem. Do we just blindly add plugins all the time and the template is literally just the main part with an empty componentReference? Or do we restrict what plugins we know about by templating that part like it is right now, we DON'T allow pushing a plugin that does NOT exist like the above flow thus currently

this is very hard to understand for me, could you try to rephrase the problem in different wording so I understand what you are looking to solve?

Do we have a follow up for this already?

Yep. I have an issue for that #1227.

It's in needs refinement for sprint 52 and doesn't belong to an EPIC yet.

this is very hard to understand for me, could you try to rephrase the problem in different wording so I understand what you are looking to solve?

Nevermind, I already decided on what to do. :) You can ignore it.

Yay, successful run after fixes ( I'll push them in a sec ):
https://github.com/Skarlso/open-component-model/actions/runs/19696661625

Whoops, previous is empty. :D

Finally! Behold:

Run actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd
Adding helminput v3.1.13 to plugin registry
Fetching registry descriptor: ghcr.io/skarlso/plugins//ocm.software/plugin-registry
Found registry v0.4.4 with 8 plugin(s)
Publishing component to ghcr.io/skarlso/plugins
Verifying component: ocm.software/plugin-registry:0.4.5
Verification successful
Successfully published registry v0.4.5

Error scenario:

Adding helminput v3.1.13 to plugin registry
Fetching registry descriptor: ghcr.io/skarlso/plugins//ocm.software/plugin-registry
Found registry v0.4.5 with 9 plugin(s)
Error: Plugin helminput v3.1.13 already exists in registry

It's working <3.

I hand wrote the prepare-registry-constructor.js then run it through an llm to make it prettier and more robust because I suck at JS. But this had the added benefit that I understand how it works. :D It's pretty basic honestly. Nothing too fancy. I shifted most of the YAML logic into the Javascript so it's testable, and more importantly, maintainable instead of everything being in github action steps.

I removed a bunch of permissions and set some others to read. I'm running a test now.

Edit: Crap. It's required for the trigger and the attestation.