-
Notifications
You must be signed in to change notification settings - Fork 26.3k
Add docs to a pytorch.github.io/doc/tag directory when repo is tagged #45204
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
Conversation
💊 CI failures summary and remediationsAs of commit e6cf93d (more details on the Dr. CI page):
ci.pytorch.org: 1 failedThis comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.Please report bugs/suggestions on the GitHub issue tracker or post in the (internal) Dr. CI Users group. This comment has been revised 43 times. |
6823111 to
208519b
Compare
|
@seemethere the build is successful when triggered on master. Is there a way to do any kind of test for a new tag? |
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 think it's reasonable to move this to a more modern build. We could do that in a follow-up PR
In the past, we've kept around the documentation for dot releases separately.
Probably. Some work also needs to be done in moving the stable/ symlink to point to the right thing when we do releases. I think it's ok if we don't automate those two things for now (it's very easy to just toss up a PR to pytorch.github.io to adjust versions.html and the stable symlink) |
81fba5e to
9ed16dc
Compare
Changed in 9ed16dc to keep this behaviour. It would be nice to merge this before the upcoming release cycle. |
9ed16dc to
a6a609a
Compare
Codecov Report
@@ Coverage Diff @@
## master #45204 +/- ##
==========================================
- Coverage 68.16% 68.16% -0.01%
==========================================
Files 395 395
Lines 51092 51092
==========================================
- Hits 34828 34827 -1
- Misses 16264 16265 +1
Continue to review full report at Codecov.
|
|
This looks fine to me but I don't know much about the circleci parts. @seemethere could you take a look please? |
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.
overall LGTM, there is one gotcha though that might limit the effectiveness on release day.
| "filters": gen_filter_dict(branches_list=["nightly"], | ||
| tags_list=RC_PATTERN) |
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.
On gotcha that I can foresee potentially happening is that CircleCI has a weird requirement that not all of the jobs can run on a tag, so we'd not only have to add this gen_filter_dict call here but we'd need to add it for all of the parent jobs as well. (i.e. all of the jobs that the docs builds requires)
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.
Ahh, I thought that would resolve automatically. The parent jobs are pytorch_cpp_doc_build, pytorch_python_doc_build, and the pytorch-linux-xenial-py3.6-gcc5.4 composite job.
48d70a2 to
1628dc0
Compare
|
I added tag filters to all the parents of the doc push jobs. The one in docker_definitions.py is particularly ugly, but I think it works. |
1628dc0 to
e6cf93d
Compare
facebook-github-bot
left a comment
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.
@seemethere has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
|
Thanks for the contribution @mattip! 😄 |
|
@seemethere merged this pull request in 147c88e. |
1 similar comment
|
@seemethere merged this pull request in 147c88e. |
|
Edit: that was a false alarm, the build must have been canceled or otherwise stopped. |
|
Now the doc push is running, but it fails. Details |
|
Not sure how, but something created the docs https://pytorch.org/docs/1.7.0/. Was this PR not needed, or did it succeed in spite of the run I pointed to failing? |
|
Oh the first one was an abort, we had to re-run due to an issue with CircleCI |

In coordination with @jlin27.
This PR is meant to build documentation when the repo is tagged. For instance, tagging the repo with 1.7.0rc1 will push that commit's documentation to pytorch/pytorch.github.io/docs/1.7.
Subsequently tagging 1.7.0rc2 will override the 1.7 docs, as will 1.7.0, and 1.7.1. I think this is as it should be: there should be one, latest, version for the 1.7 docs. This can be tweaked differently if desired.
There is probably work that needs to be done to adjust the versions.html to add the new tag?
Is there a way to test the tagging side of this without breaking the production documentation?
As an aside, the documentation is being built via the
pytorch_linux_xenial_py3_6_gcc5_4_buildimage. Some projects are starting to move on from python3.6 since it is in security-only support mode, no new binaries are being released.