Merge lp:~rharding/charmworld/bundle-metadata into lp:~juju-jitsu/charmworld/trunk
Status: | Merged |
---|---|
Approved by: | Aaron Bentley |
Approved revision: | 405 |
Merged at revision: | 404 |
Proposed branch: | lp:~rharding/charmworld/bundle-metadata |
Merge into: | lp:~juju-jitsu/charmworld/trunk |
Diff against target: |
340 lines (+191/-41) 3 files modified
charmworld/testing/factory.py (+43/-1) charmworld/views/api.py (+115/-38) charmworld/views/tests/test_api.py (+33/-2) |
To merge this branch: | bzr merge lp:~rharding/charmworld/bundle-metadata |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Juju Gui Bot | continuous-integration | Approve | |
Benji York (community) | Approve | ||
Review via email: mp+188905@code.launchpad.net |
Commit message
Implement the /file/xxxx api off of the bundle api space.
Description of the change
This branch implements the /file/xxxx api off of the bundle api space. This is required to pull README content. This duplicates some of the style of the api parsing from the Charm code with some changes to be a little simpler. Things are kept as lists until the last minute, etc.
The general idea is to get back to the idea of an api call with a /bundle/
The _charm_icon stuff is a start because we'll need to have the ability to load the bundle icon by default if the charm is not promulgated/has one much like we do with charm icon. It just won't have the category complication part.
makeBundle was updated so that you can force the basket record to be created as well. This was required to be able to load the test file object into gridfs to make sure we could fetch it via the api response.
QA:
pull the changes, if you've got the demo bundles loaded you should be able to hit:
http://
http://
and get the proper response.
The big goal was to get back the idea of the trailing. I kept it a [] vs a string so that it's easier to find the bits in it.
One thing I changed to make consistent was the custom json response if the bundle id was invalid. That matched the charm behavior vs just throwing the not found exception. We had agreed during API design that all failures should provide some sort of payload of helpful info if possible.
The _charm_icon stuff is a start because we'll need to have the ability to load the bundle icon by default if the charm is not promulgated/has one much like we do with charm icon. It just won't have the category complication part.
As is the old tests are passing and were very helpful. The next step is to get the readme into the test bundle and have tests against getting it back out again via the url /~owner/ basket/ bundle/ file/README and such.