fix(charts): v1.0.22-1 chart has breaking changes from main. Semver issues.

[saernz]

Hiya, sorry to be opening another issue :-(

I recently updated my Helm chart to use v1.0.22-1 to fix an issue which was closed here: #7937.
I have since ran into more issues unfortunately, and I believe the images being used by the helm chart contain breaking changes that are currently in main, or slated for v1.1.0, though I would assume they should only contain code from the v1.0.22 tag.

The issue that I am now seeing is that a breaking change has been introduced into the Helm release which was introduced in the following PRs:

• chore: move jans-auth base configuration to jans-core-service #7673
• chore: move jans-auth base configuration to jans-core-service #7673 #7676

For some reason these changes have made their way into the images being used by the helm chart for v1.0.22-1, which is using docker images with version v1.0.22-2.

The version information I am getting after running /opt/jans/bin/printVersion.py is as below:

Title: Jans authentication server
Version: 1.0.22
Builddate: 2024-02-07 21:08:18
Build: 9c1045a9ce0cbaedc0062ef5a04b282e90415354

Title: jans-config-api-server
Version: 1.0.22
Builddate: 2024-02-07 21:23:14
Build: 9c1045a9ce0cbaedc0062ef5a04b282e90415354

As you can see the build hash references the following commit hash: 9c1045a

I have tried to look into why this is happening, but unfortunately I just don't understand this project's build workflow yet, especially for the Helm charts.

I'd also like to add that the changes in the PRs listed above are breaking changes and should not be released until a major semver version. They end up breaking custom scripts that might reference the GluuConfiguration, and it looks like these changes are being targeted for v1.1.0 as they are present in the nightly releases: https://github.com/JanssenProject/jans/releases/tag/v1.1.0.nightly

If anyone has implemented any of these custom scripts from previous versions (like me): https://github.com/search?q=repo%3AJanssenProject%2Fjans+%22import+GluuConfiguration%22+path%3Adocs%2F**&type=code their scripts will stop working when they upgrade to v1.1.0, which should not happen as it's not a major version change. Since a breaking change is being made these PRs should only be released on a major version, i.e. v2.0.0, or the changes should at least allow for backwards compatibility while issuing a deprecation notice that the code will change in the next major release.

I'm not sure why I'm running into so many issues with these helm charts, any help would be appreciated if I'm not understanding how things are versioned or something. I'm not 100% sure what I'm doing wrong but it is blowing out my project deadlines for sure :-P

So, to sum up, main issues are:

• Helm chart deployments contain code outside of the targeted app version. i.e. a v1.0.22-1 chart containing code from the main branch.
• Breaking changes being introduced in chore: move jans-auth base configuration to jans-core-service #7673 and chore: move jans-auth base configuration to jans-core-service #7673 #7676 should be looked into.

If you need any more information on the issue, I'll be happy to provide it.

I am running with the following config:

• Installed via Helm charts (v1.0.22-1, digest: sha256:5dcc1cb6a4ed203863e0d3209a681ca082983aa158916561687fca8466d92655)
• Running in a Kubernetes environment.
• MySQL persistence.
• Installed modules: auth-server, config-api, scim.

[moabu]

Thanks @saernz and apologies for the 1.0.22 mess. We had a lot of issues that occurred due to expanding the service modules. However, you are right regarding the breaking custom script changes but we do assume users have terraform set to pull and use the correct custom scripts with the tags as we cannot change that during upgrades. Due to the custom scripts being a sort of an external configuration we don't count it as a changer for the sem version. I do understand that it might be considered so but they are considered to be a catalog of examples to be used rather then a part of the code handled which is why we have them in the docs folder .

With that said we realize the end user might be using part of the code that got deprecated so this item will also be addressed so we don't run into it again.

The whole release strategy and workflows are being reworked so we simplify it and lock in the changes. We do appreciate your comments.

Let us know if the issue persists post 1.1.0 .

Thanks

[moabu]

#8112 (comment)