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 live rendering of /changelog entries #1052

Merged
merged 13 commits into from
Mar 8, 2021

Conversation

StanczakDominik
Copy link
Member

This uses https://github.com/OpenAstronomy/sphinx-changelog (@Cadair's new toy) to render our changelog entries on documentation builds during tests. Figured we could do a test run for him. 😄

@StanczakDominik StanczakDominik added docs PlasmaPy Docs at http://docs.plasmapy.org PDD labels Mar 2, 2021
@@ -0,0 +1,5 @@
Plasmapy v0.6.0 (to be released mid-march)
Copy link
Contributor

Choose a reason for hiding this comment

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

You probably don't need the title, towncrier will render one.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fair point!

Copy link
Member Author

@StanczakDominik StanczakDominik Mar 2, 2021

Choose a reason for hiding this comment

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

It does, however, set the title to Plasmapy 0.5.1.dev87+g7438c409.d20210301 (2021-03-02), a bugfix release. I don't mind setting the title manually to 0.6.0 once we've got it out the door, so I'll just remove the custom title for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

If the next release that will be made off of your master branch is going to be v0.6.0 you should add a v6.0.0 tag on master so that setuptools_scm knows what version to render. As described here: https://packaging-guide.openastronomy.org/en/latest/releasing.html#releasing-from-branches

@codecov
Copy link

codecov bot commented Mar 2, 2021

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.86%. Comparing base (6a161f0) to head (ef310db).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1052   +/-   ##
=======================================
  Coverage   96.86%   96.86%           
=======================================
  Files          70       70           
  Lines        6864     6864           
=======================================
  Hits         6649     6649           
  Misses        215      215           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -0,0 +1,19 @@
{% for section, _ in sections.items() %} {% set underline = underlines[0] %}{% if section %}{{section}} {{ underline * section|length }}{% set underline = underlines[1] %}
Copy link
Contributor

Choose a reason for hiding this comment

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

have you modified this? if not you shouldn't need it, I only added it to upstream to test it as astropy customised it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I just copied it over - my bad. I was trying to fix https://github.com/PlasmaPy/PlasmaPy/pull/1052/checks?check_run_id=2012587897#step:6:643 this test failure, where the documentation is built within this tox env:

PlasmaPy/tox.ini

Lines 39 to 44 in 6a161f0

[testenv:build_docs]
changedir = {toxinidir}
extras = dev
setenv =
HOME = {envtmpdir}
commands = sphinx-build docs docs/_build/html -W -b html

For some reason, it seems to be running into

https://github.com/OpenAstronomy/sphinx-changelog/blob/90e565cb35e3f80bdebd6da358ecfdc9d2ac9b14/sphinx_changelog/towncrier.py#L33

with config = None, which implies that this part

https://github.com/twisted/towncrier/blob/7f209109513534d4c3e9defc732fa43ce0ff99aa/src/towncrier/_settings.py#L60-L65

cannot locate pyproject.toml:

[tool.towncrier]
package = "plasmapy"
filename = "CHANGELOG.rst"
directory = "changelog/"
issue_format = "`#{issue} <https://github.com/plasmapy/plasmapy/pull/{issue}>`__"

which might warrant a if config is None or config["template"] is None in sphinx-changelog and definitely warrants more debugging on our end to figure out what happens to pyproject.toml 😅

docs/whatsnew/0.6.0.rst Outdated Show resolved Hide resolved
Co-authored-by: Stuart Mumford <[email protected]>
@Cadair
Copy link
Contributor

Cadair commented Mar 2, 2021

@StanczakDominik I just pushed a new rc of the changelog package if you want to restart it and try again. It should at least give a better error now and then hopefully we can see what's going on.

@StanczakDominik
Copy link
Member Author

Yup, now RTD is broken, and note that it was building correctly before the config change. This is definitely something about our tox config, so don't worry about it too much - I'll figure it out later (busy elsewhere atm) and report back!

@Cadair
Copy link
Contributor

Cadair commented Mar 2, 2021

I am very confused as to why your tox config would be busting this, it should be relative to the rst file.

docs/whatsnew/0.6.0.rst Outdated Show resolved Hide resolved
Co-authored-by: Stuart Mumford <[email protected]>
@rocco8773
Copy link
Member

With respect to the wrong version being displayed for the "live" changelog, it appears when RTD is building and installing plasmapy that it is not respecting the SCM version. Here's a screenshot from the last RTD build of this PR...

