Daniel Axtens [Mon, 29 Apr 2019 15:33:16 +0000 (01:33 +1000)]
REST: Handle regular form data requests for checks
08d1459a4a40 ("Add REST API validation using OpenAPI schema") moved
all API requests to JSON blobs rather than form data.
dc48fbce99ef ("REST: Handle JSON requests") attempted to change the
check serialiser to handle this. However, because both a JSON dict
and a QueryDict satisfy isinstance(data, dict), everything was handled
as JSON and the old style requests were broken.
Found in the process of debugging issues from the OzLabs PW & Snowpatch
crew - I'm not sure if they actually hit this one, but kudos to them
anyway as we wouldn't have found it without them.
Fixes: dc48fbce99ef ("REST: Handle JSON requests") Signed-off-by: Daniel Axtens <dja@axtens.net>
Jeremy Kerr [Sat, 27 Apr 2019 11:12:16 +0000 (19:12 +0800)]
notifications: fix notification expiry when no user is associated
It's possible that an EmailConfirmation object will have no associated
user (eg, for email opt-out, which does not require a user object). In
this case, we will see a NULL value for EmailConfirmation.user_id.
However, having a NULL value appear in a SQL 'IN' clause will match
every value. This means that once one of these null-user
EmailConfirmations is present, we will never expire any non-active user
accounts.
This change adds a filter for a valid user_id when we query for active
EmailConfirmation objects. This means we'll have a valid values set to
use in the pending_confs set.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
[dja: fix pep8 issue] Signed-off-by: Daniel Axtens <dja@axtens.net>
Daniel Axtens [Fri, 15 Mar 2019 06:27:40 +0000 (17:27 +1100)]
Fix YAML loader warning
In my tests I'm seeing:
/home/patchwork/patchwork/patchwork/tests/api/validator.py:229:
YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated,
as the default Loader is unsafe. Please read https://msg.pyyaml.org/load
for full details.
Fix this by using the safe loader in the tests.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Stephen Finucane <stephen@that.guru>
Daniel Axtens [Thu, 28 Feb 2019 04:29:53 +0000 (15:29 +1100)]
parser: recognise git commit consisting only of empty new file
Commits with only an empty new file are liable to be missed.
The parser state machine doesn't recognise the headers "new
file mode" and "index": teach it about them.
Add a test to demonstrate.
It's a little bit academic as you don't usually send patches like
that but sometimes you do, especially if you're a snowpatch dev :)
Closes: #256 Reported-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Stephen Finucane <stephen@that.guru>
Ali Alnubani [Tue, 8 Jan 2019 12:38:47 +0000 (12:38 +0000)]
Beautify check counts in the patch list view
This patch [1] adds colors to the checks in the patch list view.
The colors are set based on the check's priority, with FAILURE
having the highest priority, followed by WARNING, and then SUCCESS.
Only the check with the highest priority and non-zero count
will be colored. This is to make failures and warnings more visible.
The patch also [2] replaces zero counts with a '-' for
FAILUREs and WARNINGs.
The SUCCESS count will only be replaced by a '-'
when all other checks have zero counts too.
Suggested-by: Thomas Monjalon <thomas@monjalon.net> Signed-off-by: Ali Alnubani <alialnu@mellanox.com> Signed-off-by: Stephen Finucane <stephen@that.guru>
Ali Alnubani [Tue, 8 Jan 2019 12:38:45 +0000 (12:38 +0000)]
Fix return code when getting patch information fails
The `info` command always exits with success, even if
the patch didn't exist.
Modified to exit with a non-zero exit status and
print an error message in that case.
Signed-off-by: Ali Alnubani <alialnu@mellanox.com> Reviewed-by: Stephen Finucane <stephen@that.guru>
It turns out it is possible to make PATCH requests with JSON bodies
rather than form-encoded data - you just need to include a Content-Type
header. Document this.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Django Admin seems to be doing something funky with how it's handling
the creation of a User's corresponding UserProfile instance when
modelled as an inline field. Re-setting the UserProfile.user attribute
seems to resolve the issue, so do just that.
Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #110
Stephen Finucane [Thu, 15 Nov 2018 12:57:58 +0000 (13:57 +0100)]
Add REST API validation using OpenAPI schema
Add validation using the rather excellent 'openapi_core' library. The
biggest issue we have to contend with is the fact that 'openapi_core'
expects us to be able to provide a templated URL string for each request
(e.g. '/api/patches/123/' would become '/api/patches/<id>/') and Django
doesn't provide a way to do this [*]. We work around this by
reverse-engineering some of the Django code to turn a URL to its
matching regex, which we can then easily convert into a template string.
It's kind of hacky and not at all portable but, crucially, it does work
and has highlighted some nice bugs in the API that have already merged.
Going forward, we can probably modify 'openapi_core' somewhat to remove
the need for the templated URL string. If and when this happens, most of
the funkier code here can happily go away.
[*] Django 2.0+ [1] does actually provide a way to do template
string-based URLs and in fact recommends them now, with regexes being
reserved for more advanced corner cases. However, we don't want to drop
support for the Django 1.11 yet as it is the most recent LTS release.
Stephen Finucane [Fri, 26 Oct 2018 23:49:17 +0000 (00:49 +0100)]
docs: Make API document versioned
OpenAPI doesn't appear to support versioning natively, suggesting
instead that separate documents are kept. Rather than doing this
manually, let's use a templating tool - Jinja2, in this case - to
generate these document for us from a single master document.
Note that while we can now auto-generate these whenever we need them
(and we tend to avoid storing auto-generated assets in VCS), these
change so rarely that it's easier to just store them. This also means we
can reference the schemas themselves online. We do this in a following
change.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Fri, 26 Oct 2018 21:12:57 +0000 (22:12 +0100)]
docs: Document the '/events' resource
This is the final resource to document and also the most complicated, on
account of the polymorphism of the responses. However, with this done,
our first pass at an OpenAPI 3.0 schema is completed.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Fri, 26 Oct 2018 20:57:40 +0000 (21:57 +0100)]
docs: Document the '/bundles' resource
This one's a little unusual too, in that we provide the embedded
serializer for resources we haven't defined the end resource for. That's
necessary in general, due to recursive references in the API
(series-patch, patch-series etc.) so might as well embrace it early.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Fri, 26 Oct 2018 20:42:02 +0000 (21:42 +0100)]
docs: Start documenting API using OpenAPI
When the REST API was first added, we attempted to document it using
OpenAPI 2.0 (formerly Swagger). This was mostly never completed because
(a) it was really tedious and (b) no one was that bothered. However, as
we expand the range of clients for the REST API, having a well
documented API becomes more and more of an asset.
Start doing this by adding a brand new schema, this time using OpenAPI.
This will entirely replace the older schema and, as such, is namespaced
separately. We start by documenting '/' (i.e. the index) page and will
add additional resources as we go.
Signed-off-by: Stephen Finucane <stephen@that.guru>
I'm not actually sure why this wasn't raising an error. Perhaps it's
because null validation for char fields happens in forms rather than at
the database level. In any case, this won't happen normally since we
only allow creation via the admin API so simply start setting this.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Fri, 16 Nov 2018 15:47:43 +0000 (16:47 +0100)]
REST: Handle unset series
This was introduced in the recent "convert series from N:M to 1:N"
series. We take the opportunity to make the 'create_patch' and
'create_cover' utility methods a little smarter, in that series will
automatically be created for the patch/cover letter unless told not to.
This requires some related changes to other modules.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Sun, 28 Oct 2018 14:43:31 +0000 (14:43 +0000)]
tests: Add 'store_samples' decorator to 'test_bundle'
Add the decorator to the 'test_bundle' test class. This involves
splitting up the test cases so that each test case we care about makes
only a single request. We also add a missing test to ensure private
bundles cannot be shown by anyone but the owner.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Sun, 28 Oct 2018 14:40:31 +0000 (14:40 +0000)]
tests: Add 'store_samples' decorator
We want to start including sample API requests and responses in our
documentation. Given that these may get out of date over time, we
should really generate these things dynamically. Create a decorator that
will allow us to do just that.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Sat, 20 Oct 2018 22:20:52 +0000 (23:20 +0100)]
REST: Add additional documentation
As noted in the Django REST Framework docs [1], views that support
multiple methods can and should split their documentation using
'method:' style delimiters. Do just this.
Stephen Finucane [Tue, 30 Oct 2018 22:04:23 +0000 (22:04 +0000)]
README: Note latest version of requirements
These were missed previously
Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: 8eb3719a ("Add support for django-filter 2.0") Fixes: fab5571e ("Add support for Django REST Framework 3.9")