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 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.