release: prepare v0.19.0-rc

Signed-off-by: chenk <hen.keinan@gmail.com>
aquasecurity · Mar 12, 2024 · 286390e · 286390e
1 parent 0f23556
commit 286390e
Show file tree

Hide file tree

Showing 6 changed files with 8 additions and 8 deletions.
diff --git a/RELEASING.md b/RELEASING.md
@@ -46,8 +46,8 @@
 5. Create an annotated git tag and push it to the `upstream`. This will trigger the [`.github/workflows/release.yaml`] workflow
 
    ```sh
-   git tag -vv0.19.0-rc -m 'Release vv0.19.0-rc'
-   git push upstream vv0.19.0-rc
+   git tag -v0.19.0-rc -m 'Release v0.19.0-rc'
+   git push upstream v0.19.0-rc
    ```
 
 6. Verify that the `release` workflow has built and published the following artifacts

diff --git a/docs/docs/crds/exposedsecret-report.md b/docs/docs/crds/exposedsecret-report.md
@@ -33,7 +33,7 @@ metadata:
 report:
   artifact:
     repository: myimagewithsecret
-    tag: vv0.19.0-rc
+    tag: v0.19.0-rc
   registry:
     server: index.docker.io
   scanner:

diff --git a/docs/docs/design/caching_scan_results_by_repo_digest.md b/docs/docs/design/caching_scan_results_by_repo_digest.md
@@ -129,5 +129,5 @@ We can't use something like ownerReference since it would delete all vulnerabili
   a gate.
 * Both Trivy-Operator CLI and Trivy-Operator Operator can read and leverage ClusterVulnerabilityReports.
 
-[Standalone]: https://aquasecurity.github.io/trivy-operator/vv0.19.0-rc/integrations/vulnerability-scanners/trivy/#standalone
-[ClientServer]: https://aquasecurity.github.io/trivy-operator/vv0.19.0-rc/integrations/vulnerability-scanners/trivy/#clientserver
+[Standalone]: https://aquasecurity.github.io/trivy-operator/v0.19.0-rc/integrations/vulnerability-scanners/trivy/#standalone
+[ClientServer]: https://aquasecurity.github.io/trivy-operator/v0.19.0-rc/integrations/vulnerability-scanners/trivy/#clientserver
diff --git a/docs/docs/design/design_vuln_scan_job_in_same_namespace_of_workload.md b/docs/docs/design/design_vuln_scan_job_in_same_namespace_of_workload.md
@@ -219,6 +219,6 @@ With this approach trivy operator will not have to worry about managing(create/d
     - As we will run scan job with service account of workload and if there are some very strict PSP defined in the cluster
     then scan job will be blocked due to the PSP.
 
-[ECR registry configuration]: https://aquasecurity.github.io/trivy-operator/vv0.19.0-rc/integrations/managed-registries/#amazon-elastic-container-registry-ecr
+[ECR registry configuration]: https://aquasecurity.github.io/trivy-operator/v0.19.0-rc/integrations/managed-registries/#amazon-elastic-container-registry-ecr
 [IAM role to service account]: https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html
 [Trivy fs command]: https://github.com/aquasecurity/trivy-operator/blob/main/docs/design/design_trivy_file_system_scanner.md
diff --git a/docs/docs/design/ttl_scans.md b/docs/docs/design/ttl_scans.md
@@ -44,7 +44,7 @@ metadata:
 report:
   artifact:
     repository: fluxcd/source-controller
-    tag: vv0.19.0-rc
+    tag: v0.19.0-rc
   registry:
     server: ghcr.io
   scanner:

diff --git a/docs/tutorials/private-registries.md b/docs/tutorials/private-registries.md
@@ -303,4 +303,4 @@ data:
 
 The last way that you could give the Trivy operator access to your private container registry is through managed registries. In this case, the container registry and your Kubernetes cluster would have to be on the same cloud provider; then you can define access to your container namespace as part of the IAM account. Once defined, trivy will already have the permissions for the registry.
 
-For additional information, please refer to the [documentation on managed registries.](https://aquasecurity.github.io/trivy-operator/vv0.19.0-rc/docs/vulnerability-scanning/managed-registries/)
+For additional information, please refer to the [documentation on managed registries.](https://aquasecurity.github.io/trivy-operator/v0.19.0-rc/docs/vulnerability-scanning/managed-registries/)
Original file line number	Diff line number	Diff line change
Expand Up		@@ -303,4 +303,4 @@ data:

		The last way that you could give the Trivy operator access to your private container registry is through managed registries. In this case, the container registry and your Kubernetes cluster would have to be on the same cloud provider; then you can define access to your container namespace as part of the IAM account. Once defined, trivy will already have the permissions for the registry.

		For additional information, please refer to the [documentation on managed registries.](https://aquasecurity.github.io/trivy-operator/vv0.19.0-rc/docs/vulnerability-scanning/managed-registries/)
		For additional information, please refer to the [documentation on managed registries.](https://aquasecurity.github.io/trivy-operator/v0.19.0-rc/docs/vulnerability-scanning/managed-registries/)