-
Notifications
You must be signed in to change notification settings - Fork 27
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
Conversation
There was a problem hiding this 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.
Hi @etpeterson, please check the website again and let me know what you think: https://ahmedbasem20.github.io/TF2.4_IVIM-MRI_CodeCollection I used this action https://github.com/dawidd6/action-download-artifact to get the |
There was a problem hiding this 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.
.github/workflows/sphinx.yml
Outdated
@@ -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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
.github/workflows/analysis.yml
Outdated
@@ -5,6 +5,7 @@ on: | |||
branches: | |||
- 'main' | |||
- 'analysis/**' | |||
- 'test-docs' |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
.github/workflows/sphinx.yml
Outdated
|
||
- name: Build html | ||
run: | | ||
mkdir docs/_static | ||
ls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for debugging?
.github/workflows/sphinx.yml
Outdated
There was a problem hiding this comment.
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.
.github/workflows/sphinx.yml
Outdated
@@ -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 |
There was a problem hiding this comment.
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.
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? |
@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. |
Describe the changes you have made in this PR
Implemented automated API documentation generation using Sphinx and Github Actions. This process involves two steps:
sphinx-apidoc -o doc src
to generate initial API documentation intodoc
folder after extracting docs fromsrc
folder.make html
to generate HTML documentation in thedoc/_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 thesrc/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