[GH Request] quince docs stuff

[kdmccormick]

Firm Name

BTR

Urgency

Low (2 weeks)

Problem/Request

Need to do https://openedx.atlassian.net/wiki/spaces/COMM/pages/19662426/Process+to+Create+an+Open+edX+Release#5b.-Ask-Axim-to-activate-hidden-release-versions-of-each-book

Reasoning

Quince release

[openedx-workflow-automation]

Thank you for your report! @openedx/axim-oncall will triage within a business day. Simple requests usually take 2-3 business days to resolve; more complex requests could take longer.

[kdmccormick]

Currently blocked as I'm waiting for access to Keeper.

[kdmccormick]

Got access.

[kdmccormick]

I'm following https://openedx.atlassian.net/wiki/spaces/COMM/pages/19662426/Process+to+Create+an+Open+edX+Release#5b.-Ask-Axim-to-activate-hidden-release-versions-of-each-book:

I was able to find, activate (and hide) quince.master for everything except:

• https://readthedocs.org/projects/donexblock
• https://readthedocs.org/projects/openedx-oars/

The process says:

If the new release isn’t in the version list:

• Check that the webhook is properly configured in GitHub openedx/edx-documentation.

I'm not sure what that means. @feanil , do you have any advice?

Also, while we're looking at this:

• Then create any branch in the repo to force readthedocs to synchronize the branches as versions.

Do we really want to have separate RTD projects for DoneXBlock and Aspects? If the long-term goal is to have an RTD project for almost every single repo, and then manually creating a branch & activating new release version in RTD isn't sustainable.

[feanil]

@kdmccormick it looks like those two repos are not currently set to get tagged for openedx releases. I've manually created the two relevant branches so that we can build the versioned docs for those repos.

If the new release isn’t in the version list:

* Check that the webhook is properly configured in GitHub openedx/edx-documentation.

I'm not sure what that piece of help is meant to do but I think the right response would be to make sure that the repos are set to get tagged for future releases. (I'm holding off right now because we're about to move this data to the catalog-info.yaml file soon.)

Do we really want to have separate RTD projects for DoneXBlock and Aspects? If the long-term goal is to have an RTD project for almost every single repo, and then manually creating a branch & activating new release version in RTD isn't sustainable.

Short term I think the manual process is fine but long term, I think this would get added to the release automation to create all the relevant RTD active versions for doc projects related to any openedx repos.

[kdmccormick]

I'm not sure what that piece of help is meant to do but I think the right response would be to make sure that the repos are set to get tagged for future releases. (I'm holding off right now because we're about to move this data to the catalog-info.yaml file soon.)

openedx-aspects should be tagged in future releases 👍🏻

However, donexblock shouldn't be, as it is installed by edx-platform. In general, we only create tags in top-level repos, so this process will not work for installed-package repos unless we start tagging them too. My gut feeling is that package-installed repos should expose their own numerical versioning in the docs rather than named releases.

Short term I think the manual process is fine but long term, I think this would get added to the release automation to create all the relevant RTD active versions for doc projects related to any openedx repos.

👍🏻

[bmtcril]

Is there anything else to be done here?

[kdmccormick]

Nope. I opened openedx/docs.openedx.org#391 to follow up on the release tagging thing.