What Do I Do If ServiceStage Failed to Build a Job?
There are many causes for software engineering build failures. Troubleshoot them using the following methods.
Build Error After Scheduling Build Job to Containerd Container Engine Node in CCE Cluster
Symptom
The build failed and the build log displays one of the following error messages:
- /proc/sys/user/max_user_namespaces needs to be set to non-zero.
- /proc/sys/user/max_user_namespaces=100 may be low. Consider setting to >= 1024.
Cause Analysis
The build job is scheduled to the Containerd container engine node of the CCE cluster; therefore, rootless is required to ensure build security. During this process, namespaces need to be created. Settings of the node VM must meet the build requirements. However, the default max_user_namespaces of some VM images is 0 or too small. As a result, the build fails and an error is reported.
Solution
- Log in to all Containerd container engine nodes in the cluster where the build job is executed as user root.
- Run the following command to set max_user_namespaces of the VM image to 1024 by default and confirm the setting:
echo 1024 > /proc/sys/user/max_user_namespaces cat /proc/sys/user/max_user_namespaces
- Restart the build job. For details, see Starting a Build Job.
- If the build is successful, no further action is required.
- If the build fails, contact customer service for assistance.
Build Error After Configuring Taint and Tolerance Policy for CCE Cluster Node
Symptom
The build failed and the build log displays this error message:
0/1 nodes are available: 1 node(s) had untolerated taint {node.kubernetes.io/route-unschedulable: }. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.
Cause Analysis
The build job is scheduled to a restricted scheduling node of the CCE cluster, and taint management is configured for the node (as shown by node.kubernetes.io/route-unschedulable in the error). The taint makes the node exclude some pods from its scheduling. This also causes the other nodes in the CCE cluster to be unavailable for scheduling.
Solution
Remove the taint on the restricted scheduling node to ensure that at least one cluster node is available for scheduling. For details, see Managing Node Taints.
Code Cannot Be Pulled
See the following figure.
The possible causes are as follows:
- If an application is built on your own node, the node may not be bound to an EIP. For example, in the preceding figure, node 192.168.x.x is not bound to an EIP. Solution: Bind an EIP to the node. For details, see Assigning an EIP and Binding It to an ECS .
- The authorization information has expired, the private token of the code source has low permission, or the authorization information has been removed. For example, code cannot be obtained from the code source of CodeArts. This may be because the user password used during authorization is incorrect. Solution: Authorize the repository again. For details, see Authorizing a Repository.
- The network between the self-built code source repository and the build node is disconnected. For example, a private Bitbucket is set up on a node in cluster A and the build is performed in cluster B. However, cluster B and cluster A are in different VPCs. As a result, their network is disconnected, and code cannot be pulled up in building. Solution: Connect the network.
Built Code Depends On Private Maven Repository
There are two solutions:
- Create the settings.xml file in the root directory of your project, and specify the private Maven repository address in it. If your private Maven repository needs to be authenticated, configure your authentication information, username, and password in the settings.xml file.
- Specify a private Maven repository in the pom.xml file of your project.
The following shows example paths of the settings.xml and pom.xml files:
Invalid Dockerfile for Source Code Job Building
For details about how to write a Dockerfile, see the official website or ServiceStage template demo.
Project Code Depends On CSE SDK and CodeArts Private Maven Repository
Perform the following steps:
- Create the settings.xml file in the root directory of your project.
- Log in to the CodeArts private dependency repository and select the Maven private dependency repository from the repository list on the left.
- Click in the upper right corner and choose Configuration Guide from the shortcut menu.
- Click Download Configuration File to download the settings.xml file.
- Modify the downloaded settings.xml file as follows:
- Add !HuaweiCloudSDK to <mirrorOf>.
<mirror> <id>z_mirrors</id> <mirrorOf>*,!releases,!snapshots,!HuaweiCloudSDK</mirrorOf> <url>https://repo.hauweicloud.com/repository/maven</url> </mirror>
- Add a Maven repository under <repositories> in <profiles>.
<repository> <id>HuaweiCloudSDK</id> <url>https://repo.huaweicloud.com/repository/maven/huaweicloudsdk/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository>
- Add !HuaweiCloudSDK to <mirrorOf>.
- Place the modified settings.xml file in the root directory of your project and build the job.
Customizing Dockerfile When Creating Software Package Building Job
When you select a software package, the system automatically uploads the software package to the current working directory of the image. The following shows an example Dockerfile:
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot