You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it stands, Uplift is designed to provide a release management strategy for standalone projects (repositories). And no easy way exists for managing other types of projects, such as monorepos. As the release strategy for a monorepo introduces additional complexity, an explicit operation should be introduced to Uplift to handle this.
Uplift needs to support running within the context of a sub-directory of a project and adopt both a tagging and changelog strategy that reflects this.
Your potential solution
Add a dedicated config (flags TBD) to switch Uplift into monorepo mode.
While in this mode:
A dedicated tag will label this a monorepo (component) release. This scheme should be flexible and support the proposed Go templating strategy
This tag will need additional processing to calculate the next semantic version. This tag will need to be handled correctly when generating a changelog and bumping files
When retrieving the git log the git command needs to be augmented to specify the monorepo directory. This will need to be reflected in both the semantic version and changelog tasks. This could be extended to grab the log from multiple directories if need be
For this initial work, an assumption will be made that each monorepo will contain its own .uplift.yml file
Any additional information?
No response
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
ga-paul-t
added
pinned
Prevent the issue from being automatically closed
and removed
wontfix
This will not be worked on
triage
Issue has been added to our triage list
labels
Feb 1, 2023
Describe your feature
As it stands, Uplift is designed to provide a release management strategy for standalone projects (repositories). And no easy way exists for managing other types of projects, such as monorepos. As the release strategy for a monorepo introduces additional complexity, an explicit operation should be introduced to Uplift to handle this.
Uplift needs to support running within the context of a sub-directory of a project and adopt both a tagging and changelog strategy that reflects this.
Your potential solution
Add a dedicated config (flags TBD) to switch Uplift into monorepo mode.
While in this mode:
For this initial work, an assumption will be made that each monorepo will contain its own
.uplift.yml
fileAny additional information?
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: