chore: adding docs to release please

[signorecello]

Description

This PR attempts to add docs to release_please

Problem*

So far our attempts with docs workflows have been unsuccessful. The latest try was almost there, but it implied having a PR after the release is merged, which would actually make the docs show up after the tag, not before. So when the release was tagged as stable, it wouldn't have the docs at that point in time.

Summary*

This change attempts to do some blind changes, as I tried faking master with another branch and somehow didn't make it actually trigger new tags.

[github-actions]

🚀 Deployed on https://6568aafe57d79f19c2eae4f7--noir-docs.netlify.app

[TomAFrench]

This will publish a new docs release every time the release please PR is updated rather than when it's merged. I can help make some changes to this on Monday.

[signorecello]

Oh I see... Well I do appreciate the help, I'm struggling a bit with this.

The only way I can imagine is having a new version of the docs be built just before merging this PR, but still on this PR. I have no idea how to achieve that...

[TomAFrench]

No worries, I've split the workflow into two steps:

1. Whenever we update the release-please PR, we create a new version of the docs and commit it to the release please branch.
2. When we merge the release please PR, that version then gets "frozen" and deployed to netlify.

That said, this PR locks us in to only allowing docs deployments in line with noir releases (i.e. to update the docs we need to push a new release of nargo). This doesn't seem quite right imo, shall we split off the publishing into a separate workflow again and allow an external trigger (or just redeploy on changes to the docs directory)?

[signorecello]

Thank you so much @TomAFrench in regards to your question, one can always change the past versions in the versioned_docs folder (which is just a snapshot of the "docs" folder at a certain tag) so I think it's no big problem 👍 we do it sometimes when we find typos in earlier versions or something

As for "up-to-date" docs we can have a workflow that deploys them on every merge, since the "docs" folder is the "current/dev/latest" version, not the one the users see first (the one they see at first is the stable version)

[Savio-Sou]

Acknowledging this is still a net positive versus where we are at.

We can address the bloat and foreseen pitfalls with subsequent Issues.

[TomAFrench]

This is on my plate for today.

[TomAFrench]

This seems reasonable now. Whenever we merge a release-please PR now:

1. We'll have a copy of the docs in versioned_docs which is correct as of the release commit.
2. A new version of the docs will be published as of that commit
   • This means that the dev docs will be automatically up to date for the new prerelease. (Although do you not want this to be published on any changes to the docs?)

If we mark the release as stable down the line we can then push out a new version of the docs by running the workflow manually. We could attach this to the release event again however.

[Savio-Sou]

Thank you Tom!

We could attach this to the release event again however.

That wouldn't quite work, as (quoting @signorecello from Slack): "When a GitHub Actions workflow is triggered by a release event, it checks out the repository at the state it was in when the release was created."

However the manual trigger is great and likely good enough until we find a better solution.

[signorecello]

I think the manual trigger would release it at the time of tagging, so it should work... But tbh my self-confidence in my CI skills is not great at this time 😂

[signorecello]

Thank you so much Tom. This makes sense to me 😊

[TomAFrench]

That wouldn't quite work, as (quoting @signorecello from Slack): "When a GitHub Actions workflow is triggered by a release event, it checks out the repository at the state it was in when the release was created."

By default this is true, but we can specify a different tag to checkout instead so that if the workflow is triggered by a release then it checks out the current master branch.