Hook fails to build when unexpected configuration is found in `.goreleaser.yaml`

[jamietanna]

When using goreleaser version 1.22.1, and following https://goreleaser.com/quick-start/, running goreleaser init, we receive the following configuration:

# This is an example .goreleaser.yml file with some sensible defaults.
# Make sure to check the documentation at https://goreleaser.com

# The lines below are called `modelines`. See `:help modeline`
# Feel free to remove those if you don't want/need to use them.
# yaml-language-server: $schema=https://goreleaser.com/static/schema.json
# vim: set ts=2 sw=2 tw=0 fo=cnqoj

version: 1

before:
  hooks:
    # You may remove this if you don't use go modules.
    - go mod tidy
    # you may remove this if you don't need go generate
    - go generate ./...

builds:
  - env:
      - CGO_ENABLED=0
    goos:
      - linux
      - windows
      - darwin

archives:
  - format: tar.gz
    # this name template makes the OS and Arch compatible with the results of `uname`.
    name_template: >-
      {{ .ProjectName }}_
      {{- title .Os }}_
      {{- if eq .Arch "amd64" }}x86_64
      {{- else if eq .Arch "386" }}i386
      {{- else }}{{ .Arch }}{{ end }}
      {{- if .Arm }}v{{ .Arm }}{{ end }}
    # use zip for windows archives
    format_overrides:
      - goos: windows
        format: zip

changelog:
  sort: asc
  filters:
    exclude:
      - "^docs:"
      - "^test:"

When we run semantic-release (version v2.29.0), we receive the following error:

[go-semantic-release]: GoReleaser hook has failed: yaml: unmarshal errors:
  line 9: field version not found in type config.Project
[go-semantic-release]: stopping plugins...    

Ideally we would not fail for unexpected configuration, but I can imagine this may also be to protect us from running potentially newer version of goreleaser than we're expecting?

[christophwitzko]

Hi @jamietanna, thanks for reporting this. This is caused by the plugin bundling the goreleaser binary (currently v1.21.2), which does not support the version config yet.

I will update goreleaser later today, so this should fix this issue.

[jamietanna]

Thanks! It's not super problematic for me, as I've simply removed version for now :smile:

[jamietanna]

Actually out of interest, why do we vendor the goreleaser codebase instead of pulling it in as a dependency?

[christophwitzko]

We have to access some internal packages of goreleaser, which is only possible by checking-in the source code.

[christophwitzko]

I have updated the GoReleaser dependency to v1.23.0 https://github.com/go-semantic-release/hooks-goreleaser/releases/tag/v1.8.0

[jamietanna]

Ah interesting - is it something we'd be able to ask upstream to open up? Or anything we can get at with reflection?

[christophwitzko]

We are accessing the internal GoReleaser pipeline to modify the release version, as GoReleaser relies only on git tags as version source. https://github.com/go-semantic-release/hooks-goreleaser/blob/main/pkg/hooks/goreleaser.go#L46

I can absolutely understand the reasoning why the maintainers of GoReleaser decided to use internal packages for that, so probably not worth asking to change that.