Feat/sphinx synch #56
Conversation
|
@ammaraskar I did read your concerns in #55 about breaking users builds if That said, my contention would be to move |
|
Hi Nicholas! Thank you so much, this is awesome and I think this seems to be the right way to move forward. It'll probably be a little bit till I can take a look at this but I've gone ahead and added you as a collaborator on the repo if you'd like to push it yourself. |
|
My pleasure @ammaraskar. Thanks for the project :) Perhaps later tonight or tomorrow I can try to push. I'll probably want to update the README to help anyone whose build breaks recover. Thanks again! |
The builds were failing because the sphinx-action used by our workflow defaulted to Sphinx 2.2.0 regardless of what was in the pyproject.toml The current solution according to ammaraskar/sphinx-action#56 is to use a tag corresponding to the sphinx version you want to use.
The builds were failing because the sphinx-action used by our workflow defaulted to Sphinx 2.2.0 regardless of what was in the pyproject.toml The current solution according to ammaraskar/sphinx-action#56 is to use a tag corresponding to the sphinx version you want to use.
Adds a commit for each version of the sphinx docker image.
Users just need to point to the commit or tag they want to use. For instance, I tested a sphinx 7.0.0 build with:
Also adds a daily workflow to compare against the latest release of the sphinx docker and crafts a new commit+tag object that uses it.
Relevant to any issue asking for a newer version.