Skip to content

Homebrew Casks

This will be available in the next release (v2.10). Stay tuned!

After releasing to GitHub, GitLab, or Gitea, GoReleaser can generate and publish a Homebrew Cask into a repository (Tap) that you have access to.

The homebrew_casks section specifies how the cask should be created. You can check the Homebrew Cask documentation, for more details.

.goreleaser.yaml
homebrew_casks:
  -
    # Name of the cask
    #
    # Default: the project name.
    # Templates: allowed.
    name: myproject

    # Alternative names for the current cask.
    #
    # Useful if you want to publish a versioned cask as well, so users can
    # more easily downgrade.
    #
    # This feature is only available in GoReleaser Pro.
    # Templates: allowed.
    alternative_names:
      - myproject@{{ .Version }}
      - myproject@{{ .Major }}

    # IDs of the archives to use.
    # Empty means all IDs.
    ids:
      - foo
      - bar

    # Binary name inside the cask
    #
    # Default: the cask name.
    # Templates: allowed.
    binary: myapp

    # Path to the manpage file
    #
    # Templates: allowed.
    manpage: man/myapp.1

    # Completions for different shells
    #
    # Templates: allowed.
    completions:
      bash: completions/myapp.bash
      zsh: completions/myapp.zsh
      fish: completions/myapp.fish


    # NOTE: make sure the url_template, the token and given repo (github or
    # gitlab) owner and name are from the same kind.
    # We will probably unify this in the next major version like it is
    # done with scoop.

    # URL which is determined by the given Token (github, gitlab or gitea).
    #
    # Default depends on the client.
    # Templates: allowed.
    url_template: "https://github.mycompany.com/foo/bar/releases/download/{{ .Tag }}/{{ .ArtifactName }}"

    # Git author used to commit to the repository.
    # Templates: allowed.
    commit_author:
      name: goreleaserbot
      email: [email protected]

    # The project name and current git tag are used in the format string.
    #
    # Templates: allowed.
    commit_msg_template: "Brew cask update for {{ .ProjectName }} version {{ .Tag }}"

    # Directory inside the repository to put the cask.
    # Default: Casks
    directory: Casks

    # Caveats for the user of your binary.
    caveats: "How to use this binary"

    # Your app's homepage.
    #
    # Default: inferred from global metadata.
    homepage: "https://example.com/"

    # Your app's description.
    #
    # Templates: allowed.
    # Default: inferred from global metadata.
    description: "Software to create fast and easy drum rolls."

    # SPDX identifier of your app's license.
    #
    # Default: inferred from global metadata.
    license: "MIT"

    # Setting this will prevent goreleaser to actually try to commit the updated
    # cask - instead, the cask file will be stored on the dist directory
    # only, leaving the responsibility of publishing it to the user.
    # If set to auto, the release will not be uploaded to the homebrew tap
    # in case there is an indicator for prerelease in the tag e.g. v1.0.0-rc1
    #
    # Templates: allowed.
    skip_upload: true

    # Custom block for brew.
    # Can be used to specify alternate downloads for devel or head releases.
    custom_block: |
      head "https://github.com/some/package.git"
      ...

    # Dependencies for the cask.
    dependencies:
      - cask: some-cask
      - formula: some-formula

    # Packages that conflict with your cask.
    conflicts:
      - cask: some-cask
      - formula: some-formula

    # Hooks for the cask lifecycle.
    hooks:
      pre:
        install: |
          system_command "/usr/bin/defaults", args: ["write", "com.example.app", "key", "value"]
        uninstall: |
          system_command "/usr/bin/defaults", args: ["delete", "com.example.app"]
      post:
        install: |
          system_command "/usr/bin/open", args: ["#{appdir}/MyApp.app"]
        uninstall: |
          system_command "/usr/bin/rm", args: ["-rf", "~/.myapp"]

    # Relative path to a Service that should be moved into the
    # ~/Library/Services folder on installation.
    service: "myapp.service"

    # Additional procedures for a more complete uninstall, including user files
    # and shared resources.
    zap:
      launchctl:
        - "my.fancy.package.service"
      quit:
        - "my.fancy.package"
      login_item:
        - "my.fancy.package"
      trash:
        - "~/.foo/bar"
        - "~/otherfile"
      delete:
        - "~/.foo/bar"
        - "~/otherfile"

    # Procedures to uninstall a cask.
    # Optional unless a pkg or installer artifact stanza is used.
    uninstall:
      launchctl:
        - "my.fancy.package.service"
      quit:
        - "my.fancy.package"
      login_item:
        - "my.fancy.package"
      trash:
        - "~/.foo/bar"
        - "~/otherfile"
      delete:
        - "~/.foo/bar"
        - "~/otherfile"

    # Repository to push the generated files to.
    repository:
      # Repository owner.
      #
      # Templates: allowed.
      owner: caarlos0

      # Repository name.
      #
      # Templates: allowed.
      name: my-repo

      # Optionally a branch can be provided.
      #
      # Default: default repository branch.
      # Templates: allowed.
      branch: main

      # Optionally a token can be provided, if it differs from the token
      # provided to GoReleaser
      #
      # Templates: allowed.
      token: "{{ .Env.GITHUB_PERSONAL_AUTH_TOKEN }}"

      # Optionally specify if this is a token from another SCM, allowing to
      # cross-publish.
      #
      # Only taken into account if `token` is set.
      #
      # Valid options:
      # - 'github'
      # - 'gitlab'
      # - 'gitea'
      #
      # This feature is only available in GoReleaser Pro.
      token_type: "github"

      # Sets up pull request creation instead of just pushing to the given branch.
      # Make sure the 'branch' property is different from base before enabling
      # it.
      #
      # This might require a personal access token.
      pull_request:
        # Whether to enable it or not.
        enabled: true

        # Whether to open the PR as a draft or not.
        draft: true

        # If the pull request template has checkboxes, enabling this will
        # check all of them.
        #
        # This feature is only available in GoReleaser Pro, and when the pull
        # request is being opened on GitHub.
        check_boxes: true

        # Base can also be another repository, in which case the owner and name
        # above will be used as HEAD, allowing cross-repository pull requests.
        base:
          owner: goreleaser
          name: my-repo
          branch: main

      # Clone, create the file, commit and push, to a regular Git repository.
      #
      # Notice that this will only have any effect if the given URL is not
      # empty.
      git:
        # The Git URL to push.
        #
        # Templates: allowed.
        url: 'ssh://[email protected]:repo.git'

        # The SSH private key that should be used to commit to the Git
        # repository.
        # This can either be a path or the key contents.
        #
        # IMPORTANT: the key must not be password-protected.
        #
        # WARNING: do not expose your private key in the configuration file!
        #
        # Templates: allowed.
        private_key: '{{ .Env.PRIVATE_KEY_PATH }}'

        # The value to be passed to `GIT_SSH_COMMAND`.
        # This is mainly used to specify the SSH private key used to pull/push
        # to the Git URL.
        #
        # Default: 'ssh -i {{ .KeyPath }} -o StrictHostKeyChecking=accept-new -F /dev/null'.
        # Templates: allowed.
        ssh_command: 'ssh -i {{ .Env.KEY }} -o SomeOption=yes'
