Skip to content
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

Expose original non-replaced single artifact fields #3588

Closed
2 tasks done
Elara6331 opened this issue Nov 24, 2022 · 2 comments · Fixed by #3589
Closed
2 tasks done

Expose original non-replaced single artifact fields #3588

Elara6331 opened this issue Nov 24, 2022 · 2 comments · Fixed by #3589
Assignees
Labels
enhancement New feature or request

Comments

@Elara6331
Copy link
Contributor

Elara6331 commented Nov 24, 2022

Is your feature request related to a problem? Please describe.

GoReleaser exposes various information for single artifacts via templates, as mentioned in https://goreleaser.com/customization/templates/#single-artifact-extra-fields. I have binaries generated by xgo that need to be placed inside an archive. Binaries compiled by xgo use the Go naming convention for architectures, so amd64, arm64, etc.

I also instruct users to choose the correct file to download by using uname -m. This means I have to use replacements to make it match that convention (x86_64, aarch64, etc.).

This makes it impossible to use {{.Arch}} to select the correct binary.

Describe the solution you'd like

I'd like there to be new template fields for non-replaced values, maybe something like {{.OriginalArch}}

Describe alternatives you've considered

I could remove the replacements, but this would make it a lot harder for users to download the correct file for their machine. I could also use a template string with a bunch of if statements to convert it back, but that isn't a very good solution.

Search

  • I did search for other open and closed issues before opening this.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Additional context

No response

@Elara6331 Elara6331 added enhancement New feature or request triage Issue pending triage by one of the maintainers labels Nov 24, 2022
@caarlos0
Copy link
Member

caarlos0 commented Nov 24, 2022

I've been thinking more and more about actually dropping the replacements in favor of something else, because it is, well, a bit weird.

Anyway, in your case, you can drop the replacements thing, and set your archive.name_template like this:

archives:
  - name_template: >-
        {{- .ProjectName }}_{{ .Version }}
        {{- if eq .Os "darwin" }}Darwin{{ end }}
        // etc..
        {{- printf "_" }}
        {{- if eq .Arch "amd64" }}x86_64{{- end }}
        // etc

@caarlos0
Copy link
Member

refs #3589

caarlos0 added a commit that referenced this issue Nov 25, 2022
The replacements thing was always a bit weird, especially on archives.

We can solve that with templates, so, removing I'm deprecating it.

Also did the same on other places that had it the same feature.

Closes #3588

Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
@caarlos0 caarlos0 removed the triage Issue pending triage by one of the maintainers label Nov 25, 2022
gigerdo added a commit to gigerdo/ecctl that referenced this issue Oct 23, 2023
The 'replacements' parameter was removed in goreleaser. The name now has to be built directly in the file-name template.

(See: goreleaser/goreleaser#3588 (comment))
gigerdo added a commit to gigerdo/ecctl that referenced this issue Oct 23, 2023
The 'replacements' parameter was removed in goreleaser. The name now has to be built directly in the file-name template.

(See: goreleaser/goreleaser#3588 (comment))
gigerdo added a commit to elastic/ecctl that referenced this issue Oct 23, 2023
The 'replacements' parameter was removed in goreleaser. The name now has to be built directly in the file-name template.
(See: goreleaser/goreleaser#3588 (comment))

Also updates the branches workflow to directly create+commit to the new branch using the prebuilt GITHUB_TOKEN. This token has by default only read permissions, so write permissions are added to allow it create branches and commit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants