Create cleaner social cards for link sharing

[etsauer]

Signed-off-by: Eric Sauer esauer@redhat.com

Describe the behavior changes introduced in this PR

When we changed to the material theme doe the docs site, it changed the logo image we use, which doesn't look nice when we share links to the pelorus site. The social cards feature from Material fixes that: https://squidfunk.github.io/mkdocs-material/setup/setting-up-social-cards/#built-in-social-plugin

Testing Instructions

Please include any additional commands or pointers in addition to our standard PR testing process.

@redhat-cop/mdt

[KevinMGranger]

/hold broken on macos

[etsauer]

The social cards aren't currently being served as expected. Opened a RTD issue to get some input: readthedocs/readthedocs.org#9680

[KevinMGranger]

/hold until RTD issue is addressed

[etsauer]

Got a response back on that issue. They pointed out that the link to those images that gets generated assumes a base domain that matches exactly what we enter in the site_url in mkdocs.yml. That value is set to https://pelorus.readthedocs.io/en/latest/. So even in the PR build version of the site, its assuming the image will be at https://pelorus.readthedocs.io/en/latest/assets/images/social/index.png, but it won't be until we merge. If we manually replace the PR build url, we do see that an image has been built and pushed: https://pelorus--695.org.readthedocs.build/en/latest/assets/images/social/index.png

I commented back to see if there's any config change that will allow that URL to be dynamically replaced during PR builds, but short of that, it sounds like we have to merge to find out if it worked.

[etsauer]

I got a comment back saying that there's currently not a way to make the build URLs dynamically replace our site URL, but that it may be comein in the future via some environment variable enhancements being discussed. With that, and considering that, by default our docs site point to the latest release, and not actually latest (master), I think we could just merge this now, and then check to see if the thumbnails in chat look better

[KevinMGranger]

@etsauer could we define an environment variable for site_url? https://www.mkdocs.org/user-guide/configuration/#environment-variables

[etsauer]

@KevinMGranger I looked into that, but since we don't control the hosting environment, we don't have access at the point where that would need to be set. That environment variable would already have to exist (which it doesn't) and then we could tap into it.

[KevinMGranger]

@etsauer Ah, I misunderstood the issue on the RTD side. Darn. Guess we can just take it on faith that they're generated, or do something to check locally?

[etsauer]

@KevinMGranger we can already verify that the images are being generated. Let's take the index page in this PR build as an example:

https://pelorus--695.org.readthedocs.build/en/695/

If you inspect the source and look in the head element, you'll see this tag:

And you try to open the link there you'll get a 404:

https://pelorus.readthedocs.io/en/latest/assets/images/social/index.png

HOWEVER, if you replace the base URL of https://pelorus.readthedocs.io/en/latest/ with the PR base URL of https://pelorus--695.org.readthedocs.build/en/695/, you'll see the image pop up:

https://pelorus--695.org.readthedocs.build/en/695/assets/images/social/index.png

So everything is working right, except the meta tag is only ever going to point to the production URL, because that's whats in mkdocs.yml

[KevinMGranger]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: KevinMGranger

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [KevinMGranger]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment