Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add sphinx documentation for Python bindings and GitHub action workflow to push to GitHub pages #5243

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

hakonhagland
Copy link
Contributor

@hakonhagland hakonhagland commented Mar 5, 2024

Builds on #5242 which should be merged first.

Added sphinx documentation for the opm.simulators.BlackOilSimulator Python module. Also added GitHub action workflow to deploy the documentation to GitHub Pages.

For this to work, someone with admin rights for the opm-simulators GitHub repository has to go to https://github.com/OPM/opm-simulators and then to the menu Settings->Pages and set the branch name for deployment to gh-pages, see screenshot below:

Pasted image 20240303133458

See also: https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site

@blattms
Copy link
Member

blattms commented Mar 5, 2024

Under what url would the documentation appear? Where would something from opm-common appear?

Will this always be the documentation for current master? Would we have release documentation on the side?

@hakonhagland
Copy link
Contributor Author

Under what url would the documentation appear?

@blattms I believe it will appear at something like https://opm.github.io/opm-simulators/

Where would something from opm-common appear?

I think: https://opm.github.io/opm-common/

Added sphinx documentation for the opm.simulators.BlackOilSimulator
Python module. Added GitHub action workflow to deploy sphinx
documentation to GitHub Pages.
@hakonhagland
Copy link
Contributor Author

Rebased

@hakonhagland
Copy link
Contributor Author

jenkins build this please

Dynamically extract sphinx documentation release version from
dune.module version.
@hakonhagland
Copy link
Contributor Author

jenkins build this please

Copy link
Member

@akva2 akva2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have settings access so I can't active it but this looks good to me at least.

@hakonhagland
Copy link
Contributor Author

Will this always be the documentation for current master? Would we have release documentation on the side?

@blattms Good point, I did not think about versions. I think we can get versioning with GitHub pages, see for example: https://github.com/devanshshukla99/sphinx-versioned-docs and https://www.codingwiththomas.com/blog/my-sphinx-best-practice-for-a-multiversion-documentation-in-different-languages. But it seems like it is not very commonly used? Maybe we should try Read the Docs instead? Since they appear to have a more well established workflow for versioning? @vkip What do you think?

@hakonhagland
Copy link
Contributor Author

hakonhagland commented Mar 6, 2024

Will this always be the documentation for current master? Would we have release documentation on the side?

@blattms I played a little bit with https://github.com/devanshshukla99/sphinx-versioned-docs and I think we can use this to get versioned docs. We have to tag the commits we want to include, then the sphinx build will collect the versions from those commits. After the build is completed, all versions will then be included in the sphinx _build directory. When we upload this directory to GitHub pages there will be a version selector at the front page similar to the one used at readthedocs. The user can then select the version of the documentation they want to view from that selector.

@vkip
Copy link
Member

vkip commented Mar 7, 2024

... @vkip What do you think?

No real strong opinion here. As you mention RTD versioning is well established, but as long as it works this is fine by me.

Use the Python module sphinx-versioned-docs to get versioned docs.
Currently, there is only a version for the HEAD of the master branch
but release versions can be added later by specifying a release tag.
@hakonhagland
Copy link
Contributor Author

@vkip, @akva2, and @blattms I added a new commit to address the versioning, see: 69d3d6c

@hakonhagland
Copy link
Contributor Author

jenkins build this please

@blattms
Copy link
Member

blattms commented Mar 8, 2024

Dumb questions from me:

  • Is this action executed for each merge?
  • Is there any version information on the generated pages (e.g. commit or date)?

I know it is surprising if you see how I behave in this project 😅, but I do not have any admin power here. Seems like only @alfbr, @atgeirr, or @totto82 can change settings.

@hakonhagland
Copy link
Contributor Author

Is this action executed for each merge?

@blattms It is executed for each merge/push to the master branch but only if anything inside the python folder was changed.

Is there any version information on the generated pages (e.g. commit or date)?

We can choose to tag certain commits (e.g. releases) and have those included in the version selector in the lower left corner of the page. Here is an example from another GitHub page:

image

This page has included versions for git tags "v0.1", "v1.0", "v1.1", and "v1.2" and for the current head of the "main" branch. The currently "active" documentation among those versions is the "main" as indicated with green color.

Let me know if we need more information than this tag information.

@totto82
Copy link
Member

totto82 commented Apr 22, 2024

Can we merge this? Or will this interfere with the release process?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants