Provide changelog for charts #18903
Comments
|
Hi, I' afraid this is currently not that easy because of how our automated systems work. However, I will forward this to the engineering team. Could you let us know the format of the changelog that renovate requires? |
|
Hey, yeah, I thought something like this. For transparency reasons, It would be beneficial to automate the Bitnami Charts release process on GitHub and use GitHub releases. It would be easier for us as a user of Bitnami Helm charts to find new Helm Chart releases and see what's changed. As far as I know, Renovate uses the Changelog from the GitHub release. GitHub can generate release notes by itself or a GitHub Action like helm/chart-releaser-action could be used to generate the notes. |
github-actions
bot
added
on-hold
|
The missing changelogs in the Bitnami chart repo is something which irritates me for long time too. It simply makes me all the time fear to update, because I don't know what will be deployed to my clusters. Or it's pretty much effort to track down the changes in the repo itself. So the keywords here really are transparency and user experience. It would BTW already help to simply tag commits accordingly, if any chart is assigned a new version. This enables the In addition, this is also the case for the https://github.com/bitnami/containers repository. No tags, no branches, no releases, no changelog. To be honest, I am also not 100% sure if these multi-concern repos (e.g. providing dozens of helm charts or containers) are a good decision at all. Because, it makes all the versioning of each individual asset very complicated and floods the repo with hundreds of tags (and maybe even branches). But still, better than no tracking at all (besides the raw git history of commits). |
github-actions
bot
added
triage
github-actions
bot
added
on-hold
|
hi, how do i get a diff/changelog for https://artifacthub.io/packages/helm/bitnami/nats/7.9.9 vs https://artifacthub.io/packages/helm/bitnami/nats/7.9.10 🤔 |
github-actions
bot
added
triage
|
@ro0NL That's not possible at the moment. The only way is to look at the commits to the From there, you have to deduce which commit belongs to 7.9.9 and which belongs to 7.9.10. All commits after the one belonging to 7.9.9, up to and including the one belonging to 7.9.10, are part of the "changelog". This is obviously extremely impractical and error-prone, however we cannot simply update Helm releases without inspecting changes, so it's unfortunately necessary to go through this pain. I hope the Bitnami team can consider implementing improvements along the lines of what @lusu007 suggests. |
agree, im going to block/ignore renovate updates |
github-actions
bot
added
on-hold
It’s definitely not the best idea to ignore or block all updates, as we might miss out on some crucial security enhancements. I hope that Bitnami prioritizes this issue. 😊 |
|
A good example of this issue is the last commit on every chart |
|
We were just affected by #22746. However, this was kind of difficult to diagnose, and also hard to prevent in the first place due to the missing changelog. Overall I would say the transparency regarding changes is not great, and this can (and does) break things. |
|
Thank you for the input, I will make sure that the team is aware of this. There are some possible initiatives but they would need to be prioritized |
|
It's a blind flight every time we carry out updates. We are realizing more and more that we can't go on like this. It would be very important for us to have transparency on updates through a changelog! |
|
@javsalgar currently release of your external-dns is 7.2.0 but commits show nothing of the sort: https://github.com/bitnami/charts/commits/main/bitnami/external-dns Bitnami charts are great but the fact that you have absolutely no way to understand what changes in them is actually "Russian roulette" (can lead to unforeseen issues including outages). How do you internally handle release management? The chart in this example bumped from 6.x to 7.x but what constituted the major release? The underlying external-dns application stayed at 0.14.0 .... as of 7.2.0 the app version bumped to 0.14.1 ... the need for what changes are made to the chart are really important. Things change like paths for values within your charts and those need to be called out in a README or CHANGELOG of some sort. Can't your workflow provide a really bad changelog without log output: sadly the commit subject formatting could use some consistency (top commit is what 7.2.0 is in but not mentioned, doesn't have the brackets around if you tagged your releases like To give example here I have tagged known release commits in the repo and used This is something that could be implemented as part of GitHub workflows. I understand possibly backporting these tags could be time consuming (could probably be scriptable) but even if you started from today it would allow the generation of a CHANGELOG going forward. |
|
Hi! Thank you so much for the feedback! I'm looking into this to see if we can improve this area, at least a first step. I created a fork with a first experiment where I tagged all the chart releases. You can see it here: https://github.com/javsalgar/charts If we added tags you would be able to perform operations like this: I'm still not sure how to implement the changelog without adding too much noise in the commit history (for example, merging a PR and then automatically creating a new commit updating the changelog). However, would something like ⬆️ help as a first step? If so, we can consider adding this first tagging automation to bitnami/charts. Also, for those experienced on this. If we went on with this, the repo would have > 22k tags. Would this have any performance impact on the repo? I'm concerned that this change makes the whole repo unusable. |
|
After several experiments, I created this PR. Feel free to take a look #25359 |
|
We are leaving this on-hold as we're first fixing an UX issue with the repo and the |
github-actions
bot
added
solved
and removed
on-hold
|
The changes were merged. Now the repo has:
Hope this makes working with Bitnami charts easier! |
|
Hi @javsalgar! This is much better now, thanks! Would you mind consider to also publish the changelog to artifact hub? https://blog.artifacthub.io/blog/changelogs/ |
Not for now, sorry. We will continue working on other initiatives to enhance Bitnami Helm charts and containers but adding annotations to render the changelog in Artifact Hub is not on our roadmap. |
What is the problem this feature will solve?
I'm using Renovate for automated Chart Updates. Renovate has a feature to automatically fetch changelogs and display them in the opened Merge Request.
The Bitnami Charts do not provide a Changelog so Renovate is not able to fetch the changes. The process of looking up the changes in the commit of the repository is tedious and takes some time.
What is the feature you are proposing to solve the problem?
Publish changelogs for Chart releases so that Renovate and other dependency management tools can fetch them.
The text was updated successfully, but these errors were encountered: