diff --git a/public-site/docs/docs/topic-releases/index.md b/public-site/docs/docs/topic-releases/index.md index bd4484c3..55338b33 100644 --- a/public-site/docs/docs/topic-releases/index.md +++ b/public-site/docs/docs/topic-releases/index.md @@ -6,6 +6,9 @@ title: What's new ## 2024 +### 2024-07-10 Custom batch status in Radix scheduled jobs +Radix now supports an optional custom rules defining a [batch status](/radix-config/index.md#batchstatusrules) by batch job statuses. If rules are not set or none of them matching, the base (previously defined) rules are applied. + ### 2024-06-06 Support for advanced horizontal scaling (KEDA) We have released initial support for KEDA Triggers, to enable scaling of pods based on messages in a Azure Service Bus, or based on a CRON Schedule, as well as resource metrics as before (CPU/Memory). If you are using a non-resource trigger, we also support scaling to 0 replicas! See [radixconfig.yaml](/radix-config/index.md#horizontalscaling) for more details. diff --git a/public-site/docs/start/radix-concepts/index.md b/public-site/docs/start/radix-concepts/index.md index a064223e..97c236e5 100644 --- a/public-site/docs/start/radix-concepts/index.md +++ b/public-site/docs/start/radix-concepts/index.md @@ -90,16 +90,12 @@ Jobs consist of a series of _steps_, run either in parallel or sequentially (thi ### Pipeline -A pipeline defines a type of job. There are currently three types of pipeline in Radix: +A pipeline defines a type of job. There are following types of pipeline in Radix: ### The `build-deploy` pipeline This is triggered by a commit in GitHub to a branch mapped to an environment. In turn, this causes all components to be rebuilt and a new deployment to be created in the appropriate environment. If many components are built from the same source, then one multi-component image is built for all components. If there are several multi-components in the config, the multi-component images will be indexed. -### Scanning images for security issues - -Before the deployment is done, after a build, the image is scanned for security-related issues using the tool [Snyk](https://snyk.io/). This scan will be a seperate step in the pipeline and the result will be logged in the step. Please note that the job will not fail if the result contains CRITICAL, HIGH and/or SEVERE issues. However every developer should investigate and fix any security issues. - ![Diagram of the build-deploy pipeline](./pipeline-build-deploy.jpg "The build-deploy pipeline") ### The `build` pipeline @@ -110,6 +106,24 @@ Exactly the same as the `build-deploy` pipeline, but a deployment is not created Used to duplicate an existing [deployment](index.md#deployment) from one environment into another (or to redeploy an old deployment). You can read more about it in the [promotion guide](/guides/deployment-promotion/index.md). +### The `apply-config` pipeline + +Used to apply config without re-building or re-deploying components in environments. No Radix deployment is created. Changes in the [radixconfig.yaml](/radix-config/index.md) are applied to the Radix application regarding changes in properties [environments](/radix-config/index.md#environments), [build](/radix-config/index.md#build), [dnsAlias](/radix-config/index.md#dnsalias). + +### Cleanup of pipeline Jobs + +Number of pipeline jobs may accumulate in time for a Radix application, cluttering the job list. Following rules are used to clean them up when a new pipeline job is created for a Radix application: +* Pipeline jobs preserved in the job history: + * All successful jobs for which there is a Radix deployment they created + * Up to 5 jobs per each environment and status type (Successful, Failed, etc.) +* Pipeline jobs being removed from the job history: + * There is no anymore a Radix deployment for a corresponding successful job + * A job is older than 30 days + +### Scanning images for security issues + +Before the deployment is done, after a build, the image is scanned for security-related issues using the tool [Snyk](https://snyk.io/). This scan will be a seperate step in the pipeline and the result will be logged in the step. Please note that the job will not fail if the result contains CRITICAL, HIGH and/or SEVERE issues. However every developer should investigate and fix any security issues. + ### Sub-pipeline After "Build components" step (if it does not exist - after "Prepare pipeline" step), the step "Run sub-pipeline" runs optional sub-pipeline, if it is configured. Sub-pipelines are based on the [Tekton CI/CD framework](https://tekton.dev/docs/getting-started/). Please read [Configure sub-pipeline](/guides/sub-pipeline/index.md) guide for details about sub-pipelines.