fix type of keywords entry in frontmatter (in /registry/) (#517)

keywords should be a string, not an array containing one string

Signed-off-by: Gaetan de Villele <gdevillele@gmail.com>

docs/spec/api.md

@@ -1,7 +1,6 @@
 ---
 description: Specification for the Registry API.
-keywords:
-- registry, on-prem, images, tags, repository, distribution, api, advanced
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced
 title: Docker Registry HTTP API V2
 ---
 
@@ -5476,4 +5475,4 @@ The following headers will be returned with the response:
 |Name|Description|
 |----|-----------|
 |`Content-Length`|Length of the JSON response body.|
-|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|
+|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|

docs/spec/auth/index.md

@@ -1,11 +1,10 @@
 ---
 description: Docker Registry v2 authentication schema
-keywords:
-- registry, on-prem, images, tags, repository, distribution, authentication, advanced
+keywords: registry, on-prem, images, tags, repository, distribution, authentication, advanced
 title: Docker Registry v2 authentication
 ---
 
 See the [Token Authentication Specification](token.md),
 [Token Authentication Implementation](jwt.md),
 [Token Scope Documentation](scope.md),
-[OAuth2 Token Authentication](oauth.md) for more information.
+[OAuth2 Token Authentication](oauth.md) for more information.

docs/spec/auth/jwt.md

@@ -1,7 +1,6 @@
 ---
 description: Describe the reference implementation of the Docker Registry v2 authentication schema
-keywords:
-- registry, on-prem, images, tags, repository, distribution, JWT authentication, advanced
+keywords: registry, on-prem, images, tags, repository, distribution, JWT authentication, advanced
 title: Docker Registry v2 Bearer token specification
 ---
 
@@ -325,4 +324,4 @@ authorization then the registry will return the appropriate error.
 
 At no point in this process should the registry need to call back to the
 authorization server. The registry only needs to be supplied with the trusted
-public keys to verify the token signatures.
+public keys to verify the token signatures.

docs/spec/auth/oauth.md

@@ -1,7 +1,6 @@
 ---
 description: Specifies the Docker Registry v2 authentication
-keywords:
-- registry, on-prem, images, tags, repository, distribution, oauth2, advanced
+keywords: registry, on-prem, images, tags, repository, distribution, oauth2, advanced
 title: Docker Registry v2 authentication using OAuth2
 ---
 
@@ -181,4 +180,4 @@ HTTP/1.1 200 OK
 Content-Type: application/json
 
 {"refresh_token":"kas9Da81Dfa8","access_token":"eyJhbGciOiJFUzI1NiIsInR5":"expires_in":900,"scope":"repository:samalba/my-app:pull,repository:samalba/my-app:push"}
-```
+```

docs/spec/auth/scope.md

@@ -1,7 +1,6 @@
 ---
 description: Describes the scope and access fields used for registry authorization tokens
-keywords:
-- registry, on-prem, images, tags, repository, distribution, advanced, access, scope
+keywords: registry, on-prem, images, tags, repository, distribution, advanced, access, scope
 title: Docker Registry token scope and access
 ---
 
@@ -133,4 +132,4 @@ restricting scope to specific type, name, and actions combinations should be
 done by fetching an access token using the refresh token. Since the refresh
 token is not scoped to specific resources for an audience, extra care should
 be taken to only use the refresh token to negotiate new access tokens directly
-with the authorization server, and never with a resource provider.
+with the authorization server, and never with a resource provider.

docs/spec/auth/token.md

@@ -1,7 +1,6 @@
 ---
 description: Specifies the Docker Registry v2 authentication
-keywords:
-- registry, on-prem, images, tags, repository, distribution, Bearer authentication, advanced
+keywords: registry, on-prem, images, tags, repository, distribution, Bearer authentication, advanced
 title: Docker Registry v2 authentication via central service
 ---
 
@@ -248,4 +247,4 @@ Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkJWM0Q6MkFWWj
 ```
 
 This is also described in [Section 2.1 of RFC 6750: The OAuth 2.0 Authorization
-Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-2.1)
+Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-2.1)

docs/spec/index.md

@@ -1,11 +1,10 @@
 ---
 description: Explains registry JSON objects
-keywords:
-- registry, service, images, repository,  json
+keywords: registry, service, images, repository,  json
 title: Docker Registry Reference
 ---
 
 * [HTTP API V2](api.md)
 * [Storage Driver](../storage-drivers/index.md)
 * [Token Authentication Specification](auth/token.md)
-* [Token Authentication Implementation](auth/jwt.md)
+* [Token Authentication Implementation](auth/jwt.md)

docs/spec/json.md

@@ -1,8 +1,7 @@
 ---
 description: Explains registry JSON objects
+keywords: registry, service, images, repository,  json
 published: false
-keywords:
-- registry, service, images, repository,  json
 title: Docker Distribution JSON canonicalization
 ---
 
@@ -84,4 +83,4 @@ var canonical bytes.Buffer
 if err := json.Indent(&canonical, incoming, "", ""); err != nil {
 	// ... handle error
 }
-```
+```

docs/spec/manifest-v2-1.md

@@ -1,7 +1,6 @@
 ---
 description: image manifest for the Registry.
-keywords:
-- registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
 title: Image manifest V2, schema 1
 ---
 
@@ -159,4 +158,4 @@ by *libtrust*.  A signature consists of the following fields:
    ]
 }
 
-```
+```

docs/spec/manifest-v2-2.md

@@ -1,7 +1,6 @@
 ---
 description: image manifest for the Registry.
-keywords:
-- registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
 title: Image manifest V2, schema 2
 ---
 
@@ -290,4 +289,4 @@ their own, but only serve to fill in the parent chain in a compatible way.
 The IDs in these synthetic configurations will be derived from hashes of their
 respective blobs. The registry will create these configurations and their IDs
 using the same scheme as Docker 1.10 when it creates a legacy manifest to push
-to a registry which doesn't support the new format.
+to a registry which doesn't support the new format.