ci: update cd/cd build processes for docker #22
Conversation
|
Important Review skippedMore than 25% of the files skipped due to max files limit. The review is being skipped to prevent a low-quality review. 71 files out of 127 files are above the max files limit of 50. Please upgrade to Pro plan to get higher limits. You can disable this status message by setting the WalkthroughThe introduction of Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Developer
Developer ->> GitHub Actions: Push changes / PR / Schedule
GitHub Actions ->> Workflow: Trigger `docker-publish.yaml` or `docker-publish-rootless.yaml`
Workflow ->> actions/checkout: Checkout repository
Workflow ->> cosign-installer: Install `cosign`
Workflow ->> docker/buildx: Setup Docker Buildx
Workflow ->> docker/login-action: Login to Docker registry
Workflow ->> docker/metadata-action: Extract Docker metadata
Workflow ->> docker/build-push-action: Build and push Docker image
Workflow ->> cosign: Sign Docker image
cosign ->> Docker Registry: Upload signed image
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 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 as PR comments)
Additionally, you can add CodeRabbit Configration 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
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (2)
- .github/workflows/docker-publish-rootless.yaml (1 hunks)
- .github/workflows/docker-publish.yaml (1 hunks)
Additional comments not posted (8)
.github/workflows/docker-publish.yaml (4)
13-17: Environment variables are set appropriately for Docker operations. Ensure that theREGISTRYandIMAGE_NAMEare configured as per your organization's policies.
21-29: The job is configured with specific permissions, which are well-suited for the tasks at hand. This includes permissions for reading contents, writing packages, and handling ID tokens, essential for operations outside of PRs.
31-94: All steps in the workflow are meticulously detailed, including conditions for running certain steps only outside of pull requests. This ensures security and control over the build and push processes. Each action uses pinned versions, enhancing the reliability and reproducibility of the workflow.
3-11: The scheduled trigger is set for daily execution at 6:38 AM UTC, which is an unusual time. Consider aligning this with a more standard time, perhaps on the hour or half-hour, unless specific reasons dictate otherwise..github/workflows/docker-publish-rootless.yaml (4)
3-11: The triggers are configured to activate the workflow on a daily schedule at 6:00 AM UTC, on pushes to the main branch, and on semver-tagged releases. This configuration ensures that the workflow runs regularly and in response to relevant repository events.
13-17: The environment setup mirrors that of the standard Docker publish workflow, ensuring consistency across workflows. This uniformity is beneficial for maintenance and understanding across different CI/CD configurations.
21-29: The job configuration is robust, specifyingubuntu-latestas the runner and setting precise permissions necessary for the workflow's operations. This setup is crucial for secure and efficient execution of the workflow steps.
31-95: The workflow steps are well-defined and include conditions to prevent operations such as pushing and signing during pull requests. This careful setup ensures that actions such as image signing only occur in controlled circumstances.
What type of PR is this?
(REQUIRED)
What this PR does / why we need it:
(REQUIRED)
This PR should update the docker building process to work better for our workflow, and also have digest signing.
Which issue(s) this PR fixes:
(REQUIRED)
No issues associated
Summary by CodeRabbit
New Features
Chores