Add copy button for configuration properties in config tables

[michalvavrik]

Addresses: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/Doc.20-.20Copy.20property.20name/near/452271216

This won't work until quarkusio/quarkusio.github.io#2157 is merged and CI is rerun with that change.

[michalvavrik]

That docs CI failure didn't fail when I build docs and served it. I'll check command used by CI and try to fix it.

Update: seems like inline macro for HTML is not used, at least I could not reproduce situation when it is used, but I don't know all the ways in which documentation is generated, so I left it there, just adjusted it to turn the copy button macro into empty <code></code> that (I tried) is not visible when part of the DOM.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit ecef520.

✅ 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.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

You can consult the Develocity build scans.

[github-actions]

🎊 PR Preview 1e2140d has been successfully built and deployed to https://quarkus-pr-main-44403-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

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

✅ 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.

[gsmet]

Thanks! I think we will need to implement something similar to what was done for env vars:

https://raw.githubusercontent.com/quarkusio/quarkus/ecef520cb35eb493a22f68804eb0f153d2b684aa/devtools/config-doc-maven-plugin/src/main/resources/templates/asciidoc/default/tags/envVar.qute.adoc

This is needed for the downstream doc.
But happy to discuss if you had something else in mind.

I think we could have only one common property for that as it's all about having the ability to handle the feature.

[michalvavrik]

Thanks! I think we will need to implement something similar to what was done for env vars:

The difference is that this is inline (like this is inside table row that is inline) so you cannot use ifdef etc. Before I went this implementation, I tried to make this conditional for hours. I am no Asciidoc expert though, if you think it can be done, I'll dig again. (also I found some links to Asciidoc about that https://discuss.asciidoctor.org/Inline-Conditional-Inclusion-Macros-td3007.html that suggested the same)

This is needed for the downstream doc. But happy to discuss if you had something else in mind.

I'll come for solution for downstream, but I'll need pointers. I added that "inline macro process" that I thought is enough for any scenario that is not supported. If you tell me how downstream docs is build, I'll prepare NOOP macro.

I think we could have only one common property for that as it's all about having the ability to handle the feature.

I'd like that, but again, I don't know how to make this conditional.

[gsmet]

But is it a problem if it's on another line? My understanding is that it would end up on the same line in the end? But maybe it wouldn't work?

[michalvavrik]

But is it a problem if it's on another line? My understanding is that it would end up on the same line in the end? But maybe it wouldn't work?

It wouldn't, it doesn't matter whether it is on the next line (well it fails for different reason, IIRC it failed over unmatched endif, but I tried many variants, so I don't remember details). Problem is that ifdef only worked for blocks, but I didn't find a way to make row a block.

[gsmet]

And the envVar a few lines below is not in the same situation? If adding a block solves the issue, maybe we could do the same as for .description and have a block with no styling? Would it change the output?

[michalvavrik]

And the envVar a few lines below is not in the same situation?
If adding a block solves the issue, maybe we could do the same as for .description and have a block with no styling? Would it change the output?

Fair point, from DOM POV they are all div paragraphs inside one content div so there shouldn't be a problem. I'll figure why it works for the env var. Thanks