Before reporting an issue, please check the common questions below and feedback to see if the issue already exists.

If you can't find an answer, please submit an issue in feedback.

• Why Didn't the Pipeline Trigger?
• Why Does It Work Locally But Fail in CI?
• How to Log into Pipeline Container for Debugging?
• Why Do Script Results Differ Between Pipeline Execution and Login Debugging?
• No Output Timeout
• Why Did Pipeline Fail Without Code Changes?
  • Code Merge Conflicts
  • View Full Logs
• Why Fixed Outbound IPs Are Not Provided
• How to Build Multi-Architecture/Multi-Platform Images

Why Didn't the Pipeline Trigger?

To troubleshoot pipeline trigger issues, first understand the workflow from trigger to execution.

Taking the push event as an example:

Where skip detection includes ifNewBranch, ifModify, refer to syntax.

You can investigate step by step following this workflow:

1. Was the code pushed to remote?
2. Does the corresponding branch have .cnb.yml?
   1. Whether the files included by include have permissions
   2. The configuration content is free of formatting and syntax issues
3. Does the .cnb.yml declare the push event pipeline for the current branch?
4. Did it hit skip detection?

In CNB, the default branch is usually main, while some repositories migrated from other platforms may have master as the default branch. Please take note of this distinction.

Why Does It Work Locally But Fail in CI?

To troubleshoot this, first clarify the differences between local and CI environments:

	Local	CI Environment
Network	Local network (e.g., office intranet)	CI machine's network
Files	All files in local directory	Git repository branch code
Environment	Native	Specified Docker container environment
Shell	Locally specified	sh

Understanding these differences, we can troubleshoot step by step:

1. Are there uncommitted files?
2. Do build dependency files match .gitignore?
3. Does it rely on resources only available locally (such as local interfaces, credentials, etc.)?
4. The cpus declared in the CI meets the requirements.
5. Run the same image locally to get the same build environment as CI for debugging.

The default image for Cloud Native Build is cnbcool/default-build-env.

You can execute the following command to enter the default CI environment for debugging:

docker run --rm -it -v $(pwd):$(pwd) -w $(pwd) cnbcool/default-build-env sh

If another image is declared as the pipeline build environment, replace cnbcool/default-build-env in the above command with the corresponding image address.

How to Log into Pipeline Container for Debugging?

Refer to Login Debugging

Why Do Script Results Differ Between Pipeline Execution and Login Debugging?

Pipelines use sh by default, while login debugging uses bash.

If you confirm the specified pipeline container supports bash (the default pipeline container does, but custom containers may not), you can change the execution script to bash xxx.sh or bash -c '{original statement}'.

No Output Timeout

If a job has no log output for over 10 minutes, it will be terminated. Consider adding logs, such as using the verbose parameter for npm install.

Note this is different from job timeout declarations and cannot be modified via configuration.

Why Did Pipeline Fail Without Code Changes?

Check if dependent resources have changed, such as:

1. Plugin task declares image version as latest - has the image changed?
2. CI configuration files reference other repository files - have those files changed?
3. Possible network fluctuations - try Rebuild.

Code Merge Conflicts

If you encounter code conflicts when creating a Pull Request (PR) or during the build process related to a PR, you can resolve them using the following commands:

git fetch origin          # Fetch updates from the remote repository
git rebase -i origin/main # Replace with the actual target branch name

# Resolve conflicts locally

git commit  # Commit the changes to the local repository as needed
git push -f # Force push to the remote repository

View Full Logs

The CI service dispatches plugin tasks and script tasks to the Runner for execution. If a task's log exceeds the maximum length, it will be truncated and returned to the CI service.

The Stage consolidates the logs of all tasks under it. If the Stage log is too long, it will also be truncated for better display on the log page.

After the build is completed, you can click the log download button at the top right corner of the pipeline on the log page to view the complete logs.

Why Fixed Outbound IPs Are Not Provided

CNB does not provide fixed outbound IP addresses. The outbound IPs used when accessing external services in the Cloud-Native Build or Cloud-Native Development services may change over time.

This is because:

1. Dynamic IP addresses reduce the risk of targeted attacks. If an outbound IP is under attack or congestion, it can be automatically switched to ensure better security and service quality.
2. We do not recommend setting up any whitelist logic for CNB’s outbound IPs. Since CNB is a publicly accessible platform, malicious attackers could exploit it. Whitelisting CNB’s outbound IPs would essentially be equivalent to whitelisting the entire public network.

If you do need a specific IP range for whitelisting (e.g., for connecting to internal services), consider the following methods:

1. Use a private proxy: Configure a private proxy in your workflow to route your requests through it. This proxy can have a fixed IP address you specify.
2. Use a jump server: Connect to the target machine via SSH using a jump server. You can achieve this with the plugin cnbcool/ssh. Reference example
3. For Tencent Cloud machines: It is recommended to use the tencentcom/tcloud-cmd to remotely execute commands on Cloud Virtual Machines (CVM) and Light Application Servers (Lighthouse). There is no need to apply for a whitelist when using this plugin.

How to Build Multi-Architecture/Multi-Platform Images

To use buildx for building multi-architecture/multi-platform images, you can enable the rootlessBuildkitd feature. This needs to be declared in the services:

main:
  push:
    - docker:
        image: golang:1.24
      services:
        - name: docker
          options:
            rootlessBuildkitd:
              enabled: true
      env:
        IMAGE_TAG: ${CNB_DOCKER_REGISTRY}/${CNB_REPO_SLUG_LOWERCASE}:latest
      stages:
        - name: go build
          script: ./build.sh
        - name: docker login
          script: docker login -u ${CNB_TOKEN_USER_NAME} -p "${CNB_TOKEN}" ${CNB_DOCKER_REGISTRY}
        - name: docker build and push
          script: docker buildx build -t ${IMAGE_TAG} --platform linux/amd64,linux/amd64/v2,linux/amd64/v3,linux/arm64,linux/riscv64,linux/ppc64le,linux/s390x,linux/386,linux/mips64le,linux/mips64,linux/loong64,linux/arm/v7,linux/arm/v6 --push .