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

Generate API documentation using Sphinx. #59

Merged
merged 10 commits into from
Mar 29, 2024

Conversation

AhmedBasem20
Copy link
Contributor

Describe the changes you have made in this PR

Implemented automated API documentation generation using Sphinx and Github Actions. This process involves two steps:

  1. Executing sphinx-apidoc -o doc src to generate initial API documentation into doc folder after extracting docs from src folder.
  2. Running make html to generate HTML documentation in the doc/_build/html folder.

This setup allows for including manual documentation alongside API documentation. I'll try to integrate the markdown files from the doc folder onto the documentation page. And exclude the src/original file as it doesn't have much documentation there.

Documentation Link

https://ahmedbasem20.github.io/TF2.4_IVIM-MRI_CodeCollection

Link this PR to an issue [optional]

Fixes #50

Copy link
Contributor

@etpeterson etpeterson left a comment

Choose a reason for hiding this comment

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

The docs look good! Just a few things.

.github/workflows/sphinx.yml Outdated Show resolved Hide resolved
.github/workflows/sphinx.yml Outdated Show resolved Hide resolved
doc/conf.py Outdated Show resolved Hide resolved
@AhmedBasem20
Copy link
Contributor Author

Hi @etpeterson, please check the website again and let me know what you think: https://ahmedbasem20.github.io/TF2.4_IVIM-MRI_CodeCollection
We now have a main page that points to the algorithm analysis figures and the API documentation.

I used this action https://github.com/dawidd6/action-download-artifact to get the Figures artifact uploaded by the analysis.yml workflow. And then included it in the docs.
This solution supersedes #49 .

@AhmedBasem20 AhmedBasem20 requested a review from etpeterson March 18, 2024 03:10
Copy link
Contributor

@etpeterson etpeterson left a comment

Choose a reason for hiding this comment

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

I haven't tried it yet but this multiple source for the pages site is the major thing.

@@ -35,16 +35,26 @@ jobs:
run: |
pip install -r requirements.txt

# Action to download artifacts from a different workflow (analysis.yml)
- name: Download figures artifact
Copy link
Contributor

Choose a reason for hiding this comment

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

This introduces a dependency between workflows that we now need to manage. Is it not possible to upload documentation into one folder on the published page from one workflow and figures from another? Or does it purge the page when a new thing is uploaded?

If we do need to merge the results from multiple workflows to publish, then that publish step should probably be a separate workflow triggered when one or both of the source workflows complete. I looks like that's possible with this and it even allows passing artifacts around, so perhaps that's how it's intended?

Another option would be to add this doc building to the analysis workflow. I'm not too happy with that because it seems like it's two separate things, but maybe that's the publishing workflow?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it not possible to upload documentation into one folder on the published page from one workflow and figures from another?

Not sure if I understand this part, can you elaborate more? The sphinx.yml workflow downloads the figures from the last completed analysis workflow. And then publish the website. So this doesn't require the current analysis job to be completed, it captures the figures from the last successful one.

I looks like that's possible with this and it even allows passing artifacts around, so perhaps that's how it's intended?

This will be very useful to keep the website updated with the current figures produced by analysis.yml.
I'm thinking of deploying the website twice: a quick one that takes ~50 seconds and uses the last available figures artifact. And the second one is when the new figures are uploaded. What do you think?

on:
  push:
    branches:
      - 'main'
  workflow_run:
    workflows: ["analysis.yml"]
    types:
      - completed

Copy link
Contributor

Choose a reason for hiding this comment

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

This is really good. It would be nice if the upload were a separate workflow, but maybe that's a followup improvement.

What happens in the case of a build failure on either branch?

I think the last thing is it would be nice to use the official github method of accessing data from the other workflows. It's much more verbose but is the official method. Let me know your thoughts.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is really good. It would be nice if the upload were a separate workflow, but maybe that's a followup improvement.

I did the build and deployment on the same workflow because each step depends on the previous one. Not sure how to further improve this, maybe upload the build folder as an artifact and use it on a separate deployment workflow?

What happens in the case of a build failure on either branch?

If the build fails for any reason the website will be available with the last successful build.

I think the last thing is it would be nice to use the official github method of accessing data from the other workflows. It's much more verbose but is the official method. Let me know your thoughts.

Done!

Copy link
Contributor

Choose a reason for hiding this comment

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

I did the build and deployment on the same workflow because each step depends on the previous one. Not sure how to further improve this, maybe upload the build folder as an artifact and use it on a separate deployment workflow?

That's what I was thinking, but that's a larger refactor at this point. Maybe a followup PR.

Thinking it through, one downside of the current approach is that the documentation is contingent on a successful analysis run. So if the analysis workflow breaks then the documentation stops getting updated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed! Now if the analysis fails, the figures step will be skipped and the generation will work.

@AhmedBasem20 AhmedBasem20 requested a review from etpeterson March 18, 2024 13:20
Copy link
Contributor

@etpeterson etpeterson left a comment

Choose a reason for hiding this comment

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

Looking good, just those small comments.

@@ -5,6 +5,7 @@ on:
branches:
- 'main'
- 'analysis/**'
- 'test-docs'
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't you want wildcards here? Or is there some specific branch called test-docs you have in mind?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh sorry, this was a branch that I was debugging in. Removed.


- name: Build html
run: |
mkdir docs/_static
ls
Copy link
Contributor

Choose a reason for hiding this comment

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

Just for debugging?

Copy link
Contributor

Choose a reason for hiding this comment

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

I just now realized it's called sphinx.yml. Probably more descriptive would be documentation.yml or something.

@@ -35,16 +35,26 @@ jobs:
run: |
pip install -r requirements.txt

# Action to download artifacts from a different workflow (analysis.yml)
- name: Download figures artifact
Copy link
Contributor

Choose a reason for hiding this comment

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

I did the build and deployment on the same workflow because each step depends on the previous one. Not sure how to further improve this, maybe upload the build folder as an artifact and use it on a separate deployment workflow?

That's what I was thinking, but that's a larger refactor at this point. Maybe a followup PR.

Thinking it through, one downside of the current approach is that the documentation is contingent on a successful analysis run. So if the analysis workflow breaks then the documentation stops getting updated.

@AhmedBasem20 AhmedBasem20 requested a review from etpeterson March 21, 2024 20:07
@etpeterson
Copy link
Contributor

This is looking good. I think it's ready. I just want to confirm with @oliverchampion and @petravanhoudt that we're putting documentation in the right place.

I'm thinking the other PR, should go in first and double check that, then this can be integrated. Is that the order you'd prefer @AhmedBasem20?

@AhmedBasem20
Copy link
Contributor Author

@etpeterson this pull request should replace #49, as we already generate the figures here but inside the sphinx theme.

@etpeterson
Copy link
Contributor

@etpeterson this pull request should replace #49, as we already generate the figures here but inside the sphinx theme.

Ah, I see. Ok, close the other one. Let's give a few more days to suggest locations and we can merge this.

@etpeterson etpeterson merged commit 5fe5728 into OSIPI:main Mar 29, 2024
12 checks passed
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.

Documentation generation
2 participants