From f39f923799ba67bc3b2adaecc30e09e16831509a Mon Sep 17 00:00:00 2001 From: Hii-Arpit Date: Tue, 8 Apr 2025 20:52:56 +0530 Subject: [PATCH 1/7] docs: jobs revamp --- docs/user-guide/jobs/README.md | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/docs/user-guide/jobs/README.md b/docs/user-guide/jobs/README.md index 7f8ba1f33..42fa9f362 100644 --- a/docs/user-guide/jobs/README.md +++ b/docs/user-guide/jobs/README.md @@ -1,18 +1,27 @@ # Jobs -Job allows manual and automated execution of your source code. Job pipeline will not have CI/CD pipeline as the job is limited to your source code only. You can also configure [preset plugins](../creating-application/workflow/ci-build-pre-post-plugins.md#preset-plugins) in your job pipeline. +Devtron Jobs provide a streamlined way to execute specific tasks or set of tasks within your application environment direlty on the source code. Devtron Jobs leverage Kubernetes Jobs to run isolated, task-specific operations within your Kubernetes cluster. -With job, you can execute your source code quickly and easily without going through CI/CD pipelines, which also optimize time. +Unlike Devtron CI/CD pipelines that primarily focus on building, testing, and deploying applications, Devtron Jobs are designed to handle independent, ephemeral tasks and allows you to execute tasks without impacting Ci/CD workflows or pipelines, making them ideal for specific tasks. -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/jobs.jpg) +Each Devtron Job corresponds to a Kubernetes Job that creates one or more Pods to carry out a specified task. Once the task is completed, the Pods are terminated, making Devtron Jobs an ideal solution for one-time, recurring, or event-driven workloads. -There are two main steps in executing Job: +Jobs can be configured to run as: -* [Configurations](configuration-job.md) +* **One-time tasks**: Useful for maintenance operations, data migrations, backups, or environment cleanups. -* [Trigger Job](triggering-job.md) +* **Recurring tasks**: Scheduled operations like daily scans, periodic backups, or routine security checks. -In the next section, we will learn on how to create, configure, trigger a job. You can also view the details on the [Overview](overview-job.md) tab and `Run History`. +* **Event-driven tasks**: Triggered by specific events such as commits, pull requests, or tag creation. + ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/jobs.jpg) +Additionally, Devtron provides integrated [plugins]() that can be utilized within Jobs to enhance automation and streamline operations. You can explore the full list of plugins and their configurations in the [Devtron Plugin Documentation]() +To learn more about how to work with Jobs in Devtron, explore the following sections: + +* [Creating a Job]() +* [configurations]() +* [Trigger Job ]() +* [Run History]() +* [Job Overview]() \ No newline at end of file From 66ca04235ce6d49f2e1bc2e8fed94180dca91362 Mon Sep 17 00:00:00 2001 From: Hii-Arpit Date: Wed, 9 Apr 2025 11:51:11 +0530 Subject: [PATCH 2/7] docs: restructure the doc --- docs/user-guide/jobs/README.md | 29 ++++++--------------- docs/user-guide/jobs/getting-started-job.md | 21 +++++++++++++++ 2 files changed, 29 insertions(+), 21 deletions(-) create mode 100644 docs/user-guide/jobs/getting-started-job.md diff --git a/docs/user-guide/jobs/README.md b/docs/user-guide/jobs/README.md index 42fa9f362..0b932f707 100644 --- a/docs/user-guide/jobs/README.md +++ b/docs/user-guide/jobs/README.md @@ -1,27 +1,14 @@ # Jobs -Devtron Jobs provide a streamlined way to execute specific tasks or set of tasks within your application environment direlty on the source code. Devtron Jobs leverage Kubernetes Jobs to run isolated, task-specific operations within your Kubernetes cluster. +Devtron Jobs provide a streamlined way to execute specific tasks or sets of tasks directly on your source code within your application environment. While they operate independently of standard CI/CD pipelines, Devtron Jobs follow a pipeline-based approach to run isolated, task-specific operations. -Unlike Devtron CI/CD pipelines that primarily focus on building, testing, and deploying applications, Devtron Jobs are designed to handle independent, ephemeral tasks and allows you to execute tasks without impacting Ci/CD workflows or pipelines, making them ideal for specific tasks. +To learn more about how Jobs work, see the full documentation below -Each Devtron Job corresponds to a Kubernetes Job that creates one or more Pods to carry out a specified task. Once the task is completed, the Pods are terminated, making Devtron Jobs an ideal solution for one-time, recurring, or event-driven workloads. +## Documentation -Jobs can be configured to run as: - -* **One-time tasks**: Useful for maintenance operations, data migrations, backups, or environment cleanups. - -* **Recurring tasks**: Scheduled operations like daily scans, periodic backups, or routine security checks. - -* **Event-driven tasks**: Triggered by specific events such as commits, pull requests, or tag creation. - - ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/jobs.jpg) - -Additionally, Devtron provides integrated [plugins]() that can be utilized within Jobs to enhance automation and streamline operations. You can explore the full list of plugins and their configurations in the [Devtron Plugin Documentation]() - -To learn more about how to work with Jobs in Devtron, explore the following sections: - -* [Creating a Job]() -* [configurations]() -* [Trigger Job ]() +* [Getting Started with Jobs](./getting-started-job.md) +* [Creating a Job](./create-job.md) +* [Configurations](./configuration-job.md) +* [Trigger Job ](./triggering-job.md) * [Run History]() -* [Job Overview]() \ No newline at end of file +* [Job Overview](./overview-job.md) \ No newline at end of file diff --git a/docs/user-guide/jobs/getting-started-job.md b/docs/user-guide/jobs/getting-started-job.md new file mode 100644 index 000000000..f90452c34 --- /dev/null +++ b/docs/user-guide/jobs/getting-started-job.md @@ -0,0 +1,21 @@ +# Getting Started With Jobs + +Devtron Jobs provide a streamlined way to execute specific tasks or set of tasks within your application environment direlty on the source code. Devtron Jobs leverage Kubernetes Jobs to run isolated, task-specific operations within your Kubernetes cluster. + +Unlike Devtron CI/CD pipelines that primarily focus on building, testing, and deploying applications, Devtron Jobs are designed to handle independent, ephemeral tasks and allows you to execute tasks without impacting Ci/CD workflows or pipelines, making them ideal for specific tasks. + +Each Devtron Job corresponds to a [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) that creates one or more Pods to carry out a specified task. Once the task is completed, the Pods are terminated, making Devtron Jobs an ideal solution for one-time, recurring, or event-driven workloads. + +Jobs can be configured to run as: + +* **One-time tasks**: Useful for maintenance operations, data migrations, backups, or environment cleanups. + +* **Recurring tasks**: Scheduled operations like daily scans, periodic backups, or routine security checks. + +* **Event-driven tasks**: Triggered by specific events such as commits, pull requests, or tag creation. + + ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/jobs.jpg) + +Additionally, Devtron provides integrated [plugins]() that can be utilized within Jobs to enhance automation and streamline operations. You can explore the full list of plugins and their configurations in the [Devtron Plugin Documentation]() + +To learn how to create a new Job in Devtron, continue with the next section. \ No newline at end of file From 302807a4689f3f560409430e46725c9c09079317 Mon Sep 17 00:00:00 2001 From: Hii-Arpit Date: Wed, 9 Apr 2025 14:52:15 +0530 Subject: [PATCH 3/7] docs: create job doc --- docs/user-guide/jobs/create-job.md | 63 ++++++++++++++++++------------ 1 file changed, 38 insertions(+), 25 deletions(-) diff --git a/docs/user-guide/jobs/create-job.md b/docs/user-guide/jobs/create-job.md index a33f33a1b..bec42bad3 100644 --- a/docs/user-guide/jobs/create-job.md +++ b/docs/user-guide/jobs/create-job.md @@ -1,42 +1,55 @@ -# Create a New Job +# Create Job -* On the Devtron dashboard, select **Jobs**. -* On the upper-right corner of the screen, click **Create**. -* Select **Job** from the drop-down list. -* **Create job** page opens. +Devtron provides two ways to create a Job: +* **Blank Job**: Create a new job by manually defining all configurations. +* **Clone Job**: Create a new job by reusing the configuration of an existing job. -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/select-create-job-latest.jpg) +## Create a Blank Job +To create a new **Blank Job** in Devtron, follow these steps: +1. From the **Devtron Dashboard** → **Jobs**. -## Create Job +2. Click the **Create** button in the top-right corner and select **Job** from the drop-down list. -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/create-job-page.jpg) +![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/select-create-job-latest.jpg) +3. The **Create Job** page opens. From the left panel, select **Blank job**, then enter the required details as listed in the table below. -Provide below information on the `Create job` page: + -| Fields | Description | -| --- | --- | -| **Job Name** | User-defined name for the job in Devtron. | -| **Description** | Enter the description of a job. | -| **Registry URL** | This is the URL of your private registry in Quay. E.g. `quay.io` | -| **Select one of them** |
  • **Create from scratch** :Select the project from the drop-down list.
    `Note`: You have to add [project under Global Configurations](../global-configurations/projects.md). Only then, it will appear in the drop-down list here.
  • **Clone existing application**: Select an app you want to clone from and the project from the drop-down list.
    `Note`: You have to add [project under Global Configurations](../global-configurations/projects.md). Only then, it will appear in the drop-down list here.
