Release to GitLab

[jorinvo]

As @bernardoVale mentioned #on Slack it would be nice to support releasing to GitLab.
There is a Go package for the API https://github.com/xanzy/go-gitlab.
Since we also plan on adding Bintray support in #15 we might be able to combine some of the releasing logic.

[jorinvo]

Currently we parse the default repository to push to from the git remote.
We explicitly check for "github" (https://github.com/goreleaser/goreleaser/blob/master/pipeline/defaults/remote.go#L21).
But we could also make this more general and map from the detected remote to a service.

This would allow using GitLab without any configuration.

But for Bintray we would need additional configuration.

And we should also support use cases where people like to upload to multiple services.

I also think in some scenario a user might not want to upload the release at all and instead has a custom script or some manual process to run after GoReleaser is done (Maybe I should open another issue to make this a separate feature request).

Anyways, I think we should keep it simple so that a user doesn't need any configuration for the most basic use case and can use GiHub and GitLab out of the box.

For customisations we should probably split the release section by service.
For GitHub we currently only have one setting, but for other services there might be more options to set later on. Therefore I would create a config object per service:

release:
  github: 
    repo: user/repo
  gitlab: 
    repo: user/repo
  bintray:
    ...

This would break the current configuration format. We could think about creating an alias from release.repo to release.github.repo.

We could also think about removing the release section completely and adding each service on the top level to the configuration.
brew is kind of the same as those other services to release to. Would be better to handle them all the same way I think.

And all service specific authentication I would handle via env vars like we already do for GitHub.

What do you think @caarlos0 @jspc?

[caarlos0]

@jspc yeah, I have a WIP stash on my machine that does basically that...

The only problem I see (and was also present on my branch) is that this allows both github and gitlab repo to be setup and also doesn't support custom hosts (github enterprise, gitlab hosted, etc).

Maybe we should do something like this:

release:
  repo:
    provider: github
    name: user/repo
    host: my.server.com

(all of which can be parsed from git remote)

[jorinvo]

@caarlos0 does this configuration format allow using multiple providers at the same time?
And what do you think about seeing Homebrew releasing on the same level as GitHub, GitLab, ...?

[zet4]

If GitLab support was to be added, would Gogs/Gitea be supported as well?

[jorinvo]

@zet4 would be great to support them as well!
Haven't looked into their API but as soon as we set up the architecture correctly it should be simple to add new providers.

[caarlos0]

@jorinvo no... that's kind of the idea actually... I'm not sure if it is a use case to have the same repo in multiple providers and to release to all of them... what do you think?

[caarlos0]

@zet4 yeah, if there is an api, why not, right? 😄

[jorinvo]

@caarlos0 I think it's difficult do see which ways people intend to use the projects.
I also only use one provider at a time. I don't mind keeping it simple for now.

One more thing: Is the repo sub-section in release necessary? Couldn't be the options directly part of release?

[caarlos0]

@jorinvo it's not necessary, but looks better IMHO...

For example, have a release.host property may not be clear enough... I think release.repo.host looks better in that sense...

Also, we may just use the same syntax in brew section, for example... and maybe other in the future...

[jorinvo]

@caarlos0 sure, can leave it like this.

Have you started implementing GitLab support already or are you changing the general setup first?

If I can help implementing GitLab support or maybe Gogs/Gitea support, let me know!

[caarlos0]

@jorinvo I just have a wip in my stash, will see what I can commit already so we can split the work like you suggested (one work on gitlab support and the other on gogs, gittea, etc)

[caarlos0]

@jorinvo actually, my stash is just wrong right now.

I'll add just the config part today, and then we can split the work =)

[thehowl]

To recap some of the info I shared on Slack, regarding this issue:

1. GitLab does not provide a way to really attach release binaries to tags/releases - the only thing you can really do is using "attach a file", which uploads the file to GitLab's server and then uses its link and places it as markdown. This definitely feels like a hack. image
2. Instead, what GitLab seems to do is to place artifacts from the tests to the release tags (e.g.).
3. It's probably best, instead of using goreleaser, to create a good build CI file that will build release binaries as artifacts when there is a new tag (i plan to document this sometime in the future).
4. One possible thing to do could be that for GitLab, goreleaser only writes the build notes with the changelog.

[sfaujour]

Are you currently working on it? :)

[andygrunwald]

Seems that no one has a work in progress online right now.
I might be benefit from this feature as well, but self hosted gitlab instances should be supported, too.

When someone starts working on this, can we agree that you post it quickly here to avoid double work on this? Would be sad to spend several hours and than finding out that someone else is working on it, because i think the time can spent on other features / fixes as well. Thank you 👍

Gitlab supports releases, but in a different form like Github with attaching binaries.
IMO it is not a hack. This is how Gitlab decided to support this. So i would vote for this way.

Here are a few reference links to get more information about this:

• Gitlab REST API: Create a new release
• Gitlab REST API: Upload a file
• GitLab 8.2 released with Award Emoji and Repository Mirroring

[stale]

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.

[andygrunwald]

Comment to prevent that the stale bot closes this. I still think this is useful.

[adeesent]

Totally agree!

[caarlos0]

Hey - we use also Gitlab and would be interested in getting this worked on. I would not mind starting work on this as it would make life easier ;)

I have created fork RafPe/goreleaser and would be great if we could narrow down where would be best to start with tackling this :D

Input much welcome!

hey @RafPe , probably the starting point is to create a gitlab client in the clients pkg. After that, probably the release pipe...

[RafPe]

Ok - I'm on it - Will do some play around over the weekend and see if we get something usable to test ;)

[caarlos0]

Nice, let me know if you need anything :)

[RafPe]

@caarlos0 how open are we to potential changes in the way client is build ? I could come up with something like this to simplify it for future use ( its subjective point of view of course :) )

type Client struct {

	config *ConfigType

	// Providers which we can use to create releases.
	Github             *GithubService
	Gitlab             *GitlabService
}

// Then in seperated provider 
type GithubService struct {
	client *Client
}


func (s *GithubService) CreateRelease(ctx *context.Context, body string) (releaseID int64, err error) {

}

func (s *GithubService) CreateFile(ctx *context.Context, commitAuthor config.CommitAuthor, repo config.Repo, content bytes.Buffer, path, message string) (err error) {

}

func (s *GithubService) Upload(ctx *context.Context, releaseID int64, name string, file *os.File) (err error) {

}

Then we create client and have access to all release providers. Input much welcome :D

[stale]

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.

[caarlos0]

@RafPe I don't like it very much, no, because the GithubService will have a client that also implements gitlab...

testing may get harder too, since we will need to mock more things...

also brew pipeline also uses the client, and would require a lot of change for everything to work as well...

[caarlos0]

PS: I don't know what's the best way to do this though...

[joerocklin]

@caarlos0 is the idea to be able to publish to both gitlab and github from the same release process, or only supporting one at a time? (I personally don't see much use for use in a single release).

I have not spent a lot of time in the code, but it would seem like defining a ProviderInterface for the client to reference and then set up either github or gitlab based on the config read could work well.

I wish I had time to prototype something right now, but I'm fully loaded with work.

[caarlos0]

yeah, I agree with releasing to both github and gitlab...

[dAnjou]

I'm currently working on a way to use GitLab CI and GitLab Pages for a releases website, a PoC is already working. Now I'm trying to do most of it with GoReleaser.

Repo: https://gitlab.com/dAnjou/goup (see .gitlab-ci.yml)
Website: https://danjou.gitlab.io/goup/

It's still very much a WIP, keep that in mind.

GitLab

Max Ludwig / goup

Small HTTP file server and uploader - https://danjou.gitlab.io/goup/

Goup

[stale]

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.

[wburningham]

@caarlos0 I started down the path of adding GitLab support. Adding a client/gitlab.go file is the easy part.
More complexity comes when pipeline/release/release.go, pipeline/brew/brew.go, and pipeline/scoop/scoop.go reference GitHub variables on the context/config.

Is there a strong desire to support releasing to both GitHub and GitLab? The code could be simplified if the assumption that it was GitHub or Gitlab (ie when the config is loaded we use a custom yaml unmarshaler to add Repo variables on the config that can be populated from GitHub setting or GitLab settings. The three files above would read from the Repo variables on the context/config rather from the GitHub variables.

Note: When I say "GitHub variables" I mean:

ctx.Config.GitHubURLs.*
ctx.Config.Release.GitHub.*
ctx.Config.Brew.GitHub.*
ctx.Config.Scoop.Bucket.*

which would become the "Repo variables":

ctx.Config.RepoURLs.*
ctx.Config.Release.Repo.*
ctx.Config.Brew.Repo.*
ctx.Config.Scoop.Repo*

Also note:
The custom YAML unmashaler would preserve backward compatibility for existing .goreleaser.yaml files. The internal Config data structure would not match 1:1 with what is in the .goreleaser.yaml.

[joerocklin]

@wburningham This is what I was trying to ask but didn't do a very good job. I don't see a lot of value in deploying to github and gitlab in the same release config. My use would be satisfied by releasing to one or the other in a single config.

[wburningham]

My use case would also be satisfied if it released to one or the other in a single config. I don't know why you would send to both if homebrew or scoop only reference one source for downloads.

[caarlos0]

Yeah, I guess that makes sense as well... if people ask for it, we may change it later...

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.