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,
![](pngVztUlywcMT.png)
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.
|
Sent from outside the BMW organization - be CAUTIOUS, particularly with
links and attachments.
|
|
Absender außerhalb der BMW Organisation - Bitte VORSICHT beim Öffnen von Links
und Anhängen.
|
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
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:
- Easier to understand what Helm Chart is responsible for which App version
- Easier spotting of which App Version is used when using other tools like Kubeapps
- Easier entry from people not having experience with Helm/Kubernetes
- Business people
- Beginners
- Testmanagers
- . . .
Disadvantages:
- More effort when having split repositories to align the helm chart releases
- Which got circumvented if you did not create an umbrella helm chart which references frontend and backend but combined it
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