CNB (Cloud Native Build) Documentation

website·Indexed 31 days ago

https://w3c.cool

Documentation for CNB, a cloud-native build platform providing code hosting, high-availability repositories, and declarative CI/CD pipelines. It features a YAML-based configuration (.cnb.yml) for managing build environments, pipeline syntax, trigger rules, and built-in tasks. The platform includes tools for repository migration, secret management, role-based access control, and a plugin market for extending build capabilities via Docker images.

Tokens
42.5K
Snippets
175
Records
310
Agent score
56%

What's inside CNB

  1. Overview of CNB Code Hosting Features

    CNB provides a comprehensive code hosting platform designed to remove the limitations and security risks of local code management. Its core capabilities include:

    • High-Availability Repositories: Cloud-based storage ensuring data security with full support for Git version control for local and cloud synchronization.
    • Online Code Browsing: Supports side-by-side and top-bottom comparison modes to visualize changes between commits.
    • Code Review (Pull Requests): Enables line-by-line comparison and commenting, with automatic reviewer assignment during branch merges.
    • Issue Tracking: A system for recording bugs, feature requests, and discussions, supporting labels, priority markers, and comments.
    • Version Management: Automatically generates standardized version numbers for releases and links them to specific tasks or defects to standardize delivery.
    • Branch Protection: Provides granular permission settings at the branch level to ensure orderly team collaboration.
  2. Overview of CNB Keystore

    The Keystore is a secure code repository provided by Cloud Native Build (CNB) specifically designed for storing sensitive information such as passwords, API keys, and certificates. It ensures secure storage and compliant usage through strict access control, page watermarking, and audit tracking.
  3. Overview of Cloud Native Development remote environments

    Cloud Native Development is a remote development solution that allows developers to connect to remote environments via WebIDE, VSCode, or Cursor clients. It features:

    • Declarative environments: Uses Dockerfiles to define the development environment, managed in the same repository as the code.
    • Fast startup: Prepares code and environments in seconds, even for very large repositories.
    • On-demand resource usage: Resources are allocated when needed and reclaimed during idle time to prevent waste.
  4. Overview of CNB Mission Sets

    CNB Mission Sets are project collaboration tools that provide visual task boards. They allow teams to centrally manage Issues and Pull Requests (PRs) across different organizations and repositories.
  5. Overview of W3C Technical Documentation Knowledge Base

    The W3C Technical Documentation knowledge base is a centralized resource for Web development core resources, standard documents, and best practices designed to help developers master modern Web technologies.
  6. Use CNB build and pipeline environment variables

    These variables provide context about the current execution environment and pipeline status:

    • CNB_BUILD_ID: Globally unique build sequence number.
    • CNB_BUILD_WEB_URL: URL to the build logs.
    • CNB_BUILD_START_TIME: Start time in UTC (e.g., Tue, 24 Dec 2024 07:42:58 GMT).
    • CNB_BUILD_USER: Name of the user who triggered the build.
    • CNB_BUILD_USER_ID: ID of the user who triggered the build.
    • CNB_BUILD_STAGE_NAME: Name of the current stage.
    • CNB_BUILD_JOB_NAME: Name of the current job.
    • CNB_BUILD_JOB_KEY: Unique key for the job within the stage.
    • CNB_BUILD_WORKSPACE: Root directory of the custom shell script execution.
    • CNB_BUILD_FAILED_MSG: Error message if the pipeline failed (usable in failStages).
    • CNB_BUILD_FAILED_STAGE_NAME: Name of the stage that failed (usable in failStages).
    • CNB_PIPELINE_NAME: Name of the pipeline.
    • CNB_PIPELINE_KEY: Index key of the pipeline (e.g., pipeline-0).
    • CNB_PIPELINE_ID: Globally unique pipeline ID string.
    • CNB_PIPELINE_DOCKER_IMAGE: The Docker image used for the pipeline (e.g., alpine:latest).
    • CNB_PIPELINE_STATUS: Status of the pipeline: success, error, or cancel (usable in endStages).
    • CNB_RUNNER_IP: IP address of the Runner executing the pipeline.
    • CNB_CPUS: Maximum CPU cores available to the pipeline.
    • CNB_MEMORY: Maximum memory available to the pipeline in GiB.
    • CNB_IS_RETRY: true if the build was triggered by a rebuild.
    • HUSKY_SKIP_INSTALL: Used for Husky compatibility in CI environments.
  7. Select GPU build clusters

    Two types of GPU clusters are available for amd64 architecture:

    1. cnb:arch:amd64:gpu: Fixed at 32 CPUs, maximum 96GB shared GPU memory.
    2. cnb:arch:amd64:gpu:L20: Fixed at 16 CPUs, maximum 48GB shared GPU memory.
  8. Use CNB commit and tag environment variables

    These variables provide metadata about the specific commit or tag triggering the build:

    • CNB_BEFORE_SHA: The SHA of the remote branch before the push (for push, commit.add). Returns 0000000000000000000000000000000000000000 for new branches.
    • CNB_COMMIT: The SHA of the code being built. Logic varies by event (e.g., for pull_request, it is the source branch SHA but the build uses a pre-merged result).
    • CNB_COMMIT_SHORT: The first 8 characters of CNB_COMMIT.
    • CNB_COMMIT_MESSAGE: The full commit message of CNB_COMMIT.
    • CNB_COMMIT_MESSAGE_TITLE: The first line of the commit message.
    • CNB_COMMITTER: The person who made the commit.
    • CNB_COMMITTER_EMAIL: The email of the committer.
    • CNB_NEW_COMMITS_COUNT: Number of new commits (max 99) for commit.add events.
    • CNB_IS_TAG: true if the build is for a Tag.
    • CNB_TAG_MESSAGE: The tag message (if applicable).
    • CNB_TAG_RELEASE_TITLE: The title of the Release associated with the tag.
    • CNB_TAG_RELEASE_DESC: The description of the Release associated with the tag.
    • CNB_TAG_IS_RELEASE: true if the tag has an associated Release.
    • CNB_TAG_IS_PRE_RELEASE: true if the associated Release is a pre-release.
    • CNB_IS_NEW_BRANCH: true if the branch was newly created.
    • CNB_IS_NEW_BRANCH_WITH_UPDATE: true if the branch was newly created and contains new commits.
  9. Understand Cloud Native Build (CNB) Community Edition billing

    The Cloud Native Build Community Edition uses a pay-as-you-go billing model. Billing is settled independently for each top-level organization, and charges for the previous month are deducted at the beginning of the current month.
  10. Use Tencent Cloud Code Assistant in WebIDE

    The Cloud Native Development WebIDE comes with the Tencent Cloud Code Assistant built-in. Developers can use it directly without any additional installation.
  11. Analyze Cloud Native Build errors with AI

    For errors occurring during Cloud Native Build, developers can send the error message to the AI with a single click to receive an analysis and help locate the problem quickly.
  12. Use CNB repository environment variables

    These variables provide information about the target repository:

    • CNB_REPO_SLUG: The repository path (e.g., group/repo).
    • CNB_REPO_SLUG_LOWERCASE: The repository path in lowercase.
    • CNB_REPO_NAME: The name of the repository.
    • CNB_REPO_NAME_LOWERCASE: The repository name in lowercase.
    • CNB_REPO_ID: The unique ID of the repository.
    • CNB_REPO_URL_HTTPS: The HTTPS URL of the repository.