image

If I go back to the last RTD build of branch v0.5.x then the SCM version is respected.

image

The only difference I can see in the build log between these two cases is which versions of setuptools-scm and setuptools are used. setuptools-scm==4.1.2 & setuptools==51.0.0 are used when SCM is respected (later case) and setuptools-scm==5.0.1 and setuptools==54.0.0 are used when SCM is NOT respected (former case). Maybe try back versioning these two to see if it resolves the issue.

@StanczakDominik
Copy link
Member Author

I think this is a relevant clue. @Cadair, in the comment earlier you wrote:

If the next release that will be made off of your master branch is going to be v0.6.0 you should add a v6.0.0 tag on master so that setuptools_scm knows what version to render. As described here: https://packaging-guide.openastronomy.org/en/latest/releasing.html#releasing-from-branches

I read the docs, but (here's an opportunity to improve it, and I'll gladly do so once we've cleared this up): are you saying that, right now, when the next release is not due for at least a week, we should put a tag called v0.6.0dev (dev seems implied by the docs) on the latest commit on master to let setuptools-scm know the version to render?

@Cadair
Copy link
Contributor

Cadair commented Mar 3, 2021

There are two things at work here.

Firstly, you have the fact that setuptools_scm will by default only increment the bugfix version. This means that if you want to increment the major (or minor) version you need to tag to tell it to do so.

we should put a tag called v0.6.0dev (dev seems implied by the docs) on the latest commit on master to let setuptools-scm know the version to render?

yes. I am not sure what workflow PlasmaPy uses, but if you tag all your releases off branches like sunpy & astropy do then you end up with the situation where your master branch has no tags on it. This means when setuptools_scm looks for the latest tag (it runs git describe) it finds some old tag which is out of date. If you don't release off branches, it will find the previous tag, and only increment the bugfix version.

Both of these issues can be fixed by adding a "start of development" tag when a new major release cycle is started. For sunpy this means at the point where the feature freeze branch is split off from master we add a vX.Y.dev tag to master so that all the version numbers on master from that point take the form of v3.0.dev12345.

(This really is only needed if you release off master to make your development versions "correct", obviously when you tag the final release setuptools_scm will get it right).

Secondly, RTD throws it's own sabo in the works by doing a shallow clone. This means that it likely doesn't fetch all of the tags, which means that git describe and therefore setuptools_scm doesn't read the version correctly. The best way to fix this is to ask RTD nicely to disable shallow clone for your builds. e.g. readthedocs/readthedocs.org#5648

@rocco8773
Copy link
Member

rocco8773 commented Mar 3, 2021

Secondly, RTD throws it's own sabo in the works by doing a shallow clone. This means that it likely doesn't fetch all of the tags, which means that git describe and therefore setuptools_scm doesn't read the version correctly. The best way to fix this is to ask RTD nicely to disable shallow clone for your builds. e.g. readthedocs/readthedocs.org#5648

This! I think this is causing the version issues I was describing in my previous post. The master branch is properly tagged (i.e. plamsapy.__version__ properly gives 0.5.1.devX right now). Further evidence of this, (if I remember correctly) when @StanczakDominik built the documentation locally this version issue was not present.

It appears the only way to get the DONT_SHALLOW_CLONE flag activated is to contact RTD admin via email or opening an issue, see https://docs.readthedocs.io/en/stable/guides/feature-flags.html and readthedocs/readthedocs.org#5031 (comment).

@StanczakDominik
Copy link
Member Author

Yup, that would be it. However, I don't want to put more strain on RTD's resources by making them download our entire repo's history (I'll do some comparisons on the bandwidth necessary later) for each build just so the version renders nicely, so I wonder if this is something we could side step on our own.

@StanczakDominik
Copy link
Member Author

Sounds like https://stackoverflow.com/a/41949974 might work?

@StanczakDominik
Copy link
Member Author

Nope, that didn't help matters. All right, I'll ask for the feature flag :)

@StanczakDominik
Copy link
Member Author

This should now work; if not, I'll tinker with the tags afterwards. :)

@StanczakDominik StanczakDominik merged commit 0c9b3c4 into PlasmaPy:master Mar 8, 2021
@StanczakDominik StanczakDominik deleted the sphinx-changelog branch March 8, 2021 13:38
@StanczakDominik StanczakDominik added this to the 0.6.0 milestone Mar 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs PlasmaPy Docs at http://docs.plasmapy.org
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants