npm audit and format

CHANGELOG.md

@@ -4,31 +4,31 @@
 
 ### Added
 
--  #356 Add fleet support
+- #356 Add fleet support
 
 ## [5.0.0] - 2024-03-12
 
 ### Changed
 
--  #309 Updated to Node20 and upgraded release workflows to @v1 tag
--  #306 update release workflow to use new prefix, remove deprecated release
--  #303 fix: ensure imageNames are not empty strings
--  #299 bump release workflow sha
--  #298 bump minikube to fix runner deps
--  #297 update release workflow
+- #309 Updated to Node20 and upgraded release workflows to @v1 tag
+- #306 update release workflow to use new prefix, remove deprecated release
+- #303 fix: ensure imageNames are not empty strings
+- #299 bump release workflow sha
+- #298 bump minikube to fix runner deps
+- #297 update release workflow
 
 ### Added
 
--  #304 add v prefix for version tagging
--  #302 adding ncc to build
--  #301 adding release workflow artifact fix
+- #304 add v prefix for version tagging
+- #302 adding ncc to build
+- #301 adding release workflow artifact fix
 
 ## [4.10.0] - 2023-10-30
 
 ### Added
 
--  #287 Make annotating resources optional
--  #283 Fix “Service” route-method of the Blue-Green strategy with some manifest files
--  #281 bump codeql to node 16
--  #279 upgrade codeql
--  #276 Fixes multiple namespaces bug
+- #287 Make annotating resources optional
+- #283 Fix “Service” route-method of the Blue-Green strategy with some manifest files
+- #281 bump codeql to node 16
+- #279 upgrade codeql
+- #276 Fixes multiple namespaces bug

CODE_OF_CONDUCT.md

