Bump go-witness to v0.6.1-0.20241106010129-63940cbec45a

[matglas]

What this PR does / why we need it

Preparation for new release.

Doing a pinned updates to [email protected] allows us to make preparations for the next release. My suggestion is that during our next release of witness cli we'll pin it to v0.7.0. But this allows us to move ahead with preparing a new release with multiple changes.

Which issue(s) this PR fixes (optional)

Allowed to merge after this PR:

• Adding functionality for dirhash in cli #436

Acceptance Criteria Met

• Docs changes if needed
• Testing changes if needed
• All workflow checks passing (automatically enforced)
• All review conversations resolved (automatically enforced)
• DCO Sign-off

Special notes for your reviewer:

[netlify]

✅ Deploy Preview for witness-project ready!

Name	Link
🔨 Latest commit	552f09c
🔍 Latest deploy log	https://app.netlify.com/sites/witness-project/deploys/673766786aa5970008c009d6
😎 Deploy Preview	https://deploy-preview-523--witness-project.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 configuration.

[jkjell]

I like this idea and definitely agree the separation of witness and go-witness makes this a problem. A couple of things I'm wondering about:

• If we merge this in main then the docs website will update. The docs site doesn't currently have any versioning. @ChaosInTheCRD do you have any thoughts on this?
• Is there an easy-ish way to prevent accidentally cutting a release with a "pre-release" version of go-witness. I think the answer to this is "yes" with a simple check in the GitHub Actions release workflow.

[matglas]

Good points. The documentations part is not really solvable in one code base I think. Not if the output of the schema coming from go-witness is stored in the witness repo. You do want to keep the option of fixing or changing documentation without creating a release. Maybe tags like docs-[increment] would be possible and then we push.

Checking in GitHub Actions is possible.

[matglas]

@jkjell for the docs we could also opt for rendering a 'notice' that says "Build from latest. May reflect some upcoming functionality provided by go-witness." This is mostly geared towards the schema's. Apart from that all should be fine.

Thinking about it we already have this problem at this moment because if you create a new flag on master and have it merged it will reflect in the docs without a release. Coming from that angle would it be an idea to create an issue to follow up on this and already merge this PR?