Info about apply-config pipeline type and pipeline job cleanup (#372)

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.

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.