Skip to content

Conversation

danbev
Copy link
Member

@danbev danbev commented Jun 26, 2025

This commit adds a should_release variable to the GitHub Actions workflow to determine if a release should be created based on the tag or branch conditions.

The motivation for this that it simplifies the logic for deciding whether to upload artifacts or not, making it easier to maintain if we need to change the conditions in the future.


Tested on my fork:

This commit adds a `should_release` variable to the GitHub Actions
workflow to determine if a release should be created based on the tag or
branch conditions.

The motivation for this that it simplifies the logic for deciding
whether to upload artifacts or not, making it easier to maintain if we
need to change the conditions in the future.
@ggerganov
Copy link
Member

What would be the steps to create a new release after these changes?

Currently, we do it like this:

  • Push commit with title "release : vX.Y.Z" (e.g. a8d002c)
  • Go to the Github UI and Draft a new release from master
  • Select to create a tag vX.Y.Z and write release summary
  • Publish and manually attach binaries

@danbev
Copy link
Member Author

danbev commented Jun 26, 2025

What would be the steps to create a new release after these changes?

With these changes it should be possible to push the new tag, which will build and publish a new release with that tag (including the artifacts). This is what I did to test this on my fork.

I'm not sure how this will fit in with the current work flow like the step "Select to create a tag vX.Y.Z and write release summary". Is this an option available when creating a tag in github UI?

Perhaps we could generate a draft release when a tag is pushed to master. So the release process would then become:

  • Create a tag and push it to master
    • This will create a draft release with all the release artifacts
  • Manually edit the draft to add the release summary.
  • Publish the release.

For example, this draft was created but pushing a tag, and this can be edited, and then published manually when we are ready.

@ggerganov Would this workflow work do you think?

@ggerganov
Copy link
Member

Perhaps we could generate a draft release when a tag is pushed to master. So the release process would then become:

  • Create a tag and push it to master

    • This will create a draft release with all the release artifacts
  • Manually edit the draft to add the release summary.

  • Publish the release.

For example, this draft was created but pushing a tag, and this can be edited, and then published manually when we are ready.

The link does not open, but the workflow sounds good to me.

@danbev
Copy link
Member Author

danbev commented Jun 26, 2025

The link does not open, but the workflow sounds good to me.

Ah sorry, I did not realize that it was not accessible. It should be available now as I've added you as a collaborator in case you want to take a look 👍

@danbev danbev merged commit 35034c5 into ggml-org:master Jun 26, 2025
55 checks passed
bygreencn added a commit to bygreencn/whisper.cpp that referenced this pull request Jun 29, 2025
* ggerganov/master: (72 commits)
  ci : use selective copy for musa image (ggml-org#3296)
  ci: set fail-fast to false in docker.yml (ggml-org#3294)
  ruby : add Whisper::VERSION (ggml-org#3292)
  whisper : add version function (ggml-org#3289)
  ci : add should_release variable (ggml-org#3288)
  docs : add cmake "-j" flag in README.md (ggml-org#3284)
  ci : add support for tag-based releases (ggml-org#3287)
  release : v1.7.6
  bench : update benches
  bench : print system info before ctx check
  stream : add nullptr check of whisper_context (ggml-org#3283)
  ci : enable main-cuda build (ggml-org#3282)
  bindings.java : update java example (ggml-org#3281)
  coreml : backport CoreML features to macos < 14 (ggml-org#3255)
  ci : reduce musa image size (ggml-org#3277)
  whisper : add .gitignore entries for OpenVINO support (ggml-org#3276)
  command: output commands to text file (ggml-org#3273)
  ci : add apt-get clean to musa Dockerfile (ggml-org#3275)
  ruby : specify Apple frameworks explicitly on build (ggml-org#3270)
  talk-llama : sync llama.cpp
  ...
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