Conversation
WalkthroughThis pull request updates documentation across 27+ files to replace Docker-specific terminology with container-agnostic language. Changes include substituting Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying alauda-container-platform with
|
| Latest commit: |
f8ad6d5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://b5fa1c27.alauda-container-platform.pages.dev |
| Branch Preview URL: | https://feat-acp-md-docker-keyword.alauda-container-platform.pages.dev |
yinshuxun
force-pushed
the
feat/acp-md-docker-keyword
branch
from
c4aa04b to
63d2ded
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
docs/en/developer/building_application/concepts/understanding_parameters.mdx (1)
22-28: Terminology inconsistency: "Container Image" vs. Dockerfile instructions.The section header "Relationship with Container Image" and text "In container image terminology:" refer to ENTRYPOINT and CMD, which are Dockerfile/Containerfile instructions rather than container image properties. A container image is the built runtime artifact, whereas the Dockerfile defines these instructions during the build process.
For consistency with
understanding_startup_commands.mdx(which correctly uses "Relationship with Dockerfile and Parameters" and "Dockerfile instructions"), consider updating this section to reference Dockerfile terminology.Apply this diff to align the terminology:
-### Relationship with Container Image +### Relationship with Dockerfile -In container image terminology: +In Dockerfile terminology: - **ENTRYPOINT**: Defines the executable (maps to Kubernetes `command`) - **CMD**: Provides default arguments (maps to Kubernetes `args`) - **Parameters**: Override CMD arguments while preserving ENTRYPOINTdocs/en/developer/images/how_to/creating_images.mdx (1)
19-19: Inconsistent container tool reference.Line 19 still mentions the
dockerCLI, which is inconsistent with the rest of the document that has been updated to use Podman and Containerfile terminology throughout.Consider updating for consistency:
-You can use the `nerdctl` or `docker` CLI directly to build images, but Alauda Container Platform also supplies builder images that assist with creating new images by adding your code or configuration to existing images. +You can use the `nerdctl` or `podman` CLI directly to build images, but Alauda Container Platform also supplies builder images that assist with creating new images by adding your code or configuration to existing images.docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx (1)
87-87: Fix inconsistent command - should usepodman pushinstead ofdocker push.Line 87 still uses
docker pushwhile all other commands in this document have been updated to usepodman(lines 54, 60, 81). This inconsistency breaks the systematic replacement pattern established in the PR.Apply this diff to maintain consistency:
- docker push build-harbor.example.cn/3rdparty/vmdisks/win-virtio:latest # Replace the repository according to your actual environment + podman push build-harbor.example.cn/3rdparty/vmdisks/win-virtio:latest # Replace the repository according to your actual environment
♻️ Duplicate comments (1)
docs/en/developer/quick_start/quick_start_app.mdx (1)
113-113: Ambiguous image reference (duplicate concern).This line has the same issue as lines 91-92: the shorthand
library/nginx:latestlacks clarity about the source registry and may cause confusion or errors for new users.Please apply the same fix here as recommended for lines 91-92.
🧹 Nitpick comments (6)
docs/en/developer/building_application/configuration/add_secret.mdx (3)
37-37: Consider removing Docker-specific reference for consistency.The parenthetical "(Docker Registry)" could be removed to maintain full consistency with the PR's goal of using container-agnostic terminology throughout the documentation.
Apply this diff for complete consistency:
-- **Image Pull Secret**: Stores the JSON authentication string required for pulling container images from private image repositories (Docker Registry). +- **Image Pull Secret**: Stores the JSON authentication string required for pulling container images from private image repositories.
76-89: Consider using a generic registry URL in the example.Line 76 now references "container registry standard login format," but the JSON example on line 81 still uses the Docker Hub-specific URL
https://index.docker.io/v1/. Using a generic registry URL likeregistry.example.comwould better align with the container-agnostic terminology update and clarify that this format works with any container registry.Apply this diff to use a generic registry example:
{ "auths": { - "https://index.docker.io/v1/": { + "registry.example.com": { "username": "myuser", "password": "mypass", "email": "my@example.com", "auth": "bXl1c2VyOm15cGFzcw==" # base64(username:password) } } }
96-97: Consider using a container-agnostic secret name in the example.The example secret name
my-docker-credscontains Docker-specific terminology. For complete alignment with the PR's systematic terminology updates, consider using a more generic name.Apply this diff:
imagePullSecrets: - - name: my-docker-creds + - name: my-registry-credsdocs/en/developer/building_application/concepts/understanding_startup_commands.mdx (1)
51-51: Consider clarifying the table header.The table header "Container Image" refers to the ENTRYPOINT and CMD baked into the image. For consistency with the terminology used throughout this document, consider using "Dockerfile" or "Image Definition" to make it clearer that these are the instructions defined during the build phase.
Example:
-| Scenario | Container Image | Kubernetes Spec | Resulting Command | +| Scenario | Dockerfile | Kubernetes Spec | Resulting Command |docs/en/developer/images/how_to/managing_images.mdx (1)
11-58: LGTM! Container-agnostic terminology updates are well-executed.The documentation updates successfully make the content more container-agnostic by:
- Replacing Docker-specific references with generic container terminology
- Updating to reference Podman as the container client example
- Maintaining clarity while broadening applicability
For slightly more concise writing, consider this minor wording improvement on line 19:
-When Alauda Container Platform creates containers, it uses the container `imagePullPolicy` to determine if the image should be pulled prior to starting the container. +When Alauda Container Platform creates containers, it uses the container `imagePullPolicy` to determine if the image should be pulled before starting the container.Based on static analysis hints.
docs/en/developer/images/overview.mdx (1)
19-19: Consider updating Docker CLI reference for consistency.Similar to other files in this PR, line 19 still references the
dockerCLI, which may be inconsistent with the broader effort to migrate to container-agnostic tooling.Consider updating for consistency:
-You can use the `nerdctl` or `docker` CLI directly to build images, but Alauda Container Platform also supplies builder images that assist with creating new images by adding your code or configuration to existing images. +You can use the `nerdctl` or `podman` CLI directly to build images, but Alauda Container Platform also supplies builder images that assist with creating new images by adding your code or configuration to existing images.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (31)
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx(1 hunks)docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx(1 hunks)docs/en/developer/building_application/application_workloads/cronjob_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deamonset_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deployment_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/pod.mdx(1 hunks)docs/en/developer/building_application/application_workloads/statefulset_create.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_parameters.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_startup_commands.mdx(2 hunks)docs/en/developer/building_application/configuration/add_secret.mdx(2 hunks)docs/en/developer/building_application/create_applications/image_app.mdx(1 hunks)docs/en/developer/building_application/create_applications/oam_app.mdx(2 hunks)docs/en/developer/building_application/create_applications/yaml_app.mdx(1 hunks)docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx(3 hunks)docs/en/developer/building_application/working_with_helm_charts.mdx(1 hunks)docs/en/developer/images/how_to/creating_images.mdx(4 hunks)docs/en/developer/images/how_to/managing_images.mdx(3 hunks)docs/en/developer/images/overview.mdx(1 hunks)docs/en/developer/oam_applications/concepts/component.mdx(1 hunks)docs/en/developer/quick_start/quick_start_app.mdx(3 hunks)docs/en/developer/registry/how_to/common_cli_command.mdx(1 hunks)docs/en/developer/registry/install/install_via_web_ui.mdx(2 hunks)docs/en/networking/operators/alb_operator/modsecurity.mdx(1 hunks)docs/en/networking/operators/alb_operator/understanding_alb.mdx(1 hunks)docs/en/observability/inspection/functions/inspection.mdx(1 hunks)docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx(3 hunks)docs/shared/openapis/apps.v1.json(2 hunks)docs/shared/openapis/batch.v1.json(2 hunks)docs/shared/openapis/core.v1.json(2 hunks)
🧰 Additional context used
🪛 Checkov (3.2.334)
docs/shared/openapis/apps.v1.json
[high] 1-16385: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-16385: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/core.v1.json
[high] 1-37024: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-37024: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/batch.v1.json
[high] 1-9629: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-9629: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
🪛 LanguageTool
docs/en/developer/images/how_to/managing_images.mdx
[style] ~19-~19: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...determine if the image should be pulled prior to starting the container. There are three...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
docs/en/developer/images/overview.mdx
[style] ~46-~46: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ic SHA identifier always references the exact same container image content. For example: `...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
docs/en/developer/images/how_to/creating_images.mdx
[style] ~41-~41: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ss, and everything works as you expect. If you did not use exec in your wrapper ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~66-~66: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...e this or another image is built. It is very important to place instructions that rarely chang...
(EN_WEAK_ADJECTIVE)
[grammar] ~66-~66: Use a hyphen to join words.
Context: ...se the cache is not invalidated by upper layer changes. For example, if you are ...
(QB_NEW_EN_HYPHEN)
[grammar] ~128-~128: Use a hyphen to join words.
Context: ...vironment variables in that they are key value pairs attached to an image or a co...
(QB_NEW_EN_HYPHEN)
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx
[style] ~19-~19: ‘in conjunction with’ might be wordy. Consider a shorter alternative.
Context: ...ess (PID 1) inside the container - Work in conjunction with parameters (args) to form the complete ...
(EN_WORDINESS_PREMIUM_IN_CONJUNCTION_WITH)
docs/en/developer/registry/how_to/common_cli_command.mdx
[grammar] ~69-~69: Use a hyphen to join words.
Context: ...istry using a standard container command line tool such as podman. ```bash # Tag...
(QB_NEW_EN_HYPHEN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Pipelines as Code CI / doc-pr-build-container-platform
🔇 Additional comments (26)
docs/en/developer/oam_applications/concepts/component.mdx (1)
61-61: LGTM! Good vendor-neutral documentation practice.The change from
index.docker.iotoregistry.example.comsuccessfully removes Docker-specific references while maintaining a clear, correct example format. Usingregistry.example.comfollows standard documentation conventions for generic examples.docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx (1)
604-604: LGTM! Documentation improved by removing registry prefix.The change from
docker.io/kubeovn/kube-ovn:v1.14.0-debugtokubeovn/kube-ovn:v1.14.0-debugmakes the documentation more container-runtime agnostic while remaining functionally equivalent, asdocker.iois the implicit default registry.docs/en/observability/inspection/functions/inspection.mdx (1)
65-65: LGTM! Terminology update improves documentation accuracy.The change from "corrupted Docker image" to "corrupted container image" appropriately modernizes the documentation to be container-runtime agnostic, aligning with the PR's objectives. The event name
NodeCorruptDockerImagecorrectly remains unchanged as it represents the actual Kubernetes event identifier.docs/en/networking/operators/alb_operator/modsecurity.mdx (1)
141-141: LGTM! Image reference standardization aligns with PR objectives.The removal of the
docker.io/registry prefix is functionally equivalent since container runtimes default to Docker Hub when no registry is specified. This change makes the documentation more container-agnostic, which aligns with the PR's goal of standardizing container image references across the codebase.docs/en/networking/operators/alb_operator/understanding_alb.mdx (1)
76-76: LGTM: Image reference simplified appropriately.Removing the
docker.io/prefix aligns with the PR objectives of using container-agnostic terminology. The change is functionally equivalent since Kubernetes defaults to the docker.io registry for unqualified image references, and the shorter form improves readability in documentation examples.docs/en/developer/building_application/create_applications/yaml_app.mdx (1)
26-26: LGTM! Docker-to-Podman terminology updated correctly.The update from
docker pulltopodman pullaligns with the PR objectives to use container-agnostic tooling references. Podman maintains command compatibility with Docker, so this change is accurate and won't confuse users.docs/en/developer/building_application/create_applications/oam_app.mdx (2)
47-47: LGTM! Formatting improvement.The added empty line improves readability between the two concept reference bullets.
59-59: LGTM! Consistent Docker-to-Podman terminology update.The command reference has been correctly updated from
docker pulltopodman pull, maintaining consistency with the changes in yaml_app.mdx and the overall PR objectives.docs/shared/openapis/batch.v1.json (1)
6727-6729: EnableServiceLinks description update looks goodThe new wording removes the Docker-specific reference while preserving the intended meaning and behavior; no further changes needed here.
docs/shared/openapis/apps.v1.json (2)
16385-16385: Minor formatting hygiene: trailing newline added.Adding a trailing newline at the end of the file is a standard practice and improves consistency.
13483-13483: Editorial update consistently applied across schema files.The description change from Docker-specific language to "matching traditional container linking syntax" is consistently applied across all three OpenAPI schema files:
apps.v1.json,core.v1.json, andbatch.v1.json. The schema behavior remains unchanged, and the update appropriately aligns with the PR objective of using container-agnostic terminology.docs/shared/openapis/core.v1.json (2)
32484-32484: Documentation update aligns with PR objective.The description change from Docker-specific to "traditional container linking syntax" is aligned with the PR objective of replacing Docker-centric terminology with generic container tooling references.
37024-37024: Static analysis hints appear to be pre-existing schema limitations.Checkov flags two high-severity issues (CKV_OPENAPI_4, CKV_OPENAPI_5) regarding missing global security definitions and empty security operations. These appear to be pre-existing limitations in the Kubernetes OpenAPI schema, not introduced by the description string update in this PR. The PR change only updates documentation text for
enableServiceLinksand does not modify any security-related fields or structure.If these security warnings are important for your documentation standards, you may want to address them separately in a dedicated issue. Otherwise, they can safely be ignored as out-of-scope for this terminology update.
docs/en/developer/quick_start/quick_start_app.mdx (1)
81-81: LGTM! Formatting improvement.The added blank line improves readability by visually separating the instruction text from the parameter table below.
docs/en/developer/building_application/working_with_helm_charts.mdx (1)
222-229: Changes to container tooling commands are correct and complete.The Docker-to-Podman migration for container image management is functionally sound and properly executed. Podman maintains compatibility with the Docker API, with about 95% of use cases working seamlessly. All command equivalents used (pull, save, load, tag, push) are syntactically very similar to Docker, with podman save writing to STDOUT by default and can be redirected to a file, just like Docker. The registry endpoint and image references are preserved appropriately. Verification confirms no remaining Docker CLI references exist in the documentation—the migration is complete and consistent.
docs/en/developer/registry/install/install_via_web_ui.mdx (2)
8-16: LGTM! Formatting improvements enhance readability.The reformatting of the "Recommended for" and "Not Recommended for" sections with bold headers creates better visual hierarchy and improves document structure.
50-50: LGTM! Terminology updated to be container-agnostic.The change from "Docker client" to "container client (e.g., Podman)" successfully makes the documentation more inclusive for users of different container runtimes, aligning with the PR objective to standardize container terminology.
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx (1)
162-162: LGTM! Container tool update is appropriate.The update from
docker pulltopodman pullaligns well with the PR's objectives to use container-agnostic tooling. The documentation now offers bothcrictl pullandpodman pullas testing alternatives, which is appropriate for different use cases.docs/en/developer/images/how_to/creating_images.mdx (1)
41-130: LGTM! Comprehensive Dockerfile→Containerfile and Docker→Podman migration.The systematic updates throughout the document are well-executed:
- All command examples updated to
podman- All file references updated to
Containerfile- Examples maintain technical accuracy
- Guidance and best practices remain clear and applicable
docs/en/developer/images/overview.mdx (1)
34-48: LGTM! Image reference simplification improves readability.Removing the
docker.io/alauda/prefix from the image references makes the examples cleaner and more focused on the essential information (repository name, tag, and digest).docs/en/developer/building_application/application_workloads/deamonset_create.mdx (1)
128-128: LGTM! Project naming update aligns with PR objectives.The update from
docker-registry-projectnametoregistry-projectnameremoves Docker-specific terminology from the example naming convention, which is consistent with the broader documentation updates in this PR.docs/en/developer/building_application/application_workloads/deployment_create.mdx (1)
108-108: LGTM! Example naming updated to be container-agnostic.The change from
docker-registry-projectnametoregistry-projectnamealigns with the PR's objective to use generic container terminology.docs/en/developer/building_application/create_applications/image_app.mdx (1)
30-30: LGTM! Consistent example naming update.The documentation example has been updated to use
registry-projectname, maintaining consistency with other workload creation docs in this PR.docs/en/developer/building_application/application_workloads/statefulset_create.mdx (1)
121-121: LGTM! Example naming standardized.Consistent with the project name example updates across other workload creation documentation files.
docs/en/developer/building_application/application_workloads/cronjob_create.mdx (1)
79-79: LGTM! Documentation example updated consistently.The integration project name example has been standardized to
registry-projectname, completing the consistent updates across all workload creation documentation.docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx (1)
30-86: Terminology and tooling updates look good.The systematic updates from Docker-specific terminology to container-agnostic language and the migration from
dockertopodmancommands are consistent and well-executed throughout this section.
yinshuxun
force-pushed
the
feat/acp-md-docker-keyword
branch
from
63d2ded to
e18f1e7
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx (1)
87-87: Inconsistent command: usepodman pushinstead ofdocker push.Line 87 still uses
docker push, which is inconsistent with thepodman pushcommand used on Line 60 for the Windows ISO section. This breaks the uniformity of the documentation and contradicts the PR objective of replacing Docker commands with Podman equivalents.Apply this diff to fix the inconsistency:
- docker push build-harbor.example.cn/3rdparty/vmdisks/win-virtio:latest # Replace the repository according to your actual environment + podman push build-harbor.example.cn/3rdparty/vmdisks/win-virtio:latest # Replace the repository according to your actual environment
♻️ Duplicate comments (6)
docs/en/developer/registry/how_to/common_cli_command.mdx (1)
69-69: Grammar issue remains unaddressed from previous review.The terminology update from "docker" to "podman" is correct. However, the grammar issue flagged in the previous review still needs to be fixed: "command line tool" should be hyphenated as "command-line tool" when used as a compound modifier.
Apply this diff:
-You need to first tag (tag) the local image with the address and namespace format of the target Registry using a standard container command line tool such as podman. +You need to first tag (tag) the local image with the address and namespace format of the target Registry using a standard container command-line tool such as podman.Based on static analysis hints.
docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx (3)
55-55: Update section header to be container-agnostic.The section header still references "Docker and Containerd Deployment" but should be updated to reflect container-agnostic terminology, consistent with the changes made elsewhere in this file.
Apply this diff:
-### Docker and Containerd Deployment +### Container Runtime Deployment
84-98: Update other nodes commands to use Podman.The commands for the other two nodes still use
docker run, creating inconsistency with the Leader node command that now usespodman run.Apply this diff:
```sh - docker run \ + podman run \ --name=ovn-ic-db \ -d \ --env "ENABLE_OVN_LEADER_CHECK=false" \ --network=host \ --restart=always \ --privileged=true \ -v /etc/ovn/:/etc/ovn \ -v /var/run/ovn:/var/run/ovn \ -v /var/log/ovn:/var/log/ovn \ -e LOCAL_IP="<IP address of the current node>" \ ## For example: -e LOCAL_IP="192.168.39.24" -e LEADER_IP="<IP address of the Leader node>" \ ## For example: -e LEADER_IP="192.168.39.37" -e NODE_IPS="<IP addresses of all nodes, separated by commas>" \ ## For example: -e NODE_IPS="192.168.39.22,192.168.39.24,192.168.39.37" <image repository address> bash start-ic-db.sh ## For example: 192.168.39.10:60080/acp/kube-ovn:v1.8.8 bash start-ic-db.sh ```
306-311: Update uninstall section to use Podman commands.The uninstall section still references "Docker command" and uses Docker-specific commands (
docker stop,docker rm), which is inconsistent with the deployment section that now uses Podman.Apply this diff:
- - Docker command: + - Podman command: ```sh - docker stop ovn-ic-db - docker rm ovn-ic-db + podman stop ovn-ic-db + podman rm ovn-ic-db ```docs/en/developer/building_application/application_workloads/pod.mdx (1)
15-15: Remove redundant circular phrasing.The phrase "containers (such as containers)" remains circular and provides no useful information. This issue was previously identified and should be addressed.
Consider one of the alternatives suggested in the previous review:
- Remove the parenthetical entirely: "...is a group of one or more containers, with shared storage..."
- Provide a meaningful example: "...containers (such as application and sidecar containers)..."
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx (1)
17-17: Align terminology: ENTRYPOINT is a Dockerfile/Containerfile instruction.This issue was previously flagged. ENTRYPOINT is defined in Dockerfiles/Containerfiles, not in container images (the built artifacts). Consider updating to reference Dockerfiles/Containerfiles for consistency with the terminology used elsewhere in this file.
🧹 Nitpick comments (2)
docs/shared/openapis/batch.v1.json (1)
1-9629: Checkov OpenAPI security findings are pre‑existing and out of scope for this PRCKV_OPENAPI_4 and CKV_OPENAPI_5 about missing global/operation
securitydefinitions apply to the overall spec and are not introduced by this wording change. If you want to address them, you’d need to add a top‑levelsecuritysection or per‑operationsecurityentries, or alternatively suppress these rules for the vendored Kubernetes OpenAPI docs.docs/en/developer/building_application/concepts/understanding_parameters.mdx (1)
17-17: Align terminology with line 10 for consistency.Line 10 uses precise wording: "override the default CMD arguments defined in container images." Line 17 should use consistent terminology by saying "CMD arguments" rather than "CMD instruction" since instructions exist in Dockerfiles while the resulting arguments are stored in the built image.
Apply this diff for consistency:
-- Override the default CMD instruction in container images +- Override the default CMD arguments in container images
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (32)
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx(1 hunks)docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx(2 hunks)docs/en/developer/building_application/application_workloads/cronjob_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deamonset_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deployment_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/pod.mdx(1 hunks)docs/en/developer/building_application/application_workloads/statefulset_create.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_parameters.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_startup_commands.mdx(2 hunks)docs/en/developer/building_application/configuration/add_secret.mdx(2 hunks)docs/en/developer/building_application/create_applications/image_app.mdx(1 hunks)docs/en/developer/building_application/create_applications/oam_app.mdx(2 hunks)docs/en/developer/building_application/create_applications/yaml_app.mdx(1 hunks)docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx(3 hunks)docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx(2 hunks)docs/en/developer/building_application/working_with_helm_charts.mdx(1 hunks)docs/en/developer/images/how_to/creating_images.mdx(4 hunks)docs/en/developer/images/how_to/managing_images.mdx(3 hunks)docs/en/developer/images/overview.mdx(1 hunks)docs/en/developer/oam_applications/concepts/component.mdx(1 hunks)docs/en/developer/quick_start/quick_start_app.mdx(3 hunks)docs/en/developer/registry/how_to/common_cli_command.mdx(1 hunks)docs/en/developer/registry/install/install_via_web_ui.mdx(2 hunks)docs/en/networking/operators/alb_operator/modsecurity.mdx(1 hunks)docs/en/networking/operators/alb_operator/understanding_alb.mdx(1 hunks)docs/en/observability/inspection/functions/inspection.mdx(1 hunks)docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx(3 hunks)docs/shared/openapis/apps.v1.json(2 hunks)docs/shared/openapis/batch.v1.json(2 hunks)docs/shared/openapis/core.v1.json(2 hunks)
✅ Files skipped from review due to trivial changes (2)
- docs/en/developer/building_application/create_applications/image_app.mdx
- docs/en/developer/building_application/application_workloads/deamonset_create.mdx
🚧 Files skipped from review as they are similar to previous changes (15)
- docs/en/developer/building_application/create_applications/yaml_app.mdx
- docs/en/developer/building_application/create_applications/oam_app.mdx
- docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx
- docs/en/developer/building_application/configuration/add_secret.mdx
- docs/en/developer/building_application/working_with_helm_charts.mdx
- docs/en/developer/building_application/application_workloads/statefulset_create.mdx
- docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
- docs/en/developer/building_application/application_workloads/cronjob_create.mdx
- docs/en/networking/operators/alb_operator/modsecurity.mdx
- docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx
- docs/en/developer/oam_applications/concepts/component.mdx
- docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx
- docs/en/developer/quick_start/quick_start_app.mdx
- docs/en/developer/registry/install/install_via_web_ui.mdx
- docs/en/networking/operators/alb_operator/understanding_alb.mdx
🧰 Additional context used
🪛 Checkov (3.2.334)
docs/shared/openapis/apps.v1.json
[high] 1-16385: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-16385: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/core.v1.json
[high] 1-37024: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-37024: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/batch.v1.json
[high] 1-9629: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-9629: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
🪛 LanguageTool
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx
[style] ~19-~19: ‘in conjunction with’ might be wordy. Consider a shorter alternative.
Context: ...ess (PID 1) inside the container - Work in conjunction with parameters (args) to form the complete ...
(EN_WORDINESS_PREMIUM_IN_CONJUNCTION_WITH)
docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx
[grammar] ~32-~32: Ensure spelling is correct
Context: ...storage (e.g., /var/lib/kubelet). - imagefs: Used by the container runtime for im...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
docs/en/developer/images/how_to/creating_images.mdx
[style] ~41-~41: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ss, and everything works as you expect. If you did not use exec in your wrapper ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~66-~66: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...e this or another image is built. It is very important to place instructions that rarely chang...
(EN_WEAK_ADJECTIVE)
[grammar] ~66-~66: Use a hyphen to join words.
Context: ...se the cache is not invalidated by upper layer changes. For example, if you are ...
(QB_NEW_EN_HYPHEN)
[grammar] ~128-~128: Use a hyphen to join words.
Context: ...vironment variables in that they are key value pairs attached to an image or a co...
(QB_NEW_EN_HYPHEN)
docs/en/developer/images/how_to/managing_images.mdx
[style] ~19-~19: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...determine if the image should be pulled prior to starting the container. There are three...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
docs/en/developer/images/overview.mdx
[style] ~46-~46: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ic SHA identifier always references the exact same container image content. For example: `...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
docs/en/developer/registry/how_to/common_cli_command.mdx
[grammar] ~69-~69: Use a hyphen to join words.
Context: ...istry using a standard container command line tool such as podman. ```bash # Tag...
(QB_NEW_EN_HYPHEN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Pipelines as Code CI / doc-pr-build-container-platform
🔇 Additional comments (24)
docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx (2)
32-32: Container-agnostic terminology is appropriate.The updated description replacing Docker-specific paths with generic "container runtime" terminology aligns well with the PR objective. The text is clear and accurate.
25-36: Static analysis false positive; no issues detected.The static analysis hint flagging a potential orthography error at line 32 appears to be a false positive. The text is grammatically correct and reads naturally. The formatting and content of the notes in this section (lines 25–36) are appropriate and clearly structured.
docs/en/developer/registry/how_to/common_cli_command.mdx (1)
73-73: LGTM!The command update from
docker tagtopodman tagis correct and consistent with the container-agnostic approach outlined in the PR objectives.docs/en/observability/inspection/functions/inspection.mdx (1)
65-65: LGTM! Terminology update improves accuracy.The change from "corrupted Docker image" to "corrupted container image" appropriately modernizes the documentation to be container-runtime agnostic while correctly preserving the system-defined event name
NodeCorruptDockerImage.docs/en/developer/building_application/application_workloads/deployment_create.mdx (1)
108-108: LGTM! Container-agnostic terminology update.The change from
docker-registry-projectnametoregistry-projectnamecorrectly removes Docker-specific terminology, making the documentation more container-agnostic and aligned with the PR objectives.docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx (1)
62-66: LGTM! Consistent container terminology and Podman command.The section correctly updates the deployment terminology and commands to use Podman instead of Docker.
docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx (4)
30-30: LGTM! Terminology updated correctly.The section title has been appropriately updated from Docker-specific to container-agnostic terminology.
46-60: LGTM! Commands and syntax labels updated correctly.The Dockerfile syntax label and build/push commands have been appropriately updated to use Podman equivalents.
63-63: LGTM! Terminology updated correctly.The section title has been appropriately updated to use container-agnostic terminology, consistent with the Windows ISO section.
73-81: LGTM! Commands and syntax labels updated correctly.The Dockerfile syntax label and build command have been appropriately updated.
docs/en/developer/images/overview.mdx (3)
34-35: LGTM!The simplified image repository example is clearer and aligns well with the PR objective of using container-agnostic terminology.
40-41: LGTM!The simplified tag example maintains clarity while following the container-agnostic approach.
48-49: LGTM!The simplified image ID example is consistent with the other changes and clearly demonstrates the SHA reference format.
docs/shared/openapis/batch.v1.json (1)
6727-6729: enableServiceLinks description wording looks goodUpdated text removes Docker‑specific terminology while still accurately describing service env var injection; no schema changes or behavioral impact.
docs/en/developer/building_application/concepts/understanding_parameters.mdx (2)
22-24: LGTM! Terminology updates improve clarity.The updates from Docker-specific terminology to container-agnostic wording improve the documentation's generality and accuracy.
28-28: LGTM! Helpful clarification added.The new bullet point accurately describes how Parameters relate to ENTRYPOINT and CMD, providing valuable context for readers.
docs/shared/openapis/apps.v1.json (1)
13483-13483: LGTM! Container-agnostic terminology improves documentation clarity.The update from "matching the syntax of Docker links" to "matching traditional container linking syntax" appropriately generalizes the description, making it vendor-neutral while preserving the intended meaning.
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx (2)
21-28: LGTM: Clear terminology alignment with Dockerfile.The updated terminology correctly distinguishes Dockerfile instructions (ENTRYPOINT, CMD) from their Kubernetes equivalents, improving clarity for readers.
51-51: LGTM: Container-agnostic terminology.Using "Container Image" instead of "Docker Image" appropriately reflects the technology-agnostic nature of container specifications.
docs/en/developer/images/how_to/managing_images.mdx (1)
40-44: LGTM: Container-agnostic terminology for pull secrets.The updates correctly generalize from Docker-specific wording to container-agnostic terminology, with Podman cited as an example. This broadens the documentation's applicability while maintaining technical accuracy.
docs/en/developer/images/how_to/creating_images.mdx (2)
41-41: LGTM: Podman command examples.The documentation correctly updates Docker commands to their Podman equivalents (
podman run,podman build,podman exec), reflecting modern container tooling options.Also applies to: 74-74, 82-82, 104-104
66-66: LGTM: Containerfile terminology.The shift from Dockerfile to Containerfile uses the OCI-standard term, appropriately aligning with the container-agnostic approach of using Podman commands throughout this document.
Also applies to: 68-68, 76-76, 86-86, 112-112, 128-128
docs/shared/openapis/core.v1.json (2)
32483-32486: LGTM! Good terminology update.The updated description using "traditional container linking syntax" is more container-agnostic and accurately describes the behavior without being vendor-specific.
37024-37024: Trailing newline is fine.The static analysis hints about missing security rules (CKV_OPENAPI_4, CKV_OPENAPI_5) are pre-existing conditions in this OpenAPI schema and are unrelated to the documentation changes in this PR. These can be safely ignored for this review.
yinshuxun
force-pushed
the
feat/acp-md-docker-keyword
branch
from
e18f1e7 to
0dfb4c9
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
docs/en/developer/building_application/application_workloads/pod.mdx (1)
15-15: The redundant parenthetical persists despite previous feedback.The phrase "containers (such as containers)" remains circular and uninformative. This was already flagged in a previous review and marked as addressed, but the issue is still present in the current code.
As suggested previously, either remove the parenthetical entirely or provide a meaningful example:
Option 1 (recommended): Remove the parenthetical
-A **Pod** is the smallest deployable unit of computing that you can create and manage in Kubernetes. A **Pod** (as in a pod of whales or a pea pod) is a group of one or more containers (such as containers), with shared storage and network resources, and a specification for how to run the containers. **Pods** are the fundamental building blocks on which all higher-level controllers (like **Deployments**, **StatefulSets**, **DaemonSets**) are built. +A **Pod** is the smallest deployable unit of computing that you can create and manage in Kubernetes. A **Pod** (as in a pod of whales or a pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. **Pods** are the fundamental building blocks on which all higher-level controllers (like **Deployments**, **StatefulSets**, **DaemonSets**) are built.Option 2: Provide a meaningful example
-A **Pod** is the smallest deployable unit of computing that you can create and manage in Kubernetes. A **Pod** (as in a pod of whales or a pea pod) is a group of one or more containers (such as containers), with shared storage and network resources, and a specification for how to run the containers. **Pods** are the fundamental building blocks on which all higher-level controllers (like **Deployments**, **StatefulSets**, **DaemonSets**) are built. +A **Pod** is the smallest deployable unit of computing that you can create and manage in Kubernetes. A **Pod** (as in a pod of whales or a pea pod) is a group of one or more containers (such as application containers), with shared storage and network resources, and a specification for how to run the containers. **Pods** are the fundamental building blocks on which all higher-level controllers (like **Deployments**, **StatefulSets**, **DaemonSets**) are built.docs/en/developer/registry/how_to/common_cli_command.mdx (1)
69-69: Hyphenation issue remains unaddressed from previous review.The phrase "command line tool" should be hyphenated as "command-line tool" when used as a compound modifier before a noun.
Apply this diff:
-You need to first tag (tag) the local image with the address and namespace format of the target Registry using a standard container command line tool such as podman. +You need to first tag (tag) the local image with the address and namespace format of the target Registry using a standard container command-line tool such as podman.Based on static analysis hints and past review comments.
docs/en/developer/images/how_to/creating_images.mdx (1)
130-130: Documentation link still points to Docker reference.This issue was previously flagged: the text refers to "Containerfile reference" but links to Docker's Dockerfile documentation. While Containerfiles use Docker-compatible syntax, consider updating the link to Podman/OCI documentation or adding a clarifying note about compatibility.
🧹 Nitpick comments (4)
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx (1)
9-51: Optional: Consider Dockerfile/Containerfile for complete container-agnostic terminology.While the current changes successfully improve accuracy and address Docker-specific terminology, for complete container-agnostic documentation you might consider using "Dockerfile/Containerfile" in places where currently only "Dockerfile" is mentioned. This would acknowledge that Podman and other container tools use "Containerfile" as the equivalent.
However, this is entirely optional—the current changes already achieve the PR objectives and "Dockerfile" remains widely understood across container tooling.
docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx (2)
17-19: Consider adding service startup instructions for Containerd.Line 17 mentions both Podman and Containerd as container runtime options, but line 19 only provides service startup instructions for Podman. Users choosing Containerd may need different service configuration steps.
Consider either:
- Adding equivalent instructions for Containerd (e.g.,
sudo systemctl enable containerd.service)- Clarifying that Podman is the recommended/required runtime for this setup
-3. If using Podman, ensure that the Podman service starts on boot for each host using the following command: `sudo systemctl enable podman.service`. +3. Ensure that the container runtime service starts on boot for each host: + - If using Podman: `sudo systemctl enable podman.service` + - If using Containerd: `sudo systemctl enable containerd.service`
185-187: Clarify that the example command uses Podman.Step 9 references "using a container runtime" (generic), but the command example is Podman-specific. Users who selected Containerd per the prerequisites (line 17) may expect a corresponding example.
Consider clarifying the example:
-9. Upload the Keepalived image to the external LB node and run Keepalived using a container runtime. +9. Upload the Keepalived image to the external LB node and run Keepalived using a container runtime. The following example uses Podman: ``` podman run -dt --restart=always --privileged --network=host -v /etc/keepalived:/live/cfg build-harbor.alauda.cn/tkestack/keepalived:v3.16.0-beta.3.g598ce923 ```Alternatively, if Podman is the only supported runtime for this deployment, consider updating line 17 to reflect that constraint.
docs/en/observability/inspection/functions/inspection.mdx (1)
65-65: The documentation update appropriately changes the description from "corrupted Docker image" to "corrupted container image," aligning with container-agnostic terminology. However, note that the event nameNodeCorruptDockerImagestill contains "Docker." This naming inconsistency reflects that the event name is platform-specific rather than a standard Kubernetes event, so changing the description without updating the event name identifier is a reasonable pragmatic approach. If this event name is defined in platform code, consider whether future updates might rename the event identifier itself for full consistency, but this is not necessary for the current documentation change.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (32)
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx(3 hunks)docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx(3 hunks)docs/en/developer/building_application/application_workloads/cronjob_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deamonset_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deployment_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/pod.mdx(1 hunks)docs/en/developer/building_application/application_workloads/statefulset_create.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_parameters.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_startup_commands.mdx(2 hunks)docs/en/developer/building_application/configuration/add_secret.mdx(2 hunks)docs/en/developer/building_application/create_applications/image_app.mdx(1 hunks)docs/en/developer/building_application/create_applications/oam_app.mdx(2 hunks)docs/en/developer/building_application/create_applications/yaml_app.mdx(1 hunks)docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx(3 hunks)docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx(2 hunks)docs/en/developer/building_application/working_with_helm_charts.mdx(1 hunks)docs/en/developer/images/how_to/creating_images.mdx(4 hunks)docs/en/developer/images/how_to/managing_images.mdx(3 hunks)docs/en/developer/images/overview.mdx(1 hunks)docs/en/developer/oam_applications/concepts/component.mdx(1 hunks)docs/en/developer/quick_start/quick_start_app.mdx(3 hunks)docs/en/developer/registry/how_to/common_cli_command.mdx(1 hunks)docs/en/developer/registry/install/install_via_web_ui.mdx(2 hunks)docs/en/networking/operators/alb_operator/modsecurity.mdx(1 hunks)docs/en/networking/operators/alb_operator/understanding_alb.mdx(1 hunks)docs/en/observability/inspection/functions/inspection.mdx(1 hunks)docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx(3 hunks)docs/shared/openapis/apps.v1.json(2 hunks)docs/shared/openapis/batch.v1.json(2 hunks)docs/shared/openapis/core.v1.json(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
🚧 Files skipped from review as they are similar to previous changes (15)
- docs/en/developer/building_application/application_workloads/deamonset_create.mdx
- docs/en/developer/quick_start/quick_start_app.mdx
- docs/en/developer/building_application/configuration/add_secret.mdx
- docs/en/developer/building_application/application_workloads/deployment_create.mdx
- docs/en/networking/operators/alb_operator/understanding_alb.mdx
- docs/en/developer/building_application/create_applications/image_app.mdx
- docs/en/developer/building_application/create_applications/yaml_app.mdx
- docs/en/developer/registry/install/install_via_web_ui.mdx
- docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx
- docs/en/developer/building_application/create_applications/oam_app.mdx
- docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx
- docs/en/developer/oam_applications/concepts/component.mdx
- docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx
- docs/en/developer/building_application/concepts/understanding_parameters.mdx
- docs/en/networking/operators/alb_operator/modsecurity.mdx
🧰 Additional context used
🪛 Checkov (3.2.334)
docs/shared/openapis/core.v1.json
[high] 1-37024: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-37024: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/apps.v1.json
[high] 1-16385: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-16385: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/batch.v1.json
[high] 1-9629: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-9629: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
🪛 LanguageTool
docs/en/developer/images/how_to/managing_images.mdx
[style] ~19-~19: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...determine if the image should be pulled prior to starting the container. There are three...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx
[grammar] ~32-~32: Ensure spelling is correct
Context: ...storage (e.g., /var/lib/kubelet). - imagefs: Used by the container runtime for im...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
docs/en/developer/images/how_to/creating_images.mdx
[style] ~41-~41: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ss, and everything works as you expect. If you did not use exec in your wrapper ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~66-~66: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...e this or another image is built. It is very important to place instructions that rarely chang...
(EN_WEAK_ADJECTIVE)
[grammar] ~66-~66: Use a hyphen to join words.
Context: ...se the cache is not invalidated by upper layer changes. For example, if you are ...
(QB_NEW_EN_HYPHEN)
[grammar] ~128-~128: Use a hyphen to join words.
Context: ...vironment variables in that they are key value pairs attached to an image or a co...
(QB_NEW_EN_HYPHEN)
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx
[style] ~19-~19: ‘in conjunction with’ might be wordy. Consider a shorter alternative.
Context: ...ess (PID 1) inside the container - Work in conjunction with parameters (args) to form the complete ...
(EN_WORDINESS_PREMIUM_IN_CONJUNCTION_WITH)
docs/en/developer/images/overview.mdx
[style] ~46-~46: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ic SHA identifier always references the exact same container image content. For example: `...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
docs/en/developer/registry/how_to/common_cli_command.mdx
[grammar] ~69-~69: Use a hyphen to join words.
Context: ...istry using a standard container command line tool such as podman. ```bash # Tag...
(QB_NEW_EN_HYPHEN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Pipelines as Code CI / doc-pr-build-container-platform
🔇 Additional comments (25)
docs/shared/openapis/batch.v1.json (1)
6727-6729: UpdatedenableServiceLinkswording looks goodThe new phrasing keeps the behavior clear while removing Docker-specific terminology; no schema or behavioral changes introduced.
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx (1)
162-162: LGTM! Docker-to-Podman migration applied correctly.The command update from Docker to Podman is accurate and aligns with the PR's objective of replacing Docker-specific tooling with container-agnostic alternatives.
docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx (3)
25-27: LGTM! Helpful clarification added.The note clearly explains the pod eviction behavior, which is useful context for users understanding resource handling.
32-32: LGTM! Container-agnostic terminology.The updated description removes Docker-specific references and provides a more generic, runtime-agnostic explanation of imagefs.
130-132: LGTM! Important operational detail clarified.The note helpfully explains that garbage collection happens before pod eviction, which is crucial for understanding the eviction workflow.
docs/en/developer/registry/how_to/common_cli_command.mdx (1)
73-73: LGTM! Docker-to-Podman migration applied correctly.The command update from
docker tagtopodman tagis accurate and consistent with the PR's objective.docs/en/developer/images/overview.mdx (1)
34-34: LGTM! Consistent example updates.The image examples have been consistently updated from
jenkins-2-rhel7tojenkins-2-centos7across all references, maintaining documentation clarity and consistency.Also applies to: 40-40, 48-48
docs/en/developer/building_application/working_with_helm_charts.mdx (1)
222-229: LGTM! Comprehensive Docker-to-Podman migration.All five Docker commands (
pull,save,load,tag,push) have been correctly replaced with their Podman equivalents. The syntax and arguments remain valid.docs/en/developer/images/how_to/managing_images.mdx (1)
11-11: LGTM! Excellent container-agnostic terminology migration.The documentation has been successfully updated to use container-runtime-agnostic terminology throughout:
- Removed Docker-specific references and configuration paths
- Replaced "Docker" with "Podman" and generic "container client" terminology
- Improved clarity around image pull secrets and service account usage
These changes align perfectly with the PR's objective of modernizing the documentation for broader container runtime compatibility.
Also applies to: 15-15, 19-19, 30-30, 34-45, 52-57, 73-73
docs/shared/openapis/apps.v1.json (1)
13483-13483: LGTM! Terminology updated to be container-agnostic.The description change from "Docker links" to "traditional container linking syntax" aligns with the PR objective and makes the documentation more vendor-neutral while remaining accurate.
docs/en/developer/images/how_to/creating_images.mdx (6)
41-41: LGTM! Consistent Podman terminology.The update from Docker to Podman commands accurately reflects the container-agnostic approach described in the PR objectives.
66-82: LGTM! Proper Containerfile and Podman terminology.The systematic replacement of Dockerfile with Containerfile and docker build with podman build throughout this section maintains consistency and aligns with the PR's container-agnostic approach.
86-93: LGTM! Consistent command and terminology updates.The updates to use
podmancommands and Containerfile references throughout the port and environment variable sections are accurate and consistent with the PR objectives.
104-104: LGTM! Appropriate Podman command reference.The update to recommend
podman execfor local container access aligns with the documentation's shift to Podman-based workflows.
112-112: LGTM! Consistent Containerfile terminology.The update maintains consistency in the volumes section.
128-128: LGTM! Consistent terminology in metadata section.The Containerfile reference aligns with the documentation updates throughout the file.
docs/shared/openapis/core.v1.json (2)
32483-32486: LGTM!The description update from "Docker links" to "traditional container linking syntax" appropriately makes the documentation container-agnostic while maintaining technical accuracy.
37024-37024: LGTM - static analysis warnings are false positives.The trailing newline addition follows standard file formatting conventions.
The Checkov warnings (CKV_OPENAPI_4, CKV_OPENAPI_5) about missing security definitions are false positives in this context—this file is a Kubernetes core API schema that documents existing Kubernetes objects, not a custom API specification that requires security field definitions.
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx (4)
9-9: LGTM! Accurate terminology update.The change from "Docker images" to "Dockerfiles" is technically correct, as ENTRYPOINT is defined in Dockerfiles (source) rather than in container images (built artifact). This improves clarity and aligns with the terminology updates throughout the document.
17-17: LGTM! Past review comment addressed.This change correctly addresses the previous review feedback about terminology mixing. ENTRYPOINT is indeed a Dockerfile instruction, and the updated wording now accurately reflects this.
21-28: LGTM! Consistent terminology throughout the section.The section title, explanatory sentence, and table header have been updated consistently from Docker-specific terminology to Dockerfile-specific terminology. This creates a clear and accurate mapping between Dockerfile instructions (ENTRYPOINT, CMD) and their corresponding Kubernetes fields (command, args).
51-51: LGTM! Improved container-agnostic terminology.The change from "Docker Image" to "Container Image" makes the terminology more container-agnostic while accurately distinguishing between build-time artifacts (Dockerfiles) and runtime artifacts (container images). This aligns well with the PR's objective of replacing Docker-specific terminology.
docs/en/developer/building_application/application_workloads/statefulset_create.mdx (1)
121-121: LGTM! Consistent terminology update.The change from
docker-registry-projectnametoregistry-projectnameis consistent with the update in cronjob_create.mdx and appropriately removes Docker-specific terminology.docs/en/developer/building_application/application_workloads/cronjob_create.mdx (1)
79-79: LGTM! Terminology update improves container-runtime neutrality.The change from
docker-registry-projectnametoregistry-projectnameappropriately removes Docker-specific terminology, making the documentation more container-runtime agnostic. Verification confirms no remainingdocker-registryreferences exist in the documentation, ensuring consistency across all documentation.docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx (1)
82-82: LGTM - formatting cleanup.The removal of the trailing comment appears to be a documentation cleanup. The peer list configuration remains functionally intact.
yinshuxun
force-pushed
the
feat/acp-md-docker-keyword
branch
from
0dfb4c9 to
1885481
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
docs/en/developer/registry/how_to/common_cli_command.mdx (1)
69-69: Hyphenation issue persists."command line tool" should be hyphenated as "command-line tool" when used as a compound modifier before a noun.
🧹 Nitpick comments (1)
docs/en/developer/building_application/configuration/add_secret.mdx (1)
76-76: LGTM - Heading updated appropriately.The section heading now uses container-runtime-agnostic terminology while the kubectl subcommand on line 79 correctly retains
docker-registry(as it's the actual kubectl command name).Optional: Consider hyphenating the compound adjective.
Based on learnings, static analysis suggests "container-registry-type Secret" for proper grammar, though the current form is clear and commonly used.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (32)
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx(3 hunks)docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx(3 hunks)docs/en/developer/building_application/application_workloads/cronjob_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deamonset_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deployment_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/pod.mdx(1 hunks)docs/en/developer/building_application/application_workloads/statefulset_create.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_parameters.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_startup_commands.mdx(2 hunks)docs/en/developer/building_application/configuration/add_secret.mdx(4 hunks)docs/en/developer/building_application/create_applications/image_app.mdx(1 hunks)docs/en/developer/building_application/create_applications/oam_app.mdx(2 hunks)docs/en/developer/building_application/create_applications/yaml_app.mdx(1 hunks)docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx(3 hunks)docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx(2 hunks)docs/en/developer/building_application/working_with_helm_charts.mdx(1 hunks)docs/en/developer/images/how_to/creating_images.mdx(4 hunks)docs/en/developer/images/how_to/managing_images.mdx(3 hunks)docs/en/developer/images/overview.mdx(1 hunks)docs/en/developer/oam_applications/concepts/component.mdx(1 hunks)docs/en/developer/quick_start/quick_start_app.mdx(3 hunks)docs/en/developer/registry/how_to/common_cli_command.mdx(1 hunks)docs/en/developer/registry/install/install_via_web_ui.mdx(2 hunks)docs/en/networking/operators/alb_operator/modsecurity.mdx(1 hunks)docs/en/networking/operators/alb_operator/understanding_alb.mdx(1 hunks)docs/en/observability/inspection/functions/inspection.mdx(1 hunks)docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx(3 hunks)docs/shared/openapis/apps.v1.json(2 hunks)docs/shared/openapis/batch.v1.json(2 hunks)docs/shared/openapis/core.v1.json(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx
🚧 Files skipped from review as they are similar to previous changes (16)
- docs/en/observability/inspection/functions/inspection.mdx
- docs/en/developer/building_application/create_applications/yaml_app.mdx
- docs/en/developer/quick_start/quick_start_app.mdx
- docs/en/developer/building_application/working_with_helm_charts.mdx
- docs/en/developer/building_application/application_workloads/cronjob_create.mdx
- docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
- docs/en/developer/building_application/application_workloads/deamonset_create.mdx
- docs/en/developer/building_application/application_workloads/pod.mdx
- docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx
- docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx
- docs/en/developer/oam_applications/concepts/component.mdx
- docs/en/developer/building_application/create_applications/oam_app.mdx
- docs/en/networking/operators/alb_operator/modsecurity.mdx
- docs/en/developer/building_application/concepts/understanding_parameters.mdx
- docs/en/developer/registry/install/install_via_web_ui.mdx
- docs/en/networking/operators/alb_operator/understanding_alb.mdx
🧰 Additional context used
🪛 Checkov (3.2.334)
docs/shared/openapis/apps.v1.json
[high] 1-16385: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-16385: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/core.v1.json
[high] 1-37024: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-37024: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/batch.v1.json
[high] 1-9629: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-9629: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
🪛 Gitleaks (8.30.0)
docs/en/developer/building_application/configuration/add_secret.mdx
[high] 95-95: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 LanguageTool
docs/en/developer/building_application/configuration/add_secret.mdx
[grammar] ~76-~76: Use a hyphen to join words.
Context: ...in ## Creating a container registry type Secret shell kubectl create sec...
(QB_NEW_EN_HYPHEN)
docs/en/developer/images/how_to/managing_images.mdx
[style] ~19-~19: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...determine if the image should be pulled prior to starting the container. There are three...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx
[style] ~19-~19: ‘in conjunction with’ might be wordy. Consider a shorter alternative.
Context: ...ess (PID 1) inside the container - Work in conjunction with parameters (args) to form the complete ...
(EN_WORDINESS_PREMIUM_IN_CONJUNCTION_WITH)
docs/en/developer/images/how_to/creating_images.mdx
[style] ~41-~41: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ss, and everything works as you expect. If you did not use exec in your wrapper ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
docs/en/developer/images/overview.mdx
[style] ~46-~46: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ic SHA identifier always references the exact same container image content. For example: `...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
docs/en/developer/registry/how_to/common_cli_command.mdx
[grammar] ~69-~69: Use a hyphen to join words.
Context: ...istry using a standard container command line tool such as podman. ```bash # Tag...
(QB_NEW_EN_HYPHEN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Pipelines as Code CI / doc-pr-build-container-platform
🔇 Additional comments (24)
docs/en/developer/building_application/create_applications/image_app.mdx (1)
30-30: LGTM! Successfully removes Docker-specific terminology.The change from
docker-registry-projectnametoregistry-projectnamemakes the documentation more container-runtime-agnostic, which aligns with the PR objectives.docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx (3)
24-24: LGTM - Docker-specific naming removed.The secret name has been successfully updated to use container-runtime-agnostic terminology.
27-27: LGTM - Documentation updated consistently.The explanation correctly references the updated secret name.
37-37: LGTM - Example output updated consistently.The example output correctly reflects the updated secret name, maintaining consistency throughout the document.
docs/en/developer/building_application/configuration/add_secret.mdx (4)
37-37: LGTM - Terminology generalized successfully.The description now uses container-runtime-agnostic language while maintaining clarity.
79-84: LGTM - Command updated with generic example values.The secret name and registry URL have been successfully updated to use generic examples rather than Docker-specific values. The kubectl subcommand
docker-registryis correctly preserved as it's the actual command name.
92-110: LGTM - YAML example and explanation updated consistently.The secret name, registry URL, and terminology have been successfully updated throughout the example. The base64-encoded data is example content (as per static analysis hints, this is a false positive for credential detection).
118-118: LGTM - Usage example consistent with definition.The imagePullSecrets reference correctly uses the updated secret name, completing the example documentation flow.
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx (2)
21-28: LGTM!The section clearly explains the relationship between Dockerfile instructions (ENTRYPOINT, CMD) and Kubernetes fields (command, args). The terminology is standard and widely understood by developers.
51-51: LGTM!The terminology update from "Docker Image" to "Container Image" aligns with the PR objective to use container-runtime-agnostic wording while maintaining clarity.
docs/en/developer/images/overview.mdx (1)
34-48: LGTM! Simplified image references improve readability.The shortened image references (removing the
docker.io/alauda/prefix) make the examples cleaner and easier to follow while maintaining clarity about the image being referenced.docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx (2)
17-19: LGTM! Container-runtime-agnostic approach improves flexibility.The update to support multiple container runtimes (Podman or Containerd) rather than requiring Docker specifically is a good practice and aligns with modern container tooling standards.
185-187: LGTM! Consistent use of Podman throughout.The migration from Docker to Podman in the deployment instructions is consistent with the earlier prerequisite changes and provides a unified approach throughout the document.
docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx (2)
62-98: LGTM! Consistent Podman migration across all deployment commands.The comprehensive update from Docker to Podman commands (including
podman images,podman runfor both Leader and follower nodes) ensures consistency throughout the container deployment section.
306-310: LGTM! Cleanup commands updated to match deployment tooling.The uninstall section now consistently uses Podman commands (
podman stop/podman rm), matching the deployment method described earlier in the document.docs/en/developer/images/how_to/managing_images.mdx (1)
11-56: LGTM! Editorial improvements and terminology updates enhance clarity.The refinements to wording and punctuation improve readability, while the migration from Docker-specific references to Podman in the pull secrets section (line 40) aligns with the PR's objective of adopting container-runtime-agnostic terminology.
docs/en/developer/images/how_to/creating_images.mdx (2)
41-104: LGTM! Comprehensive migration to Podman commands.The systematic replacement of Docker commands (
docker run,docker build,docker ps,docker inspect,docker exec) with their Podman equivalents is thorough and maintains the clarity of the examples throughout the document.
130-130: Verify Docker documentation reference is intentional.Line 130 links to Docker's Dockerfile reference documentation. Given the PR's objective to migrate from Docker-specific to Podman/container-runtime-agnostic terminology, and the past review comment from user tossmilestone ("改错了" - changed incorrectly), please confirm whether:
- This link should remain as Docker documentation (since Dockerfile/Containerfile formats are compatible)
- This should link to Podman/OCI Containerfile documentation instead
- A clarifying note should be added about format compatibility
Based on the past review discussion, this was marked as addressed in commit 0dfb4c9, but the user comment suggests there may still be a concern about this approach.
docs/shared/openapis/batch.v1.json (2)
6727-6729: ClarifiedenableServiceLinksdescription looks goodWording is now runtime-agnostic while still describing the legacy env var behavior accurately. No schema impact.
9629-9629: Trailing newline / EOF formattingFinal brace plus trailing newline is fine and keeps the file well‑formed JSON; no further changes needed.
docs/shared/openapis/apps.v1.json (1)
13482-13485: LGTM!The terminology update from Docker-specific language to "traditional container linking syntax" appropriately generalizes the description while maintaining accuracy. This aligns well with the PR objective of making the documentation container-runtime-agnostic.
docs/shared/openapis/core.v1.json (2)
32483-32486: LGTM!The terminology update from "Docker links" to "traditional container linking syntax" appropriately makes the documentation container-runtime-agnostic, which is consistent with the broader Kubernetes ecosystem moving away from Docker-specific terminology.
37024-37024: Static analysis hints are false positives — no action needed.The Checkov warnings (CKV_OPENAPI_4, CKV_OPENAPI_5) about missing security fields are not applicable here. This file documents Kubernetes API data model schemas (io.k8s.api.core.v1), not a service API specification requiring authentication rules.
docs/en/developer/building_application/application_workloads/statefulset_create.mdx (1)
121-121: LGTM! Consistent terminology update.The terminology change is identical to the update in
deployment_create.mdx, ensuring consistency across different workload documentation. The removal of Docker-specific references makes the documentation more universally applicable.
yinshuxun
force-pushed
the
feat/acp-md-docker-keyword
branch
from
1885481 to
8569704
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
docs/en/developer/building_application/application_workloads/deployment_create.mdx (1)
108-108: LGTM - Consistent with approved terminology update.The change from
docker-registry-projectnametoregistry-projectnamein the Integration Project Name example makes the documentation container-runtime agnostic, as noted in the previous review approval.docs/en/developer/quick_start/quick_start_app.mdx (1)
91-92: The registry ambiguity issue remains unresolved.The previous review flagged that shorthand image references like
library/nginx:latestcreate ambiguity for new users. While the current change simplifies this tonginx:latest, it doesn't address the core concerns:
- Still Docker Hub-specific:
nginx:latestwithout a registry prefix assumes Docker Hub as the default registry, which may not be configured in all environments.- No clarification provided: The documentation doesn't explain that this is shorthand or what happens when the default registry isn't available.
- Inconsistent with PR goals: The PR aims for registry-agnostic terminology, but
nginx:latestremains Docker Hub shorthand.- Target audience risk: New users (line 17) may fail to pull images if Docker Hub isn't accessible or configured.
Consider the previously suggested approaches:
- Use fully qualified registry paths (e.g.,
index.docker.io/library/nginx:latest)- Add explicit clarification that
nginx:latestis Docker Hub shorthand- Provide examples from multiple registries for true registry-agnostic guidance
🧹 Nitpick comments (4)
docs/en/developer/registry/how_to/common_cli_command.mdx (1)
69-69: Address the hyphenation issue flagged in previous review.The phrase "command line tool" should be hyphenated as "command-line tool" when used as a compound modifier. This was previously flagged and confirmed by static analysis.
Apply this diff:
-You need to first tag (tag) the local image with the address and namespace format of the target Registry using a standard container command line tool such as podman. +You need to first tag (tag) the local image with the address and namespace format of the target Registry using a standard container command-line tool such as podman.Based on static analysis hints.
docs/en/developer/images/how_to/managing_images.mdx (1)
19-19: Optional: Consider simplifying "prior to" for conciseness.The phrase "prior to starting" could be shortened to "before starting" for improved readability.
Apply this diff to simplify the wording:
-When Alauda Container Platform creates containers, it uses the container `imagePullPolicy` to determine if the image should be pulled prior to starting the container. There are three possible values for `imagePullPolicy`: +When Alauda Container Platform creates containers, it uses the container `imagePullPolicy` to determine if the image should be pulled before starting the container. There are three possible values for `imagePullPolicy`:Based on static analysis hints.
docs/en/developer/images/how_to/creating_images.mdx (1)
41-41: Docker→Podman terminology updated correctly.The replacement of Docker commands with Podman equivalents is appropriate and consistent with the PR objectives.
Optionally, consider rewording to reduce repetitive sentence structure. Three consecutive sentences begin with "If," which slightly affects readability:
-If you have a wrapper script that starts a process for some server. You start your container, for example, using `podman run -i`, which runs the wrapper script, which in turn starts your process. If you want to close your container with `CTRL+C`. If your wrapper script used `exec` to start the server process, `podman` sends SIGINT to the server process, and everything works as you expect. If you did not use `exec` in your wrapper script, `podman` sends SIGINT to the process for the wrapper script and your process keeps running like nothing happened. +Consider a wrapper script that starts a process for some server. You start your container using `podman run -i`, which runs the wrapper script, which in turn starts your process. When you want to close your container with `CTRL+C`, the behavior depends on whether your wrapper script used `exec`. If it did, `podman` sends SIGINT to the server process, and everything works as expected. Otherwise, `podman` sends SIGINT to the wrapper script process, and your server keeps running like nothing happened.docs/en/developer/building_application/configuration/add_secret.mdx (1)
76-76: Consider hyphenating compound adjective.The grammar checker suggests hyphenating "container registry type" to "container-registry type" for compound adjective clarity. This is a minor style consideration.
Apply this diff if you choose to address it:
-## Creating a container registry type Secret +## Creating a container-registry type Secret
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (32)
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx(3 hunks)docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx(3 hunks)docs/en/developer/building_application/application_workloads/cronjob_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deamonset_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deployment_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/pod.mdx(1 hunks)docs/en/developer/building_application/application_workloads/statefulset_create.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_parameters.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_startup_commands.mdx(2 hunks)docs/en/developer/building_application/configuration/add_secret.mdx(4 hunks)docs/en/developer/building_application/create_applications/image_app.mdx(1 hunks)docs/en/developer/building_application/create_applications/oam_app.mdx(2 hunks)docs/en/developer/building_application/create_applications/yaml_app.mdx(1 hunks)docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx(3 hunks)docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx(2 hunks)docs/en/developer/building_application/working_with_helm_charts.mdx(1 hunks)docs/en/developer/images/how_to/creating_images.mdx(4 hunks)docs/en/developer/images/how_to/managing_images.mdx(3 hunks)docs/en/developer/images/overview.mdx(1 hunks)docs/en/developer/oam_applications/concepts/component.mdx(1 hunks)docs/en/developer/quick_start/quick_start_app.mdx(3 hunks)docs/en/developer/registry/how_to/common_cli_command.mdx(1 hunks)docs/en/developer/registry/install/install_via_web_ui.mdx(2 hunks)docs/en/networking/operators/alb_operator/modsecurity.mdx(1 hunks)docs/en/networking/operators/alb_operator/understanding_alb.mdx(1 hunks)docs/en/observability/inspection/functions/inspection.mdx(1 hunks)docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx(3 hunks)docs/shared/openapis/apps.v1.json(2 hunks)docs/shared/openapis/batch.v1.json(2 hunks)docs/shared/openapis/core.v1.json(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (17)
- docs/en/developer/building_application/application_workloads/deamonset_create.mdx
- docs/en/developer/oam_applications/concepts/component.mdx
- docs/en/developer/building_application/create_applications/image_app.mdx
- docs/en/networking/operators/alb_operator/understanding_alb.mdx
- docs/en/developer/building_application/create_applications/yaml_app.mdx
- docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx
- docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx
- docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx
- docs/en/developer/building_application/concepts/understanding_parameters.mdx
- docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx
- docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx
- docs/en/developer/building_application/application_workloads/pod.mdx
- docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx
- docs/en/networking/operators/alb_operator/modsecurity.mdx
- docs/en/developer/registry/install/install_via_web_ui.mdx
- docs/en/observability/inspection/functions/inspection.mdx
- docs/en/developer/building_application/create_applications/oam_app.mdx
🧰 Additional context used
🪛 Checkov (3.2.334)
docs/shared/openapis/apps.v1.json
[high] 1-16385: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-16385: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/core.v1.json
[high] 1-37024: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-37024: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/batch.v1.json
[high] 1-9629: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-9629: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
🪛 Gitleaks (8.30.0)
docs/en/developer/building_application/configuration/add_secret.mdx
[high] 95-95: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 LanguageTool
docs/en/developer/images/how_to/creating_images.mdx
[style] ~41-~41: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ss, and everything works as you expect. If you did not use exec in your wrapper ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
docs/en/developer/images/how_to/managing_images.mdx
[style] ~19-~19: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...determine if the image should be pulled prior to starting the container. There are three...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
docs/en/developer/images/overview.mdx
[style] ~46-~46: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ic SHA identifier always references the exact same container image content. For example: `...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
docs/en/developer/registry/how_to/common_cli_command.mdx
[grammar] ~69-~69: Use a hyphen to join words.
Context: ...istry using a standard container command line tool such as podman. ```bash # Tag...
(QB_NEW_EN_HYPHEN)
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx
[style] ~19-~19: ‘in conjunction with’ might be wordy. Consider a shorter alternative.
Context: ...ess (PID 1) inside the container - Work in conjunction with parameters (args) to form the complete ...
(EN_WORDINESS_PREMIUM_IN_CONJUNCTION_WITH)
docs/en/developer/building_application/configuration/add_secret.mdx
[grammar] ~76-~76: Use a hyphen to join words.
Context: ...in ## Creating a container registry type Secret shell kubectl create sec...
(QB_NEW_EN_HYPHEN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Pipelines as Code CI / doc-pr-build-container-platform
🔇 Additional comments (24)
docs/en/developer/building_application/application_workloads/cronjob_create.mdx (1)
79-79: LGTM - Consistent documentation update.The Integration Project Name example update to
registry-projectnamealigns with the container-runtime-agnostic terminology changes applied consistently across the workload creation documentation.docs/en/developer/building_application/application_workloads/statefulset_create.mdx (1)
121-121: LGTM - Completes consistent documentation update.The Integration Project Name example update to
registry-projectnamemaintains consistency with the terminology changes in Deployment and CronJob documentation, successfully achieving container-runtime neutrality across all workload creation guides.docs/en/developer/quick_start/quick_start_app.mdx (1)
81-81: LGTM: Formatting adjustment.The whitespace adjustment around "Initiate new integration:" improves consistency.
docs/en/developer/registry/how_to/common_cli_command.mdx (1)
69-77: LGTM! Docker-to-Podman migration looks good.The updates from
dockertopodmanin both the descriptive text and code examples are correct and align with the PR's objective of adopting container-runtime-agnostic terminology.docs/en/developer/building_application/working_with_helm_charts.mdx (1)
222-229: LGTM! Podman command replacements are correct.All Docker commands have been properly replaced with their Podman equivalents (
pull,save,load,tag,push). The workflow remains functionally identical, and the changes align with the PR's objective of adopting container-runtime-agnostic tooling.docs/shared/openapis/core.v1.json (2)
32483-32486: LGTM!The updated description appropriately removes Docker-specific terminology and uses container-runtime-agnostic wording ("traditional container linking syntax"), which aligns with the PR objective and is consistent with similar changes in
apps.v1.jsonandbatch.v1.json.
37024-37024: LGTM!The trailing newline addition is good practice for text files.
Regarding the Checkov hints (CKV_OPENAPI_4, CKV_OPENAPI_5): These are false positives. This file documents Kubernetes core API schemas where security is handled at the Kubernetes runtime level, not defined within the OpenAPI schema documentation itself.
docs/en/developer/images/how_to/managing_images.mdx (1)
40-42: LGTM! Container-runtime-agnostic terminology improves documentation clarity.The shift from Docker-specific references to Podman and generic "container clients" aligns with modern Kubernetes practices where the container runtime is abstracted. This makes the documentation more accurate and future-proof.
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx (1)
162-162: LGTM! Consistent Docker → Podman migration.The command update from
docker pulltopodman pullis consistent with the broader documentation modernization effort across this PR.docs/shared/openapis/batch.v1.json (2)
6727-6727: Runtime‑agnostic enableServiceLinks wording looks goodThe new description drops the Docker‑specific reference while keeping the behavior clear and matches the overall doc goal; no schema impact.
9629-9629: EOF newline addition is fineEnding the JSON with a newline is conventional and has no effect on tooling.
docs/shared/openapis/apps.v1.json (2)
13482-13484: LGTM! Good terminology update.The change from "Docker links" to "traditional container linking syntax" makes the documentation more container-runtime-agnostic, which aligns with the PR objectives.
16385-16385: Static analysis warnings are false positives.The Checkov warnings about missing security fields are not applicable to this file. This is a Kubernetes API object schema definition, not an API service specification that would require security definitions for authentication/authorization.
docs/en/developer/images/how_to/creating_images.mdx (4)
74-74: LGTM: Build command references updated consistently.The replacement of
docker buildwithpodman buildin both examples correctly reflects the container-runtime-agnostic approach.Also applies to: 82-82
86-89: LGTM: Port exposure documentation updated correctly.All Docker command references (
docker run,docker ps,docker inspect) have been appropriately replaced with their Podman equivalents, maintaining consistency with the PR's container-runtime-agnostic approach.
104-104: LGTM: Container access commands updated appropriately.The replacement of
docker execwithpodman execfor local container access, alongsidekubectl execfor cluster access, correctly reflects the container-runtime tooling updates.
130-130: Verify Docker documentation link is intentional.This line still references Docker's Dockerfile documentation, which appears inconsistent with the PR's objective of replacing Docker-specific terminology with container-runtime-agnostic wording. While the LABEL instruction format is standardized and Docker's documentation is canonical, consider whether linking to Podman or OCI documentation would better align with the terminology changes throughout this PR.
Based on past review comments, there appears to be disagreement about this link ("改错了" - "corrected incorrectly"), so please confirm whether keeping the Docker documentation reference here is intentional.
If a change is desired, consider linking to Podman's documentation instead:
-See the [Dockerfile reference](https://docs.docker.com/reference/dockerfile/#label) for more information on the `LABEL` instruction. +See the [Containerfile reference](https://docs.podman.io/en/latest/markdown/podman-build.1.html#label) for more information on the `LABEL` instruction.Or add a clarifying note that Containerfile uses Docker-compatible syntax if keeping the Docker link is preferred.
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx (1)
17-17: LGTM! Terminology successfully updated to be container-runtime-agnostic.The changes effectively replace Docker-specific terminology with container-runtime-agnostic wording throughout the document:
- "Container images" instead of "Docker images"
- Section heading clarified to "Relationship with Dockerfile and Parameters"
- Table headers updated to "Dockerfile" and "Container Image"
These changes achieve the PR objective while maintaining technical accuracy and improving clarity.
Also applies to: 21-21, 23-23, 25-25, 51-51
docs/en/developer/building_application/configuration/add_secret.mdx (6)
37-37: LGTM!Simplifying the heading improves readability while the technical type details remain in the YAML examples.
79-84: LGTM!The command correctly retains the
docker-registrysubcommand (which is the actual kubectl command name), updates the secret name to be more container-agnostic, and uses the example registry URL as requested in previous review feedback.
92-92: LGTM!The secret name has been consistently updated throughout the examples.
97-97: LGTM!Removing "Docker" from the description makes the documentation more container-runtime-agnostic while maintaining technical accuracy.
102-102: LGTM!The JSON example correctly reflects the updated registry URL.
118-118: LGTM!The secret reference is consistent with the updated naming throughout the document.
yinshuxun
force-pushed
the
feat/acp-md-docker-keyword
branch
from
8569704 to
f8ad6d5
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx (1)
78-87: Inconsistent command - still usingdocker pushinstead ofpodman push.Line 87 still uses
docker pushwhile line 60 correctly usespodman push. This inconsistency breaks the PR's objective of replacing Docker commands with Podman equivalents throughout the documentation.🔎 Apply this fix
- docker push build-harbor.example.cn/3rdparty/vmdisks/win-virtio:latest # Replace the repository according to your actual environment + podman push build-harbor.example.cn/3rdparty/vmdisks/win-virtio:latest # Replace the repository according to your actual environmentdocs/en/developer/images/how_to/managing_images.mdx (1)
63-63: Update example secret name to use container-agnostic terminology.The example secret name
default-dockercfg-123456contains Docker-specific terminology ("dockercfg"), which is inconsistent with the PR's objective to replace Docker-specific terms. Consider using a container-agnostic name likedefault-regcfg-123456or similar.🔎 Apply this diff to use container-agnostic terminology:
-- name: default-dockercfg-123456 +- name: default-regcfg-123456
♻️ Duplicate comments (2)
docs/en/developer/registry/how_to/common_cli_command.mdx (1)
69-73: LGTM! Podman terminology update is correct.The update from
docker tagtopodman tagat line 73 and the corresponding text update at line 69 correctly align with the PR's objective.Note: The hyphenation issue in "command line tool" (should be "command-line tool") was flagged in a previous review.
docs/en/developer/building_application/configuration/add_secret.mdx (1)
95-95: Base64 data contains outdated registry URL.The base64-encoded
.dockerconfigjsonat line 95 decodes tohttps://index.docker.io/v1/, but the JSON example at line 102 showshttps://registry.example.com. This mismatch was flagged in a previous review but remains unresolved. The base64 string needs to be regenerated to match the example registry URL.🔎 Regenerate the base64 value to match the example
First, create the correct JSON:
{ "auths": { "https://registry.example.com": { "username": "myuser", "password": "mypass", "email": "my@example.com", "auth": "bXl1c2VyOm15cGFzcw==" } } }Then encode it:
echo -n '{"auths":{"https://registry.example.com":{"username":"myuser","password":"mypass","email":"my@example.com","auth":"bXl1c2VyOm15cGFzcw=="}}}' | base64 -w 0Update line 95 with the new base64 value.
🧹 Nitpick comments (2)
docs/en/developer/images/how_to/managing_images.mdx (2)
42-44: Consider clarifying which configuration files are referenced.These lines mention that container clients use configuration files but don't specify which files or provide examples. For Podman, this would typically be
${XDG_RUNTIME_DIR}/containers/auth.jsonor~/.config/containers/auth.json. Adding concrete examples would improve clarity for users.
19-19: Optional: Simplify "prior to" → "before".Static analysis suggests that "prior to" could be simplified to "before" for better readability.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (28)
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx(1 hunks)docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx(3 hunks)docs/en/developer/building_application/application_workloads/cronjob_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deamonset_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/deployment_create.mdx(1 hunks)docs/en/developer/building_application/application_workloads/pod.mdx(1 hunks)docs/en/developer/building_application/application_workloads/statefulset_create.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_parameters.mdx(1 hunks)docs/en/developer/building_application/concepts/understanding_startup_commands.mdx(2 hunks)docs/en/developer/building_application/configuration/add_secret.mdx(4 hunks)docs/en/developer/building_application/create_applications/image_app.mdx(1 hunks)docs/en/developer/building_application/create_applications/oam_app.mdx(2 hunks)docs/en/developer/building_application/create_applications/yaml_app.mdx(1 hunks)docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx(3 hunks)docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx(2 hunks)docs/en/developer/building_application/working_with_helm_charts.mdx(1 hunks)docs/en/developer/images/how_to/creating_images.mdx(4 hunks)docs/en/developer/images/how_to/managing_images.mdx(3 hunks)docs/en/developer/images/overview.mdx(1 hunks)docs/en/developer/oam_applications/concepts/component.mdx(1 hunks)docs/en/developer/quick_start/quick_start_app.mdx(3 hunks)docs/en/developer/registry/how_to/common_cli_command.mdx(1 hunks)docs/en/developer/registry/install/install_via_web_ui.mdx(2 hunks)docs/en/observability/inspection/functions/inspection.mdx(1 hunks)docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx(3 hunks)docs/shared/openapis/apps.v1.json(2 hunks)docs/shared/openapis/batch.v1.json(2 hunks)docs/shared/openapis/core.v1.json(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- docs/en/developer/building_application/application_workloads/statefulset_create.mdx
🚧 Files skipped from review as they are similar to previous changes (11)
- docs/en/developer/building_application/concepts/understanding_parameters.mdx
- docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx
- docs/en/developer/building_application/create_applications/yaml_app.mdx
- docs/en/developer/registry/install/install_via_web_ui.mdx
- docs/en/developer/oam_applications/concepts/component.mdx
- docs/en/developer/building_application/application_workloads/deamonset_create.mdx
- docs/en/developer/building_application/working_with_helm_charts.mdx
- docs/en/developer/building_application/application_workloads/deployment_create.mdx
- docs/en/developer/building_application/create_applications/image_app.mdx
- docs/en/observability/inspection/functions/inspection.mdx
- docs/en/developer/quick_start/quick_start_app.mdx
🧰 Additional context used
🪛 Checkov (3.2.334)
docs/shared/openapis/core.v1.json
[high] 1-37024: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-37024: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/apps.v1.json
[high] 1-16385: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-16385: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
docs/shared/openapis/batch.v1.json
[high] 1-9629: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[high] 1-9629: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
🪛 LanguageTool
docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx
[grammar] ~32-~32: Ensure spelling is correct
Context: ...storage (e.g., /var/lib/kubelet). - imagefs: Used by the container runtime for im...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
docs/en/developer/images/how_to/creating_images.mdx
[style] ~41-~41: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ss, and everything works as you expect. If you did not use exec in your wrapper ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
docs/en/developer/building_application/concepts/understanding_startup_commands.mdx
[style] ~19-~19: ‘in conjunction with’ might be wordy. Consider a shorter alternative.
Context: ...ess (PID 1) inside the container - Work in conjunction with parameters (args) to form the complete ...
(EN_WORDINESS_PREMIUM_IN_CONJUNCTION_WITH)
docs/en/developer/building_application/configuration/add_secret.mdx
[grammar] ~76-~76: Use a hyphen to join words.
Context: ...in ## Creating a container registry type Secret shell kubectl create sec...
(QB_NEW_EN_HYPHEN)
docs/en/developer/images/how_to/managing_images.mdx
[style] ~19-~19: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...determine if the image should be pulled prior to starting the container. There are three...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
docs/en/developer/images/overview.mdx
[style] ~46-~46: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ic SHA identifier always references the exact same container image content. For example: `...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
docs/en/developer/registry/how_to/common_cli_command.mdx
[grammar] ~69-~69: Use a hyphen to join words.
Context: ...istry using a standard container command line tool such as podman. ```bash # Tag...
(QB_NEW_EN_HYPHEN)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Pipelines as Code CI / doc-pr-build-container-platform
🔇 Additional comments (20)
docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx (4)
25-27: Good addition of eviction behavior context.This note clearly explains the pod lifecycle during eviction, helping administrators understand the impact of resource reclamation policies.
32-32: Appropriate generalization to container-agnostic terminology.The updated description correctly focuses on the logical purpose of
imagefs(storing images and writable layers) rather than implementation-specific paths, aligning with the container-runtime agnostic approach.
34-36: Valuable technical constraint documented.This note appropriately highlights the prerequisites for pod disk usage limitations, helping administrators understand when disk-based resource controls will be effective.
130-132: Helpful clarification of eviction sequence.This note correctly explains that garbage collection is attempted before pod eviction, providing users with important context about the node's resource reclamation strategy.
docs/shared/openapis/batch.v1.json (1)
6727-6729: Description wording aligns with container‑agnostic goalThe updated
enableServiceLinksdescription correctly removes Docker‑specific terminology while preserving meaning and behavior. No further changes needed here.docs/shared/openapis/apps.v1.json (1)
13483-13483: LGTM! Documentation terminology updated appropriately.The change from "Docker links" to "traditional container linking" makes the description more container-runtime agnostic, which aligns with the PR's objective to replace Docker-specific terminology.
docs/shared/openapis/core.v1.json (2)
32483-32485: LGTM!The terminology update from Docker-specific language to "traditional container linking syntax" is accurate and aligns with the PR objective of using container-agnostic terminology throughout the documentation.
37024-37024: Static analysis warnings are false positives.The Checkov warnings (CKV_OPENAPI_4, CKV_OPENAPI_5) about missing security definitions don't apply here. This file is a Kubernetes API schema documenting resource object structures (e.g.,
io.k8s.api.core.v1.*types), not an API specification defining endpoints that require authentication configuration. These rules are intended for REST API definitions, not Kubernetes object schemas.docs/en/developer/building_application/concepts/understanding_startup_commands.mdx (1)
17-17: LGTM! Terminology updates are accurate and consistent.The changes successfully replace Docker-specific terminology with container-agnostic language while maintaining technical accuracy:
- "container images" correctly refers to the runtime artifacts that contain ENTRYPOINT metadata
- "Dockerfile" properly distinguishes the build-time instructions from the resulting images
- Table headers and section titles are now more precise and aligned with Kubernetes documentation conventions
Note: The static analysis hint about "in conjunction with" on line 19 can be safely ignored—this phrasing is appropriate and precise for technical documentation.
Also applies to: 21-21, 23-23, 25-25, 51-51
docs/en/developer/building_application/create_applications/oam_app.mdx (1)
59-59: The change fromdocker pulltopodman pullis technically sound—both commands are functionally equivalent for image pulling operations. However, the documentation should clarify tool availability. The current text simply instructs users to "Execute thepodman pullcommand to verify" without mentioning thatdocker pullis an acceptable alternative or providing guidance on tool installation. Consider adding a note that either command works for verification, or link to podman installation instructions if the platform requires it.docs/en/developer/building_application/application_workloads/cronjob_create.mdx (1)
79-79: LGTM! The update fromdocker-registry-projectnametoregistry-projectnamealigns well with the PR's objective of adopting container-agnostic terminology.Verification confirms the terminology is consistently applied across all related workload creation files (deployment, statefulset, daemonset, and cronjob), with no remaining instances of the old naming pattern. The explanation remains clear and helpful.
docs/en/developer/building_application/application_workloads/pod.mdx (1)
15-15: Past issue already addressed.The redundant phrase "containers (such as containers)" was flagged in a previous review and marked as addressed in commit e18f1e7. No further action needed.
docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx (1)
24-56: LGTM! Secret name updates are consistent.The secret name has been updated from
my-docker-credstomy-registry-credsconsistently throughout the file (lines 24, 27, 37), and the formatting at line 56 has been properly closed. These changes align well with the PR's objective of moving away from Docker-specific naming.docs/en/developer/images/overview.mdx (1)
34-48: Past suggestion about registry prefix in educational examples.A previous review noted that removing the
docker.io/alauda/prefix may reduce educational clarity since this section explains image registries, repositories, and tags. The full image references better illustrate the complete structure for learners.However, this was already reviewed and the decision appears intentional to simplify examples.
docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx (1)
30-63: LGTM! Container image terminology consistently applied.The updates from "Docker Image" to "Container Image" in section titles (lines 30, 63) and the corresponding command updates to use
podman(lines 51, 54, 60) correctly align with the PR's objectives. The code block language tags have also been appropriately updated.docs/en/developer/images/how_to/creating_images.mdx (3)
41-41: LGTM! Podman command examples are clear and consistent.The narrative and examples have been properly updated from Docker to Podman (e.g.,
podman run,podmansends signals, etc.). The explanation of signal handling with wrapper scripts is now correctly contextualized with Podman tooling.
74-89: LGTM! Build commands and CLI references updated to Podman.All Docker CLI references have been consistently updated to Podman equivalents:
docker build→podman build(lines 74, 82)podman ps,podman inspectreferences (lines 87-89)The caching behavior explanation remains accurate with the Podman context.
104-104: LGTM! Container exec command updated.The update from
docker exectopodman execfor local container access is correct, and the guidance to usekubectl execfor cluster-managed containers remains appropriate.docs/en/developer/images/how_to/managing_images.mdx (1)
11-11: LGTM! Terminology updates align with container-agnostic goals.The changes successfully replace Docker-specific terminology with container-agnostic language (e.g., referencing Podman at Line 40, using generic "container" and "registry" terminology throughout). This improves the documentation's applicability across different container runtimes.
Also applies to: 15-15, 19-19, 30-30, 34-34, 36-36, 40-40, 52-52, 55-55, 57-57, 73-73
docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx (1)
162-162: LGTM! Container-agnostic command update.The change from
docker pulltopodman pullcorrectly aligns with the PR's objective of replacing Docker-specific terminology with container-agnostic language. The command syntax is correct, and providing bothcrictlandpodmanalternatives gives users flexibility based on their container runtime.
4 participants
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.