Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

📖 switch markdownlint container to markdownlint-cli2 #419

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions .markdownlint-cli2.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Reference: https://github.com/DavidAnson/markdownlint-cli2#markdownlint-cli2yaml

config:
ul-indent:
# Kramdown wanted us to have 3 earlier, tho this CLI recommends 2 or 4
indent: 3

# Don't autofix anything, we're linting here
fix: false
24 changes: 12 additions & 12 deletions VERSIONING.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,37 +20,37 @@ Cluster API follows [Semantic Versioning](https://semver.org).
I'd recommend reading the aforementioned link if you're not familiar,
but essentially, for any given release X.Y.Z:

- an X (*major*) release indicates a set of backwards-compatible code.
- an X (**major**) release indicates a set of backwards-compatible code.
Changing X means there's a breaking change.

- a Y (*minor*) release indicates a minimum feature set. Changing Y means
- a Y (**minor**) release indicates a minimum feature set. Changing Y means
the addition of a backwards-compatible feature.

- a Z (*patch*) release indicates minimum set of bugfixes. Changing
- a Z (**patch**) release indicates minimum set of bugfixes. Changing
Z means a backwards-compatible change that doesn't add functionality.

*NB*: If the major release is `0`, any minor release may contain breaking
changes.

These guarantees extend to all code exposed in public APIs of
IP Address Manager. This includes code both in IP Address Manager
Baremetal itself, *plus types from dependencies in public APIs*. Types and
Baremetal itself, _plus types from dependencies in public APIs_. Types and
functions not in public APIs are not considered part of the guarantee.

In order to easily maintain the guarantees, we have a couple of processes
that we follow.

## Branches

IP Address Manager contains two types of branches: the *main*
branch and *release-X* branches.
IP Address Manager contains two types of branches: the _main_
branch and _release-X_ branches.

The *main* branch is where development happens. All the latest and
The _main_ branch is where development happens. All the latest and
greatest code, including breaking changes, happen on main.

The *release-X* branches contain stable, backwards compatible code. Every
major (X) release, a new such branch is created. It is from these
branches that minor and patch releases are tagged. In some cases, it may
The _release-X_ branches contain stable, backwards compatible code. Every
major (X) release, a new such branch is created. It is from these
branches that minor and patch releases are tagged. In some cases, it may
be necessary to open PRs for bugfixes directly against stable branches, but
this should generally be avoided.

Expand Down Expand Up @@ -98,12 +98,12 @@ for a command reference.
Minor and patch releases are generally done immediately after a feature or
bugfix is landed, or sometimes a series of features tied together.

Minor releases will only be tagged on the *most recent* major release
Minor releases will only be tagged on the _most recent_ major release
branch, except in exceptional circumstances. Patches will be backported
to maintained stable versions, as needed.

Major releases are done shortly after a breaking change is merged -- once
a breaking change is merged, the next release *must* be a major revision.
a breaking change is merged, the next release _must_ be a major revision.
We don't intend to have a lot of these, so we may put off merging breaking
PRs until a later date.

Expand Down
7 changes: 4 additions & 3 deletions hack/markdownlint.sh
Original file line number Diff line number Diff line change
@@ -1,19 +1,20 @@
#!/bin/sh
# markdownlint-cli2 has config file(s) named .markdownlint-cli2.yaml in the repo

set -eux

IS_CONTAINER="${IS_CONTAINER:-false}"
CONTAINER_RUNTIME="${CONTAINER_RUNTIME:-podman}"

# all md files, but ignore .github
if [ "${IS_CONTAINER}" != "false" ]; then
TOP_DIR="${1:-.}"
find "${TOP_DIR}" -type d \( -path ./vendor -o -path ./.github \) -prune -o -name '*.md' -exec mdl --style all --warnings {} \+
markdownlint-cli2 "**/*.md" "#.github"
else
"${CONTAINER_RUNTIME}" run --rm \
--env IS_CONTAINER=TRUE \
--volume "${PWD}:/workdir:ro,z" \
--entrypoint sh \
--workdir /workdir \
docker.io/pipelinecomponents/markdownlint:0.13.0@sha256:9c0cdfb64fd3f1d3bdc5181629b39c2e43b6a52fc9fdc146611e1860845bbae0 \
docker.io/pipelinecomponents/markdownlint-cli2:0.9.0@sha256:71370df6c967bae548b0bfd0ae313ddf44bfad87da76f88180eff55c6264098c \
/workdir/hack/markdownlint.sh "$@"
fi
6 changes: 3 additions & 3 deletions test/fuzz/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,19 +21,19 @@

b. Run below command to make C binary files for the same function.

```
```bash
clang -o yaml_FuzzNewIPPoolManager  yaml_FuzzNewIPPoolManager.a -fsanitize=fuzzer
```

c. Run the fuzzer as below

```
```bash
./yaml_FuzzNewIPPoolManager
```

- Execution: Here is an example for execution of some test outputs:

```
```text
[63 32 45 58 119 50 9 119 50 9 119 50 9 45 58
50 9 119 9 119 50 9 91 13 45 58]
&{TypeMeta:{Kind: APIVersion:}
Expand Down
Loading