Find a way to properly pass the quarkus version to our helm chart labels

[iocanel]

We need to pass the exact quarkus version as a label to our application deployements. So, we need to somehow extract the version.

Using the version from the QuarkusVersionList is not enough as it only contains major and minor but not micro parts.

Maybe an action that reads the pom and set the value in the helm values.yaml file is needed or something smarter.

[cmoulliard]

We can extract the quarkusVersion from what we got as template's parameter using a filter as documented here: https://github.com/q-shift/qshift-templates/issues/48#issuecomment-2037285616

Such a filter can be now registered part of a backendModule as I documented here: https://backstage.io/docs/features/software-templates/writing-templates#custom-filters :-)

IMPORTANT: What you are looking for is not to get the version that a user selects using the list (e.g. 3.9, 3.10, 3.11, etc) but the version which has been scaffolded within the pom.xml.

So my proposition can help if we want to pass as parameter such a version: 3.9 instead of io.quarkus.platform:3.9 to an action able to fetch and process the templates using nunjucks like the following

    - id: gitopsTemplate
      name: Generating GitOps Resources
      action: fetch:template
      input:
        url: manifests/
        copyWithoutTemplating: []
        values:
          quarkusVersion: ${{ parameters.quarkusVersion | extractVersionFromKey }}

In this case, we don't need anymore such a code part of the helm file

{%- if values.quarkusVersion %}
  {%- set streamKey = values.quarkusVersion %}
  {%- set quarkusVersionArr = streamKey.split(':') %}
  {%- set quarkusVersion = quarkusVersionArr[1] %}
{%- else %}
  {%- set quarkusVersion = '' %}
{%- endif %}
apiVersion: backstage.io/v1alpha1
kind: Component
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: ${{ values.component_id }}
  {%- if values.title %}
  title: ${{ values.title }}
  {%- endif %}
  {%- if values.description %}
  description: ${{ values.description }}
  {%- endif %}
  annotations:
...
    app.quarkus.io/quarkus-version: "${{ quarkusVersion }}"

So, what you want to get is this quarkus maven version (when declared as property) = https://github.com/ch007m/my-quarkus-todo-app/blob/main/pom.xml#L14 ? Why instead of using `3.9, 3.10, etc ?@iocanel

[cmoulliard]

Instead of parsing a maven DOM file, I would like to propose that we create a new action fetching the version from code.quarkus.io using the streams data as they include the micro part too. WDYT ? @iocanel

http --follow https://code.quarkus.io/api/streams | jq -r '.[]'
{
  "key": "io.quarkus.platform:3.11",
  "quarkusCoreVersion": "3.11.1",
  "javaCompatibility": {
    "versions": [
      17,
      21
    ],
    "recommended": 21
  },
  "platformVersion": "3.11.1",
  "recommended": true,
  "status": "FINAL",
  "lts": false
}

To get the version, we can do this search based on the platform key selected by the user

http --follow https://code.quarkus.io/api/streams | jq -r '.[] | select(.key == "io.quarkus.platform:3.2") | .quarkusCoreVersion'
3.2.12.Final

[cmoulliard]

Here is what I propose to validate and to do:

• Instead of developing a new action, we could try to use QuarkusVersionList where we continue to display the versions as now (and like this is also the case on code.quarkus.io) BUT where we pass as selected value the version major.minor.patchthat we got from /api/streams and field: platformVersion or quarkusCoreVersion. Which field is the good one to use ? I did a quick change/test and that works when we select as version 3.8 then the version that we will pass to the template engine will be 3.8.5

• We create a Templatefilter able to recreate from a version major.minor.patch => io.quarkus.platform:major.minor and use it where this is needed within the template: quarkus:create:app, etc

• Alternatively, we could instead of using a TemplateFilter recreate it within quarkus:create:app action

• We review the existing templates + skeletons to align the template files with this change

• Develop some Test mock cases to validate the actions and/or template (still not sure that we can execute a template using jest). I will again check within the backstage code project to see if a jest scaffolder template test exist

• Have a 2e2 test case (as discussed within issue: #81) to verify that scaffolding + resources generated + goldenpath still works

WDYT ? @iocanel @aureamunoz

[aureamunoz]

LGTM. The TemplateFilter seems ok for me if it's also easy to test.

Regarding the 2e2 test case, as already mentioned it would be nice to have it but I think it can be done in another PR.

[cmoulliard]

Regarding the 2e2 test case, as already mentioned it would be nice to have it but I think it can be done in another PR.

Yes

[iocanel]

@i3andy: Can we correctly infer the stream key from the major.minor.patch version of quarkus ?

[maxandersen]

@iocanel depends which version of quarkus you are referring to. The stream refer to the Quarkus Platform version not directly tied with Quarkus core artifact (though it is aligned today its not guaranteed it continues)

[maxandersen]

@iocanel https://github.com/q-shift/backstage-playground/issues/114#issuecomment-2152389529 shows how a stream gives you the recommend quarkus platform version.

[cmoulliard]

• Instead of developing a new action, we could try to use QuarkusVersionList where we continue to display the versions as now (and like this is also the case on code.quarkus.io) BUT where we pass as selected value the version major.minor.patchthat we got from /api/streams and field: platformVersion or quarkusCoreVersion. Which field is the good one to use ? I did a quick change/test and that works when we select as version 3.8 then the version that we will pass to the template engine will be 3.8.5

Here is then what we should do:

• Adapt the code of QuarkusVersionList.tsx to use as value quarkusCoreVersion instead of key

  const versionItems: SelectItem[] = value
      ? value?.map((i: Version) => ({label: userLabel(i), value: i.quarkusCoreversion}))
      : [{label: 'Loading...', value: 'loading'}];

• Create a new function (aka this PR https://github.com/q-shift/backstage-playground/pull/156) able to recreate from the version major.minor.patch the key which is expected by the action create:quarkus:app.

Important: I notice a small issue. If no value is selected from the QuarkusVersion list within the screen and the default value is kept (aka 3.11 (RECOMMENDED)), then the Quarkus version remains the key and not 3.11.1. However, if you select 3.2, then the version passed to the parameter will be 3.2.12.Final

FYI: @aureamunoz