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

feat: Auto create release on merge to master #117

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

disaac
Copy link

@disaac disaac commented Feb 6, 2025

  • Updated build.sh script to support accepting an argument to run one of the build step functions. Using this to execute get_current_version to obtain the version number during workflow.
  • Added github-script steps in ci.yml to create a release and upload the workflow asset.

Fixes: issue #52

* Updated build.sh script to support accepting an argument to run one of the build step functions. Using this to execute `get_current_version` to obtain the version number during workflow.
*  Added github-script steps in ci.yml to create a release and upload the workflow asset.

Fixes: issue jsumners#52
Copy link
Owner

@jsumners jsumners left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for taking the time to work on this. I think that an auto-release on branch push is probably too aggressive. We don't always update the version in the same branch that gets merged from an improvement PR.

I think we should create a new workflow file named release.yml that keys on workflow_dispatch (https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow#configuring-a-workflow-to-run-manually). This would allow us to trigger a new release once we are ready instead of on every merged PR.

@disaac
Copy link
Author

disaac commented Feb 6, 2025

@jsumners no problem. Sounds good can make the change when I get sometime. Another option is to do it after a push tag event that's how I usually do it in projects but this requires a git push tags from project.

@jsumners
Copy link
Owner

jsumners commented Feb 6, 2025

@jsumners no problem. Sounds good can make the change when I get sometime. Another option is to do it after a push tag event that's how I usually do it in projects but this requires a git push tags from project.

That's how I typically do things in a Go based project. For this one, though, I think it would be better to use the dispatch approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants