Tutorial timestamps

[brcolli]

Fixes #2848

Description

I wrote a script that goes to each .py and .rst file in beginner_source, intermediate_source, and advanced_source directories. The timestamp format is "Updated: HH:MM AM/PM, mm dd, yyyy". It appends the timestamp to the end of the file. At first, I added it to the line above or below the author line, but this had a lot of edge cases, depending on how a particular person wrote their tutorial. I could broach this again, but I figured that was an overengineered solution to a simple problem.

The timestamp is generated by looking at git logs for the specific file and seeing when it was last committed. Alternative solution was looking at last modified time for the file, but that isn't concrete or modular. Another possible alternative is adding a check in the pipeline to ensure the user manually inserts the line before they commit. This is the safest but least user friendly.

I created a .sh script to get called during the build-tutorials workflow. It is placed at the very beginning of the manager job or right before running make docs in the worker job. This does add a few seconds to the build time, but nothing major.

I was able to test this on my forked repo with a simple runner, but I obviously couldn't test this in your dedicated pipeline.

Checklist

• [x] The issue that is being fixed is referred in the description (see above "Fixes #ISSUE_NUMBER")
• [x] Only one issue is addressed in this pull request
• [ ] Labels from the issue that this PR is fixing are added to this pull request
• [x] No unnecessary issues are included into this pull request.

[pytorch-bot[bot]]

:link: Helpful Links

:test_tube: See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/tutorials/2876

• :page_facing_up: Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

:heavy_exclamation_mark: 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• NVIDIA runners have a blacklog of 2000+ jobs

:white_check_mark: No Failures

As of commit eb8f1d44d718095aa299a71462c808f0c7973fe0 with merge base 2b0e4649f2d88f29160d2e4050195c33f613882a (): :green_heart: Looks good so far! There are no failures yet. :green_heart:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[brcolli]

I also think it looks better if it's right after the title, but this comes with some caveats. Since we do not standardize the title across .py and .rst files, I would have to get very broad. Many people start files in many different ways. Often they follow the line with a separator like === or *** but some files don't have this. I would love your input, the best I came up with was "Define title as first line with alphabet characters, except in .rst files that begin with `". Is that an acceptable definition of "title"?

[brcolli]

Finally, you requested that the font is weight 300. Is that the default weight used by our stylings for the HTML/CSS files?

[svekars]

I also think it looks better if it's right after the title, but this comes with some caveats. Since we do not standardize the title across .py and .rst files, I would have to get very broad. Many people start files in many different ways. Often they follow the line with a separator like === or *** but some files don't have this. I would love your input, the best I came up with was "Define title as first line with alphabet characters, except in .rst files that begin with `". Is that an acceptable definition of "title"?

You could implement a different approach - instead of trying to match that in .rst/.py, you could have timestamps say in a yml file and load them with .js based after the HTML

[github-actions[bot]]

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.