Conditionalize paragraph that links to conditional content

[rolfedh]

Enhance the documentation's clarity and conditional logic by enclosing cross-references that link to the ifndef::no-quarkus-oidc-token-propagation-reactive[] section within the same conditionals. Otherwise, the cross references are broken when the condition is asserted.

[sberyozkin]

@rolfedh I've approved, but then I thought, should we have this conditional content on main two for these extensions ? I see way it may have to be the case for 3.8 but what about main ?

[rolfedh]

@rolfedh I've approved, but then I thought, should we have this conditional content on main two for these extensions ? I see way it may have to be the case for 3.8 but what about main ?

Good question, @sberyozkin. Currently, main includes conditional content for these two extensions. To maintain consistency and ensure main serves as the current source of truth, I propose we add this change now. If we confirm product support for any extension in the future, I'll remove the corresponding conditionalization tags from all affected content. WDYT?

[sberyozkin]

Sure, but is it the current state of truth though for main, which is an upstream thing, with both of these extensions to be supported at the next RHBQ level...
Let me CC @rsvoboda

[rsvoboda]

@rolfedh we need to understand if this work is related to 3.8 or to the future RHBQ feature release.

[rolfedh]

@rolfedh we need to understand if this work is related to 3.8 or to the future RHBQ feature release.

@rsvoboda,

This PR relates to main only. I have created #41921 for 3.8.

Could you please confirm if we have tested or can guarantee support for the following extensions in RHBQ 3.14?

• quarkus-oidc-token-propagation (also known as quarkus-resteasy-client-oidc-token-propagation)
• quarkus-oidc-token-propagation-reactive (also known as quarkus-rest-client-oidc-token-propagation)

If support is confirmed, I suggest we close this PR and I will create a new one to remove this type of conditionalization from the other content. Otherwise, I recommend merging this PR now and removing the conditionalization once support is verified. WDYT?

[rolfedh]

@rsvoboda, maintaining two separate realities in main can lead to inconsistencies where the extension is supported in some content but not in others. It would be more effective to have a consistent approach throughout.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 128f600.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[rolfedh]

@rsvoboda @sberyozkin, for main and the upcoming 3.14 release, what are your thoughts on this PR instead: PR #41938?

[rolfedh]

@sberyozkin @rsvoboda let's close this one and use #41938 instead, okay?

[rsvoboda]

@rolfedh
quarkus-oidc-token-propagation and quarkus-oidc-token-propagation-reactive are tracked https://issues.redhat.com/browse/QUARKUS-4179, the target was 3.8.5, tests plan was done, tests were added, functional testing passed, the only trouble that remains is that extension atrifacts are not productized even though the tech preview support metadata are present.
https://code.quarkus.redhat.com/?extension-search=origin:platform%20token-propagation

So I would treat them as supported extenstions (with tech preview level) so the parts about quarkus-oidc-token-propagation(-reactive) should be available in 3.8 and 3.15 documentation.

[rolfedh]

Not needed. The quarkus-oidc-token-propagation and quarkus-oidc-token-propagation-reactive extensions have tech preview (supported) status in 3.8 and later.

[github-actions]

🙈 The PR is closed and the preview is expired.