如何在GitHub Actions不同工作流运行之间共享数据？

Great question! Artifacts are indeed limited to sharing within the same workflow run, but there are several solid ways to pass data like an ID between separate GitHub Actions workflows. Let’s break down the most practical options with examples:

1. Store Data in Your Repository (Files/Tags) #

This is the simplest approach for non-sensitive data—you can write the shared ID to a file, commit it to your repo, and let the second workflow read it after checking out the code.

Example Workflow 1 (Write Data): #

jobs:
  save-data:
    runs-on: ubuntu-latest
    permissions:
      contents: write  # Needed to push changes to the repo
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Save shared ID to file
        run: echo "MY_SHARED_ID=12345" > .github/shared_id.txt

      - name: Commit and push the file
        run: |
          git config --global user.name "GitHub Actions Bot"
          git config --global user.email "actions@github.com"
          git add .github/shared_id.txt
          git commit -m "Update shared ID for cross-workflow use"
          git push

Example Workflow 2 (Read Data): #

jobs:
  read-data:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Load shared ID into environment
        run: |
          source .github/shared_id.txt
          echo "SHARED_ID=$MY_SHARED_ID" >> $GITHUB_ENV

      - name: Use the shared ID
        run: echo "The shared ID from the other workflow is $SHARED_ID"

Note: This adds a commit to your repo, so consider using a dedicated branch for shared data if you want to avoid cluttering your main branch.

2. Use GitHub Secrets (For Sensitive Data) #

If your ID is sensitive, you can dynamically update a GitHub Secret using the GitHub CLI, then reference it in the second workflow.

Example Workflow 1 (Update Secret): #

jobs:
  update-secret:
    runs-on: ubuntu-latest
    permissions:
      secrets: write  # Needed to update secrets
    steps:
      - name: Install GitHub CLI
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g gh

      - name: Set shared ID as a secret
        run: echo "12345" | gh secret set SHARED_WORKFLOW_ID --repo ${{ github.repository }}
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Example Workflow 2 (Use Secret): #

jobs:
  use-secret:
    runs-on: ubuntu-latest
    steps:
      - name: Use the shared sensitive ID
        run: echo "The sensitive shared ID is ${{ secrets.SHARED_WORKFLOW_ID }}"

Note: Secret updates take effect immediately for new workflow runs, but you can’t view the secret’s plaintext value after setting it (only use it in workflows).

3. Embed Data in GitHub Releases #

If you need to track historical versions of your shared data, you can attach it to a GitHub Release—either in the release description or as an asset file.

Example Workflow 1 (Create Release with Data): #

jobs:
  create-release:
    runs-on: ubuntu-latest
    permissions:
      contents: write  # Needed to create releases
    steps:
      - name: Create release with shared ID
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: shared-data-v1
          release_name: Shared Data v1
          body: |
            Shared ID for cross-workflow use: 12345
          draft: false
          prerelease: false

Example Workflow 2 (Fetch Data from Release): #

jobs:
  fetch-release-data:
    runs-on: ubuntu-latest
    steps:
      - name: Install GitHub CLI
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g gh

      - name: Extract shared ID from release
        run: |
          SHARED_ID=$(gh release view shared-data-v1 --json body --jq '.body | split("\n") | .[] | select(startswith("Shared ID")) | split(": ")[1]')
          echo "SHARED_ID=$SHARED_ID" >> $GITHUB_ENV

      - name: Use the shared ID
        run: echo "Shared ID from release: $SHARED_ID"

4. Use External Storage (For Complex Scenarios) #

For larger datasets or cross-repo sharing, use an external service like Redis, AWS S3, or a simple custom API. This gives you more flexibility but requires additional setup.

Example Workflow 1 (Store in Redis): #

jobs:
  store-in-redis:
    runs-on: ubuntu-latest
    steps:
      - name: Install Redis CLI
        run: sudo apt-get install redis-tools

      - name: Save ID to Redis
        run: |
          redis-cli -h ${{ secrets.REDIS_HOST }} -p ${{ secrets.REDIS_PORT }} -a ${{ secrets.REDIS_PASSWORD }} SET workflow_shared_id "12345"

Example Workflow 2 (Retrieve from Redis): #

jobs:
  retrieve-from-redis:
    runs-on: ubuntu-latest
    steps:
      - name: Install Redis CLI
        run: sudo apt-get install redis-tools

      - name: Get ID from Redis
        run: |
          SHARED_ID=$(redis-cli -h ${{ secrets.REDIS_HOST }} -p ${{ secrets.REDIS_PORT }} -a ${{ secrets.REDIS_PASSWORD }} GET workflow_shared_id)
          echo "SHARED_ID=$SHARED_ID" >> $GITHUB_ENV

      - name: Use the shared ID
        run: echo "Shared ID from Redis: $SHARED_ID"

Choosing the Right Method #

• Repository files/tags: Best for simple, non-sensitive data; no extra services needed.
• GitHub Secrets: Ideal for sensitive data that shouldn’t be exposed in repo history.
• GitHub Releases: Great if you need to track versions of shared data.
• External storage: Perfect for large datasets or cross-repo sharing.

内容的提问来源于stack exchange，提问作者roisto