| Re: [tractusx-dev] Discussion / Suggestion: Alignment of Helm Chart Versions with App Versions |
|
Hi all, while I can understand, that tracking this many components that we have in App version and Chart version might be overwhelming in the beginning, I think forcefully aligning
them is not the solution. In my opinion, the table in our Release Changelog that maps the two versions is good enough. I would like to keep the option to just release the Chart without creating a new App version. We have seen fixes and improvements to Charts in the past, that did not
require any change to the application itself. So it was ok to just bump the Chart version and keep the app version. If we would be required to align the versions, we also would need to create a new app release. This would mean, like Mathias already mentioned, creating new tags and
releases. Like I said at the beginning, I think the release table does a good enough job and we do not need the require alignment via release guideline. Cheers Sebastian Von:
tractusx-dev <tractusx-dev-bounces@xxxxxxxxxxx> im Auftrag von "Brunkow Moser, Mathias via tractusx-dev" <tractusx-dev@xxxxxxxxxxx> [**EXTERNAL E-MAIL**]
Hi Sigi! I will give my honest opinion also. I find a good idea in general to align the helm chart versions and the app versions, because when you configure the helm charts is more easy since you don’t need to
search for it where is the latest version of the chart or which is the specific version. However I believe that in this case we are forcing that every time we push to the tractus-x main we need to create an application version tag. This does not allows us
to have many small merges related to one version for later creating a release tag. This also means that the app version needs to be incremented always when the chart version is incremented. However it can be the case that just a chart configuration
change was necessary and it was independent from the application changes which are in another version. I hope it could help, Best Regards,
Mathias Brunkow Moser | Software
Engineer Consultant Industry 4.0, IoT & Catena-X
|
CGI Deutschland B.V. & Co. KG Leitzstraße, 45 | 70467 Stuttgart, Germany
M: + 49 1525 6723056
mathias.brunkowmoser@xxxxxxx
|
www.cgi.com/de/de CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained
in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or
deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. Von: tractusx-dev <tractusx-dev-bounces@xxxxxxxxxxx>
Im Auftrag von Kiermayer, Siegfried via tractusx-dev
Hi everyone! Holidays are probably over and I would like to “remind” you about this discussion, but I would also like to add the following screenshot to show you how it looks to people outside: <see attachment> Tx, Sigi From:
Kiermayer, Siegfried <siegfried.kiermayer@xxxxxxx> Hi everyone! We need to talk about Helm charts and versioning of them in connection with app versions: You have probably seen that we have released 3.1 of Eclipse Tractus-X; You might also have seen how this looks in our Changelog:
https://github.com/eclipse-tractusx/tractus-x-release/blob/main/CHANGELOG.md
. Confusing I would say. It’s a big wide table with different versions and a lot of potential for confusions, wrong versions etc. I haven’t suggested any TRG like “Alignment of Helm chart version with App Version” regarding this alignment before because I did not had any practical experience with this particular issue. Also
when you look at other Helm charts, especially the quite often used bitnami postgresql helm chart, they do diverge. BUT! My current assumption is that bitnami Helm charts diverge primarily because those helm charts are build by bitnami and others for other products like postgresql. I see following advantages and disadvantages: Advantages:
Disadvantages:
Overall, I do personally think it would be much easier and more stable to combine your frontend/backend code in one repository and have your helm chart also in the same spot. This would guarantee
that you release holistically. The complexity of combining multiply code projects is reduced on GitHub through path filters:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore
with this you are easily able to do certain things like backend/frontend tests etc. only when your frontend or backend has changed. Please bring up your points (upsides, downsides), your experience with it and everything else to make it easier for the Eclipse Project Leads to decide if this is something we should or should
not make mandatory. At the current point there is no TRG planed, if this is a controversial topic, a TRG might be introduced which is optional but suggests one specific strategy. Thanks, Sigi |
