* endpoint/api/repository: limit the number of tags returned
- Limit the number of tags returned by /api/v1/repository/<ns:repo> to 500.
- Uses the tag history endpoint instead, with an active tag filte.
- Update UI to use tag history endpoint instead.
The user metadata fields are nullable in the database, but were not in
the json sechema. This prevented users from updating some of their
information on the site if they hadn't set the metadata fields.
1) Change to show solid dots (instead of open ones) if we are collapsing into a single track due to track count being > 5
2) Add a hover tooltip on track dots to show the tags associated with that image
3) Change the tag selection menu to only show images that are visible currently
4) Refactor the tracks code to massively reduce the amount of ng-repeats thus making the loading much faster when there are many, many tags
Fixes https://jira.coreos.com/browse/QUAY-949
We no longer allow viewing individual images, but instead only manifests. This will help with the transition to Clair V3 (which is manifest based) and, eventually, the the new data model (which will also be manifest based)
Before, we'd load *all* the robots, which can be a huge issue in namespaces with a large number of robots. Now, we only load the top-20 robots (as per recency in login), and we also limit the information returned to the entity search to save some bandwidth.
Fixes https://jira.coreos.com/browse/QUAY-927
Before this change, if a build was triggered by a build trigger that was subsequently deleted, we'd display "Manually triggered" for the build in the UI, even though we have sufficient metadata to show *nearly the same* normal build information. After this change, if we have said trigger metadata, we still display as much as we can.
Fixes https://jira.coreos.com/browse/QUAY-855
includes the options for maximum search results per page, and the
maximum number of pages available before help text is shown, and
the next page button is disabled
Instead of deleting a namespace synchronously as before, we now mark the namespace for deletion, disable it, and rename it. A worker then comes along and deletes the namespace in the background. This results in a *significantly* better user experience, as the namespace deletion operation now "completes" in under a second, where before it could take 10s of minutes at the worse.
Fixes https://jira.coreos.com/browse/QUAY-838
