変数とシークレット

概要

Bitbucket Pipelines enables configuration of default and custom variables usable in builds and scripts as environment variables.

Referencing Variables

Variables are accessed as environment variables in the build container:

Linux/macOS:

$AWS_SECRET

Windows runners:

$env:AWS_SECRET

Default Variables

Pipelines provides built-in variables available for all builds:

変数	目的
`CI`	Set to `true` when pipeline runs
`BITBUCKET_BUILD_NUMBER`	Unique, incrementing build identifier
`BITBUCKET_CLONE_DIR`	Repository clone directory path
`BITBUCKET_COMMIT`	Commit hash triggering the build
`BITBUCKET_WORKSPACE`	ワークスペース名
`BITBUCKET_WORKSPACE_UUID`	Workspace UUID
`BITBUCKET_REPO_SLUG`	URL-friendly repository name
`BITBUCKET_REPO_UUID`	Repository UUID
`BITBUCKET_REPO_FULL_NAME`	Full repository name (workspace/repo-slug)
`BITBUCKET_REPO_IS_PRIVATE`	True if the repository is private, otherwise false
`BITBUCKET_BRANCH`	Source branch (branches only)
`BITBUCKET_TAG`	Tag name (tags only)
`BITBUCKET_BOOKMARK`	For use with Mercurial projects
`BITBUCKET_PARALLEL_STEP`	グループ内の現在のステップのゼロベースインデックス。例: 0、1、2、... 並行ステップでのみ使用できます。
`BITBUCKET_PARALLEL_STEP_COUNT`	グループ内のステップの合計数。例: 5。並行ステップでのみ使用できます。
`BITBUCKET_PR_ID`	Pull request ID (PR builds only)
`BITBUCKET_PR_DESTINATION_BRANCH`	Target branch for PR
`BITBUCKET_PR_DESTINATION_COMMIT`	Current commit hash of the destination branch
`BITBUCKET_MERGE_QUEUE_PR_IDS`	Ordered list of IDs of the pull requests currently in the queue
`BITBUCKET_GIT_HTTP_ORIGIN`	URL for the origin, for example: http://bitbucket.org/<workspace>/<repo>
`BITBUCKET_GIT_SSH_ORIGIN`	SSH origin, for example: git@bitbucket.org:/<workspace>/<repo>.git
`BITBUCKET_EXIT_CODE`	The exit code of a step, can be used in after-script sections. Values can be 0 (success) or 1 (failed)
`BITBUCKET_STEP_UUID`	Unique identifier for the step
`BITBUCKET_STEP_TRIGGERER_UUID`	Person who started the build (by completing a push, merge, etc.), and for scheduled builds, the UUID of the pipelines user.
`BITBUCKET_TRIGGER_PIPELINE_UUID`	Unique identifier of the upstream pipeline that triggered the pipeline
`BITBUCKET_TRIGGER_PIPELINE_RUN_UUID`	Unique identifier of the pipeline run that triggered the pipeline
`BITBUCKET_TRIGGER_STEP_UUID`	Unique identifier of the step that triggered the pipeline
`BITBUCKET_TRIGGER_PIPELINE_SELECTOR_TYPE`	Selector type of the pipeline that triggered the pipeline
`BITBUCKET_TRIGGER_PIPELINE_SELECTOR_PATTERN`	Selector pattern of the pipeline that triggered the pipeline
`BITBUCKET_TRIGGER_PIPELINE_STATUS`	Status of the pipeline that triggered the pipeline
`BITBUCKET_TRIGGER_DEPLOYMENT_UUID`	Unique identifier of the deployment that triggered the pipeline
`BITBUCKET_TRIGGER_DEPLOYMENT_STATUS`	Status of the deployment that triggered the pipeline
`BITBUCKET_TRIGGER_DEPLOYMENT_ENVIRONMENT_NAME`	Name of the environment belonging to the deployment that triggered the pipeline
`BITBUCKET_TRIGGER_PACKAGES_PACKAGE_TYPE`	Type of the package, for example CONTAINER or MAVEN
`BITBUCKET_TRIGGER_PACKAGES_PACKAGE_NAME`	Name of the package, for example ubuntu or com.atlassian:my-library
`BITBUCKET_TRIGGER_PACKAGES_ARTIFACT_NAME`	Name of the artifact, for example for Docker containers this is the ID of the manifest, such as manifest:sha256:1646cefe9f37d36912d5a179eabef4a91ace6489377b252fe7dd3eeb062eabab, or for Maven packages it is the version, such as 1.0.0.
`BITBUCKET_TRIGGER_FIX_FLAKY_TEST_TARGET_BRANCH`	Branch that the pull request containing the generated code fix for the flaky test should target. Typically your default branch where the fix needs to land.
`BITBUCKET_TRIGGER_FIX_FLAKY_TEST_SOURCE_BRANCH`	Pre-generated branch name the agent must use to push fixes. This is to be used as the source branch when raising the pull request to ensure linking between the flaky test and the generated pull request.
`BITBUCKET_TRIGGER_TEST_CASE_FQDN`	Fully qualified domain name of the flaky test. Use this to locate the exact test file and method in your codebase that the agent should fix.
`BITBUCKET_TRIGGER_TEST_CASE_UUID`	Unique identifier of the flaky test case that triggered this pipeline. Use this to look up test history, execution details, or call the API.
`BITBUCKET_STEP_OIDC_TOKEN`	ID Token generated by the Bitbucket OIDC provider that identifies the step. This token can be used to access resource servers, such as AWS and GCP without using credentials. Learn more
`BITBUCKET_PIPELINE_UUID`	Unique identifier for the pipeline
`BITBUCKET_DEPLOYMENT_ENVIRONMENT`	デプロイ環境名
`BITBUCKET_DEPLOYMENT_ENVIRONMENT_UUID`	Unique identifier of the environment to access environments via the REST API
`BITBUCKET_PROJECT_KEY`	The project key belonging to the current pipeline
`BITBUCKET_PROJECT_UUID`	Unique identifier of the project belonging to the current pipeline
`BITBUCKET_SSH_KEY_FILE`	The location of the Bitbucket Pipelines private SSH key. This key can be used with BuildKit to access external resources using SSH. この変数は、Bitbucket Cloud と Linux Docker Pipelines ランナー上で実行されているパイプラインでのみ利用できます。
`BITBUCKET_STEP_RUN_NUMBER`	The current step's run number. It helps identify the number of times a particular step has been executed, beginning at 1 for the first execution.
`BITBUCKET_PACKAGES_USERNAME`	The 'username' to authenticate as Bitbucket Pipelines against Bitbucket Packages. This variable is to be used with BITBUCKET_PACKAGES_TOKEN.
`BITBUCKET_PACKAGES_TOKEN`	The 'token' to authenticate as Bitbucket Pipelines against Bitbucket Packages. This variable is to be used with BITBUCKET_PACKAGES_USERNAME.
`DOCKER_HOST`	Host of the step's Docker daemon

