bootstrap konflux build pipelines#181
bootstrap konflux build pipelines#181rauhersu wants to merge 3 commits intorh-ecosystem-edge:mainfrom rauhersu:appstudio-recert-4-19
Conversation
Signed-off-by: red-hat-konflux <konflux@no-reply.konflux-ci.dev>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rauhersu The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
WalkthroughThis pull request introduces two new Tekton Changes
Sequence Diagram(s)Pull-Request PipelinesequenceDiagram
participant PR as PipelineRun (PR Event)
participant INIT as Init Task
participant CLONE as Clone Repository
participant BUILD as Build Container
participant CLAIR as Clair Scan
participant SAST as SAST-Snyk Check
participant DEPREC as Deprecated Base Image Check
PR->>INIT: Start initialization
INIT->>CLONE: Trigger repository clone
CLONE->>BUILD: On completion, build container image
BUILD->>CLAIR: Trigger Clair Scan
BUILD->>SAST: Trigger SAST-Snyk Check
BUILD->>DEPREC: Trigger Deprecated Base Image Check
Push PipelinesequenceDiagram
participant PR as PipelineRun (Push Event)
participant INIT as Init Task
participant CLONE as Clone Repository
participant DEP as Prefetch Dependencies
participant BUILD as Build Container
participant SCAN as Security/SAST Checks
participant INDEX as Image Index/Source Tasks
PR->>INIT: Start initialization
INIT->>CLONE: Trigger repository clone
CLONE->>DEP: Prefetch dependencies
DEP->>BUILD: Build container image
BUILD->>SCAN: Initiate security and SAST checks
BUILD-->>INDEX: On successful build, trigger indexing tasks
Suggested labels
Suggested reviewers
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
.tekton/recert-4-19-push.yaml (2)
1-12: Review Metadata and Annotation Formatting
The metadata block is comprehensive. In particular, the multiline setting of thepipelinesascode.tekton.dev/on-cel-expression(lines 10–11) should be verified for proper YAML formatting. Consider whether quoting the entire expression might help avoid parsing issues.
141-597: Assess Tasks Sequence and Dependencies
The tasks are arranged in a logical sequence with appropriaterunAfterandwhenconditions. Each task references specific Tekton bundles with clearly defined parameters. As this section is extensive, consider periodic refactoring or modular segmentation to enhance maintainability..tekton/recert-4-19-pull-request.yaml (1)
144-594: Assess Tasks Sequence and Dependencies for PR
The tasks in the pull request pipeline are ordered with clear dependencies usingrunAfterandwhenclauses. Their configuration closely follows that of the push pipeline. As this section is extensive, consider future modularization to improve clarity and maintainability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.tekton/recert-4-19-pull-request.yaml(1 hunks).tekton/recert-4-19-push.yaml(1 hunks).tekton/recert-4-19-pull-request.yaml(1 hunks).tekton/recert-4-19-push.yaml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (16)
.tekton/recert-4-19-push.yaml (8)
13-18: Labels and Namespace Verification
Labels, the pipeline name (recert-4-19-on-push), and the namespace (telco-5g-tenant) are set clearly. Ensure that these values align with your deployment and organizational policies.
20-28: Inspect Top-level Pipeline Parameters
The parameters forgit-url,revision,output-image, anddockerfileuse templating syntax (e.g.{{source_url}},{{revision}}) correctly. Please verify that these tokens resolve as expected during runtime.
29-34: Clear Pipeline Description
The description provided in thepipelineSpec(lines 30–34) is informative and outlines the purpose of the pipeline. Consider adding any additional usage guidance if needed for clarity.
35-48: Validate 'finally' Section – SBOM Task
Theshow-sbomtask is well defined with proper parameters and bundle reference. Confirm that the value retrieved via$(tasks.build-image-index.results.IMAGE_URL)is reliably produced by thebuild-image-indextask.
49-57: Validate 'finally' Section – Summary Task
Theshow-summarytask effectively aggregates build results and repository details using context variables like$(context.pipelineRun.name). Ensure that the workspace binding and parameter passing meet your expected outcomes.
71-127: Examine PipelineSpec Parameter Definitions
The detailed parameter definitions inside thepipelineSpec(lines 71–127) cover build options such aspath-context,rebuild,skip-checks, and others. The default values and types appear consistent; please double-check that these match your intended pipeline behavior.
128-137: Review Results Configuration
Theresultsblock is standard and correctly maps outputs from thebuild-image-indextask. Verify that all result references remain consistent with the task definitions.
598-611: Review TaskRunTemplate and Workspace Setup
ThetaskRunTemplateis left empty (implying default behavior) and the workspaces are defined with a volume claim template forworkspacealong with optionalgit-authandnetrcworkspaces. Confirm that the allocated storage (1Gi) and these bindings meet your requirements for build artifacts and source persistence..tekton/recert-4-19-pull-request.yaml (8)
1-13: Metadata for Pull Request Pipeline
The metadata is well tailored for pull request events. Notably, the inclusion of thebuild.appstudio.redhat.com/pull_request_number: '{{pull_request_number}}'annotation (line 7) enhances traceability, and settingpipelinesascode.tekton.dev/cancel-in-progressto"true"(line 9) appropriately prioritizes new PR events.
14-19: Verify Labels and Namespace
The labels, pipeline name (recert-4-19-on-pull-request), and the namespace (telco-5g-tenant) are clearly specified. These settings are consistent with the push pipeline and should ensure uniform deployment targets.
21-31: Inspect Spec Parameters for PR Build
The top-level parameters—especially theoutput-imageparameter usingon-pr-{{revision}}(line 27) and theimage-expires-afterset to5d(line 29)—are correctly differentiated from the push pipeline. Verify these values against your versioning and retention strategies.
32-37: Pipeline Description Clarity
The brief description in thepipelineSpec(lines 32–37) effectively communicates the pipeline’s purpose for pull request events. Confirm this description aligns with your broader documentation and intended use case.
38-51: Validate 'finally' Section – SBOM Task for PR
Theshow-sbomtask (lines 38–51) mirrors the push pipeline’s configuration and correctly uses$(tasks.build-image-index.results.IMAGE_URL). Make sure this integration reliably produces the expected SBOM artifacts.
52-73: Validate 'finally' Section – Summary Task for PR
Theshow-summarytask (lines 52–73) aggregates critical details using context variables. It is well integrated with the repository and build tasks. Double-check that the workspace and parameter mappings are consistent with your CI/CD requirements for pull requests.
74-130: Examine PipelineSpec Parameter Section
The parameters defined within thepipelineSpec(lines 74–130) are comprehensive and mirror those in the push pipeline—with defaults and types clearly stated. Please verify that these settings precisely support the pull request build logic.
595-618: Review TaskRunTemplate and Workspace Configuration
ThetaskRunTemplate(empty object) implies default behavior, and the subsequent workspace definitions—including a volume claim template forworkspaceand optionalgit-auth/netrc—are set up appropriately. Ensure that the storage and secret configurations meet your pipeline’s operational needs.
|
/retest |
6 similar comments
|
/retest |
|
/retest |
|
/retest |
|
/retest |
|
/retest |
|
/retest |
Signed-off-by: red-hat-konflux <konflux@no-reply.konflux-ci.dev>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.tekton/recert-4-19-pull-request.yaml (1)
423-461: Task “sast-coverity-check”This task (lines 423–461) performs a Coverity static analysis and depends on a successful “coverity-availability-check”. For clarity, consider reordering its definition so that the “coverity-availability-check” task appears before this task in the YAML (even though Tekton uses runAfter for execution order).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.tekton/recert-4-19-pull-request.yaml(1 hunks).tekton/recert-4-19-push.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .tekton/recert-4-19-push.yaml
🔇 Additional comments (26)
.tekton/recert-4-19-pull-request.yaml (26)
1-12: Metadata & Annotations StructureThe API version, kind, and metadata (including the repository annotations and CEL expression) are clearly defined. Please double-check that the multi‐line CEL expression (lines 11–12) behaves as intended in your Tekton environment.
21-37: Outer Spec Parameters and PipelineSpec DescriptionThe outer spec parameters (lines 21–31) correctly supply dynamic values (e.g. git URL, revision, output image, dockerfile path). The subsequent pipelineSpec description (lines 32–37) is clear and informative. Ensure that the parameters defined here and later within pipelineSpec remain consistent.
38-70: Finally Block – Post-Build TasksThe “finally” section (lines 38–70) includes the critical tasks “show-sbom” and “show-summary” that always execute, regardless of build success. Their parameter references (e.g. using results from previous tasks and context variables) look correct. Consider adding inline comments if further clarity is needed in the future.
74-94: Pipeline Parameters Definitions within pipelineSpecThe pipeline parameters (lines 74–94) are defined with descriptive defaults and types. Note that some defaults (e.g. for the dockerfile) differ from the outer spec—please verify that these intentional overrides meet your repository layout and build requirements.
131-142: Result Parameters ConfigurationThe result parameters (lines 131–142) properly capture outputs (such as IMAGE_URL, IMAGE_DIGEST, and Git commit info) from tasks. This configuration will support downstream tasks that rely on these results.
144-161: Task “init”This task (lines 144–161) initializes the build setup by passing relevant parameters like the output image URL, rebuild flag, and skip-checks option. The Tekton bundle reference appears correct.
162-190: Task “clone-repository”The “clone-repository” task (lines 162–190) is well-configured: it receives the git URL and revision, runs after “init”, and its conditional execution based on the build flag is clear.
189-216: Task “prefetch-dependencies”The task (lines 189–216) handles dependency prefetching effectively by checking that the “prefetch-input” parameter is not empty. Its runAfter dependency on “clone-repository” is properly set.
216-252: Task “build-container”This task (lines 216–252) uses parameters (IMAGE, DOCKERFILE, CONTEXT, etc.) for building the container image with buildah. One note: verify that the provided DOCKERFILE value (set to “.konflux/Dockerfile”) intentionally overrides any defaults and accurately reflects your repo structure.
256-284: Task “build-image-index”The “build-image-index” task (lines 256–284) correctly creates an OCI image index by combining the image URL and digest. The parameter substitution (using the “@” separator) is neat and should work as expected.
285-309: Task “build-source-image”This task (lines 285–309) conditionally builds a source image by checking both the build flag and the “build-source-image” parameter. The two “when” conditions ensure it runs only when intended.
312-332: Task “deprecated-base-image-check”Task “deprecated-base-image-check” (lines 312–332) verifies if the base image is deprecated. Its configuration and condition (based on skip-checks) are appropriate.
334-354: Task “clair-scan”The “clair-scan” task (lines 334–354) is properly set up to run vulnerability scans using Clair. The linkage to the image digest and URL is correct.
356-375: Task “ecosystem-cert-preflight-checks”This task (lines 356–375) runs ecosystem certification preflight checks. Its dependency on the build-image-index and the skip-checks condition are properly defined.
376-392: Task “sast-snyk-check”The “sast-snyk-check” task (lines 376–392) triggers a SAST scan using Snyk. The parameters and conditional execution based on skip-checks look good. It might be beneficial to periodically validate that the bundled Snyk task remains up to date with security advisories.
401-421: Task “clamav-scan”Configured in lines 401–421, the “clamav-scan” task integrates antivirus scanning. Its use of the image digest and URL from the previous task is consistent.
469-486: Task “coverity-availability-check”The “coverity-availability-check” task (lines 469–486) checks whether Coverity scanning can proceed. Its dependency on skip-checks being false is correctly implemented.
487-507: Task “sast-shell-check”The “sast-shell-check” task (lines 487–507) inspects shell scripts for potential vulnerabilities. Its configuration is standard and matches expected parameters.
511-530: Task “sast-unicode-check”Task “sast-unicode-check” (lines 511–530) is straightforward—it checks for issues related to Unicode characters. The setup and condition ensure it runs only when skip-checks is false.
534-548: Task “apply-tags”This task (lines 534–548) applies tags to the built image. It correctly references the image URL from the “build-image-index” task.
550-569: Task “push-dockerfile”The “push-dockerfile” task (lines 550–569) pushes the Dockerfile along with context parameters. Please ensure that the DOCKERFILE and CONTEXT values accurately match your repository layout.
573-594: Task “rpms-signature-scan”Task “rpms-signature-scan” (lines 573–594) is aimed at verifying RPM signatures for the image. Its execution condition based on skip-checks is sound.
596-600: Pipeline Workspaces ConfigurationThe pipeline-level workspaces (lines 596–600) are defined with the expected workspaces (“workspace”, “git-auth”, and “netrc” marked as optional). This provides flexibility for tasks that require authentication or network runtime settings.
602-613: Persistent Volume Claim Template for WorkspaceThe volumeClaimTemplate (lines 602–613) allocates 1Gi storage with ReadWriteOnce access. This is adequate for intermediate build artifacts and shared workspaces.
614-617: Git-Auth Workspace Secret ReferenceThe git-auth workspace (lines 614–617) correctly employs a templated secret reference via
{{ git_auth_secret }}. Ensure that the corresponding secret exists in the target namespace.
617-618: Status InitializationThe status field (lines 617–618) is initialized as an empty map, which is standard for new PipelineRun definitions.
|
superseded by: #182 |
1 participant
Summary by CodeRabbit
PipelineRunto enhance the container image build process.