Template Language

Discover more about the name template engine.

Versioned Casks

GoReleaser Pro

One or more features are exclusively available with GoReleaser Pro.

GoReleaser can also create a versioned Cask. For instance, you might want to make keep previous minor versions available to your users, so they easily downgrade and/or keep using an older version.

To do that, use alternative_names:

.goreleaser.yaml
homebrew_casks:
  - name: foo
    alternative_names:
      - "foo@{{ .Major }}.{{ .Minor }}"
    # other fields

So, if you tag v1.2.3, GoReleaser will create and push foo.rb and [email protected].

Later on, you can tag v1.3.0, and then GoReleaser will create and push both foo.rb (thus overriding the previous version) and [email protected]. Your users can then brew install [email protected] to keep using the previous version.

GitHub Actions

To publish a cask from one repository to another using GitHub Actions, you cannot use the default action token. You must use a separate token with content write privileges for the tap repository. You can check the resource not accessible by integration for more information.

Limitations

  • Only one GOARM build is allowed;

Pull Requests

GoReleaser allows you to, instead of pushing directly to the main branch, push to a feature branch, and open a pull requests with the changes.

Templates

GoReleaser will check for a .github/PULL_REQUEST_TEMPLATE.md, and set it in the pull request body if it exists.

We do that to prevent extra work for maintainers of things like winget-pkgs, nixpkgs, and so on.

Cross-repository pull requests

You can also push to a fork, and open the pull request in the original branch.

Here's an example on how to set it up:

.goreleaser.yaml
# ...
something: # can be nix, brews, etc...
  - repository:
      owner: john
      name: repo
      branch: "{{.ProjectName}}-{{.Version}}"
      pull_request:
        enabled: true
        base:
          owner: mike
          name: repo
          branch: main

This will:

  • Try to sync the john/repo fork with mike/repo:main (if on GitHub).
  • Create the files into john/repo, in the branch foo-1.2.3 (assuming ProjectName=foo and Version=1.2.3). 1
  • Open a pull request from john/repo into mike/repo, with the branch main as target. 2

Things that don't work

  • Opening pull requests to a forked repository (go-github does not have the required fields to do it).
  • Since this can fail for a myriad of reasons, if an error happen, it'll log it to the release output, but will not fail the pipeline.

  1. In GitHub's terms, this means head=john:repo:foo-1.2.3 

  2. In GitHub's terms, this means base=mike:repo:main