[GH-ISSUE #119] Showcase how to create an up-to-date pending changelog

kerem commented

2026-03-04 00:40:46 +03:00

Owner

Originally created by @pat-s on GitHub (Oct 18, 2024).
Original GitHub issue: https://github.com/thegeeklab/git-sv/issues/119

Not a request, just some thoughts (that could potentially be a nice addition to the README):

git sv release-notes creates the currently pending changelog for the next upcoming version.

In the current CI runs of this repo there is already a step that generates those (github.com/thegeeklab/git-sv@647aa9cf53/.woodpecker/build-package.yml (L20-L25)) but only publishes them on a tag event.

Arguably, a pending changelog that is somewhat visible and easy to find while at the same time unintrusive can be beneficial for certain projects. I was thinking about this coming from the plugin-release-ready-go plugin. I like that git-sv is a lot more lightweight and doesn't keep a static PR that even triggers all pull_request workflows by default.

A middle-way between a static PR and local invocation could be to have a dedicated pipeline (instead of a step) that just cats the pending release notes.
I don't see an easy way to dynamically infer the link to the respective latest pipeline execution (to add this then to the README), so the README would likely need a statement like "for the pending changelog, visit the "changelog" pipeline of the most recent CI run of the main branch").

PS: very nice work overall! 👍️

Originally created by @pat-s on GitHub (Oct 18, 2024). Original GitHub issue: https://github.com/thegeeklab/git-sv/issues/119 Not a request, just some thoughts (that could potentially be a nice addition to the README): `git sv release-notes` creates the currently pending changelog for the next upcoming version. In the current CI runs of this repo there is already a step that generates those (https://github.com/thegeeklab/git-sv/blob/647aa9cf538545142d7877c5af9015f663947063/.woodpecker/build-package.yml#L20-L25) but only publishes them on a `tag` event. Arguably, a pending changelog that is somewhat visible and easy to find while at the same time unintrusive can be beneficial for certain projects. I was thinking about this coming from the `plugin-release-ready-go` plugin. I like that `git-sv` is a lot more lightweight and doesn't keep a static PR that even triggers all `pull_request` workflows by default. A middle-way between a static PR and local invocation could be to have a dedicated *pipeline* (instead of a step) that just `cat`s the pending release notes. I don't see an easy way to dynamically infer the link to the respective latest pipeline execution (to add this then to the README), so the README would likely need a statement like "for the pending changelog, visit the "changelog" pipeline of the most recent CI run of the main branch"). PS: very nice work overall! 👍️

kerem closed this issue

2026-03-04 00:40:47 +03:00

kerem commented

2026-03-04 00:40:48 +03:00

Author

Owner

@xoxys commented on GitHub (Oct 20, 2024):

Personally, I would use an issue e.g. something like the renovate dashboard to always show the upcoming release changelog but I dont think I would like to implement it for this repo.

@xoxys commented on GitHub (Oct 20, 2024): Personally, I would use an issue e.g. something like the renovate dashboard to always show the upcoming release changelog but I dont think I would like to implement it for this repo.

kerem commented

2026-03-04 00:40:48 +03:00

Author

Owner

@pat-s commented on GitHub (Oct 20, 2024):

An issue would be neat indeed. I also thought about this but had the impression that this tool wants to avoid forge-specific code/actions and aims to only interact with the local git information. Which is why I focused on the "link to the latest CI run" idea.

But yes, I also think that this would be great. It would also solve the issue of the plugin-ready-release plugin which always triggers unrelated checks for every changelog update.

@pat-s commented on GitHub (Oct 20, 2024): An issue would be neat indeed. I also thought about this but had the impression that this tool wants to avoid forge-specific code/actions and aims to only interact with the local git information. Which is why I focused on the "link to the latest CI run" idea. But yes, I also think that this would be great. It would also solve the issue of the `plugin-ready-release` plugin which always triggers unrelated checks for every changelog update.

kerem commented

2026-03-04 00:40:48 +03:00

Author

Owner

@xoxys commented on GitHub (Oct 20, 2024):

I don't want to implement it in this repo as, indeed, the tool should stay independent of a forge. My suggestion would to use preferred CI system to update a forge issue on every commit to the default branch.

@xoxys commented on GitHub (Oct 20, 2024): I don't want to implement it in this repo as, indeed, the tool should stay independent of a forge. My suggestion would to use preferred CI system to update a forge issue on every commit to the default branch.

kerem commented

2026-03-04 00:40:48 +03:00

Author

Owner

@xoxys commented on GitHub (Oct 21, 2024):

I'm going to close this issue for now. If you have built something like that and want to document it, I'm happy to add it to the readme. Hope that's fine for you.

@xoxys commented on GitHub (Oct 21, 2024): I'm going to close this issue for now. If you have built something like that and want to document it, I'm happy to add it to the readme. Hope that's fine for you.

kerem commented

2026-03-04 00:40:48 +03:00

Author

Owner

@pat-s commented on GitHub (Oct 21, 2024):

Here's an example of a generic solution that can be c/p in any (Forgejo/Gitea) repo. It is also CI agnostic, thanks to git-sv, of course.

A similar solution can easily be created for GH, maybe you're motivated to do so?

Examples for both GH and Gitea in the README would be a great addition, I think.

@pat-s commented on GitHub (Oct 21, 2024): [Here's an example](https://git.devxy.io/helm/shinyproxy/src/commit/5b3260540395c16ea9421199fac895af98507144/.woodpecker/changelog.yaml) of a generic solution that can be c/p in any (Forgejo/Gitea) repo. It is also CI agnostic, thanks to `git-sv`, of course. A similar solution can easily be created for GH, maybe you're motivated to do so? Examples for both GH and Gitea in the README would be a great addition, I think.

kerem commented

2026-03-04 00:40:48 +03:00

Author

Owner

@pat-s commented on GitHub (Jan 18, 2025):

Forgot that the repo was private and is meanwhile deleted. Here's the example in text:

clone:
  git:
    image: docker.io/thegeeklab/wp-git-clone:1.0.14
    settings:
      tags: true

when:
  event: [push, manual]
  branch: ${CI_REPO_DEFAULT_BRANCH}

steps:
  - name: 'Upcoming Changelog'
    environment:
      ISSUE_TOKEN:
        from_secret: codeberg_bot_token
    image: docker.io/thegeeklab/git-sv:1.0.10
    commands: |
      apk add -q --no-cache curl jq sed
      # A string input with (escaped) linebreaks (\n) is needed for valid JSON in the API call
      git sv rn -o changelog.md
      export RELEASE_NOTES=$(cat changelog.md | sed ':a;N;$!ba;s/\n/\\\\n/g')
      export ISSUE_NUMBER=$(curl -s "${CI_FORGE_URL}/api/v1/repos/${CI_REPO}/issues?state=open&q=Changelog%20for%20upcoming%20version" | jq '.[].number')

      echo $RELEASE_NOTES

      if [ -z "$ISSUE_NUMBER" ]; then
        curl -s -X POST "${CI_FORGE_URL}/api/v1/repos/${CI_REPO}/issues?token=$ISSUE_TOKEN" -H 'Content-Type: application/json' -d "{\"title\":\"Changelog for upcoming version\", \"body\":\"$RELEASE_NOTES\"}"
      else
        curl -s -X PATCH "${CI_FORGE_URL}/api/v1/repos/${CI_REPO}/issues/$ISSUE_NUMBER?token=$ISSUE_TOKEN" -H 'Content-Type: application/json' -d "{\"title\":\"Changelog for upcoming version\", \"body\":\"$RELEASE_NOTES\"}"
      fi

@pat-s commented on GitHub (Jan 18, 2025): Forgot that the repo was private and is meanwhile deleted. Here's the example in text: ```yaml clone: git: image: docker.io/thegeeklab/wp-git-clone:1.0.14 settings: tags: true when: event: [push, manual] branch: ${CI_REPO_DEFAULT_BRANCH} steps: - name: 'Upcoming Changelog' environment: ISSUE_TOKEN: from_secret: codeberg_bot_token image: docker.io/thegeeklab/git-sv:1.0.10 commands: | apk add -q --no-cache curl jq sed # A string input with (escaped) linebreaks (\n) is needed for valid JSON in the API call git sv rn -o changelog.md export RELEASE_NOTES=$(cat changelog.md | sed ':a;N;$!ba;s/\n/\\\\n/g') export ISSUE_NUMBER=$(curl -s "${CI_FORGE_URL}/api/v1/repos/${CI_REPO}/issues?state=open&q=Changelog%20for%20upcoming%20version" | jq '.[].number') echo $RELEASE_NOTES if [ -z "$ISSUE_NUMBER" ]; then curl -s -X POST "${CI_FORGE_URL}/api/v1/repos/${CI_REPO}/issues?token=$ISSUE_TOKEN" -H 'Content-Type: application/json' -d "{\"title\":\"Changelog for upcoming version\", \"body\":\"$RELEASE_NOTES\"}" else curl -s -X PATCH "${CI_FORGE_URL}/api/v1/repos/${CI_REPO}/issues/$ISSUE_NUMBER?token=$ISSUE_TOKEN" -H 'Content-Type: application/json' -d "{\"title\":\"Changelog for upcoming version\", \"body\":\"$RELEASE_NOTES\"}" fi ```

kerem referenced this issue

2026-03-04 00:40:58 +03:00

[PR #5] [CLOSED] fix(deps): update module gopkg.in/yaml.v2 to v3 - autoclosed #18

Rows
Columns

[GH-ISSUE #119] Showcase how to create an up-to-date pending changelog #5