New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Support monorepos #723

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
6 participants
@tsenart

tsenart commented Jul 11, 2018

Vegeta hosts both a Go library and a CLI in a single repo. In that sense, it is a mono-repo, with multiple projects that ought to be versioned separately.

This version split only happened recently with this PR. When releasing, I found goreleaser didn't have a way of selecting which tags to use for a release.

I had to unblock myself and release Vegeta so I hacked my way in go-releaser. This proposal is not so much to bring in this code which is not robust enough in all likelihood. It's about discussing the idea of supporting monorepos which contain multiple independent components that ought to be versioned separately.

In my case, as convention, I decided to prefix all tags of a given component with the component's identifier (i.e. cli/v8.1.0, lib/v9.0.0).

@GitCop

This comment has been minimized.

GitCop commented Jul 11, 2018

There were the following issues with your Pull Request

  • Commit: 7993da9
  • Commits must be in the following format: %{type}: %{description}

Guidelines are available at https://github.com/goreleaser/goreleaser/blob/master/CONTRIBUTING.md#create-a-commit


This message was auto-generated by https://gitcop.com

GitHub
goreleaser - Deliver Go binaries as fast and easily as possible
@@ -82,7 +82,7 @@ func (t *Template) Apply(s string) (string, error) {
return "", err
}
sv, err := semver.NewVersion(t.fields[tag].(string))
sv, err := semver.NewVersion(t.fields[version].(string))

This comment has been minimized.

@caarlos0

caarlos0 Jul 11, 2018

Member

this is a good change anyways, can you open a separate PR with just this? Thanks!

@caarlos0

This comment has been minimized.

Member

caarlos0 commented Jul 11, 2018

To be honest, that's the first time I've seen two projects in the same git project with different tags... as far as I remember at least...

Not sure if that's a common use case.

Either way, we need to fix the packaging step, which if you have multiple builds, always archive all of them in the same archive - this is to allow people to release two projects, with the same version, on separated artifacts...

After that, we can work on something like this for sure... but It's uncharted waters for me. Will have to research first...

@caarlos0

This comment has been minimized.

Member

caarlos0 commented Jul 11, 2018

BTW: Vegeta is awesome, thanks for the great work on the project!!

@tsenart

This comment has been minimized.

tsenart commented Jul 12, 2018

To be honest, that's the first time I've seen two projects in the same git project with different tags... as far as I remember at least... Not sure if that's a common use case.

That will always be the case with monorepos if people need to release its components independently. Good links on monorepos: https://gomonorepo.org/

@jacekjagiello

This comment has been minimized.

jacekjagiello commented Jul 19, 2018

@caarlos0 I also think that support for monorepos is a good thing.

Monorepo in many cases, allows developers(and even whole teams) to work together faster. It simplifies things like dependency management, build and release configuration, CI pipelines or deployment process. Of course, structuring project in monorepo has it's cons too, but it's up to team to decide whenever or not they want to go with monorepo.

Nevertheless, more and more projects decide to go with monorepo structure. In Go I think monorepos are quite common because of the lightweight package system. Beside awesome Vegeta, I can highlight projects like:

Note the cmd directory that is used to separate source code to build binaries.

Other projects for management Go source code, already adapted to monorepo structured projects. For example in realize you can define in single configuration file multiple binaries to compile when source code changes.

I'm happy to help by contributing to this feature :)

@caarlos0

This comment has been minimized.

Member

caarlos0 commented Jul 19, 2018

Yeah, I didn't disagree about the usage of monorepos (which goreleaser already support), I just had never seen before things being tagged separately inside a monorepo... so, don't know how popular that is...

Either way, if we decide to do this thing with tags as proposed, I'll need some help, probably haha :D

@tsenart

This comment has been minimized.

tsenart commented Jul 19, 2018

Either way, if we decide to do this thing with tags as proposed, I'll need some help, probably haha :D

What do you need? :-)

@caarlos0

This comment has been minimized.

Member

caarlos0 commented Aug 20, 2018

I think that if are gonna support this tagging thing, we need at least it.

Meanwhile, I'll create a twitter poll to see if I can find out what people usually do. :)

@dpastoor

This comment has been minimized.

dpastoor commented Aug 20, 2018

Perhaps an issue or a wiki article where known monorepos are to use as a reference and a place to look at how they are currently releasing version(s)?

@caarlos0

This comment has been minimized.

Member

caarlos0 commented Aug 20, 2018

Link to the research, FWIW: https://twitter.com/caarlos0/status/1031516398315552769

Twitter
“I'm doing some research for @goreleaser, please RT for reach! 🚀

Regarding #monorepos, how to you release the different apps under it?”

@sidh

This comment has been minimized.

sidh commented Sep 19, 2018

Any status update on this? Any help needed with it?

I'm currently using goreleaser patched with proposed PR and it seems to work just fine.

@caarlos0

This comment has been minimized.

Member

caarlos0 commented Sep 19, 2018

only that we will move on with the tag prefixes thing, but I have other stuff on line before working on this.

@caarlos0 caarlos0 referenced this pull request Sep 19, 2018

Open

Road to v1.0.0 #807

2 of 5 tasks complete
@stale

This comment has been minimized.

stale bot commented Oct 31, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Oct 31, 2018

@sidh

This comment has been minimized.

sidh commented Nov 3, 2018

Some activity so it won't get closed.

@stale stale bot removed the wontfix label Nov 3, 2018

@stale

This comment has been minimized.

stale bot commented Nov 17, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Nov 17, 2018

@stale stale bot closed this Nov 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment