Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

info-about-pipeline-job-cleanup-rules #372

Merged
merged 1 commit into from
Aug 2, 2024
Merged

info-about-pipeline-job-cleanup-rules #372

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions public-site/docs/docs/topic-releases/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
24 changes: 19 additions & 5 deletions public-site/docs/start/radix-concepts/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.
Expand Down