With the new unmaintained process [1], branches are being tagged with
EOM before being removed.
This behaviour breaks reno, making it struggle to find respective origin
and leads to releasenotes job failure.
In order to overcome the issue we add eom tag to the list of expected ones
when we can not find the refferenced branch.
With that, EOL tag will have prescedence over EOM one.
[1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html
Change-Id: Ic641af5aa65add9751b49fb47691a98f80a7c5a8
Python 3.9, 3.10 and 3.11 are now part of tested runtimes and we
actually test these versions.
Also Python 3.6 test is added so that the minimum version is actually
tested.
Change-Id: I1cb6a0dc6c2cd18eaf64ead4d4e8b3d686f1ecee
I believe this `print()` statement was not intentional, as it's the only `print` to `sys.stderr` in the entire project. We already are logging to debug level, so we don't need to also print.
This issue causes ~20 log lines for Qiskit Terra any time we run Reno.
Change-Id: I664156017ea24e819c6a7cffe6711376306b59fe
Subsections will appear underneath their top-level section, in
the order defined in the config file. They will use a ^ or ~
underline rather than -.
Users define subsections by adding a number to the end
of the section entry, either 2 or 3. It will be a subsection
of the parent section above it. This syntax is simpler than others
considered, like nesting lists inside a top-level section. It also
makes it easy for us to support deeper levels of nesting if we'd like.
Like normal sections, in users' notes files, they will use the
ID they define for each subsection.
Change-Id: Ib7b4781de81e19d11a7acb863204067c0946827b
Story: 2010375
OpenStack has changed the naming scheme for stable branches after
reaching the end of the alphabet. In order to make sure that the new
branches like stable/2023.1 are sorted after the previous names like
stable/zed, two new variables are introduced that control the sorting
behaviour.
Change-Id: I489dd7a811ebd09c16ecb1f85a0a2e162146962a
Users configure the sections as a List[List[str]]. That continues
to be the case.
But now we parse that raw list into a list of a NamedTuple
called Section. This makes our consuming code, `formatter.py`
and `linter.py` more clear because we can access the values
by name, rather than index.
But more importantly, this is a "prefactor" to add support
for nested headers. In a followup, we will add the field
'top_level: bool' so that `formatter.py` can know how to
render the section. This factoring simplifies that
change.
Change-Id: Ie80a525af61e879dd872079b2b9d0513db40e82d
Git 2.37 is setting the default branch name as `main`, rather than
`master`. This is without me having set `init.defaultBranch`. So,
test_scanner.py fails for me because it expects `master`.
For our tests, we don't care which branch name is used. We only
need consistency, regardless of Git version. So, we can use
`git init --initial-branch`.
Change-Id: I8690432130bb49063276182926dd0e9003c98cf5
It is no longer supported by jammy and lead us to the following errors with the announce-release job.
```
No package matching 'python-dev' is available
```
Change-Id: I3abd71b9b18e627b3185b7a07a7a33f516ec3a72
We're seeing noise like the following in doc builds:
/foo/.tox/docs/lib/python3.9/site-packages/docutils/statemachine.py:707:
ResourceWarning: unclosed file <_io.BufferedReader name='/foo/.git/objects/pack/pack-dd69481843ca1b7377f2f109b0022221437aca20.pack'>
if not hasattr(pattern, 'match'):
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Enable tracemalloc for Sphinx gives us the 'Loader' as the root cause:
$ python -W all::ResourceWarning -X tracemalloc=100 -m sphinx.cmd.build ...
...
File "/foo/.tox/docs/lib/python3.9/site-packages/reno/sphinxext.py", lineno 114
ldr = loader.Loader(conf)
File "/foo/.tox/docs/lib/python3.9/site-packages/reno/loader.py", lineno 63
self._load_data()
...
(you could also use PYTHONTRACEMALLOC and PYTHONWARNINGS env vars)
Following this thread, it appears 'reno.scanner.Scanner' creates an
instance of 'dulwich.repo.Repo', however, it fails to close it [1]. The
'reno.loader.Loader' uses 'Scanner', meaning this also leaves around
open files.
The solution is simple: add a 'close()' method to both the 'Scanner' and
'Loader', and provide the necessary '__enter__' and '__exit__' magic
methods to use it as a context manager, like the 'Repo' object itself
supports.
[1] https://www.dulwich.io/docs/api/dulwich.repo.html#dulwich.repo.Repo.close
Change-Id: I0b9776f431cf902a9ace5d52961eb77caaae8eaa
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This stops silly typos making their way into release notes.
Change-Id: I43d98cc75332677c604e53a5b7a21239505ab4a4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Story: 1670421
Task: 6737
Make the tests a little more obvious as to what they're validating. Also
make use of delayed logging interpolation where possible.
Change-Id: I5da9cf6e744ea98834de2335b4d3ea0e02a74613
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Release note files should look like this:
issues:
- |
Some text here.
However, it's possible to make a mistake and create a release note
missing the top-level key:
- |
Some text here.
If you do this, reno fails with a cryptic error which Sphinx will bubble
up with zero context:
AttributeError: 'list' object has no attribute 'items'
Make this failure more obvious.
Change-Id: I488d14bc1134a38d4f76ed5f5368c84db8e39df3
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Story: 1670421
Task: 42802
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: Ic6a8a29687cb85b7867a5d5fa2ae58f6052f9692
This commit adds a new configuration option `default_branch`, which is
used to specify the default/base branch a repository is using.
Previously reno assumed the default branch was always named 'master'
which causes commands such as 'reno lint' to fail when it is run on a
repository that uses a different default branch name such as 'main'.
This config option gives users an option to specify which branch should
be used for cases like that.
Change-Id: I08f258206290fdc1dcb9fcfc078e30384667c925
Currently if we put a path separator in slug, "reno new" command
creates subdirectories under the notes subdirectory. This usually
results in the situation where the note file is put to an unexpected
place.
For example we have seen several cases with reno files placed under
releasenote/notes/releasenote/notes directory because the notes
subdirectory path is accidentally included in slug, like;
$ reno new releasenotes/notes/something-new
no configuration file in: ./releasenotes/config.yaml, ./reno.yaml
Created new notes file in releasenotes/notes/releasenotes/notes/something-new-2ff053c99583fc69.yaml
This change prohibits users from creating such subdirectries under
the notes subdirectory. The previous behavior can be restored by
the allow_subdirectories config option.
Change-Id: I30b5de3d5f35abb3b903e9ed9e4db42671421e88
The new pip resolver is extremely slow at calculating the
lower-constraints. Some other OpenStack projects have already dropped
the job. Let's do the same for reno.
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Change-Id: I489cbdf603991888c13b7730cfeb590fea175c25
When a commit matches multiple tags, it's usually preferable to select the
release tag. The typical use case is tagging a release candidate and then
tagging it with the release tag with no new commits.
Change-Id: I77ae7c2d5716430bb0a83d4f1ff82c75a8b695d6
The older PyYAML does not install cleanly on macOS.
Change-Id: I7772360d6988f305df19c761021b9eca3735e94c
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Add a sub-command for computing the next release version number by
applying Semantic Versioning rules to the release notes added to a
project since the last published release.
Add configuration options to control which notes sections trigger
updates to each level of the version number.
Change-Id: I96be0c81a3947aaa0bf9080b500cf1bc77abe655
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This commit adds a new config option 'encoding' which when set will take
a codec string from the stdlib codec library and use it as the encoding
kwarg for all open() calls that are part of the reno commands. This will
let a project assert a specific encoding for all release note files,
which can be important if the project is using special characters and
have contributors using multiple platforms or locales.
Change-Id: If90422fa95cb4eabc4c1722104cef3b28b7fca2d
Story: #2007757
Task: #39959
Some small changes for Victoria:
* Remove obsolete sections from setup.cfg
* Add Python 3.8 to setup.cfg
* Update hacking to version 3.1.0, disable E741 as we can ignore
this.
* Switch to victoria jobs
* Remove oslosphinx specific conditions from conf.py, oslosphinx is
retired and will not work with current Sphinx/python/reno anyhow.
Change-Id: I3a16eb66af59c8bd27b36c203260cfd3197f52f0
Switch to openstackdocstheme 2.2.1 version. Using
this version will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: I778b288f3b478c0fe1718bf5517c2c818b8d305e
This commit sets the parallel_read_safe extension metadata attribute to
True. This was previously set to False as a precaution and to avoid the
warning about the implicit default in change
I80a671a98901eb45ecb732d699400a76326b4cf2. However, in subsequent
testing running a sphinx build in parallel with the reno extension does
not cause any errors or issues in the built documentation and trying to
run in parallel with this value set to false raises a warning (which is
fatal if -W is set). This commit makes this change so that people can
use sphinx-build's parallel build option (-j) and -W at the same time.
Change-Id: I5a3b5f11d94c2a29c04582b4dde813d67a0efbc1
Current code was assuming if a reno.yaml file was found that it could
load that file to read config options. While probably a safe assumption
in the majority of cases, someone that isn't aware of this could modify
their config file to remove settings, leaving an empty or comment-only
file that when read does not actually load any yaml that can be used.
This adds protection for that to make reno does not try to use an empty
file.
Change-Id: I0ae0bcc93a79bbf66735833b654964b494485ee1
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
We only support Python 3 runtimes now. We no longer need future imports.
Change-Id: Ib568709bd01d12ff2fb6ef6fe31b290ea63e7caa
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
If no earliest version is provided for a branch, reno will scan commits
on the branch in reverse order, attempting to find a common ancestor
with the master branch. Currently, the first patch this finds must be
the tagged one or it will quit early. There's no particular reason to do
this. Instead, we can keep going for a little longer. This is helpful
for situations where we haven't branched off straight after the tag.
Change-Id: Ic0ed1305cf21deb6abea0991ec604d7f9b821622
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Change I49b659948f35381a44e2fb5f91dd6bf9e8ef619e provided a mechanism to
include the release note cache into generated sdists. Unfortunately,
attempting to build documentation with these tarballs generates the
following error:
Exception occurred:
File ".../lib/python3.7/site-packages/dulwich/repo.py", line 1004, in discover
"No git repository was found at %(path)s" % dict(path=start)
dulwich.errors.NotGitRepository: No git repository was found at PATH
This is because we're attempting to find the root of the git repo using
dulwich, which clearly isn't possible outside of a git repo.
Work around this by falling back to a search. We consider three options:
'.', '..', and '../..', which will handle calling Sphinx from the
rootdir, a 'docs' dir, and a 'docs/source' dir, which seem to be the
most common configurations.
We have no test coverage of the Sphinx integration so this is tested
manually.
Change-Id: Ic3a8ab8b127fd5bf51b91ac6e83d459ffc087fc4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Story: #1520096
Task: #6724