Fixing Github action for nightly build and release

[salehkhazaei]

Right now every merge on dev results in a pre-release build. Also all the merged into main result in release build.

Since we're using go-releaser we have to remove these two lines for merging from dev to main. prerelease: "true" make_latest: false

[salehkhazaei]

we want to switch branching to Github-flow. All the releases must happen on git tags.

[ADorigi]

Regarding the nightly builds:

• Should we replace the builds for every push to dev with nightly builds, or should the nightly builds be independent of pre-release builds?

With regards to Git tags:

• I understand that we are currently creating the tags and then generating the corresponding release artifacts. Does that need to change?

Additionally, is there a specific reason we are using GH_TOKEN for authenticating the workflows instead of the built-in GITHUB_TOKEN? I believe using the built-in token is a better approach, as it eliminates the need to maintain a separate secret in the repository. We can fine tune the token's permissions in individual workflows.

[salehkhazaei]

Hi @ADorigi Thanks for picking up this issue.

We want to migrate from Git flow to Github flow for our branching. this will help us move faster. but since we dont have proper testings in place we can't have releases on each merge. So, right now the target is to have one main branch and feature branches merging into it and we wont have dev branch anymore. once we are sure everything is ok we will push a tag on main branch and the release github action should run on the tag

also, we dont want to have a pre-release on every single merge commit. I'm not sure whether to go with nightly builds or having manual tags for pre-releases and I'm open to ideas/discussions. To keep it simple, we can do pre-release on tags as well for now and see if it works for us.

On GH_TOKEN, we needed some access which wasn't available on the built-in token and changing it was disable we didn't do proper investigation on how we can solve it and got around it by introducing another secret. but you're right, the correct approach is to use the built-in token and we also had it in mind to fix it later.

[ADorigi]

Thank you for the clarification. I will try to modify the workflow to accommodate running on a manual tag push. For now, we can go with the same manual tag push for pre-release. It will be easier to modify this once the workflow is in place. I will try to see if we can integrate the built-in token in a future pull request, to avoid making multiple changes in a single update.

[ADorigi]

I have created a pull request with changes to allow running the main workflow with a tag push - #150

[ADorigi]

Created draft pull request for addressing this issue with the additional scope. - #157