Using Default Variables

pipelines:
  default:
    - step:
        script:
          - echo "Building commit $BITBUCKET_COMMIT"
          - echo "Build number $BITBUCKET_BUILD_NUMBER"
          - echo "Branch $BITBUCKET_BRANCH"

User-Defined Variables

Variables can be configured at multiple levels with override hierarchy:

Pipeline > Deployment > Repository > Workspace

Naming Requirements

Alphanumeric characters and underscores only
Case-sensitive
Cannot start with digits
120,000 character value limit

Avoid using PATH variable—it breaks pipeline commands.

Workspace Variables

Accessible across all repository builds. Requires workspace administrator access.

Navigation: Workspace Settings → Pipelines → Workspace variables

Use case: Shared credentials, API keys used across multiple repositories

Repository Variables

Available to users with write access. Requires repository admin to manage.

Location: Repository Settings → Pipelines → Repository variables

Use case: Repository-specific configuration, API endpoints

Deployment Variables

Environment-specific variables override repository and workspace settings.

Location: Repository Settings → Pipelines → Deployments

Use case: Different credentials per environment (staging vs production)

pipelines:
  branches:
    main:
      - step:
          name: Deploy to Production
          deployment: production
          script:
            - echo "API URL: $API_URL"  # Uses production deployment variable