@@ -4,6 +4,6 @@ This project has adopted the [Microsoft Open Source Code of Conduct](https://ope
 
 Resources:
 
--  [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/)
--  [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)
--  Contact [[email protected]](mailto:[email protected]) with questions or concerns
+- [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/)
+- [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)
+- Contact [[email protected]](mailto:[email protected]) with questions or concerns

README.md

@@ -17,22 +17,22 @@ permissions:
 
 Following are the key capabilities of this action:
 
--  **Artifact substitution**: Takes a list of container images which can be specified along with their tags or digests. They are substituted into the non-templatized version of manifest files before applying to the cluster to ensure that the right version of the image is pulled by the cluster nodes.
+- **Artifact substitution**: Takes a list of container images which can be specified along with their tags or digests. They are substituted into the non-templatized version of manifest files before applying to the cluster to ensure that the right version of the image is pulled by the cluster nodes.
 
--  **Object stability checks**: Rollout status is checked for the Kubernetes objects deployed. This is done to incorporate stability checks while computing the action status as success/failure.
+- **Object stability checks**: Rollout status is checked for the Kubernetes objects deployed. This is done to incorporate stability checks while computing the action status as success/failure.
 
--  **Secret handling**: The secret names specified as inputs in the action are used to augment the input manifest files with imagePullSecrets values before deploying to the cluster. Also, checkout the [Azure/k8s-create-secret](https://github.com/Azure/k8s-create-secret) action for creation of generic or docker-registry secrets in the cluster.
+- **Secret handling**: The secret names specified as inputs in the action are used to augment the input manifest files with imagePullSecrets values before deploying to the cluster. Also, checkout the [Azure/k8s-create-secret](https://github.com/Azure/k8s-create-secret) action for creation of generic or docker-registry secrets in the cluster.
 
--  **Deployment strategy** Supports both canary and blue-green deployment strategies
+- **Deployment strategy** Supports both canary and blue-green deployment strategies
 
-   -  **Canary strategy**: Workloads suffixed with '-baseline' and '-canary' are created. There are two methods of traffic splitting supported:
-      -  **Service Mesh Interface**: Service Mesh Interface abstraction allows for plug-and-play configuration with service mesh providers such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). Meanwhile, this action takes away the hard work of mapping SMI's TrafficSplit objects to the stable, baseline and canary services during the lifecycle of the deployment strategy. Service mesh based canary deployments using this action are more accurate as service mesh providers enable granular percentage traffic split (via service registry and sidecar containers injected into pods alongside application containers).
-      -  **Only Kubernetes (no service mesh)**: In the absence of service mesh, while it may not be possible to achieve exact percentage split at the request level, it is still possible to perform canary deployments by deploying -baseline and -canary workload variants next to the stable variant. The service routes requests to pods of all three workload variants as the selector-label constraints are met (KubernetesManifest will honor these when creating -baseline and -canary variants). This achieves the intended effect of routing only a portion of total requests to the canary.
-   -  **Blue-Green strategy**: Choosing blue-green strategy with this action leads to creation of workloads suffixed with '-green'. An identified service is one that is supplied as part of the input manifest(s) and targets a workload in the supplied manifest(s). There are three route-methods supported in the action:
+   - **Canary strategy**: Workloads suffixed with '-baseline' and '-canary' are created. There are two methods of traffic splitting supported:
+      - **Service Mesh Interface**: Service Mesh Interface abstraction allows for plug-and-play configuration with service mesh providers such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). Meanwhile, this action takes away the hard work of mapping SMI's TrafficSplit objects to the stable, baseline and canary services during the lifecycle of the deployment strategy. Service mesh based canary deployments using this action are more accurate as service mesh providers enable granular percentage traffic split (via service registry and sidecar containers injected into pods alongside application containers).
+      - **Only Kubernetes (no service mesh)**: In the absence of service mesh, while it may not be possible to achieve exact percentage split at the request level, it is still possible to perform canary deployments by deploying -baseline and -canary workload variants next to the stable variant. The service routes requests to pods of all three workload variants as the selector-label constraints are met (KubernetesManifest will honor these when creating -baseline and -canary variants). This achieves the intended effect of routing only a portion of total requests to the canary.
+   - **Blue-Green strategy**: Choosing blue-green strategy with this action leads to creation of workloads suffixed with '-green'. An identified service is one that is supplied as part of the input manifest(s) and targets a workload in the supplied manifest(s). There are three route-methods supported in the action:
 
-      -  **Service route-method**: Identified services are configured to target the green deployments.
-      -  **Ingress route-method**: Along with deployments, new services are created with '-green' suffix (for identified services), and the ingresses are in turn updated to target the new services.
-      -  **SMI route-method**: A new [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/master/apis/traffic-split/v1alpha3/traffic-split.md) object is created for each identified service. The TrafficSplit object is updated to target the new deployments. This works only if SMI is set up in the cluster.
+      - **Service route-method**: Identified services are configured to target the green deployments.
+      - **Ingress route-method**: Along with deployments, new services are created with '-green' suffix (for identified services), and the ingresses are in turn updated to target the new services.
+      - **SMI route-method**: A new [TrafficSplit](https://github.com/servicemeshinterface/smi-spec/blob/master/apis/traffic-split/v1alpha3/traffic-split.md) object is created for each identified service. The TrafficSplit object is updated to target the new deployments. This works only if SMI is set up in the cluster.
 
       Traffic is routed to the new workloads only after the time provided as `version-switch-buffer` input has passed. The `promote` action creates workloads and services with new configurations but without any suffix. `reject` routes traffic back to the old workloads and deletes the '-green' workloads.
 
@@ -466,9 +466,9 @@ jobs:
 
 ## Traceability Fields Support
 
--  Environment variable `HELM_CHART_PATHS` is a list of helmchart files expected by k8s-deploy - it will be populated automatically if you are using k8s-bake to generate the manifests.
--  Use script to build image and add dockerfile-path label to it. The value expected is the link to the dockerfile: https://github.com/${{github.repo}}/blob/${{github.sha}}/Dockerfile. If your dockerfile is in the same repo and branch where the workflow is run, it can be a relative path and it will be converted to a link for traceability.
--  Run docker login action for each image registry - in case image build and image deploy are two distinct jobs in the same or separate workflows.
+- Environment variable `HELM_CHART_PATHS` is a list of helmchart files expected by k8s-deploy - it will be populated automatically if you are using k8s-bake to generate the manifests.
+- Use script to build image and add dockerfile-path label to it. The value expected is the link to the dockerfile: https://github.com/${{github.repo}}/blob/${{github.sha}}/Dockerfile. If your dockerfile is in the same repo and branch where the workflow is run, it can be a relative path and it will be converted to a link for traceability.
+- Run docker login action for each image registry - in case image build and image deploy are two distinct jobs in the same or separate workflows.
 
 ## Contributing
 

SECURITY.md

@@ -14,13 +14,13 @@ You should receive a response within 24 hours. If for some reason you do not, pl
 
 Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
 
--  Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
--  Full paths of source file(s) related to the manifestation of the issue
--  The location of the affected source code (tag/branch/commit or direct URL)
--  Any special configuration required to reproduce the issue
--  Step-by-step instructions to reproduce the issue
--  Proof-of-concept or exploit code (if possible)
--  Impact of the issue, including how an attacker might exploit the issue
+- Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
+- Full paths of source file(s) related to the manifestation of the issue
+- The location of the affected source code (tag/branch/commit or direct URL)
+- Any special configuration required to reproduce the issue
+- Step-by-step instructions to reproduce the issue
+- Proof-of-concept or exploit code (if possible)
+- Impact of the issue, including how an attacker might exploit the issue
 
 This information will help us triage your report more quickly.