Conversation
Reviewed-by: <jordan.bonser@arm.com> # gatekeeper
meteorcloudy
requested review from
Wyverald and
meteorcloudy
and removed request for
jin and
lberki
|
|
||
| # Proposal | ||
|
|
||
| I propose we add an `index.json` under the `modules` directory of the registry, which will list the modules that exist in the registry. |
There was a problem hiding this comment.
IMO we should put this file in the root directory -- it should be possible for a module named index.json to exist.
|
|
||
| As part of adding a module to the BCR, there needs to be a mechanism to ensure that a PR to add a module also has the addition of the module to the `index.json`. One approach to this would be to add logic to a script ran as part of the PR Pipeline, that would ensure the new module exists in the index. The `bcr_validate.py` may be a good candidate for this logic. | ||
|
|
||
| ## Handling Merge Conflicts |
There was a problem hiding this comment.
this is my biggest concern with a proposal like this, so thanks for devoting a sizeable chunk of text to it. I have just one question regarding the merge driver etc setup: would it allow multiple PRs touching index.json to be submitted without the PR authors needing to sync and resolve conflicts manually?
Say users A and B both submit a PR adding a new module, and both PRs change index.json accordingly. Both PRs are approved at around the same time. A's PR goes in first. When B's PR is about to be submitted, does B get an error, or does the PR submission process automatically run the merge driver? If B does get an error, can they somehow run the merge driver using GitHub's web UI, or will they actually have to resort to using the git CLI themselves?
lberki
left a comment
lberki
left a comment
There was a problem hiding this comment.
Approving because the discussion about a design doc is not supposed to happen on this review but on a discussion or issue thread.
3 participants
Reviewed-by: jordan.bonser@arm.com # gatekeeper