Secured Variables

Sensitive values can be encrypted—marked with a padlock icon. These provide:

Hidden values in build logs
Automatic masking of matching values
URL-encoded variant detection

Secured variables cannot be edited, only replaced or deleted.

Creating Secured Variables

Navigate to Repository Settings → Pipelines → Repository variables
Click "Add variable"
Enter name and value
Check "Secured" checkbox
Click "Add"

使用例

pipelines:
  default:
    - step:
        script:
          - echo "Deploying with key $API_KEY"  # Will show as $API_KEY in logs
          - curl -H "Authorization: Bearer $API_KEY" https://api.example.com

Shared Pipeline Variables

Export variables between steps using $BITBUCKET_PIPELINES_VARIABLES_PATH:

pipelines:
  default:
    - step:
        name: Generate version
        script:
          - export VERSION=$(date +%Y%m%d)
          - echo "VERSION=$VERSION" >> $BITBUCKET_PIPELINES_VARIABLES_PATH
        output-variables:
          - VERSION
    - step:
        name: Use version
        script:
          - echo "Deploying version $VERSION"

Constraints:

50 variable limit per pipeline
100KB total size limit
Only available to subsequent steps

YAML Templating

Non-secured variables can be injected into YAML using template syntax:

image: ${{IMAGE_NAME}}
definitions:
  caches:
    custom-cache: ${{CACHE_PATH}}
pipelines:
  default:
    - step:
        name: Build for ${{ENVIRONMENT}}
        script:
          - npm run build

Supported variables:

Workspace and repository variables
Specific defaults: BITBUCKET_WORKSPACE, BITBUCKET_REPO_SLUG, BITBUCKET_BRANCH, BITBUCKET_COMMIT, BITBUCKET_PR_ID

Limitations: Secured variables and runtime-defined custom variables are not supported.

Variable Examples

API Keys and Credentials

pipelines:
  default:
    - step:
        script:
          - npm install
          - npm run deploy -- --key=$DEPLOY_KEY

Dynamic Configuration

pipelines:
  branches:
    staging:
      - step:
          deployment: staging
          script:
            - echo "Deploying to $BITBUCKET_DEPLOYMENT_ENVIRONMENT"
            - ./deploy.sh $API_URL $DB_HOST
    main:
      - step:
          deployment: production
          script:
            - echo "Deploying to $BITBUCKET_DEPLOYMENT_ENVIRONMENT"
            - ./deploy.sh $API_URL $DB_HOST  # Different values for production

ビルド情報

pipelines:
  default:
    - step:
        script:
          - echo "Build Info" > build-info.txt
          - echo "Commit: $BITBUCKET_COMMIT" >> build-info.txt
          - echo "Branch: $BITBUCKET_BRANCH" >> build-info.txt
          - echo "Build: $BITBUCKET_BUILD_NUMBER" >> build-info.txt

Third-Party Secret Providers

Advanced organizations can integrate secret management tools for dynamic secret retrieval:

HashiCorp Vault
AWS Secrets Manager
Azure Key Vault
Google Secret Manager

These integrations work with self-hosted or cloud runners to fetch secrets at runtime without storing them in Bitbucket.

ベストプラクティス

Use secured variables for sensitive data - Always mark passwords, API keys, and tokens as secured
Scope appropriately - Use workspace variables for shared resources, deployment variables for environment-specific values
Don't commit secrets - Never put credentials in your bitbucket-pipelines.yml file
Rotate regularly - Update credentials periodically, especially after team member departures
Use descriptive names - Name variables clearly (e.g., AWS_PROD_ACCESS_KEY vs KEY1)
Document variables - Keep a list of required variables in your README

次のステップ

Learn about Docker Images to use private registries
Configure Deployments with environment-specific variables
Set up SSH Keys for secure authentication

この内容はお役に立ちましたか?

正確ではなかった明確ではなかった関係なかった

さらにヘルプが必要ですか?

アトラシアンコミュニティをご利用ください。

コミュニティに質問