-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Conversation
Do not pull updates for submodules at subrepos Read directories with subrepos from Docfile instead of hardcoded Instantiate content map only once and reuse in tasks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works as described, however, I think we should discuss the use of submodules in general.
I'm glad that the current rake task failed and notified us that we're using a submodule in the page builder subrepo because we should not be doing that in production.
With these changes, it won't be as obvious if a submodule is introduced into a subrepo and I worry that it could potentially break something or create an unexpected user experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works well.
A bit of explanation for this scenario. In my case, having the parliament submodule in the master
branch is/was a test for operating parliament alongside the devdocs pipeline. And until today, that had been working fine for a couple of weeks. I setup the magento2-page-builder-docs
to trigger GitHub actions that publish the parliament output to the repo's gh-pages
branch. This allows me to check both outputs (devdocs vs parliament) from the same markdown files while I work on achieving parity on the parliament side.
Meanwhile, the devdocs pipeline is/was still doing its own thing, processing and publishing the same markdown files with Jekyll. This ensured I could always compare to parliament's output.
I used the docs/
directory on the master
branch is my single source of truth.
In such a scenario, the two pipelines don't intersect. The docs/
directory stays pristine with markdown files only.
Hope that helps in explaining this particular scenario.
In the page-builder case, the link to a submodule existed only at the |
The issue with |
I think it's okay to allow a code repository to contain submodules, because developer teams may need to use them. Since we do not pull or checkout any content for the submodules, I don't see major risks in explicitly avoiding them. For example, if a submodule was public, then nothing would've break, and the addition of a submodule would be less noticeable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, if there are no major concerns from anyone else about using submodules, then I'm good.
@bdenham, that means you can keep master as the source of truth for both scenarios you describe.
running tests |
Great. I'll keep it there since it will be a bit easier to keep doing the comparisons that way. @dshevtsov, I'm glad to hear you got an error on it last week. That was a head scratcher. Mystery solved. And thanks for the fix! |
Hi @dshevtsov, thank you for your contribution! |
Purpose of this pull request
This pull request (PR) updates rake update tasks:
How to test
Run
rake update:subrepos
(orrake update:all
)