Support for Phoenix Umbrella projects

[amacgregor]

Summary: Currently git_ops doesn't seem compatible with Phoenix umbrella projects.

Expected Behavior

Install git_ops on each one of the umbrella apps Inside the app folder execute mix git_ops.release --initial Git ops should initialize the project on the right context

Current Behavior

The following error happens when executing at

** (Git.Error) fatal: your current branch 'master' does not have any commits yet

    lib/git.ex:128: Git.result_or_fail/1
    lib/git_ops/git.ex:29: GitOps.Git.get_initial_commits!/1
    lib/mix/tasks/git_ops.release.ex:140: Mix.Tasks.GitOps.Release.get_commit_messages/4
    lib/mix/tasks/git_ops.release.ex:92: Mix.Tasks.GitOps.Release.run/1
    (mix) lib/mix/task.ex:331: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:79: Mix.CLI.run_task/2

Alternative

Installed at the main umbrella project resulted on a different failure where git_ops can't read the configuration from the child app.

[zachdaniel]

Yeah, there really isn't any good way to manage this with the current design of git_ops. It uses git tags to determine previous versions, and things like that. So you could maybe work it out where only one app in the umbrella is versioned with git_ops for now, but that probably wouldn't be worth it. I've been meaning to refactor git_ops to instead use like a git_ops.json file in the root (this could be in each project root). We could support git_ops in umbrellas then by keeping track of the last sha each project was released at. Additionally, there would be an important extra step if you want to manage multiple projects in one repo, you'd have to use a component in each commit to signify which commits apply to which project, so we could properly determine the next version. like fix(my_app_web, my_app_something): message

[zachdaniel]

Its a fair amount of work, though, and I don't really plan on doing it anytime soon.

[thiagomajesk]

I might be interested in this use case for a personal project...

I don't know if this would work but perhaps git_ops could rely on git submodules for separate releases and provide a mix git_ops.release --umbrella option that looks for those module tags.

I'm not sure if trying to circumvent git to do multiple releases under the same repo would be a good pattern though. Using multiple repos/ submodules seems very reasonable to me if you want to do multiple releases of independent apps. But it seems that there's another question here that is more important than how to implement releases with umbrella apps: "how to semver an umbrella app"; and that depends on how you release to your end-user. It's also important to reference the docs on this subject:

Umbrella projects are a convenience to help you organize and manage multiple applications. While it provides a degree of separation between applications, those applications are not fully decoupled, as they share the same configuration and the same dependencies.

If you find yourself in a position where you want to use different configurations in each application for the same dependency or use different dependency versions, then it is likely your codebase has grown beyond what umbrellas can provide.

[zachdaniel]

Agreed. Overall I doubt the juice is worth the squeeze, but git submodules could definitely be a solution, along with the umbrella release task. I'd happily review a PR to that effect.