Auto-generate the Kamelet Catalog website

[nicolaferraro]

This generates an Antora module for the Kamelet catalog directly from the Kamelet YAML files.

cc: @davsclaus , @oscerd , @astefanutti , @squakez , @doru1004 , @lburgazzoli, @christophd

A preview...

Next step for the UI:

• Move the markup to the main Camel website UI bundle
• Add Netlify integration to this repo
• Add a section in the main Camel website

[oscerd]

We need @zregvart for including this somewhere in the website.

[lburgazzoli]

random thought:

• we should probably have some way of grouping kamelets, i.e. there may be a number of telegram related kamelets
• we shold think about versioning

[nicolaferraro]

random thought:

• we should probably have some way of grouping kamelets, i.e. there may be a number of telegram related kamelets
• we shold think about versioning

Yeah, so versioning can be done by tagging this repo as per proposal. Antora supports multiple versions oob.

There's a camel.apache.org/kamelet.group=<name of the group> label that should be used for grouping. The UI still does not support that but that's an improvement.
I wonder if we should make the group mandatory and have it for all Kamelets. The catalog can have both a link to a page where single kamelets of a group are listed (if more than one), but also direct links to the specific Kamelets in the display box.

[oscerd]

I'm not sure if it makes sense to have the same ui we are using on the camel website, just for visual identity, btw we need @zregvart to include it.

[nicolaferraro]

I'm not sure if it makes sense to have the same ui we are using on the camel website, just for visual identity, btw we need @zregvart to include it.

Yeah, this includes a custom UI with additional CSS and layout on top of the Antora default one, but it's a temporary solution until we embed the camel default UI.

I'd like adding the "catalog" layout to the main Camel UI and the best would be to have it published in an HTTP location (maybe using Github actions, like the Antora folks seem to do), so that we can reference it back from here in:

camel-kamelets/docs/antora-playbook.yml

Line 15 in 15165a7

url: ./kamelet-catalog-ui/build/ui-bundle.zip

Is it possible @zregvart ?

[lburgazzoli]

random thought:

• we should probably have some way of grouping kamelets, i.e. there may be a number of telegram related kamelets
• we shold think about versioning

Yeah, so versioning can be done by tagging this repo as per proposal. Antora supports multiple versions oob.

I was more thinking about kamelet specific versions, giving that they can be used even without a catalog, whould we also let people browse to a specific kamelet version ?

There's a camel.apache.org/kamelet.group=<name of the group> label that should be used for grouping. The UI still does not support that but that's an improvement.
I wonder if we should make the group mandatory and have it for all Kamelets. The catalog can have both a link to a page where single kamelets of a group are listed (if more than one), but also direct links to the specific Kamelets in the display box.

+1 for making group mandatory

[zregvart]

@nicolaferraro perhaps you can start a pull request with the changes needed to the website on the website repository. Not sure what's to gain by adding those changes here. Is the end goal to publish to a different domain?

[nicolaferraro]

@nicolaferraro perhaps you can start a pull request with the changes needed to the website on the website repository. Not sure what's to gain by adding those changes here. Is the end goal to publish to a different domain?

No, it's only for the Camel website, I did them here just to have a quick preview in dev + I want later to integrate Netlify on PR.. but the code is well separated so the plan was to move it to the camel-website from the beginning. I'll try to publish the layout there, and also the final bundle so I can link it from here (if possible with the new Apache rules for Githu Actions...)

[astefanutti]

Gorgeous 👏🏼!

[zregvart]

@nicolaferraro perhaps you can start a pull request with the changes needed to the website on the website repository. Not sure what's to gain by adding those changes here. Is the end goal to publish to a different domain?

No, it's only for the Camel website, I did them here just to have a quick preview in dev + I want later to integrate Netlify on PR.. but the code is well separated so the plan was to move it to the camel-website from the beginning. I'll try to publish the layout there, and also the final bundle so I can link it from here (if possible with the new Apache rules for Githu Actions...)

If at all possible do not add another UI bundle to the camel-website, there are a number of optimizations that went into the apache-camel-ui UI bundle in the camel-website repository that you'll need to repeat in the second bundle. Adding changes to the existing apache-camel-ui UI bundle should be preferred.

This also maintains the separation of presentation vs content we have between the camel-website and other git repositories we pull to build the website.

Not sure about the Netlify integration, this is already present on the camel-website repository.

If you wish trigger publishing of changes made here to the website, that needs to happen with the trigger to the Camel.website job on the ASF Jenkins. Automating that could be done via a generic webhook on push to this repository (would require a secret to be added by INFRA).

[nicolaferraro]

@nicolaferraro perhaps you can start a pull request with the changes needed to the website on the website repository. Not sure what's to gain by adding those changes here. Is the end goal to publish to a different domain?

No, it's only for the Camel website, I did them here just to have a quick preview in dev + I want later to integrate Netlify on PR.. but the code is well separated so the plan was to move it to the camel-website from the beginning. I'll try to publish the layout there, and also the final bundle so I can link it from here (if possible with the new Apache rules for Githu Actions...)

If at all possible do not add another UI bundle to the camel-website, there are a number of optimizations that went into the apache-camel-ui UI bundle in the camel-website repository that you'll need to repeat in the second bundle. Adding changes to the existing apache-camel-ui UI bundle should be preferred.

This also maintains the separation of presentation vs content we have between the camel-website and other git repositories we pull to build the website.

Not sure about the Netlify integration, this is already present on the camel-website repository.

If you wish trigger publishing of changes made here to the website, that needs to happen with the trigger to the Camel.website job on the ASF Jenkins. Automating that could be done via a generic webhook on push to this repository (would require a secret to be added by INFRA).

It wasn't my intention.. I kept changes separated into a bunch of files to merge them: apache/camel-website#536

I managed to display this catalog with the website UI with that change:

[zregvart]

I'd like to polish this a bit, either as a PR on top of this PR (preferred) or as a followup PR.

[nicolaferraro]

I'd like to polish this a bit, either as a PR on top of this PR (preferred) or as a followup PR.

You're welcome to do so. Look also at apache/camel-website#537 to completely remove the custom UI from here.

[zregvart]

I've created a PR to polish this against this PR: nicolaferraro#1

[nicolaferraro]

Let's merge this to unlock: apache/camel-website#536