# Docker Image Build Issues
Call yunxiao_flow_get_job_step_log.py to get step logs. Based on the log information and knowledge base, further analyze the root cause and provide solutions. Before analyzing, make sure to clarify the following questions:
* What build machine is the current job using
* Whether the current step has cloned code. Check the "Download Pipeline Source" option in the corresponding job: ["Download All Pipeline Sources", "Do Not Download Pipeline Sources", "Download Partial Pipeline Sources"]
* What branch and commit were used for code cloning

**Note**:
* Build cluster name must NOT be obtained from `params.buildNodeGroup`. It **MUST** be obtained from the "Request Runtime Environment" step logs.
* Job workspace must be obtained from the `PROJECT_DIR` in the Pipeline Cache step

Yunxiao default build clusters are currently only available in three regions: Beijing, Hangzhou, and Hong Kong. Beijing and Hangzhou are in mainland China and cannot directly access overseas repositories. The Hong Kong region can access overseas repositories.
Build cluster sample logs:
```json
[Build Cluster Info]
>> Cluster Name    : Yunxiao China Hong Kong Build Cluster
```
VPC build cluster (managed build cluster), supports Shanghai, Beijing, Shenzhen, Hangzhou, Singapore (ap-southeast-1), sample log:
```json
[Build Cluster Info]
>> Cluster Name    : xxxxx
```
Private build cluster log:
```json
[Runner Group Info]:
>> RunnerGroupId   : xxxxx
>> RunnerGroupName : xxxxx
```

## Job Working Directory
Job workspace must be obtained from the `PROJECT_DIR` in the Pipeline Cache step

## terminalUrl
If the job has debug mode enabled (i.e., the debugPolicy field in the job's params object is not none), you can request the terminalUrl from the user to log into the build machine and execute shell commands to troubleshoot issues and verify solutions. Since the terminalUrl link has a time limit, use `webTerminal.py` to connect first before troubleshooting or solution verification.
**Note**: Executing any upload commands is prohibited. Every command executed and its results must be displayed. Execute `exit` to quit when troubleshooting is complete. Commands need a newline character \n to trigger execution.


## Common Issues
### Dockerfile Not Found
Check if the Dockerfile required by the user exists in the build directory


### no such file or directory
- 1. Check if the contextPath parameter is set
- 2. Determine if this file was generated by a build process, e.g., java build producing jar files, golang build producing executables. If these files are missing, there may have been an issue during the build or the build artifacts are in a different directory
- 3. Check if the corresponding file exists in the downloaded code source
- 4. Check if .dockerignore exists in the downloaded files


### Dockerfile uses ARG instruction but parameters are not received
- 1. Check if --build-arg is set in the build command to pass the corresponding parameters
- 2. When passing parameters via --build-arg, check if the values are set as ${xxxx} format variables. If variables are used, further check if the pipeline variables exist

### Accessing image repository timeout (Client.Timeout) issue
- 1. Yunxiao default public build clusters can only access public networks and non-VPC endpoint services (services accessible by all VPCs). The following cases cannot be accessed:
    * Public build clusters cannot access ACR Enterprise Edition image repositories via internal network
    * Public build clusters cannot access user-built image repositories via internal network
- 2. Check if there are cross-border network paths, as cross-border connections may cause network inaccessibility
- 3. Check if the image repository has the corresponding whitelist configured

### Image push reports Conflict error
- 1. The error indicates a duplicate push of the built image. The user needs to check if there are duplicate images in the image repository
- 2. The error indicates a duplicate push of flow-docker-build-cache. This is the Yunxiao build cache image. Check the cacheType of the corresponding step. Remote cache uses flow-docker-build-cache as the cache image by default. If there is a cache image conflict, it is recommended to change the cache image name or disable caching in the job configuration.

### Error: getDockerAcrEnterPriseCertificate but error: {"username":null, "password":null}
- 1. The RAM authorization for the pipeline ACR service connection is abnormal. Find the pipeline service connection, click "Edit", change the service connection authorization, or click "Re-authorize".

### Error: Get https://flow.aliyun.com/openapi/certificates/dockerAcrPersonal failed, abort request.
Yunxiao uses the AliyunRDCDefaultRole RAM role to access ACR. Deleting this role will cause access anomalies. Follow these steps:
- 1. Find the pipeline service connection, click "Edit", then click "Re-authorize". You will be redirected to the RAM authorization page. Click "Confirm Authorization" to create the AliyunRDCDefaultRole RAM role.
- 2. After creating the role, go back to the pipeline service connection, click "Edit", then click "Re-authorize" to authorize the service connection.

### Push error: failed to solve: failed to push xxxx: server message: insufficient_scope: authorization failed
Run the following command to clean up docker buildx cache on the build machine, then retry the build: `docker buildx prune -af`. GitHub issues: https://github.com/docker/buildx/issues/2364

### Private build machine has local images but build still pulls from dockerhub causing build failure
- Yunxiao builds use `buildkit` by default, which uses the `docker-container` driver. You can switch the driver to `default` for building. Note that `default` does not support remote cache; you need to disable remote cache in the corresponding step.
- Common commands:
  * `docker buildx ls` - List available docker drivers
  * `docker buildx inspect --bootstrap` - Show the default driver for the current context
  * `docker buildx use <NAME/NODE>` - Switch the default driver