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.
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 https://github.com/ubiquity/ubiquibot-kernel/issues/47#issuecomment-2162159354