Updating workflows

[ADorigi]

Description

Fixes #136 For the end user, there are no noticeable changes. The main workflow has been updated internally without altering its results. Additionally, the workflows homebrew-bump-debug and dev.yaml have been replaced by pre-release.yaml and test.yaml. The goreleaser.yml configuration and the accompanying Makefile have also been modified to extend their usage beyond the main workflow. Now, the goreleaser.yml configuration serves as a single source of truth for all builds.

Scope of the Pull Request

• Modified main workflow to accommodate the shift to GitHub flow.
• Changes the approach to publishing to homebrew
  • Now handled by goreleaser
  • an autogenerated formula will replace the homebrew formula in homebrew-cli-tap. The end usage of tap remains the same.
• The pre-release workflow now runs at 00:00 UTC every day, or it can be triggered manually.
• the test workflow runs on any commit or pull request to the main branch. However, it will build using the same goreleaser configuration, without creating a release or publishing packages, ensuring the build in other workflows will succeed after it is merged.

Summary of changes

• Main Workflow
  • The pipeline will trigger on a tag push of the form v[0-9]+.[0-9]+.[0-9]+. eg v1.2.3
  • Added env context variables at workflow scope, to facilitate modification.
  • Removed the tag job from the workflow
  • Release job
  • bumped setup-go to v5
  • removing Chocolatey API key for goreleaser
  • adding details for HomeBrew
  • removed release downloader and homebrew steps
  • Sign Windows job
  • settings its tag for use
  • avoided change in this as it needs further investigation
• Pre-release Workflow
  • scheduled to run at midnight(00:00) in UTC, by manual trigger, or by pushing -rc tags
  • Added env context variables at workflow scope, to facilitate modification.
  • preserves automatic tagging for pre-releases.
  • updated environment variables for goreleaser step
  • pre-release job will not update brew tap.
• Test workflow
  • runs on push to main
  • only tests whether a build can be successfully created with current changes
• Goreleaser
  • update the use of variables from workflow template
  • updated id of goreleaser archives for homebrew compatibility. The end-generated release archives remain the same.
  • added brews step
• Makefile
  • clean: removes the folder dist for creating a clean build
  • goreleaser: creates a build for current GOOS and GOARCH in the dist folder, using the goreleaser.yml configuration

The new steps which will trigger the release workflow:

• pushing a tag similar to v1.2.3
• workflow trigger for chocolatey

The new steps which will trigger the pre-release workflow:

• pushing a tag similar to v1.2.3-rc.4
• nightly builds at 00:00 in UTC
• manually triggering

The new steps which will trigger the test workflow:

• any merge or commit to main branch

Test Workflow for Repository Updates

1. Duplicate Branch:

   • Duplicated the updating-workflows branch in my forked repository - test-updating-workflows

2. Make Changes and Test:

   • Made changes to the branch in my repository.
   • Pushed these changes to trigger the test workflow.

3. Create and Push Tag for Release:

   • Created a tag v3.0.0 locally.
   • Pushed the tag, triggering the main workflow to create the release for v3.0.0.

4. Trigger Pre-release Manually:

   • Manually triggered the pre-release workflow.
   • pre-release workflow triggered, creating release v3.0.1-rc.0.

5. Simulate Change and Test:

   • Simulated a change in the branch and pushed it, triggering the test workflow.

6. Create and Push Tag for Pre-release:

   • Created a tag v3.0.1-rc.1 locally.
   • Pushed the tag, triggering the pre-release workflow to create the release v3.0.1-rc.1.

What type of PR(Pull Request) is this?

• [ ] 🐛 Bug Fix
• [ ] 🍕 New Feature
• [ ] 🔥 Performance Improvement
• [ ] 📝 Documentation update
• [x] ✅ Test
• [x] 🤖 Build
• [x] 📦 Release
• [x] 🔁 CI/CD

  Added to documentation?

• [ ] 📜 README.md
• [ ] 🤝 CONTRIBUTING.md
• [ ] 🙅 no documentation needed

[ADorigi]

Please let me know if I can elaborate on any piece of the PR.

In regards to the GH_TOKEN, I believe we would need to keep using the same. Internal token only provides us access to the components of the current repository. Since our Homebrew Tap is a different repository, a PAT, similar to the one we are currently using, would be more suitable in this scenario.

[ADorigi]

Hello @artaasadi , responding to your comment on #150 As pointed out by Saleh, we will eventually shift to completely automated process for the releases. But while we are developing the other parts, this solution gives us control of the release with manual tag push. We can easily bring back the tag generation step if required. Nevertheless, let me know if you would like me to revert this.

[ADorigi]

Todo: Modifying dev pipeline for nightly and prerelease builds

[ADorigi]

Pre-release workflow configured for nightly and pre-release builds. A new workflow was created for the test workflow.

[salehkhazaei]

LGTM