add new workflow for go-releaser

pallasite99 commented 2 years ago

delete SLSA goreleaser workflow
as reported by a member, this does not publish go packages properly yet and is something different from what was planned
added new workflow goreleaser.yml and added a .goreleaser.yaml file generated by go-releaser tool
verified working on own public repo and here with a dry run

C:\Users\DELL\Documents\golang-template-repository>goreleaser release --snapshot --rm-dist
   • releasing...
   • loading config file       file=.goreleaser.yaml
   • loading environment variables
   • getting and validating git state
      • couldn't find any tags before "v1.0.0"
      • building...               commit=84fab1a7cd2733549d3111c001786bc42b962145 latest tag=v1.0.0
      • pipe skipped              error=disabled during snapshot mode
   • parsing tag
   • running before hooks
      • running                   hook=go mod tidy
      • running                   hook=go generate ./...
   • setting defaults
   • snapshotting
      • building snapshot...      version=1.0.1-next
   • checking distribution directory
      • --rm-dist is set, cleaning it up
   • loading go mod information
   • build prerequisites
   • writing effective config file
      • writing                   config=dist\config.yaml
   • building binaries
      • building                  binary=dist\golang-template-repository_darwin_arm64\cmd\build\bin
      • building                  binary=dist\golang-template-repository_linux_arm64\cmd\build\bin
      • building                  binary=dist\golang-template-repository_darwin_amd64_v1\cmd\build\bin
      • building                  binary=dist\golang-template-repository_linux_amd64_v1\cmd\build\bin
      • building                  binary=dist\golang-template-repository_windows_arm64\cmd\build\bin.exe
      • building                  binary=dist\golang-template-repository_windows_amd64_v1\cmd\build\bin.exe
   • archives
      • creating                  archive=dist\golang-template-repository_1.0.1-next_Windows_arm64.tar.gz
      • creating                  archive=dist\golang-template-repository_1.0.1-next_Linux_arm64.tar.gz
      • creating                  archive=dist\golang-template-repository_1.0.1-next_Windows_x86_64.tar.gz
      • creating                  archive=dist\golang-template-repository_1.0.1-next_Linux_x86_64.tar.gz
      • creating                  archive=dist\golang-template-repository_1.0.1-next_Darwin_x86_64.tar.gz
      • creating                  archive=dist\golang-template-repository_1.0.1-next_Darwin_arm64.tar.gz
   • calculating checksums
   • storing release metadata
      • writing                   file=dist\artifacts.json
      • writing                   file=dist\metadata.json
   • release succeeded after 16.60s

pallasite99 commented 2 years ago

We should add .goreleaser.yaml file as well.

Will add that, I think I have a reference linked shared by @haani-niyaz

pallasite99 commented 2 years ago

@vancanhuit Added a .goreleaser.yml file

pallasite99 commented 2 years ago

I think it would be better if we use generated .goreleaser.yaml file from goreleaser init command and then customize it from https://goreleaser.com/customization/.

cool, trying this then

pallasite99 commented 2 years ago

@vancanhuit added generated file and squashed commits

pallasite99 commented 2 years ago

@pallasite99 It looks good now but we are missing project_name (if you run goreleaser release --snapshot --rm-dist command on local, it will fail). Also it is good to specify dir, main, binary and goarch like documented here: https://goreleaser.com/customization/build/.

Feel free to add more options.

sure, I'll add what @haani-niyaz suggested to look at here. That will have all of this included in the builds section

pallasite99 commented 2 years ago

@vancanhuit made the changes and tested locally. Binary does get built now without any errors - so good to go from my end

haani-niyaz commented 2 years ago

@vancanhuit the project_name doesn't break the CI build. For this reason I wonder if we keep it commented out in the docs so that it is one less thing the users need to setup before they can consume the repo.

@pallasite99 appreciate the effort to try and get this over the line. I have however found another issue. The semantic-release workflow is what creates the release tag via the github-actions account. This is currently the trigger for the goreleaser workflow. However, there is a limitation documented:

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run.

This means it does not trigger the goreleaser workflow.

I think to get around this we should merge the 2. Add goreleaser as a job to the semantic-release workflow with a needs directive.

Here's a rough example workflow:

name: Release Package
on:
  push:
    branches:
      - main
jobs:
  tag:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version:
          - 16.x
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

  goreleaser:
    needs: [tag]
    runs-on: ubuntu-latest
    steps:
      -
        name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      -
        name: Fetch all tags
        run: git fetch --force --tags
      -
        name: Set up Go
        uses: actions/setup-go@v2
        with:
          go-version: 1.18
      -
        name: Run GoReleaser
        uses: goreleaser/goreleaser-action@v2
        with:
          # either 'goreleaser' (default) or 'goreleaser-pro'
          distribution: goreleaser
          version: latest
          args: release --rm-dist
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # Your GoReleaser Pro key, if you are using the 'goreleaser-pro' distribution
          # GORELEASER_KEY: ${{ secrets.GORELEASER_KEY }}

pallasite99 commented 2 years ago

@haani-niyaz I see what you mean, cool this can be done

pallasite99 commented 2 years ago

@haani-niyaz @vancanhuit I checked the semver part and it does work. Just a downside here was that I needed to change the root go.mod file to use 1.17 here without which the goreleaser workflow was failing here on GH.

lgtm otherwise and can be merged. I've changed the run strategy to push (main branch) + release to account for semver changes ... if the release part is not needed lmk, will remove that

haani-niyaz commented 2 years ago

@haani-niyaz @vancanhuit I checked the semver part and it does work. Just a downside here was that I needed to change the root go.mod file to use 1.17 here without which the goreleaser workflow was failing here on GH.

lgtm otherwise and can be merged. I've changed the run strategy to push (main branch) + release to account for semver changes ... if the release part is not needed lmk, will remove that

@pallasite99 I didn't encounter an issue with go 1.18 in my test pipeline. See repo, releases etc. https://github.com/haani-niyaz/semantic-release-testing

If we do keep 1.17, we'll be shipping a broken workflow if repo owners decide to update go.mod to 1.18 so this not feasible.

pallasite99 commented 2 years ago

@haani-niyaz I got this error right after introducing the semver changes here so I would probably need some more info. I haven’t worked much with CI directly before

it mentioned that the max compatible version is 1.17 but you have specified 1.18

haani-niyaz commented 2 years ago

@haani-niyaz I got this error right after introducing the semver changes here so I would probably need some more info. I haven’t worked much with CI directly before

it mentioned that the max compatible version is 1.17 but you have specified 1.18

Np, I'll take a look.

pallasite99 commented 2 years ago

@haani-niyaz This is the error I'm facing with 1.18 set for go.mod file:

release failed after 0serror=hook failed: go mod tidy: exit status 1; output: go mod tidy: go.mod file indicates go 1.18, but maximum supported version is 1.17

haani-niyaz commented 2 years ago

@pallasite99 this might be the fix:

steps:
      - name: Setup Go
        uses: actions/setup-go@v3
        with:
          go-version: "1.18.0"

Ref: https://github.com/actions/setup-go/issues/206#issuecomment-1077642621

pallasite99 commented 2 years ago

@haani-niyaz made the requested changes and verified locally as a sanity check

shukra-in-spirit commented 2 years ago

Just to add a note: Great work on the reviews @haani-niyaz @vancanhuit. Really appreciate your dedication and promptness in fixing the issues @pallasite99. Thank you buddy.