Repository navigation
Add support for submodules #90
Description
Activity
Thanks for the detailed context. Your understanding is right: submodules are not supported by
linear-releasetoday.The current limitation is that
linear-releaseonly scans the Git history of the repository it runs in. So when it runs from the root repo, it can see that a submodule pointer changed, but it won’t recurse into the submodule and scan the commits between the previous and current submodule SHAs.To make sure we’re thinking about the right solution, could you share a bit more about your workflow? In particular, are deployments triggered from the root repo only, and does each deployment correspond to one root commit plus the submodule SHAs pinned by that commit? Also, when a submodule pointer changes, do you already have a PR or commit in the root repo that represents that bump?
Thanks for looking into this, much appreciated! We’d love to use linear release, and this is I think the last thing blocking us.
are deployments triggered from the root repo only, and does each deployment correspond to one root commit plus the submodule SHAs pinned by that commit?
Yes, exactly!
when a submodule pointer changes, do you already have a PR or commit in the root repo that represents that bump?
I’m not sure I understand the question. Each submodule pointer change is triggered by a commit in the root repo (I don’t think there’s another way to change a submodule pointer?).
For various reasons we haven’t jumped on the monorepo train with our project and are using submodules for sub-components of our product. Reading the documentation it seems like submodules are not yet supported.
In order to associate issues fixed in submodules with Linear releases I think we’d need an option to have linear-release recurse into submodules to detect Linear issue references.
With this setup, linear-release would still only be called from the main (root) repo, and a release would still only be associated with a commit SHA from the main repo (as the submodule pointers are taken from that state of the main repo).
Your support suggested to manually scan the submodules in addition to the main repo, but I don’t think this would work for continuous pipelines, where every deployment creates a completed release. Also for scheduled pipelines it is unclear to me if a release can be associated with multiple repositories.