Front matter defaults for collection's documents in subfolders - yaml

I would like to organize collection's documents in subfolders and assign them different categories through front matter defaults. I have the following structure:
_kb
- category1
- article1.md
- category2
- article2.md
In my _config.yml file I have:
# Collections
collections:
kb:
output: true
permalink: /kb/:name/
# Defaults
defaults:
-
scope:
path: "_kb/category1/"
type: "kb"
values:
category: "category1"
-
scope:
path: "_kb/category2/"
type: "kb"
values:
category: "category2"
But this doesn't work. Any idea how I can assign different categories to documents in different subfolders through front-matter defaults?

I don't think what you are looking for is possible.
Reading the documentation, it should be possible. But I have done some experimentation with Jekyll 2.4 and the "path" appears to be the result of the permalink conversion.
With your example setup I added this as a set of defaults
-
scope:
path: "kb/article1/"
type: "kb"
values:
category: "category6"
The generated file got "category6" assigned to it.

Related

Microsoft Power Automate - Hide body from response

I am trying to develop a custom connector in Microsoft Power Platform. Currently my connector have one action:
paths:
/Array_Find-Differences:
post:
description: Find items from one array that is not present in the second array
operationId: post-array-find-differences
summary: Array - Find Difference Between Two Arrays
tags:
- Array
parameters:
- name: array_Find-Difference-Definition
in: body
schema:
$ref: '#/definitions/Array_Find-Difference-Definition'
description: Provide an input array as well as an array to compare against.
required: true
x-ms-visibility: important
consumes:
- application/json
produces:
- application/json
responses:
'200':
description: >-
Returns a new array containing the values that are not present in
the original array.
examples:
application/json: []
schema:
type: object
properties:
array:
type: array
items:
type: string
description: The new array containing different values.
title: Difference Array
x-ms-visibility: important
description: array
definitions:
Array_Find-Difference-Definition:
type: object
x-ms-visibility: important
properties:
array:
type: string
compare:
type: string
example:
array:
- 1
- 2
- 3
compare:
- 1
- 2
- 3
- 4
As you can see in the response, I have only defined "Difference Array" as the output I want to show.
However, in the Power Automate workflow designer, I am presented with other options such as array and body.
How can I hide these?
In the UI you can set the visibility of each property when you import the Response 'from sample'. If you then click on the respective properties, you can change the visibility from there.
Does that fix your problem?

Pywalify - evaluate nested maps

I'm using pykwalify to validate a schema.
Given this yaml:
variables:
dev:
options:
key: value
uat:
key: value
key2: value
prd:
key: value
key2: value
Under variables, any map should be allowed.
Under that second level (dev, uat, prd) - any key should be allowed, EXCEPT options. "options" should not be allowed here.
I've tried using a regex, but this is only evaluating the top level, and I'm not quite sure how evaluate the level nested under that "dev, uat, prd" level.
variables:
type: map
matching-rule: all
mapping:
regex;([^,]+):
type: any
regex;(^(?!.*options:).*$):
type: any
Another potential option would be if I have to explicitly list the values that are allowed, that would work too.
I see two issues in your snippet:
The regex to match anything but "options" is wrong.
The schema isn't properly structured for the nested mapping.
The following schema should provide what you need:
variables:
type: map
matching-rule: all
mapping:
regex;([^,]+):
type: map
mapping:
regex;(^(?!options$).*):
type: any

raml2html not generating arrays declarations properly

