Cloud Native Build

Frequently Asked Questions

Before providing feedback, it is recommended to check the common questions below and the feedback section to see if the issue already exists.

If you cannot find an answer, please submit an issue in the feedback section.

# Why is the pipeline not triggering?

To troubleshoot the issue of a pipeline not triggering, it is important to understand the process from triggering to execution of the pipeline.

Taking the push event as an example:

The skip detection includes ifNewBranch and ifModify, refer to the syntax.

You can follow this process step by step to investigate:

  1. Check if the code is pushed to the remote repository.
  2. Verify if the corresponding branch has a .cnb.yml file.
  3. Check if the pipeline is configured for the push event.
  4. Determine if the skip detection conditions are met.

# Why does the code work locally but fail in the CI environment?

To troubleshoot this issue, it is important to understand the differences between the local and CI environments:

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

With an understanding of these differences, you can investigate the following:

  1. Check if there is any resource accessed locally that requires access to an internal network.
  2. Verify if all files are committed.
  3. Check if the files required for the build are ignored by .gitignore.
  4. Run the same image locally to replicate the CI build environment and perform debugging.

The default image for Cloud Native Build is cnbcool/default-build-env (opens new window).

To debug in the default CI environment, you can execute the following command:

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

If you have specified a different image for the pipeline build environment, replace cnbcool/default-build-env in the above command with the corresponding image address.

# How to log in to the pipeline container for debugging?

Refer to Login and Debug

# The script execution in the pipeline and the script execution in the login debug have different results

The default shell used in the pipeline is sh, while the login debug uses bash.

If it is confirmed that the specified pipeline container supports bash (the default pipeline container supports it, but if it is a custom container, it may not), you can modify the execution script to bash xxx.sh or bash -c '{original statement}'.

# Timeout without output

If a job does not produce any log output for more than 10 minutes, it will be terminated. Consider adding logs, for example, for cases like npm install, you can add the verbose parameter.

Note that this is different from the timeout declared for the job and cannot be modified through configuration.

# Why did the pipeline fail without making any code changes?

Check if there are any changes in the dependencies or other resources, such as:

  1. The plugin task declares the image version as latest, and the image has changed.
  2. The CI configuration file references files from other repositories. and the referenced files have changed.
  3. It could be due to network fluctuations, try rebuilding.