| +| Fields| Description| +|:---|:---| +| **Project** | User-defined name for the job in Devtron.| +| **Job Name** | User-defined name for the job in Devtron.| +| **Description** | Enter the description of a job.| +|**Tags**|Key-value pairs used for identifying and organizing the application.
Users can propagate tags as Kubernetes labels to enable filtering, bulk operations, and integrations with Kubernetes tools.
  1. Click the **Add tags to job** dropdown on the **Create job** page.
  2. Under the **Tags** section, Click `+` to add a new tag.
  3. You can click `X` icon to delete an existing tag.
  4. You can click the `propagation icon` to propagate a tag (turns dark grey when propagated), click again to remove propagation.
    [[Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/overview/manage-tags-latest-1.jpg)]
| -**Note**: Do not forget to modify git repositories and corresponding branches to be used for each Job Pipeline if required. +![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/create-job-page.jpg) +4. Click **Create Job**. The job will be created, and you will be automatically redirected to the [Configurations page](./configuration.md)to continue setting up the job pipeline. + -### Tags + -`Tags` are key-value pairs. You can add one or multiple tags in your application. +## Create a Clone Job -**Propagate Tags** -When tags are propagated, they are considered as labels to Kubernetes resources. Kubernetes offers integrated support for using these labels to query objects and perform bulk operations e.g., consolidated billing using labels. You can use these tags to filter/identify resources via CLI or in other Kubernetes tools. +To create a new **Clone Job** in Devtron, follow these steps: +1. From the **Devtron Dashboard** → **Jobs**. + +2. Click the **Create** button in the top-right corner and select **Job** from the drop-down list. + +![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/select-create-job-latest.jpg) -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/propagate-tags.jpg) +3. The **Create Job** page opens. From the left panel, select **Clone Job**, then enter the required details as listed in the table below. -* Click `+ Add tag` to add a new tag. -* Click the symbol on the left side of your tag to propagate a tag.
`Note`: Dark grey colour in symbol specifies that the tags are propagated. -* To remove the tags from propagation, click the symbol again. -* Click `Save`. + +| Fields| Description| +|:---|:---| +| **Project** | User-defined name for the job in Devtron.| +| **Job Name** | User-defined name for the job in Devtron.| +| **Description** | Enter the description of a job.| +|**Tags**|Key-value pairs used for identifying and organizing the application.
Users can propagate tags as Kubernetes labels to enable filtering, bulk operations, and integrations with Kubernetes tools.
  1. Click the **Add tags to job** dropdown on the **Create job** page.
  2. Under the **Tags** section, Click `+` to add a new tag.
  3. You can click `X` icon to delete an existing tag.
  4. You can click the `propagation icon` to propagate a tag (turns dark grey when propagated), click again to remove propagation.
    [[Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/overview/manage-tags-latest-1.jpg)]