I am using the raml2html tool to generate html documentation for my ReST apis.
I have defined all my types in a raml file memberTypes.raml that I include in the main service.raml.
Following is a sample from the service.raml file.
#%RAML 1.0
title: update member object
uses:
memberTypes: /memberTypes.raml
types:
Member:
properties:
termsAndConditions:
type: memberTypes.TermsAndConditions[]
description: The terms and conditions that the member has accepted.
required: false
person:
type: memberTypes.Person
description: The personal details of the member.
required: true
And following is a sample for the 2 properties above in memberTypes.raml
Person:
properties:
personName:
type: NameType
description: The name of the member.
required: true
dateOfBirth:
type: DateOfBirth
required: true
TermsAndConditions:
properties:
version:
type: string
description: The version of the terms and conditions.
acceptedDate:
type: date-only
description: The date on which the corresponding terms and conditions were accepted. Format is YYYY-MM-DD, ISO-8601 Calendar date format.
Now, below is the what I get in the html
The array is shown as array of memberTypes.TermsAndConditions. The questions is how do i get rid of the memberTypes? i simply want the type to be array of TermsAndConditions.
How do I achieve this? is there a command line option to raml2html tool that will do the trick?
I don't think there is command line option to do that, since the template / theme of raml2html defines how things are shown in HTML. You can edit the default theme. If I recall correctly that is defined in item.nunjucks file.
The usual use case for that is "array of objects" or "array of strings" but there is also definitions how to show non standard type types.

Optional itemin a swagger yaml definition

I have the following deinition in swagger.yaml
Content:
type: object
properties:
text:
type: string
image:
ref: "#/definitions/Image"
allowEmptyValue: true
I get Additional properties not allowed: allowEmptyValue as an error
How do I make image optional? ie might only be text no images
allowEmptyValue applies only to query parameters and means a different thing -
the parameter is included, but its value may be empty, as in ?param=.
In schemas, all properties are optional by default. You can make certain properties required by including them in the required array. Properties not listed in required are considered optional.
Content:
type: object
properties:
text:
type: string
image:
ref: "#/definitions/Image"
# text is required, image is optional
required:
- text

YAML by example

I am trying to design the configuration file format for my app and have chosen YAML. However, this (obviously) means I need to be able to define, parse and validate proper YAML syntax!
In the config file, there must be a collection/sequence called widgets. This sequence needs to contain a set of typed widgets (possible types are fizz, buzz and foobaz). Each widget also has a name and various other properties (depending on the type). For example:
myappconfig.yaml
================
widgets:
- buzz:
name: Red Buzz
isSilly: true
- buzz:
name: Blue Buzz
isSilly: false
- foobaz:
name: Abracadabra
rating: 3000
specialty: Such YAML much amaze
My simple question is: Have I created a proper/valid YAML file above? Meaning, based on my constraints, am I understanding YAML syntax correctly in my implementation?
You can check the syntax of your YAML, e.g. on this website.
Your YAML is parsed as this:
{'widgets': [{'buzz': {'name': 'Red Buzz', 'isSilly': True}}, {'buzz': {'name': 'Blue Buzz', 'isSilly': False}}, {'foobaz': {'rating': 3000, 'name': 'Abracadabra', 'specialty': 'Such YAML much amaze'}}]}
which looks like what you seem to be after.
If the widget name should be unique, you can use it for keys:
widgets:
RedBuzz:
type: buzz
isSilly: true
BlueBuzz:
type: buzz
isSilly: false
Abracadabra:
type: foobaz
rating: 3000
specialty: Such YAML much amaze
This one uses grouping by widget type:
widgets:
buzz:
- RedBuzz:
isSilly: true
- Blue Buzz:
isSilly: false
foobaz:
- Abracadabra:
rating: 3000
specialty: Such YAML much amaze
Also if you're feeling nerdy you can use widgets types merge like this:
buzz_widget: &buzz_widget
type: buzz
foobaz_widget: &foobaz_widget
type: foobaz
widgets:
RedBuzz:
isSilly: true
<<: *buzz_widget
BlueBuzz:
isSilly: false
<<: *buzz_widget
Abracadabra:
rating: 3000
specialty: Such YAML much amaze
<<: *foobaz_widget
As for me, using nested key-values structure (for non-primitive elements) is preferable. Being parsed into a map, you can always access it's values as a collection. At the same time you have unique constraint and constant access time (by key). If your keys should not be unique, then you should try restructuring it before giving back to sequence.

Resources