Merge configurations by unique IDs

[gentlementlegen]

We should look into a more robust configuration merge.

Quote from discussion:

I know there isn't a concept of merging configurations together on GitHub Actions.

This doesn't address the key point I am making. The cause we are discussing is a collision with dependency IDs. And whether there are real-world scenarios where configurations might lead to duplicate dependencies.

From my experience creating GitHub Actions CI scripts, I haven't encountered situations where adding redundant dependencies was necessary. This makes the theoretical merging logic problem irrelevant to our practical implementation.

We should focus on the actual conditions under which our configurations operate, rather than hypothetical scenarios that don't align with real-world use cases.

Basically I'm saying to drop support for using the same dependency more than one, particularly when associated with the same webhook event. See this comment for a suggestion on how to handle that.

Originally posted by @0x4007 in #47 (comment)

[gentlementlegen]

Now that we are creating a configuration editor, I feel like this is not really needed and could introduce a lot of complexity and errors while we could easily handle configurations through the UI what do you think @0x4007

[rndquu]

@gentlementlegen I've actually thought this task is for merging organization and repository configs by unique plugin ids/keys, no?

[gentlementlegen]

This would be doable but because we now have multiple keys and reusable anchors in our configuration I am not sure how this can be achieved.

[rndquu]

This would be doable but because we now have multiple keys and reusable anchors in our configuration I am not sure how this can be achieved.

You mean that uses is an array?

[gentlementlegen]

Yes both plugins and uses are arrays. Try the tool for installing the configuration through the web UI and you'll see how anchors are also used to populate the configuration, which I don't think is mergeable.

[0x4007]

There are two scenarios for matching plugin ids:

1. org + repo config merged
2. repo + repo config (aka two instances of matching plugin id)

In the first scenario, we should clobber the org plugin setting with the repo plugin setting. This is consistent with our intent to allow for local repository level overrides against the organization wide config.

In the second scenario, this is most likely to be an error. I think that this should throw an error when pushing these changes. We should also throw an error if this is detected in our UI. We should not support this configuration in the UI or with the kernel.

[henalolp]

/help

[rndquu]

This would be doable but because we now have multiple keys and reusable anchors in our configuration I am not sure how this can be achieved.

You mean that uses is an array?

@gentlementlegen What's the use case for uses to be an array?

[gentlementlegen]

@rndquu it should be an array when we want plug-ins to run sequentially and forward the outputs to each other. When placed at top level, execution has not order. When chained in the uses section, they run one after another and send the payloads one to another.