| +| **Select an job to clone** | Select the existing job from the dropdown that you want to clone.Enter the description of a job.| +4. Click **Create Job**. The **Clone job** will be created, and you will be automatically redirected to the [Configurations page](./configuration.md), where the configuration will be pre-populated based on the selected source job. You may review and modify these settings as required. \ No newline at end of file From 82f8cbaa09224f6adc19cfa87babb8ebb7004558 Mon Sep 17 00:00:00 2001 From: Hii-Arpit Date: Wed, 9 Apr 2025 14:54:04 +0530 Subject: [PATCH 4/7] docs: add create job doc --- docs/user-guide/jobs/create-job.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/docs/user-guide/jobs/create-job.md b/docs/user-guide/jobs/create-job.md index bec42bad3..0c3fa7d5e 100644 --- a/docs/user-guide/jobs/create-job.md +++ b/docs/user-guide/jobs/create-job.md @@ -15,8 +15,6 @@ To create a new **Blank Job** in Devtron, follow these steps: 3. The **Create Job** page opens. From the left panel, select **Blank job**, then enter the required details as listed in the table below. - - | Fields| Description| |:---|:---| | **Project** | User-defined name for the job in Devtron.| @@ -27,9 +25,6 @@ To create a new **Blank Job** in Devtron, follow these steps: ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/create-job-page.jpg) 4. Click **Create Job**. The job will be created, and you will be automatically redirected to the [Configurations page](./configuration.md)to continue setting up the job pipeline. - - - ## Create a Clone Job @@ -42,8 +37,6 @@ To create a new **Clone Job** in Devtron, follow these steps: 3. The **Create Job** page opens. From the left panel, select **Clone Job**, then enter the required details as listed in the table below. - - | Fields| Description| |:---|:---| | **Project** | User-defined name for the job in Devtron.| From 466b929132783af8c892c5a4b384a0f455503d05 Mon Sep 17 00:00:00 2001 From: Hii-Arpit Date: Thu, 10 Apr 2025 16:21:00 +0530 Subject: [PATCH 5/7] docs: Source Code section added --- docs/user-guide/jobs/configuration-job.md | 79 ++++++++++++++++++++++- 1 file changed, 76 insertions(+), 3 deletions(-) diff --git a/docs/user-guide/jobs/configuration-job.md b/docs/user-guide/jobs/configuration-job.md index afd0d7daf..99b883d76 100644 --- a/docs/user-guide/jobs/configuration-job.md +++ b/docs/user-guide/jobs/configuration-job.md @@ -1,9 +1,82 @@ # Configuration -For the Jobs, you must configure the following sections before you run and trigger the job: +After creating a Job, the next step is to configure it. This involves specifying the source code and using the Workflow Editor to define the sequence of tasks, such as code scanning, vulnerability checks, or data migrations, and setting up the conditions for when these tasks should run. -[Source Code](../creating-application/git-material.md) +The following sections will guide you through configuring the source code, setting up the Workflow Editor, and defining ConfigMaps, Secrets, and Environment Overrides for the job. -[Workflow Editor](workflow-editor-job.md) +## Source Code +In Devtron, the Source Code configuration is used to specify the repository that contains your scripts, terraform files, YAML configurations, or other resources. The repository acts as a central location for these files, allowing you to reference and execute them in your job without needing to rewrite the scripts in the Workflow Editor each time. +To configure the Source Code, follow these steps: + +1. If the job has been just created, you will be automatically directed to the Configurations page. If not, navigate to the **Devtron Dashboard** → **Jobs** → **Select the job** → **Configurations**. + +2. Select the **Source Code** tab from the left sidebar. + +3. Under Add Git Repository, select the Git Account from the dropdown menu.
You can also select GitHub Public from the same dropdown to configure a public repository that does not require authentication. + +4. Enter the Repository URL in the Git Repo URL field, corresponding to the selected Git account.
+If GitHub Public is selected, you can enter the URL of any public repository, as no authentication is required. + +5. Configure the [Additional Options](#configure-additional-options-optional) for the job as per your requirements. + +6. Click on the **Save** button to save the changes. + +### Configure Additional Options (optional) + +#### Exclude specific file/folder in this repo + +Devtron allows you to exclude specific files or folders from the repository from being included in the job execution. This is particularly useful for avoiding unnecessary files or folders that do not contribute to the job’s tasks that are not relevant to the current job execution. + +You can define either exclusion rules or inclusion rules to filter the files and folders ensuring that only the necessary parts of the repository are used in the job. + +Commits that contain only changes to excluded files or folders will be marked as excluded when selecting commits to trigger the job, preventing them from being included in the build. + +To define the exclusion or inclusion rules, follow these steps: + +1. Check the **Exclude specific file/folder in this repo** checkbox. + +2. Enter the exclusion or inclusion rules in the **Enter file or folder paths to be included or excluded** field. + +| Sample Rules | Description | Impact on Commits | +|:---|:---|:---| +| `!README.md` | **Exclusion of a single file in root folder:** | Commits containing changes made only in README.md file will not be shown | +| `!README.md`
`!index.js` | **Exclusion of multiple files in root folder:** | Commits containing changes made only in README.md or/and index.js files will not be shown | +| `README.md` | **Inclusion of a single file in root folder:** | Commits containing changes made only in README.md file will be shown. Rest all will be excluded. | +| `!src/extensions/printer/code2.py` | **Exclusion of a single file in a folder tree:** |Commits containing changes made specifically to code2.py file will not be shown | +| `!src/*` | **Exclusion of a single folder and all its files:** |Commits containing changes made specifically to files within src folder will not be shown | +| `!README.md`
`index.js` | **Exclusion and inclusion of files:** | Commits containing changes made only in README.md will not be shown, but commits made in index.js file will be shown. All other commits apart from the aforementioned files will be excluded. | +| `!README.md`
`README.md` | **Exclusion and inclusion of conflicting files** | If conflicting paths are defined in the rule, the one defined later will be considered. In this case, commits containing changes made only in README.md will be shown. | + + +You may use the **Learn how** link (as shown below) to understand the syntax of defining an exclusion or inclusion rule. + +![Figure 6: 'Learn how' Button](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/git-material/rules.jpg) + +Since file paths can be long, Devtron supports regex too for writing the paths. To understand it better, you may click the **How to use** link as shown below. + +![Figure 7: Regex Support](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/git-material/regex-help.jpg) + + +#### Set checkout path + +Devtron allows you to define a custom directory path where the repository will be checked out during job execution. By default, the repository is checked out to the root directory (./). However, you can set a custom path to specify a particular folder within the repository to be accessed and utilized during job execution. + +To set the checkout path, follow these steps: + +1. Check the **Set checkout path** checkbox. + +2. Enter the path to the folder you want to check out from the repository in the **Set checkout path** field. + +|Sample paths|Description| +|:---|:---| +|`./`|Checkout the repository to the root directory i.e., the entire repository itself| +|`./src`|Checkout the repository to the src folder| +|`./src/app`|Checkout the repository to the app folder inside the src folder| + +#### Pull submodules recursively + +This checkbox is used for pulling [git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) present in a repo. The submodules will be pulled recursively, and the auth method used for the parent repo will be used for submodules too. + +To pull the submodules recursively, check the **Pull submodules recursively** checkbox. \ No newline at end of file From cd657e5579f5dbbb4882df2405a7a3ec9a05ed19 Mon Sep 17 00:00:00 2001 From: Hii-Arpit Date: Thu, 24 Apr 2025 15:23:30 +0530 Subject: [PATCH 6/7] New Structure --- .../workflow/ci-pipeline-new.md | 110 ++++++++++ docs/user-guide/jobs/README.md | 28 ++- docs/user-guide/jobs/configurations/README.md | 9 + .../configurations/configmap-secret/README.md | 10 + .../configmap-secret/configmap-job | 149 +++++++++++++ .../configmap-secret/secret-job | 204 ++++++++++++++++++ .../configurations/environment-override-job | 105 +++++++++ .../source-code-job} | 14 ++ .../workflow-editor-job.md | 12 ++ docs/user-guide/jobs/create-job.md | 40 ++-- docs/user-guide/jobs/overview-job.md | 96 ++++++--- docs/user-guide/jobs/run-history-job.md | 61 ++++++ docs/user-guide/jobs/triggering-job.md | 35 ++- ...{getting-started-job.md => what-is-job.md} | 10 +- 14 files changed, 810 insertions(+), 73 deletions(-) create mode 100644 docs/user-guide/creating-application/workflow/ci-pipeline-new.md create mode 100644 docs/user-guide/jobs/configurations/README.md create mode 100644 docs/user-guide/jobs/configurations/configmap-secret/README.md create mode 100644 docs/user-guide/jobs/configurations/configmap-secret/configmap-job create mode 100644 docs/user-guide/jobs/configurations/configmap-secret/secret-job create mode 100644 docs/user-guide/jobs/configurations/environment-override-job rename docs/user-guide/jobs/{configuration-job.md => configurations/source-code-job} (98%) rename docs/user-guide/jobs/{ => configurations}/workflow-editor-job.md (89%) create mode 100644 docs/user-guide/jobs/run-history-job.md rename docs/user-guide/jobs/{getting-started-job.md => what-is-job.md} (52%) diff --git a/docs/user-guide/creating-application/workflow/ci-pipeline-new.md b/docs/user-guide/creating-application/workflow/ci-pipeline-new.md new file mode 100644 index 000000000..a167b1aa7 --- /dev/null +++ b/docs/user-guide/creating-application/workflow/ci-pipeline-new.md @@ -0,0 +1,110 @@ +# CI Pipeline + +{% hint style="info" %} +For Devtron version older than v0.4.0, please refer the [CI Pipeline (legacy)](https://docs.devtron.ai/v/v0.4/devtron/user-guide/creating-application/workflow/ci-pipeline-legacy) page. +{% endhint %} + +## Introduction + +In Devtron, the Build and Deploy from Source Code method allows users to build container images directly from a Git repository and deploy them in a Kubernetes environment. + +## When to Use This Method? + +* When you need to build a container image from your application's source code. +* When you want automated builds triggered by code changes. +* When you require pre-build and post-build customization steps. + +{% hint style="info" %} +hint about docker image +{% endhint %} + +## Step-by-Step Guide to Creating a CI Pipeline + +1. Navigate to Workflow Editor +2. From the Applications menu, select your application. +3. Go to the App Configuration page and select Workflow Editor. +4. Click + New Workflow. +5. Select Build and Deploy from Source Code. + +### Configure Build Pipeline +1. In the Create Build Pipeline window, enter the following details: + +| Field Name | Required/Optional | Description | +| :--- | :--- | :--- | +| Pipeline Name | Required | A unique name for the build pipeline. | +| Source type | Required | Source type to trigger the CI. Available options: [Branch Fixed](#source-type-branch-fixed) \| [Branch Regex](#source-type-branch-regex) \|[Pull Request](#source-type-pull-request) \| [Tag Creation](#source-type-tag-creation) | +| Branch Name | Required | Branch that triggers the CI build | +| Advanced Options | Optional | Create Pre-Build, Build, and Post-Build tasks | + +#### Understanding Source Types + +Devtron provides multiple ways to trigger a build pipeline: + +| Source Type | Description | Additional Requirements | +| :--- | :--- | :--- | +| Branch Fixed | Triggers a CI build whenever changes are pushed to a specified branch. | Requires a predefined branch name.| +| Branch Regex | Allows dynamic branch selection based on a regex pattern, useful for branches following a common naming convention (e.g., feature-*). | Requires a regex pattern to be defined.| +| Pull Request (PR) | Triggers a CI build when a new pull request is created.| Requires webhook configuration for GitHub or Bitbucket.| +| Tag Creation | Triggers a build whenever a new tag is created. | Requires webhook configuration for GitHub or Bitbucket.| + +2. Click Create Pipeline to save the configuration and proceed. You can now use the default settings, or continue below to explore additional configuration options for customizing your pipeline. + +### Configuring Advanced Options + +Devtron provides three stages in a CI pipeline: Pre-Build, Build, and Post-Build. + +1. Pre-Build Stage: This stage is used for preparing the environment before the actual build begins. Tasks such as dependency installation, secret management, and validation can be configured here. + +2. Build Stage: The core stage where the application source code is compiled, a container image is built, and the necessary artifacts are generated. + +3. Post-Build Stage: This stage runs after the build is complete, where additional tasks such as security scans, notifications, or artifact uploads can be executed. + +This guide focuses on configuring the Build Stage. If you want to set up Pre-Build and Post-Build stages, refer to the separate documentation + +* Pre-Build Stage Configuration +* Post-Build Stage Configuration + +#### Scan for Vulnerabilities + +Devtron supports security scanning after the build stage. + +##### Prerequisite + +Ensure you have installed one of the following integrations: +* Clair +* Trivy + +##### How to Enable Security Scan? + +* In the Build Stage tab, enable Scan for vulnerabilities. +* This will scan the built container image for known vulnerabilities. + +#### Custom Image Tag Pattern + +You can define custom image tags for better version tracking. + +* Enable the Custom Image Tag Pattern toggle. +* Define an alphanumeric pattern (e.g., test-v1.0.{x} where x auto-increments with each build). +* Click Update Pipeline. + +{% hint style="info" %} +Ensure custom tags do not start or end with a period (.) or comma (,). +{% endhint %} + +#### Triggering a Build + +Once the CI pipeline is set up, follow these steps to trigger a build: + +* Navigate to Build & Deploy. + +* Click Select Material. + +* Choose the Git commit to build. + +* Click Start Build. + +Once successful, the image tag will be available in: + +* Build History +* Docker Registry  +* CD Pipeline (Image Selection) \ No newline at end of file diff --git a/docs/user-guide/jobs/README.md b/docs/user-guide/jobs/README.md index 0b932f707..d3430111d 100644 --- a/docs/user-guide/jobs/README.md +++ b/docs/user-guide/jobs/README.md @@ -1,14 +1,30 @@ # Jobs -Devtron Jobs provide a streamlined way to execute specific tasks or sets of tasks directly on your source code within your application environment. While they operate independently of standard CI/CD pipelines, Devtron Jobs follow a pipeline-based approach to run isolated, task-specific operations. +Devtron Jobs provide a streamlined way to execute specific tasks or set of tasks defined by the user within the user's application environment. -To learn more about how Jobs work, see the full documentation below +To learn more about how Jobs work, see the below sections -## Documentation -* [Getting Started with Jobs](./getting-started-job.md) +* [What is Jobs](./what-is-job.md) + * [Creating a Job](./create-job.md) + * [Configurations](./configuration-job.md) + + * [Source Code](./configuration/source-code.md) + + * [Workflow editor](./configuration/workflow-editor.md) + + * [ConfigMaps & Secrets](./configuration/config-maps-and-secrets/README.md) + + * [ConfigMaps](./configuration/config-maps-and-secrets/configmaps.md) + + * [Secrets](./configuration/config-maps-and-secrets/secrets.md) + + * [Environments Override](./configuration/environment-overrides.md) + * [Trigger Job ](./triggering-job.md) -* [Run History]() -* [Job Overview](./overview-job.md) \ No newline at end of file + +* [Run History](./run-history.md) + +* [Job Overview](./overview-job.md) \ No newline at end of file diff --git a/docs/user-guide/jobs/configurations/README.md b/docs/user-guide/jobs/configurations/README.md new file mode 100644 index 000000000..3221de2e1 --- /dev/null +++ b/docs/user-guide/jobs/configurations/README.md @@ -0,0 +1,9 @@ +# Configuration + +After you have created a Job, the next step is, to configure the job. This means specifying the source code and using the Workflow Editor to create and configure the job pipeline, which include defining tasks such as code scanning, vulnerability checks, or data migrations, and configuring the sequence in which these tasks should be executed. + +In the following sections we will explore how you can configure your Job which includes, + +1. Configuring the [Source Code](/jobs/configuration/source-code.md) +2. Creating and configuring the job pipeline through [Workflow Editor](/jobs/configuration/workflow-editor.md). +3. Defining [ConfigMaps](/jobs/configuration/config-maps-and-secrets/configmaps.md) & [Secrets](/jobs/configuration/config-maps-and-secrets/secrets.md), and [Environment Overrides](/jobs/configuration/environment-overrides.md) for the job. \ No newline at end of file diff --git a/docs/user-guide/jobs/configurations/configmap-secret/README.md b/docs/user-guide/jobs/configurations/configmap-secret/README.md new file mode 100644 index 000000000..a2b404fb8 --- /dev/null +++ b/docs/user-guide/jobs/configurations/configmap-secret/README.md @@ -0,0 +1,10 @@ +# ConfigMaps & Secrets +## ConfigMaps +A ConfigMap stores key-value pairs that your jobs can use as environment variables or mounted files. ConfigMaps are meant for non-sensitive data. Moreover, you can update configurations without modifying or rebuilding your container images, thus making the deployments more efficient. + +To configure a ConfigMap for your job-pipeline, refer the [ConfigMaps](./configmap-job) section. + +## Secrets +Secrets and ConfigMaps are both used to store configurations but there is one major difference between them: ConfigMap stores key-values in normal text format; whereas secrets store them in base64 encrypted form. Devtron hides the data of secrets for the normal users and it is only visible to the users having edit permission. + +To configure a Secret for your job-pipeline, refer the [Secrets](./secret-job) section. \ No newline at end of file diff --git a/docs/user-guide/jobs/configurations/configmap-secret/configmap-job b/docs/user-guide/jobs/configurations/configmap-secret/configmap-job new file mode 100644 index 000000000..4b1520a55 --- /dev/null +++ b/docs/user-guide/jobs/configurations/configmap-secret/configmap-job @@ -0,0 +1,149 @@ +# ConfigMaps + +A ConfigMap stores key-value pairs that your jobs can use as environment variables or mounted files. Unlike secrets, ConfigMaps are meant for non-sensitive data. Moreover, you can update configurations without modifying or rebuilding your container images, thus making the deployments more efficient. + +## Add ConfigMap + +1. Go to the **Configurations** → **ConfigMaps & Secrets**. + + + +2. Click the **+** button next to **ConfigMaps**. + + + +3. Enter a name for the ConfigMap (Once defined, name cannot be changed later). + + In case, you are using a External Kubernetes ConfigMap, name should be exactly same as the as the name given using `kubectl create configmap ` command. + +4. **Data Type** - Choose between the following data types: + * [Kubernetes ConfigMap](#kubernetes-configmap): Select the Data Type as Kubernetes ConfigMap, if you wish to create and use the ConfigMap using Devtron. + + * [Kubernetes External ConfigMap](#kubernetes-external-configmap): Select the Data Type as Kubernetes External ConfigMap if you have already created a ConfigMap using the kubectl command and wants to use that in Devtron. + +5. After selecting the data type, you can choose how to mount the data of your ConfigMap. Devtron allows you to mount ConfigMap Data in following ways

**Mount data as** - Select how you want to mount the ConfigMap: + * [**Environment Variable**](#mount-data-as-environment-variables) – Select this option if you want to inject Environment Variables in pods using ConfigMap. + * [**Data Volume**](#mount-data-as-data-volume) – Select this option, if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-valume) to know more. + +### Mount data as environment variables + +This will pass your ConfigMap data into your Job pod as environment variables, thus making the configurations values directly acessible by your job. + +#### For Kubernetes ConfigMap + + If you have selected Data type as `Kubernetes ConfigMap` then, you also need to enter the required data (key-value pairs) in the **Data** field

Enter data in: + + * **GUI mode** – User-friendly interface. Click **+Add** button and enter the **Key** and **Value** fields without quotes. + + + + * **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes. + + + {% embed url="https://www.youtube.com/watch?v=QfJqX6KM2lU" %} + +#### For Kubernetes External ConfigMap + +If you have selected Data type as `Kubernetes External ConfigMap` then, no data is required as devtron will fetch the external ConfigMap data and use it to create a ConfigMap. + +### Mount data as Data Volume + +This option allows you to create a ConfigMap by passing the content of a file. The content could be a plain text, json, yaml, bash script, etc. + + ![Figure 4: Selecting Data Volume Option](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/config-maps/cm-data-volume.jpg) + +### Volume Mount Path + +Enter the folder path where the data volume should be mounted for it to be accessible to the containers running in a pod. Your keys will be mounted as files to that volume. + +### Set Sub Path + +When mounting multiple files to the same location, you can use the **Set Sub Path** option to control how the files are handled. This setting allows you to control whether existing files are overwritten or preserved when mounting new files. + +* If **Set Sub Path** is enabled, the system will preserve existing files in the [specified path](#volume-mount-path) and append the new file using the file name as a sub-path. + +* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files. + +{% hint style="info" %} +### Note +In case of Kubernetes ConfigMap, all keys will be mounted as files on the specified path. +In case of Kubernetes External ConfigMap, manually specify the keys which should be mounted as files. +{% endhint %} + +### Set File Permission + +The **Set File Permission** option applies permissions at the ConfigMap level, not to individual keys within the ConfigMap. Enabling this option will let you enter a 3-digit standard permission value to control access to the file. + +The 3-digit numeric value represents the permission settings for the file: + +* **First digit**: Owner permissions (user). +* **Second digit**: Group permissions. +* **Third digit**: Other users' permissions. + +| **Permission** | **Description** | +|----------------|------------------------------------------------| +| **r** (read) | Grants the ability to read the file. | +| **w** (write) | Grants the ability to modify the file. | +| **x** (execute)| Grants the ability to execute the file as a program. | + +For example, **755** means: +* Owner can read, write, and execute (7), +* Group can read and execute (5), +* Others can read and execute (5). + +### Data + +#### For Kubernetes ConfigMap + + The key of the ConfigMap should be your filename and the value of the ConfigMap should be your file content. In the below example, you `file.json` is the key, and the json content is the value of that ConfigMap (below the pipe (**|**) symbol). This file will be created on your specified [volume mount path](#volume-mount-path). + +![Figure 5: Adding File Content](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/config-maps/filecontent-cm.jpg) + +#### For Kubernetes External ConfigMap + + If you have selected Data type as `Kubernetes External ConfigMap` then, no data is required as devtron will fetch the external ConfigMap along with any volumes attach with it and use it to create a ConfigMap. + +7. You may [perform a dry run](#perform-a-dry-run) before clicking **Save**. + +8. Select **Save** to create a ConfigMap. +--- + +## Perform a Dry Run + +Before saving your configured ConfigMap, you can use the **Dry Run** option (as shown below) to preview the final Kubernetes manifest. + +This feature helps you verify your configurations, detect issues, and ensure correctness. + +![Figure 6: Performing a Dry Run](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/config-maps/dry-run-cm.gif) + +Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifest. + +--- + +## Update ConfigMap + +1. Click your ConfigMap available inside the list of **ConfigMaps** inside **Base Configurations**. +2. Modify its values. +3. Click **Update**. + +{% hint style="warning" %} +### Note +You cannot change the name of a ConfigMap. Create a new ConfigMap instead. +{% endhint %} + +![Figure 7: Updating Existing ConfigMap](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/config-maps/update_configmap.jpg) + +--- + +## Delete ConfigMap + +You may delete a ConfigMap if not in use anymore. Once a ConfigMap is deleted, it will not be used in future deployments. + +1. Click your ConfigMap available inside the list of **ConfigMaps** inside **Base Configurations**. +2. On the right side, click the kebab menu (3 vertical dots). +3. Click **Delete**. +4. Confirm the deletion in the dialogbox. + +![Figure 8: Deleting ConfigMap](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/config-maps/delete_configmap.jpg) + +--- \ No newline at end of file diff --git a/docs/user-guide/jobs/configurations/configmap-secret/secret-job b/docs/user-guide/jobs/configurations/configmap-secret/secret-job new file mode 100644 index 000000000..ec79c7c31 --- /dev/null +++ b/docs/user-guide/jobs/configurations/configmap-secret/secret-job @@ -0,0 +1,204 @@ +# Secrets + +Secrets and ConfigMaps are both used to store configurations but there is one major difference between them: ConfigMap stores key-values in normal text format; whereas secrets store them in base64 encrypted form. Devtron hides the data of secrets for the normal users and it is only visible to the users having edit permission. + +Secret objects let you store and manage sensitive information, such as passwords, authentication tokens, and ssh keys. Embedding this information in secrets is safer and more flexible than putting it verbatim in a Pod definition or in a container image. + +## Add Secret + +1. Go to the **Configurations** → **Base Configurations**. + + + +2. Click the **+** button next to **Secrets**. + + + +3. Enter a name for the Secret (Once defined, name cannot be changed later). + + In case, you are mounting Existing Kubernetes Secret, name should be exactly same as the as the name given using `kubectl create secret ` command. + + + +4. **Data Type** - Choose between the following data types: + * [Kubernetes Secret](#kubernetes-secret): Select the Data Type as Kubernetes Secret, if you wish to create and use the Secret using Devtron. + + * [Mount Existing Kubernetes Secret](#mount-existing-kubernetes-secrets): Select the Data Type as Existing Kubernetes Secret if you have already created a Secret using the kubectl command and wants to use that in Devtron. + + * [External Secret Operator (ESO)](#external-secret-operator-eso): External Secrets Operator (ESO) is a Kubernetes component that integrates with external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, and more. It retrieves secrets from these external sources and injects them into Kubernetes Secrets automatically. + + >Refer the [External Secret Operator (ESO)](#external-secret-operator-eso) section to setup ESO + + +
**Note**: Devtron automatically converts secrets from various data types to Kubernetes Secrets. Regardless of the original data type, once the conversion is complete, the Pods can access the secrets in the same way as native Kubernetes Secrets. + +5. After selecting the data type, you can choose how to mount the data of your Secret. Devtron allows you to mount Secret data in following ways

**Mount data as** - Select how you want to mount the Secret: + + * [**Environment Variable**](#mount-data-as-environment-variables) – Select this option if you want to inject Secret data(key-value pairs) as Environment Variables in pods using Secret. + + * [**Data Volume**](#mount-data-as-data-volume) – Select this option, if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-valume) to know more. + +### Mount data as environment variables + +This will pass your secret data into your Job pod as environment variables, thus making the configurations values directly accessible by your job. + +#### For Kubernetes Secret + + If you have selected Data type as `Kubernetes Secret` then, you also need to enter the required data (key-value pairs) in the **Data** field

Enter data in: + + * **GUI mode** – User-friendly interface. Click **+Add** button and enter the **Key** and **Value** fields without quotes. + + + + * **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes. + + + {% embed url="https://www.youtube.com/watch?v=x6IIr6pDZig" %} + + + +### Mount Existing Kubernetes Secrets + +This option allows you to mount an existing Kubernetes Secret in your job pods. A Secret will not be created by system so please ensure that the secret with the same name already exists within the namespace. Otherwise, the deployment will fail. + +If you have selected Data type as `Mount Existing Kubernetes Secrets` then, no data is required as devtron will fetch the existing Secret data and use it to create a Secret. + +--- + +### Mount Data as Data Volume + + +This option allows you to create a Secret by passing the content of a file. The content could be a plain text, json, yaml, bash script, etc. + + + +### Volume Mount Path + +Enter the folder path where the data volume should be mounted for it to be accessible to the containers running in a pod. Your keys will be mounted as files to that volume. + + + +### Set Sub Path + +When mounting multiple files to the same location, you can use the **Set Sub Path** option to control how the files are handled. This setting allows you to control whether existing files are overwritten or preserved when mounting new files. + +* If **Set Sub Path** is enabled, the system will preserve existing files in the [specified path](#volume-mount-path) and append the new file using the file name as a sub-path. + +* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files. + +{% hint style="info" %} +### Note +In case of Kubernetes Secrets, all keys will be mounted as files on the specified path. +In case of External Secrets, manually specify the keys which should be mounted as files. +{% endhint %} + +### Set File Permission + +The **Set File Permission** option applies permissions at the Secret level, not to its individual secret keys. Enabling this option will let you enter a 3-digit standard permission value to control access to the file. + +The 3-digit numeric value represents the permission settings for the file: + +* **First digit**: Owner permissions (user). +* **Second digit**: Group permissions. +* **Third digit**: Other users' permissions. + +| **Permission** | **Description** | +|----------------|------------------------------------------------| +| **r** (read) | Grants the ability to read the file. | +| **w** (write) | Grants the ability to modify the file. | +| **x** (execute)| Grants the ability to execute the file as a program. | + +For example, **755** means: +* Owner can read, write, and execute (7), +* Group can read and execute (5), +* Others can read and execute (5). + +### Data +#### For Kubernetes Secret + +The key of the Secret should be your filename and the value of the Secret should be your file content. In the below example, you `file.json` is the key, and the json content is the value of that Secret (below the pipe (**|**) symbol). This file will be created on your specified [volume mount path](#volume-mount-path). + +![Figure 5: Adding File Content](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/secrets/filecontent-secret.jpg) + +#### For Mount Existing Kubernetes Secrets + +This option allows you to mount an existing Kubernetes Secret in your job pods as data volumes. A Secret will not be created by system so please ensure that the secret with the same name already exists within the namespace. Otherwise, the deployment will fail.

If you have selected Data type as `Mount Existing Kubernetes Secrets` then, no data is required as devtron will fetch the existing Secret data and use it to create a Secret. + +--- +## Perform a Dry Run + +Before saving your configured Secret, you can use the **Dry Run** option (as shown below) to preview the final Kubernetes manifest. + +This feature helps you verify your configurations, detect issues, and ensure correctness. + +![Figure 7: Performing a Dry Run](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/secrets/dry-run-secret.gif) + +Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifest. + +--- + +## Update Secret + +1. Click your Secret available inside the list of **Secrets** inside **Base Configurations**. +2. Modify its values. +3. Click **Update**. + +{% hint style="warning" %} +### Note +You cannot change the name of a Secret. Create a new Secret instead. +{% endhint %} + +![Figure 8: Updating Existing Secret](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/secrets/update-secret.jpg) + +--- + +## Delete Secret + +You may delete a Secret if not in use anymore. Once a Secret is deleted, it will not be used in future deployments. + +1. Click your Secret available inside the list of **Secrets** inside **Base Configurations**. +2. On the right side, click the kebab menu (3 vertical dots). +3. Click **Delete**. +4. Confirm the deletion in the dialogbox. + +![Figure 9: Deleting Secret](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/secrets/delete-secret.jpg) + +--- + +## External Secret Operator (ESO) + +{% hint style="info" %} +### Prerequisite +Chart version should be > 4.14.0 +{% endhint %} + +### Purpose + +This section is for users who wish to use the following data type while adding secrets in Devtron: +* [Google Secrets Manager](./eso/gcp-eso.md) +* [AWS Secrets Manager](./eso/aws-eso.md) +* [Hashi Corp Vault](./eso/hashicorp-eso.md) +* [Azure Secrets Manager](./eso/azure-eso.md) + +External Secrets Operator (ESO) is a Kubernetes component that integrates with external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, and more. It retrieves secrets from these external sources and injects them into Kubernetes Secrets automatically. Before you can create external secrets in Devtron, you need to install the External Secrets Operator on the target cluster. + +### Installation Steps + +1. Go to the **Chart Store**. + +2. Search for the `external-secrets` chart. + + ![Figure 10: Searching External Secrets Chart](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/secrets/external-secret.jpg) + +{% hint style="info" %} +### What if external-secrets chart is not found? +Manually add the following chart repository URL in Devtron: `https://charts.external-secrets.io`. Follow this [guide](../../global-configurations/chart-repo.md#add-chart-repository) to know the steps. +{% endhint %} + +3. Give a name to the helm app that will be created from the chart. Also enter the project and environment where you wish to install the chart. + + ![Figure 11: Adding Details](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/secrets/ext-secret-fields.jpg) + +4. Click **Deploy Chart**. + +After Deploying the Chart, refer the [ESO Documentation]() to setup ESO for different providers. diff --git a/docs/user-guide/jobs/configurations/environment-override-job b/docs/user-guide/jobs/configurations/environment-override-job new file mode 100644 index 000000000..c43682c5d --- /dev/null +++ b/docs/user-guide/jobs/configurations/environment-override-job @@ -0,0 +1,105 @@ +# Environment Overrides + +You can view all environments associated with a job under the **Environment Overrides** section. + + + +The Environment Overrides section allows you to customize the **ConfigMaps**, and **Secrets** for different environments such as development, testing, staging, and production. + +## How it works + +* When you add a job pipeline to an job's workflow, each environment configuration initially inherits the ConfigMap and Secret from the **Base Configurations** of the job. + +* The **Environment Overrides** section lets you customize those ConfigMap and Secret per environment without affecting those of other environments. For example, in a non-production environment, you might allocate `100m` CPU, while in production, you may increase it to `500m` to handle higher traffic. + +--- + +## Environment Configurations Page + +{% hint style="warning" %} +### Who Can Perform This Action? +Users need to have [Admin role](../global-configurations/authorization/user-access.md#role-based-access-levels) or above (along with access to the environment and applications) to perform environment override. +{% endhint %} + +1. In your job, go to **Configurations** → **Environment Overrides**. + + + +2. Select an environment whose configurations you wish to modify. + + + +3. You will get the following options (similar to the **ConfigMaps & Secrets** page): + * [ConfigMaps](#override-configmap--secret) + * [Secrets](#override-configmap--secret) + +Let's visit each of the configuration files and see how to override their values for the selected environment. + +## Override ConfigMaps & Secrets + +If you want to configure your ConfigMaps and Secrets at the application-level then you can provide them in [ConfigMaps](../configuration/config-maps-and-secrets/configmaps.md) and [Secrets](../configuration/config-maps-and-secrets/secrets.md), but if you want to have environment-specific ConfigMaps & Secrets, use **Environment Override** to create new environment specific ConfigMaps & Secrets or override existing ConfigMaps & Secrets for specific environments. At the time of execution, devtron will pick environment specific ConfigMaps & Secrets according to the environment in which the job is executed and pass them to your job pods. + +1. Select the ConfigMap or Secret you wish to override, by default the ConfigMap or Secret is inherited from the base configuration. + + + +2. To create Override, select the **No Override** tab and click the **Create Override** button. + + + +4. In the same tab (now labelled as **Override**), you can choose any one mode for changing the configuration values: + * **YAML** - This mode has a YAML based editor intended for advanced users. + * **GUI** - This mode has a user-friendly interface intended for beginner to advanced users. + +{% hint style="info" %} +### Note +Users who are not super-admins will land on GUI mode when they override; whereas super-admins will land on YAML mode. This is just the default behavior, users can still toggle the mode if needed. +{% endhint %} + + + +5. You can override the values using [Replace](#using-replace-strategy) merge strategy: + +### Replace Strategy + +* The entire configuration is replaced with your new environment-specific settings. +* The replaced template will no longer depend or inherit from base configuration anymore. +* Best for a complete override. + +| Field | Inherited Configuration | Input (with Replace) | Final Configuration | +|-----------|--------------------|------------------------------|---------------------| +| cpu | 100m | 500m | 500m | +| memory | 256Mi | 512Mi | 512Mi | +| replicas | 2 | *(Not specified)* | *(Removed)* | +| logLevel | "info" | *(Not specified)* | *(Removed)* | +| timeout | (Not specified) | 30s | 30s (Added) | + +Refer the tutorials below to know the process in YAML mode. In case you wish to use GUI mode, skip to [Overriding in GUI mode](#using-gui-mode-for-overriding). + +{% embed url="https://www.youtube.com/watch?v=lSoj8wwOej0" %} + +--- + +## Using GUI Mode for Overriding + +The above sections, i.e., [Override ConfigMap & Secret](#override-configmap--secret) explained the process of environment override using YAML. + +Refer the below tutorial videos to know the process of overriding them using GUI. + +### Override ConfigMaps and Secrets using GUI + +{% embed url="https://www.youtube.com/watch?v=UOTKLVuSkDg" %} + +--- + +## Delete Override + +This action will discard the current overrides and the base configuration file (in this example, deployment template) will be restored back for the environment. + +1. On the right side, click the kebab menu (3 vertical dots). +2. Click **Delete Override**. +3. Confirm the deletion in the dialogbox. + + +--- \ No newline at end of file diff --git a/docs/user-guide/jobs/configuration-job.md b/docs/user-guide/jobs/configurations/source-code-job similarity index 98% rename from docs/user-guide/jobs/configuration-job.md rename to docs/user-guide/jobs/configurations/source-code-job index 99b883d76..0d095ae93 100644 --- a/docs/user-guide/jobs/configuration-job.md +++ b/docs/user-guide/jobs/configurations/source-code-job @@ -12,13 +12,21 @@ To configure the Source Code, follow these steps: 1. If the job has been just created, you will be automatically directed to the Configurations page. If not, navigate to the **Devtron Dashboard** → **Jobs** → **Select the job** → **Configurations**. + + 2. Select the **Source Code** tab from the left sidebar. + + 3. Under Add Git Repository, select the Git Account from the dropdown menu.
You can also select GitHub Public from the same dropdown to configure a public repository that does not require authentication. + + 4. Enter the Repository URL in the Git Repo URL field, corresponding to the selected Git account.
If GitHub Public is selected, you can enter the URL of any public repository, as no authentication is required. + + 5. Configure the [Additional Options](#configure-additional-options-optional) for the job as per your requirements. 6. Click on the **Save** button to save the changes. @@ -37,6 +45,8 @@ To define the exclusion or inclusion rules, follow these steps: 1. Check the **Exclude specific file/folder in this repo** checkbox. + + 2. Enter the exclusion or inclusion rules in the **Enter file or folder paths to be included or excluded** field. | Sample Rules | Description | Impact on Commits | @@ -52,6 +62,8 @@ To define the exclusion or inclusion rules, follow these steps: You may use the **Learn how** link (as shown below) to understand the syntax of defining an exclusion or inclusion rule. + + ![Figure 6: 'Learn how' Button](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/git-material/rules.jpg) Since file paths can be long, Devtron supports regex too for writing the paths. To understand it better, you may click the **How to use** link as shown below. @@ -75,6 +87,8 @@ To set the checkout path, follow these steps: |`./src`|Checkout the repository to the src folder| |`./src/app`|Checkout the repository to the app folder inside the src folder| + + #### Pull submodules recursively This checkbox is used for pulling [git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) present in a repo. The submodules will be pulled recursively, and the auth method used for the parent repo will be used for submodules too. diff --git a/docs/user-guide/jobs/workflow-editor-job.md b/docs/user-guide/jobs/configurations/workflow-editor-job.md similarity index 89% rename from docs/user-guide/jobs/workflow-editor-job.md rename to docs/user-guide/jobs/configurations/workflow-editor-job.md index c29cb9e62..829ae6a4e 100644 --- a/docs/user-guide/jobs/workflow-editor-job.md +++ b/docs/user-guide/jobs/configurations/workflow-editor-job.md @@ -99,3 +99,15 @@ In the **Edit job pipeline** window, edit the required fields and select **Updat You can only delete a job pipeline in your workflow. To delete a job pipeline, go to **Configurations > Workflow Editor** and select **Delete Pipeline**. + +--- + +## Next Steps + +* After creating and configuring the job pipeline, the next optional step is to configure ConfigMaps and Secrets for your job. Refer the [ConfigMaps & Secrets](./configmap-secret/README.md) to configure them. + +* Devtron also allows you to configure environment-specific ConfigMaps and Secrets. Refer the [Environment Override](./environment-override-job) section to configure them. + +* After creating and configuring the ConfigMaps & Secrets, the next step is to trigger your job pipeline. To trigger your configured job-pipeline refer [Triggering a job pipeline](../triggering-job.md) + +--- \ No newline at end of file diff --git a/docs/user-guide/jobs/create-job.md b/docs/user-guide/jobs/create-job.md index 0c3fa7d5e..f5771469e 100644 --- a/docs/user-guide/jobs/create-job.md +++ b/docs/user-guide/jobs/create-job.md @@ -1,15 +1,17 @@ # Create Job -Devtron provides two ways to create a Job: -* **Blank Job**: Create a new job by manually defining all configurations. -* **Clone Job**: Create a new job by reusing the configuration of an existing job. +In devtron, jobs can be created by two ways: + +* **Blank Job**: This allows you to create a new job from scratch by manually defining all configurations. + +* **Clone Job**: This allows you to create a new job by reusing the configuration of an existing job. ## Create a Blank Job To create a new **Blank Job** in Devtron, follow these steps: -1. From the **Devtron Dashboard** → **Jobs**. -2. Click the **Create** button in the top-right corner and select **Job** from the drop-down list. +1. Navigate to **Devtron Dashboard** → **Jobs**. +2. Click **Create** button in the top-right corner and select **Job** from the drop-down list. ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/select-create-job-latest.jpg) @@ -17,20 +19,20 @@ To create a new **Blank Job** in Devtron, follow these steps: | Fields| Description| |:---|:---| -| **Project** | User-defined name for the job in Devtron.| -| **Job Name** | User-defined name for the job in Devtron.| -| **Description** | Enter the description of a job.| -|**Tags**|Key-value pairs used for identifying and organizing the application.
Users can propagate tags as Kubernetes labels to enable filtering, bulk operations, and integrations with Kubernetes tools.
  1. Click the **Add tags to job** dropdown on the **Create job** page.
  2. Under the **Tags** section, Click `+` to add a new tag.
  3. You can click `X` icon to delete an existing tag.
  4. You can click the `propagation icon` to propagate a tag (turns dark grey when propagated), click again to remove propagation.
    [[Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/overview/manage-tags-latest-1.jpg)]
| +| **Project**| User-defined name for the job in Devtron.| +| **Job Name**| User-defined name for the job in Devtron.| +| **Description** | Enter the description of a job.| +| **Tags**|

Key-value pairs used for identifying and organizing the application.
Users can propagate tags as Kubernetes labels to enable filtering, bulk operations, and integrations with Kubernetes tools.

  1. Click the Add tags to job dropdown on the Create job page.
  2. Under the Tags section, Click + to add a new tag.
  3. You can click X icon to delete an existing tag.
  4. You can click the propagation icon to propagate a tag (turns dark grey when propagated), click again to remove propagation.
    [Snapshot]
| ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/create-job-page.jpg) -4. Click **Create Job**. The job will be created, and you will be automatically redirected to the [Configurations page](./configuration.md)to continue setting up the job pipeline. +4. Click **Create Job**. The job will be created, and you will be automatically redirected to the [Configurations page](configuration/)to continue setting up the job pipeline. ## Create a Clone Job To create a new **Clone Job** in Devtron, follow these steps: -1. From the **Devtron Dashboard** → **Jobs**. +1. From the **Devtron Dashboard** → **Jobs**. 2. Click the **Create** button in the top-right corner and select **Job** from the drop-down list. ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/select-create-job-latest.jpg) @@ -38,11 +40,15 @@ To create a new **Clone Job** in Devtron, follow these steps: 3. The **Create Job** page opens. From the left panel, select **Clone Job**, then enter the required details as listed in the table below. | Fields| Description| -|:---|:---| -| **Project** | User-defined name for the job in Devtron.| -| **Job Name** | User-defined name for the job in Devtron.| -| **Description** | Enter the description of a job.| -|**Tags**|Key-value pairs used for identifying and organizing the application.
Users can propagate tags as Kubernetes labels to enable filtering, bulk operations, and integrations with Kubernetes tools.
  1. Click the **Add tags to job** dropdown on the **Create job** page.
  2. Under the **Tags** section, Click `+` to add a new tag.
  3. You can click `X` icon to delete an existing tag.
  4. You can click the `propagation icon` to propagate a tag (turns dark grey when propagated), click again to remove propagation.
    [[Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/overview/manage-tags-latest-1.jpg)]
| +|:---|:--- | +| **Project**| User-defined name for the job in Devtron.| +| **Job Name**| User-defined name for the job in Devtron.| +| **Description**| Enter the description of a job.| +| **Tags**|

Key-value pairs used for identifying and organizing the application.
Users can propagate tags as Kubernetes labels to enable filtering, bulk operations, and integrations with Kubernetes tools.

  1. Click the Add tags to job dropdown on the Create job page.
  2. Under the Tags section, Click + to add a new tag.
  3. You can click X icon to delete an existing tag.
  4. You can click the propagation icon to propagate a tag (turns dark grey when propagated), click again to remove propagation.
    [Snapshot]
| | **Select an job to clone** | Select the existing job from the dropdown that you want to clone.Enter the description of a job.| -4. Click **Create Job**. The **Clone job** will be created, and you will be automatically redirected to the [Configurations page](./configuration.md), where the configuration will be pre-populated based on the selected source job. You may review and modify these settings as required. \ No newline at end of file + + +4. Click **Create Job**. The **Clone job** will be created, and you will be automatically redirected to the [Configurations page](configuration/), where the configuration will be pre-populated based on the selected source job. You may review and modify these settings as required. + +After creating a job, the next step is to configure the job, refer the [Configurations](./configuration/README.md) section to configure the job. \ No newline at end of file diff --git a/docs/user-guide/jobs/overview-job.md b/docs/user-guide/jobs/overview-job.md index cbd25200a..6f544716d 100644 --- a/docs/user-guide/jobs/overview-job.md +++ b/docs/user-guide/jobs/overview-job.md @@ -1,49 +1,93 @@ # Overview -The `Overview` section contains the brief information of the job, any added tags, and deployment details of the particular job. -In this section, you can also [change project of your job](#change-project-of-your-job) and [manage tags](#manage-tags) if you added them while creating job. +The Overview page provides a centralized view of a job’s details within Devtron. It allows users to quickly access information about the job, manage tags, view job pipelines — all in a single, organized interface. ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/overview-job.jpg) +The `Overview` page contains three main sections: +* [`About`](#about): Contains job's metadata such as name, description, project, project, creator, and it also includes options to manage tags. -The following details are provided on the **Overview** page: +* [`Job Pipelines`](#job-pipelines): Displays all job pipelines along with their last status and quick access to associated workflows. -| Fields | Description | -| :--- | :--- | -| **Job Name** | Displays the name of the job. | -| **Created on** | Displays the day, date and time the job was created. | -| **Created by** | Displays the email address of a user who created the job. | -| **Project** | Displays the current project of the job. You can change the project by selecting a different project from the drop-down list. | +--- +## About -## Change Project of your Job +The `About` section allows you to: -You can change the project of your job by clicking **Project** on the `Overview` section. +* View key job details +* Change the project your application is assigned to +* Manage tags that you may have added during the job’s creation -1. Click `Project`. -2. On the `Change project` dialog box, select the different project you want to change from the drop-down list. +The left side of the `About` section displays essential information about the job. -Click **Save**. The job will be moved to the selected project. + -## Manage Tags +The table below captures all the key elements presented in this section, along with their descriptions and whether they can be edited by the user. -`Tags` are key-value pairs. You can add one or multiple tags in your application. When tags are propagated, they are considered as labels to Kubernetes resources. Kubernetes offers integrated support for using these labels to query objects and perform bulk operations e.g., consolidated billing using labels. You can use these tags to filter/identify resources via CLI or in other Kubernetes tools. +| Field Name | User Editable |Description| +| :--------- | :--------------- |:--------- | +| `Job Name` | No |Displays the name of the application (e.g., backend-healthcare-app).| +| `Short Description`|Yes|A short, optional description to summarize the application's purpose.| +| `Project` |Yes|Indicates the current project under which the application is organized.
You can change the project directly from this section.
  1. Click the `Edit` icon next to the current project.
  2. In the `Change Project` window, select the new project from the dropdown.
  3. Click `Save`.
Changing the project will revoke access for existing users and grant access only to those who have permissions in the newly selected project.| +| `Created on` |No|Shows the exact date and time when the application was created.| +| `Created by`|No|Displays the email address of the user who created the application.| -`Manage tags` is the central place where you can create, edit, and delete tags. You can also propagate tags as labels to Kubernetes resources for the application. +| `Tags` |Yes|Key-value pairs used for identifying and organizing the application.
Users can propagate tags as Kubernetes labels to enable filtering, bulk operations, and integrations with Kubernetes tools.
  1. Click the `Edit` icon next to `Tags`.
  2. On the `Manage Tags` page, Click `+ Add tag` to add a new tag.
  3. You can click `X` icon to delete an existing tag.
  4. You can click the `propagation icon` to propagate a tag (turns dark grey when propagated), click again to remove propagation.
    [[Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/overview/manage-tags-latest-1.jpg)]
  5. Click `Save`, Configured Tags will reflect immediately under `Tags` in `About` Section
| -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/manage-tags-latest.jpg) +### Readme +The right side of the `About` section contains a `README` area where you can maintain job-specific notes or documentation. The `Readme` supports Markdown formatting, making it easy to include formatted text, instructions, or important context related to the application. -* Click `Edit tags`. -* On the `Manage tags` page, click `+ Add tag` to add a new tag. -* Click `X` to delete a tag. -* Click the symbol on the left side of your tag to propagate a tag.
`Note`: Dark grey colour in symbol specifies that the tags are propagated. -* To remove the tags from propagation, click the symbol again. -* Click `Save`. + -The changes in the tags will be reflected in the `Tags` on the `Overview` section. +To add or update the `Readme`: +1. Click the **Edit** button in the Readme section. +2. A Markdown editor will appear where you can write or modify content under the `Write` tab. +3. Use standard Markdown syntax to format text, create lists, insert links, and more. +4. Preview the content using the `Preview` tab. +5. Click **Save** to update the README. + +{% hint style="info" %} + After saving, the system displays the email address of the user who last updated the README, along with the date and time. This information appears in the header of the Readme section, beside the title. +{% endhint %} +### Catalog [![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/elements/EnterpriseTag.svg)](https://devtron.ai/pricing) +The **Catalog** in the **About** section displays information about your job—such as Container port, Environment Variables, Arguments, Resources(CPU and RAM) This data is managed using [Devtron’s Catalog Framework](../global-configurations/catalog-framework.md). - +![Figure 2d: Catalog](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/overview/catalog.jpg) + +`Super-Admins` define a custom JSON schema that determines what fields are shown in the catalog form. This schema is specific to each resource type, such as Devtron applications. + +When you click the **Edit** icon, a form appears based on the defined schema. As an job owner, you can fill out fields like: +* Container port (e.g., API contract, service documentation) +* Environment Variables +* Arguments +* Resources(CPU and RAM) + + + +{% hint style= "info" %} +The structure and labels in the catalog form are entirely configurable by your platform team via JSON schema in **Catalog Framework**. Field names and sections may vary depending on how the schema was defined by your organization. +{% endhint %} + +Once saved, this information is displayed in a readable format within the Catalog subsection and is accessible to all users who have permission to view the job. + + + +--- + +## Job Pipelines + +The Job Pipelines section provides a detailed view of all job pipelines. For each job pipeline, it displays + +| Field Name |Description| +| :--------- |:--------- | +| Pipeline name |Name of the job pipeline.| +| Last Run Status|Displays the status of the most recent job execution| +| Run in environment | Displays the name of the environment in which job is executed. | +| Last Run AT| Displays how long ago the job was last triggered.| + + diff --git a/docs/user-guide/jobs/run-history-job.md b/docs/user-guide/jobs/run-history-job.md new file mode 100644 index 000000000..1a7c80353 --- /dev/null +++ b/docs/user-guide/jobs/run-history-job.md @@ -0,0 +1,61 @@ +# Run History + +The run history allows you to review each and every execution of job-pipelines. Here you can review who triggered each pipeline, when it started executing and finished, and whether it succeeded or failed. It also allows you to inspect logs for each execution. + +## Accessing run history for specific pipeline + +Either you have just executed the job and want to inspect live execution or you just want to check previous executions of a job pipeline + +1. Navigate to **Devtron Dashboard** → **Jobs** → **Select the job** → **Run History**, all the executions will appear in a reverse chronological order under the pipeline name. In case you have configured multiple job pipelines within a job, you need to select the pipeline from `Select Pipeline` dropdown in the top-left corner. + + + +2. Select the specific execution you want to inspect. By default the latest execution is selected. + + + +3. After selecting the execution, the right section of the page will display the details about that particular execution. + +|Field|Description| +|:---|:---| +|Triggered|Shows the date, time, user, and commit ID that initiated this run.| +|Environment|Indicates which execution environment (e.g., devtron-ci) was used for this job.| +|Execution started|Timestamp marking when the job actually began running.| +|Execution succeeded|Timestamp marking when the job finished successfully.| +|Worker status|Final outcome of the worker performing the job (e.g., Succeeded or Failed). On failure, the error message is also shown| + + + +Apart from these details, you can also inspect logs, source code, security, and download artifacts (if any). + +### Logs +* In logs tab, you can inspect logs for each pipeline stage and task along with thier runtime. +* Use the `Search log` search bar to search specific keywords or errors. +* You can expand/collapse each pipeline stage to view specific logs related to that stage. Use the `Expand/collapse all stages` button near the search bar to expand or collapse all stages at once. +* Select the fullscreen button in the bottom-right corner to view logs in fullscreen. + + + +### Source +The source tab shows which commit is from the source code (configured Git repository) is used to execute the job pipeline. + +It shows following commit details +|Field|Description| +|:---|:---| +|Repository name & icon |The Git repo used with its provider logo| +|Commit hash|A short, clickable commit ID (e.g. 443vecd) that opens the full commit details when clicked.| +|Commit message|Commit message used while psuhing that commit| +|Author|Name & email of the committer.| +|Date & time|When that commit was authored| + + + +### Artifacts +The Artifacts tab shows all archives or files your job has produced such as backup binaries, reports, log bundles and let you download them for inspection or further use your job has produced. + + +### Security + +The Security tab provides a view of vulnerability scanning results for code, the container images used or built during the job execution. It appears when a security scan plugin (e.g., Trivy via the Code Scan plugin) is integrated into your job pipeline. + + \ No newline at end of file diff --git a/docs/user-guide/jobs/triggering-job.md b/docs/user-guide/jobs/triggering-job.md index bd2071278..45d19cc58 100644 --- a/docs/user-guide/jobs/triggering-job.md +++ b/docs/user-guide/jobs/triggering-job.md @@ -1,34 +1,31 @@ -# Triggering Job +# Triggering Job Pipeline -## Triggering Job Pipeline +After creating the job pipeline, the next step is to trigger the job pipeline. This is the step where the job will executed in the selected environment. -The Job Pipeline can be triggered by selecting `Select Material` +To trigger the job-pipeline: -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/trigger-job.jpg) - -Job Pipelines that are set as automatic are always triggered as soon as a new commit is made to the git branch they're sensing. However, Job pipelines can always be manually triggered as and if required. +1. Navigate to the **Devtron Dashboard** → **Jobs** → **Select the job** → **Trigger Job**, which list all configured pipelines. -Various commits done in the repository can be seen here along with details like Author, Date etc. Select the commit that you want to trigger and then click on `Run Job` to trigger the job pipeline. - -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/run-job.jpg) +2. Select `Select Material` for the job-pipeline you wish to execute, a modal window will open, under `Code-source` tab, this window lists all recent commits along with their hash, author, date, and message. from your configured source repository. +![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/trigger-job.jpg) -**Refresh** icon, refreshes Git Commits in the job Pipeline and fetches the latest commits from the `Git Repository`. - -**Ignore Cache** : This option will ignore the previous build cache and create a fresh build. If selected, will take a longer build time than usual. [Click here](../creating-application/workflow/ci-pipeline.md#docker-layer-caching) to read more about controlling cache behavior in Devtron. +3. Select the commit you want to use in the job execution. You can use the search bar to filter the commits hash, and you can also click the kebab menu to reveal excluded commits. If a recent commit isn’t displayed, click the Refresh icon to reload the commit list from your Git repository. -It can be seen that the job pipeline is triggered here and is the _Running_ state. +![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/run-job.jpg) -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/click-job-details.jpg) +4. Select the `Parameters` tab to configure pipeline runtime inputs(if any). The Key and Type columns are read‑only; enter values for each required parameter (denoted by *). Optional parameters can be configured as needed or left blank. -Click your `job pipeline` or click `Run History` to get the details about the job pipeline such as logs, reports etc. + -![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/run-history-job.jpg) +5. After selecting the commit and configuring runtime inputs, pick the target environment from the `Execute job in` dropdown at the bottom. -Click `Source code` to view the details such as commit id, Author and commit message of the Git Material that you have selected for the job. + -Click `Artifacts` to download the _reports_ of the job, if any. +6. Select `Run Job` to execute your pipeline. -If you have multiple job pipelines, you can select a pipeline from the drop-down list to view th details of logs, source code, or artifacts. + +After executing your pipeline, the pipeline will now be in running state and you can monitor the pipeline execution(such as logs, source,artifacts)in [run-history](./run-history.md) either by navigating to `Run History` tab or by clicking `details` above the `Select Material` of the specific pipeline. +![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/click-job-details.jpg) \ No newline at end of file diff --git a/docs/user-guide/jobs/getting-started-job.md b/docs/user-guide/jobs/what-is-job.md similarity index 52% rename from docs/user-guide/jobs/getting-started-job.md rename to docs/user-guide/jobs/what-is-job.md index f90452c34..c83f2c1f9 100644 --- a/docs/user-guide/jobs/getting-started-job.md +++ b/docs/user-guide/jobs/what-is-job.md @@ -1,10 +1,10 @@ -# Getting Started With Jobs +# What is Jobs? -Devtron Jobs provide a streamlined way to execute specific tasks or set of tasks within your application environment direlty on the source code. Devtron Jobs leverage Kubernetes Jobs to run isolated, task-specific operations within your Kubernetes cluster. +Devtron Jobs provide a streamlined way to execute specific tasks or set of tasks defined by the user within the user's application environment. Unlike Devtron CI/CD pipelines that primarily focus on building, testing, and deploying applications, Devtron Jobs are designed to handle independent, ephemeral tasks and allows you to execute tasks without impacting Ci/CD workflows or pipelines, making them ideal for specific tasks. -Each Devtron Job corresponds to a [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) that creates one or more Pods to carry out a specified task. Once the task is completed, the Pods are terminated, making Devtron Jobs an ideal solution for one-time, recurring, or event-driven workloads. +Each Devtron Job corresponds to a [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) that creates one or more Pods to carry out the specific task. Once the task is completed, the Pods are terminated, making Devtron Jobs an ideal solution for one-time, recurring, or event-driven workloads. Jobs can be configured to run as: @@ -16,6 +16,6 @@ Jobs can be configured to run as: ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/create-job/jobs.jpg) -Additionally, Devtron provides integrated [plugins]() that can be utilized within Jobs to enhance automation and streamline operations. You can explore the full list of plugins and their configurations in the [Devtron Plugin Documentation]() +Devtron Jobs support executing custom tasks or predefined operations using integrated pipeline plugins. These plugins extend job functionality by enabling tasks such as code scanning, image signing, vulnerability patching, container image copying, and external automation through tools like Ansible and Bitbucket Runners. To explore the full list of supported plugins and their configuration options, refer to the [Devtron Plugin Documentation](). -To learn how to create a new Job in Devtron, continue with the next section. \ No newline at end of file +To learn how to create a new Job in Devtron, continue to the [Create a new job](./create-a-new-job.md) section. \ No newline at end of file From ec5e23434306dfc742ab5ffbde35c805679cd837 Mon Sep 17 00:00:00 2001 From: Hii-Arpit Date: Thu, 24 Apr 2025 15:27:58 +0530 Subject: [PATCH 7/7] docs:removing CI Pipeline doc --- .../workflow/ci-pipeline-new.md | 110 ------------------ 1 file changed, 110 deletions(-) delete mode 100644 docs/user-guide/creating-application/workflow/ci-pipeline-new.md diff --git a/docs/user-guide/creating-application/workflow/ci-pipeline-new.md b/docs/user-guide/creating-application/workflow/ci-pipeline-new.md deleted file mode 100644 index a167b1aa7..000000000 --- a/docs/user-guide/creating-application/workflow/ci-pipeline-new.md +++ /dev/null @@ -1,110 +0,0 @@ -# CI Pipeline - -{% hint style="info" %} -For Devtron version older than v0.4.0, please refer the [CI Pipeline (legacy)](https://docs.devtron.ai/v/v0.4/devtron/user-guide/creating-application/workflow/ci-pipeline-legacy) page. -{% endhint %} - -## Introduction - -In Devtron, the Build and Deploy from Source Code method allows users to build container images directly from a Git repository and deploy them in a Kubernetes environment. - -## When to Use This Method? - -* When you need to build a container image from your application's source code. -* When you want automated builds triggered by code changes. -* When you require pre-build and post-build customization steps. - -{% hint style="info" %} -hint about docker image -{% endhint %} - -## Step-by-Step Guide to Creating a CI Pipeline - -1. Navigate to Workflow Editor -2. From the Applications menu, select your application. -3. Go to the App Configuration page and select Workflow Editor. -4. Click + New Workflow. -5. Select Build and Deploy from Source Code. - -### Configure Build Pipeline -1. In the Create Build Pipeline window, enter the following details: - -| Field Name | Required/Optional | Description | -| :--- | :--- | :--- | -| Pipeline Name | Required | A unique name for the build pipeline. | -| Source type | Required | Source type to trigger the CI. Available options: [Branch Fixed](#source-type-branch-fixed) \| [Branch Regex](#source-type-branch-regex) \|[Pull Request](#source-type-pull-request) \| [Tag Creation](#source-type-tag-creation) | -| Branch Name | Required | Branch that triggers the CI build | -| Advanced Options | Optional | Create Pre-Build, Build, and Post-Build tasks | - -#### Understanding Source Types - -Devtron provides multiple ways to trigger a build pipeline: - -| Source Type | Description | Additional Requirements | -| :--- | :--- | :--- | -| Branch Fixed | Triggers a CI build whenever changes are pushed to a specified branch. | Requires a predefined branch name.| -| Branch Regex | Allows dynamic branch selection based on a regex pattern, useful for branches following a common naming convention (e.g., feature-*). | Requires a regex pattern to be defined.| -| Pull Request (PR) | Triggers a CI build when a new pull request is created.| Requires webhook configuration for GitHub or Bitbucket.| -| Tag Creation | Triggers a build whenever a new tag is created. | Requires webhook configuration for GitHub or Bitbucket.| - -2. Click Create Pipeline to save the configuration and proceed. You can now use the default settings, or continue below to explore additional configuration options for customizing your pipeline. - -### Configuring Advanced Options - -Devtron provides three stages in a CI pipeline: Pre-Build, Build, and Post-Build. - -1. Pre-Build Stage: This stage is used for preparing the environment before the actual build begins. Tasks such as dependency installation, secret management, and validation can be configured here. - -2. Build Stage: The core stage where the application source code is compiled, a container image is built, and the necessary artifacts are generated. - -3. Post-Build Stage: This stage runs after the build is complete, where additional tasks such as security scans, notifications, or artifact uploads can be executed. - -This guide focuses on configuring the Build Stage. If you want to set up Pre-Build and Post-Build stages, refer to the separate documentation - -* Pre-Build Stage Configuration -* Post-Build Stage Configuration - -#### Scan for Vulnerabilities - -Devtron supports security scanning after the build stage. - -##### Prerequisite - -Ensure you have installed one of the following integrations: -* Clair -* Trivy - -##### How to Enable Security Scan? - -* In the Build Stage tab, enable Scan for vulnerabilities. -* This will scan the built container image for known vulnerabilities. - -#### Custom Image Tag Pattern - -You can define custom image tags for better version tracking. - -* Enable the Custom Image Tag Pattern toggle. -* Define an alphanumeric pattern (e.g., test-v1.0.{x} where x auto-increments with each build). -* Click Update Pipeline. - -{% hint style="info" %} -Ensure custom tags do not start or end with a period (.) or comma (,). -{% endhint %} - -#### Triggering a Build - -Once the CI pipeline is set up, follow these steps to trigger a build: - -* Navigate to Build & Deploy. - -* Click Select Material. - -* Choose the Git commit to build. - -* Click Start Build. - -Once successful, the image tag will be available in: - -* Build History -* Docker Registry  -* CD Pipeline (Image Selection) \ No newline at end of file