@@ -145,7 +145,7 @@ In other words, you would use the push-based deployment technique for your revie
Another possible way of implementing push-based deployment from the application pipeline is by [triggering a remote pipeline](https://docs.gitlab.com/ci/triggers/) on the deployment project.
While publishing a new versioned package, you might also want to implement a final job that triggers the GitOps deployment by Git committing/pushing the version of the newly published artifact
(:information_source: the [GitOps template](../ref/gitops/) can be used for this).
(:information_source: the [GitOps template](./ref/gitops.md) can be used for this).
The resulting CI/CD pipeline would look like this:
No, GitLab `include` feature is designed to allow [override](https://docs.gitlab.com/ci/yaml/includes/#override-included-configuration-values) of the included job configuration for flexibility.
Depending on your GitLab Edition, you may consider using GitLab [compliance frameworks](https://docs.gitlab.com/user/group/compliance_frameworks/) and/or [Scan Execution Policies](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) that allow group admin to mandate certain job executions in the pipeline, but it CAN NOT prevent developers from doing any particular thing.
Depending on your GitLab Edition, you may consider using GitLab [compliance frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/) and/or [Scan Execution Policies](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) that allow group admin to mandate certain job executions in the pipeline, but it CAN NOT prevent developers from doing any particular thing.
## Is there any vulnerability scanner to run against the GitLab/_to-be-continuous_ templates?
@@ -197,7 +197,7 @@ decoded by our templates (make sure you're using a version of the template that
If you want to pull secrets from an external secrets management system, declare a variable with `@url@` prefix, followed by the URL of the secret. Our templates will automatically fetch the URL and put the content into the variable (make sure you're using a version of the template that supports this syntax).
For [Hashicorp Vault](https://developer.hashicorp.com/vault), we provide a [vault-secrets-provider](https://gitlab.com/to-be-continuous/tools/vault-secrets-provider) image, available in most templates through a `-vault`[variant](../self-managed/advanced/#template-variants). It allows fetching secrets from a Vault server and inject them into your CI/CD variables using the `@url@http://vault-secrets-provider/api/secrets/{secret_path}?field={field}` syntax.
For [Hashicorp Vault](https://developer.hashicorp.com/vault), we provide a [vault-secrets-provider](https://gitlab.com/to-be-continuous/tools/vault-secrets-provider) image, available in most templates through a `-vault`[variant](./self-managed/advanced.md#template-variants). It allows fetching secrets from a Vault server and inject them into your CI/CD variables using the `@url@http://vault-secrets-provider/api/secrets/{secret_path}?field={field}` syntax.
Default timeout for fetching secrets is 5 seconds. If you need to increase it, you can set the global `TBC_SECRET_URL_TIMEOUT` variable to the desired number of seconds.