Improve apify-cli release process

[DaveHanns]

Problem:
The current apify-cli release workflow does not update documentation automatically. Developers must update docs manually.

Requirements:

• Update existing release workflow (GitHub Actions) to generate docs using Docusaurus

Examples:
Follow conventions used in:

• https://github.com/apify/apify-client-js/blob/master/.github/workflows/release.yaml#L112

  • preferred approach: docs are versioned by major version only (e.g. 2), and regenerated on minor releases within the same version folder

• https://github.com/apify/crawlee/blob/master/.github/workflows/release.yml#L178

[B4nan]

Creating a PR seems unnecessary, what would you like to review there? We just do this as part of the release process, and that part is missing here.

https://github.com/apify/crawlee/blob/master/.github/workflows/release.yml#L178

edit: maybe better example is the JS client where we only deal with major versions and regenerate on minor release:

https://github.com/apify/apify-client-js/blob/master/.github/workflows/release.yaml#L112

[DaveHanns]

Creating a PR seems unnecessary, what would you like to review there? We just do this as part of the release process, and that part is missing here.

https://github.com/apify/crawlee/blob/master/.github/workflows/release.yml#L178

edit: maybe better example is the JS client where we only deal with major versions and regenerate on minor release:

https://github.com/apify/apify-client-js/blob/master/.github/workflows/release.yaml#L112

Makes sense. If this is already the standard in other Apify repos, I’m fine following that approach.
The benefit of an explicit PR is reviewability and control, but since the docusaurus output should be stable and reliable, there shouldn’t be any need for that.

[B4nan]

This is all just about updating what you see in /next to be a stable release, so you can review things before the actual release just fine.