@@ -72,7 +72,7 @@ kind: ClusterRBACSyncConfig
72
72
metadata :
73
73
name : example-simple
74
74
spec :
75
- # Defines the roleRef to use against the subects defined above.
75
+ # Defines the roleRef to use against the subjects defined above.
76
76
bindings :
77
77
78
78
roleRef :
@@ -226,7 +226,7 @@ Usage of bin/rbacsync:
226
226
` ` `
227
227
228
228
In configuring upstreams, you'll likely have to add one or more flags. Note
229
- that you can also increase logging granulatiy , if you need more in depth
229
+ that you can also increase logging granularity , if you need more in depth
230
230
debugging.
231
231
232
232
# ### Enabling GSuite Group Configuration
@@ -425,11 +425,11 @@ You'll need cluster admin to perform this operation.
425
425
Release Process
426
426
---------------
427
427
428
- RBACSync is versioned using [semantic versioing ](https://semver.org/). For the
428
+ RBACSync is versioned using [semantic versioning ](https://semver.org/). For the
429
429
most part, patch releases should be only bug fixes, minor releases can have
430
430
backwards compatible feature introductions and major releases are for breaking
431
431
changes. If you can't decide whether a feature or change is breaking, err on
432
- the side of caution when incrementing the verion number and just do it.
432
+ the side of caution when incrementing the version number and just do it.
433
433
434
434
The release process for rbacsync is triggered with tags. Every build in master
435
435
will pickup the tag and create a version number relative, using a git
@@ -458,7 +458,7 @@ rbacsync 0.1.0
458
458
459
459
With this release, we introduce support for Google Groups API with
460
460
GSuite Directory SDK. This allows one to configure groups without
461
- declared memberships that are queryed to the GSuite upstream resource.
461
+ declared memberships that are queried to the GSuite upstream resource.
462
462
```
463
463
464
464
There may be releases with complex information for upgrades and caveats, so
@@ -484,7 +484,7 @@ to be compatible with markdown.
484
484
485
485
While this is an extra step when releasing the software, it is very helpful
486
486
when looking at a project to see its releases properly documented in github.
487
- Falso ollow this practice to have a healthy project!
487
+ Also follow this practice to have a healthy project!
488
488
489
489
# License
490
490
0 commit comments