.goreleaser.yaml and GitHub action for Go Mono repo

[nourspace]

I'm dealing with a Go mono repo that has the following structure:

├── Dockerfile
├── cmd
│   ├── exampleclient/
│   ├── exampleserver/
│   ├── listener/
│   └── price/
├── go.mod
├── go.sum
├── internal
│   ├── database/
│   ├── exampleclient/
│   ├── exampleserver/
│   ├── listener/
│   ├── order/
│   └── price/
├── pkg
│   ├── db
│   └── proto

I want to push a tag exampleclient/v1.2.3 and get a release for that sub-project only. As you can see, however, the changes for a sub-project would be in different directories.

# subroj1/.goreleaser.yaml
project_name: subproj1

monorepo:
  tag_prefix: subproject1/
  dir: subproj1

https://goreleaser.com/customization/monorepo/#category-1

The above example assumes a single directory on the root will encapsulate everything related to a sub-project.

I'm unsure where to place the sub-project .goreleaser.yaml files. The example also doesn't expand on the config. Do we add the builds and dockers and other sections in the subprojeect configs?

I also could not find an example of a relevant GitHub action. I thought I could hack something up by creating multiple GoReleaser workflows, each of which gets triggered by certain tags and on certain files only. I wasn't sure, though, how GoReleaser would create a proper changelog.

[caarlos0]

Hey!

There's a full example here: https://github.com/goreleaser/example-monorepo

Basically, each folder has its own config, and the release workflow decides which config to use based on the tag.

Hope that helps!

[nourspace]

Thanks, @caarlos0. That was helpful. I might have missed that repo and been digging in the source code instead 😅.

One issue is still pending, though. The mono repo.dir only accepts a single item. In the example repo, it works, but in repos where subprojects have multiple folders, it won't.

[caarlos0]

for the changelog, right?

if so, you can set:

changelog:
  paths:
  - dir1
  - dir2

https://goreleaser.com/customization/changelog/

[nourspace]

Legend! Thanks a lot. I will try that and report, but changelog.paths seems to do it.