fix checksum accordions

[aevesdocker]

this PR fixes the issue of the checksum accordions not expanding/collapsing

closes#16440

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	9aebdce
🔍 Latest deploy log	https://app.netlify.com/sites/docsdocker/deploys/63b6c8a365a730000a28ef8f
😎 Deploy Preview	https://deploy-preview-16441--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[mat007]

Makes sense!

This is going to be a tad annoying when adding a new release, I’m wondering if there isn’t a way to factor this out and make it simpler to define, but I’m not an expert in these.
@thaJeztah would you have any suggestion?

[thaJeztah]

This is going to be a tad annoying when adding a new release, I’m wondering if there isn’t a way to factor this out and make it simpler to define, but I’m not an expert in these.
@thaJeztah would you have any suggestion?

Hm... yeah, this is a bit awkward. Not sure if there's an easy solution with the current components. Perhaps we can look at how we present these (maybe in a different way) 🤔

[thaJeztah]

As these are mostly to verify if the bytes came across correctly (binaries would still be signed to verify in other ways, correct?), we could still consider

• uploading .sha256 files
• or a checksums.txt (similar to what Buildx does); https://github.com/docker/buildx/releases/tag/v0.9.1

That way we could outline how users can verify, without having to mention it for each release

[aevesdocker]

Thanks for catching that @thaJeztah 😅

I wonder if there might be some other useful component that Hugo has to offer as well? Maybe it's worth waiting until we've migrated to Hugo and then revisiting this?

[thaJeztah]

The fix itself looks ok (looking at the code), but it's indeed a bit of a repetitive job to make sure we don't accidentally make the same mistake.

One thing we could look at (separate from migrating to Hugo) is if we can use a template for these blocks, so that it automatically generates unique IDs based on (e.g.) the Docker Desktop build-number or version; something like

{%- include download_buttons.md VERSION=4.16 BUILD_NUMBER=12345 WIN_CHECKSUM=<foo> MAC_CHECKSUM=<bar> -%}

Although that would also be a lot of boiler plating with all the checksums 🤔 so yeah, perhaps having .sha256 files (and/or .asc for the deb/rpm files) would make that easier.

[aevesdocker]

@thaJeztah would you mind approving the PR in the meantime? It'd be good to get the immediate bug fixed

[mat007]

As these are mostly to verify if the bytes came across correctly (binaries would still be signed to verify in other ways, correct?), we could still consider

• uploading .sha256 files
• or a checksums.txt (similar to what Buildx does); https://github.com/docker/buildx/releases/tag/v0.9.1

That way we could outline how users can verify, without having to mention it for each release

Yes, that makes sense, I’ll create a ticket in the DKP backlog for this.

[thaJeztah]

LGTM, thanks!