diff --git a/Jenkinsfile b/Jenkinsfile
index d9086afea..f62286e4f 100644
--- a/Jenkinsfile
+++ b/Jenkinsfile
@@ -94,7 +94,7 @@ pipeline {
agent {
dockerfile {
filename 'ci/typos.Dockerfile'
- additionalBuildArgs '--build-arg VERSION=1.0'
+ additionalBuildArgs '--build-arg VERSION=1.16.5'
}
}
steps {
diff --git a/README.adoc b/README.adoc
index 23092e10b..443f68468 100644
--- a/README.adoc
+++ b/README.adoc
@@ -15,14 +15,14 @@ Once `g8` command is installed (see http://www.foundweekends.org/giter8/setup.ht
```
% g8 file://.
```
-You can alos use the github resolution:
+You can also use the github resolution:
```
% g8 normation/rudder-plugins
```
And answer the questions. Only the `name` is mandatory: use the plugin short name, with
-space and capital if you want (see convetion below).
+space and capital if you want (see convention below).
Juste hitting choose the default value (the one between []).
```
@@ -50,7 +50,7 @@ minus 'rudder-plugin-" prefix.
Each plugin build information are grouped in file `build.conf` in plugin root directory.
-== Branch versionning and compatibility with Rudder versions
+== Branch versioning and compatibility with Rudder versions
Plugins are linked to Rudder patch version, so we retrieve in `rudder-plugins` the same branch
@@ -64,7 +64,7 @@ corresponding Rudder patch version:
- etc
```
-This scheme allows to ensure total binary compatiblity, and upgrade is done automatically by rudder package at upgrade.
+This scheme allows to ensure total binary compatibility, and upgrade is done automatically by rudder package at upgrade.
== Plugin version and Tag convention
@@ -73,7 +73,7 @@ This scheme allows to ensure total binary compatiblity, and upgrade is done aut
Plugin versions are composed in two parts separated by a `-`:
- the Rudder corresponding version (including the patch number),
-- the plugin own version in format X.Y(.Z) where the Z part is optionnal.
+- the plugin own version in format X.Y(.Z) where the Z part is optional.
For example, the `datasources` plugin, in own version 2.1, for Rudder 7.2.3 will get version: `7.2.3-2.2`.
@@ -126,7 +126,7 @@ npm install -g elm
To build a plugin package, do:
```
-git checkout tag-corresponding-to-plugin-vesion
+git checkout tag-corresponding-to-plugin-version
make clean && make generate-all-pom && make plugin-name
```
@@ -172,4 +172,4 @@ https://www.rudder.io/en/expand/contribute/
== Authors
-Authors are tracked by their git name and public git hostory of the project.
+Authors are tracked by their git name and public git history of the project.
diff --git a/_typos.toml b/_typos.toml
index 32facb09a..1b5b5a155 100644
--- a/_typos.toml
+++ b/_typos.toml
@@ -1,5 +1,9 @@
[default.extend-words]
monitord = "monitord"
+Ser = "Ser"
+unser = "unser"
+# False positive on the OAUTHv2 string
+OAUT = "OAUT"
# All exceptions below should be removed when upstream will be fixed
includeSytem = "includeSytem"
@@ -7,3 +11,6 @@ Sytem = "Sytem"
cssPsuedoElementExclusion = "cssPsuedoElementExclusion"
Psuedo = "Psuedo"
criterias = "criterias"
+Formater = "Formater"
+Provid = "Provid"
+Optionnal = "Optionnal"
\ No newline at end of file
diff --git a/ansible-policies/build.conf b/ansible-policies/build.conf
index bc22bc6a5..07c69f8a2 100644
--- a/ansible-policies/build.conf
+++ b/ansible-policies/build.conf
@@ -11,7 +11,7 @@ plugin-name=ansible-policies
# the full name is derived from rudder-plugin-name
plugin-fullname=rudder-plugin-${plugin-name}
-# Human readable short/title descrption (used for one line text)
+# Human readable short/title description (used for one line text)
plugin-title-description="""This plugin distributes a technique to run Ansible jobs from Rudder and reports their results."""
# WEB, HTML description.
@@ -21,6 +21,6 @@ plugin-web-description=
This plugin distributes a technique to run Ansible job
# - A.B: Rudder major.minor
# - x.y(.z): plugin major.minor.micro. Micro should be omitted. When omitted, z is assumed to be 0.
# For the build, we split the information between two properties, rudder branch and plugin version,
-# which must be concaneted with "-" to build the plugin version.
+# which must be concatenated with "-" to build the plugin version.
plugin-version=2.0
diff --git a/ansible-policies/packaging/postinst b/ansible-policies/packaging/postinst
index b7b2af458..bd6a2cd10 100755
--- a/ansible-policies/packaging/postinst
+++ b/ansible-policies/packaging/postinst
@@ -4,7 +4,7 @@ PLUGIN_FULL_NAME="rudder-plugin-ansible-policies"
PRETTY_NAME="Ansible Policies"
CONFIGURATION_PATH=/var/rudder/packages/$PLUGIN_FULL_NAME
-# Code below should be mostly comon between the plugins
+# Code below should be mostly common between the plugins
SOURCE_DIR=${CONFIGURATION_PATH}/techniques
CONFIG_REPO=/var/rudder/configuration-repository
diff --git a/api-authorizations/README.adoc b/api-authorizations/README.adoc
index a91b70c82..115b1021b 100644
--- a/api-authorizations/README.adoc
+++ b/api-authorizations/README.adoc
@@ -23,7 +23,7 @@ You can log information about ACL (behavior and errors) by adding the following
+
- If enabled, all change to configuration (Directives, Rules, Groups and Parameters) will be submitted for validation via a Change Request based on node targeting (configured below).
- A new Change Request will enter the Pending validation status, then can be moved to Pending deployment (approved but not yet deployed) or Deployed (approved and deployed) statuses.
+ If enabled, all change to configuration (directives, rules, groups and parameters) will be
+ submitted for validation via a change request based on node targeting (configured
+ below).
+ A new change request will enter the Pending validation status, then can be moved to
+ Pending deployment (approved but not yet deployed) or Deployed (approved and
+ deployed) statuses.
- If you have the user management plugin, only users with the validator or deployer roles are authorized to perform
+ If you have the user management plugin, only users with the validator or
+ deployer roles are authorized to perform
these steps (see /opt/rudder/etc/rudder-users.xml).
- If disabled or if the change is not submitted to validation, the configuration will be immediately deployed.
+ If disabled or if the change is not submitted to validation, the configuration will be
+ immediately deployed.
- By default, email notifications are disabled. To enable it make sure that the smtp.hostServer parameter is
- not left empty in the configuration file: /opt/rudder/etc/plugins/change-validation.conf
+ By default, email notifications are disabled. To enable them, make sure that the
+ smtp.hostServer parameter is
+ not left empty in the configuration file:
+ /opt/rudder/etc/plugins/change-validation.conf
@@ -170,13 +194,15 @@
Configure change request triggers
exempt some users from validation;
-
trigger change request only for changes impacting nodes belonging to some supervised groups;
+
trigger change request only for changes impacting nodes belonging to some supervised groups;
+
-
Be careful: a change request is created when at least one predicate matches, so an exempted user
+
Be careful: a change request is created when at least one predicate matches, so an
+ exempted user
still need a change request to modify a node from a supervised group.
-
Configure Users with change validation
+
Configure users with change validation
@@ -189,49 +215,55 @@
Configure Users with change validation
- Any change done by a Validated User will be automaticaly deployed without validation needed by another user.
+ Any change done by a validated user will be automatically deployed without validation needed
+ by another user.
-
Configure Groups with Change Validations
-
-
-
-
+
Configure groups with change validations
+
+
+
+
+
+
-
-
-
-
-
-
+
+
+
+
+
+
+ Change validation are enable for any change that would impact a node belonging to one
+ of the chosen groups below.
+ Be careful: a change on one another group
+
+
+ The supervised changes are:
+
+
any change in a global parameter, as these changes can have side effects spreading
+ technique code,
+
any modification in one of the supervised groups,
+
any change in a rule which targets a node which belong to a group marked as supervised,
+
+
any change in a directive used in one of the previous rules.
+
+
+
+ Changes in techniques are not subjected to change validation, nor are changes resulting from
+ an archive import.
+
-
- Change validation are enable for any change that would impact a node belonging to one of the chosen groups below.
- Be careful: a change on one another group
-
-
- The supervised changes are:
-
-
any change in a global parameter, as these changes can have side effects spreading technique code,
-
any modification in one of the supervised groups,
-
any change in a rule which targets a node which belong to a group marked as supervised,
-
any change in a directive used in one of the previous rules.
-
-
-
- Changes in techniques are not subjected to change validation, nor are changes resulting from an archive import.
-