When generating the human-readable api-status.md document from the
JSON, the logic used to determine if a package had no Preview/Deprecated
APIs was incorrect. This change fixes and simplifies that condition.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Adds a info and a warning function that currently just wraps print.
In the future these classified print statements could be customized
for output specific to the message type.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Previously, apiage.py just print out a problem count when it found
an unexpected stable api in the new apis file. Now the output displays
something like this:
```
found new unexpected stable apis: API.LeakyBucket
error: 1 problems detected
```
Signed-off-by: John Mulligan <jmulligan@redhat.com>
There are instances in API status json with empty list for preview or
deprecated APIs. Due to a missing empty check we had corresponding
tables created without any content.
While adding the empty check also modify the condition which adds an
entry indicating absence of any preview/deprecated APIs to consider
empty lists.
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
I hadn't tested apiage well enough to see that the existing code didn't
correctly handle the case when all or many apis were becoming stable all
together. Things worked fine for a single function call, but not with
many. This fix tries to only update the JSON when needed while correctly
handling the case of multiple changes in one pkg at once.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Probably caused by last minute changes to the pr that added the feature,
it just needed the same initialization as the other section.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Promote an API from preview to stable, after the build tags are removed
from the Go source code. This mode can be used to help move apis that
are now stable out of preview state in our api-status.json file.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Find preview apis that should become stable. Find deprecated apis that
should be removed. Have a mode to convert between the low level json
report and some markdown that could be pasted into an issue.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
For those packages without any preview/deprecated APIs we used to
include a header despite any content under it. We could instead
mention the state in a meaningful sentence.
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
Fixes: #718
This change adds a new "fix-versions" mode to apiage.py, as well as the
ability to set placeholder version values when adding a new API. The
fix-versions mode replaces placeholder versions with real version
numbers. When fixing versions, the --fix-filter-pkg & --fix-filter-func
options can be used to narrow down what APIs will be fixed in case not
all version placeholder should be fixed to the same values.
Note that the placeholders being with a '$' character and look a bit
like a shell variable. However, the text is simply a reminder - only the
'$' prefix is significant. This indicates that the field is a
placeholder.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
It is kind of pointless to let the tool run if no source data is
present, so treat empty/missing source as an error.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This tool can be run as part of our CI as a mechanism to check that
(some) of the policy requirements are being met. It can also be run by
humans as part of the process to update the tracked API information.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Because there will be a lot of stable functions we only report on them
in the json report as the text report is more meant for summaries.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The go source (ast) visitor will now keep track of all public functions it
finds putting them into lists by category: deprecated, preview, stable.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Do more than collect names, because we're going to need more information
to feed to the eventual check tool.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Teach the implements tool how to detect functions marked deprecated and
marked preview in the go-ceph codebase. Especially helpful will be the
JSON output which can, in the future, be added to a tool-chain that
helps track when deprecated functions are to be removed and when preview
functions should become stable.
Note that this change ONLY implements the detection of
preview/deprecated based on the doc comments.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add new arguments to 'implements' that allow for specifying one or more
report type and either a dash ('-' meaning stdout) or a file name to
control where the report is written.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This io.Writer will be the destination for writes from the report.
This better matches with what the JSON report was doing.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This is a dev tool mainly for just those of us who work on the project,
so this is mainly just a quick-start type description.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
To be clearer about what the tool detects, rename "covered" to "found"
such as not to indicate an undocumented but used function is considered
"covered". Future arguments about what "covered" really means to be
scheduled at a later date. :-)
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Currently, annotating the functions (are they documented, deprecated,
etc) in the function listing is not very costly and there are very
few situations where that extra information would be unwanted. Just
annotate the listing every time when running the tool.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Allowing the tool to generate a JSON report makes it easier to add
additional tools later to make use of this data, without hand parsing
the text output.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add simple reporting functionality to the implements package that is
intended to mimic the output of the current contrib/apicompare.py
script.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a file for processing C sources using the `castxml` tool. This tool
produces XML describing a C AST. This file adds go code for invoking the
tool and minimal processing of the XML it generates.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This code makes use of Go's native AST processing packages and allows us
to analyze our source code using the go-ceph conventions.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This log.go file establishes the ability for the package's user to hand
it any logger that meets the very minimal interface.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This fairly hacky script can be used to check how much of the
various apis are covered by the go-ceph library.
It doesn't care about a lot of subtlety at the moment but does
give a fair idea of what types of functions are implemented vs.
those that are not.
Requires the tool 'castxml'.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
