[AmyLGalles]

Summary

This is Phase 2 of 3 (finalize-source) for migrating passwordless-nodejs's npm publishing workflow to the centralized deploy repo as part of BRE-1935.

What This PR Does

Converts the cd.yml workflow to use trigger-actions deployment events, delegating the actual npm publishing to bitwarden/deploy's standardized workflow.

Pattern: Full Migration (like passwordless-java)

Unlike the passwordless-devops hybrid pattern used for deploy-passwordless-nodejs.yml, this cd.yml workflow follows the full migration pattern:

• ✅ Phase 1: Receiver workflow created in bitwarden/deploy (already merged)
• ⏳ Phase 2 (this PR): Replace local publish logic with trigger-actions caller
• ⏳ Phase 3: Wire trigger-actions.yml receiver

Current Workflow

The workflow keeps its build and format steps but replaces the publish logic:

Retained (unchanged):

• ✅ format job: Runs linting
• ✅ build job: Runs npm build and uploads artifacts

Modified:

• ✅ trigger-deploy job: Now emits deployment event to bitwarden/deploy
  • Triggered on release: published events
  • Forwards release tag to deploy repo
  • Deploy repo handles the actual npm publish

Changes Applied

1. Trigger-Actions Integration

The trigger-deploy job now uses bitwarden/gh-actions/trigger-actions@main:

trigger-deploy:
  name: Trigger deployment
  if: ${{ github.event_name == 'release' }}
  needs: build
  runs-on: ubuntu-24.04
  permissions:
    contents: read
    id-token: write
  steps:
    - name: Log in to Azure
      uses: bitwarden/gh-actions/azure-login@main
      with:
        subscription_id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
        tenant_id: ${{ secrets.AZURE_TENANT_ID }}
        client_id: ${{ secrets.AZURE_CLIENT_ID }}

    - name: Trigger deployment to deploy repo
      uses: bitwarden/gh-actions/trigger-actions@main
      with:
        azure_subscription_id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
        azure_tenant_id: ${{ secrets.AZURE_TENANT_ID }}
        azure_client_id: ${{ secrets.AZURE_CLIENT_ID }}
        task: deploy-passwordless-nodejs
        data: |
          {
            "tag": "${{ github.event.release.tag_name }}"
          }

2. What Gets Forwarded

Single input forwarded to deployment event:

• tag: Release tag name (e.g., v1.0.0)

The deploy repo receiver workflow will:

1. Extract the tag from the deployment event
2. Download build artifacts from this workflow run
3. Publish to npm using OIDC authentication

3. Workflow Flow

Before (if this was the old pattern):

1. Build → Upload artifacts → Publish to npm locally

After (this PR):

1. passwordless-nodejs: Build → Upload artifacts → Trigger deployment event
2. bitwarden/deploy: Receive event → Download artifacts → Publish to npm

How It Works

Current Flow (After This PR + Phase 3)

1. Release Published in passwordless-nodejs

   • User creates and publishes a release

2. Build & Format (this workflow)

   • Runs linting (format job)
   • Runs build (build job)
   • Uploads artifacts (dist + package.json)

3. Trigger Deployment (this workflow)

   • Emits deployment event to bitwarden/deploy
   • Task: deploy-passwordless-nodejs
   • Data: { "tag": "v1.0.0" }

4. Publish Runs (bitwarden/deploy)

   • trigger-actions.yml receives deployment event
   • Dispatches deploy-passwordless-nodejs.yml
   • Downloads artifacts from this workflow run
   • Publishes to npm with OIDC

Three-Stage Migration Status

Phase 1: Draft ✅ Complete

• Receiver workflow exists in bitwarden/deploy
• Merged via previous PR

Phase 2: Finalize Source ⏳ This PR

• Convert cd.yml to use trigger-actions
• Keep build/format jobs
• Replace publish logic with deployment event emission

Phase 3: Wire Trigger ⏳ Next

• Add trigger-deploy-passwordless-nodejs job to trigger-actions.yml
• Complete end-to-end deployment event chain

Comparison with passwordless-java

This follows the same pattern as passwordless-java Phase 2:

Aspect	passwordless-java	passwordless-nodejs
Trigger	release: published	release: published
Build location	N/A (Maven builds from tag)	passwordless-nodejs (this repo)
Publish location	deploy repo	deploy repo
Pattern	Full migration	Full migration

Testing Plan

After Phase 3 completes:

1. Create and publish a test release:

   gh release create v1.0.0-test --repo bitwarden/passwordless-nodejs --draft
   gh release edit v1.0.0-test --repo bitwarden/passwordless-nodejs --draft=false

2. Verify workflow runs:

   # Check this workflow completes
   gh run list --repo bitwarden/passwordless-nodejs --workflow=cd.yml --limit 5
   
   # Check trigger-actions receives event
   gh run list --repo bitwarden/deploy --workflow=trigger-actions.yml --limit 5
   
   # Check deploy workflow runs
   gh run list --repo bitwarden/deploy --workflow=deploy-passwordless-nodejs.yml --limit 5

3. Verify npm package published

Rollback Plan

If issues arise:

1. Revert this PR
2. Releases will trigger the old local publish flow
3. No impact to production npm publishing

Related

• Jira: BRE-1935 - Centralize deploy workflows in bitwarden/deploy
• Phase 1 PR: bitwarden/deploy (already merged)
• Phase 3 PR: bitwarden/deploy (TBD - wire trigger-actions.yml)
• Target Workflow: bitwarden/deploy .github/workflows/deploy-passwordless-nodejs.yml
• Similar Pattern: passwordless-java Phase 2

Validation

• ✅ actionlint passes with no errors
• ✅ Build and format jobs unchanged
• ✅ Trigger-actions integration follows established pattern
• ✅ Minimal changes to workflow structure

[AmyLGalles]

@claude review this

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: REQUEST CHANGES

This review covers the changes to .github/workflows/cd.yml, which add a format job, update the pinned versions of actions/checkout and actions/setup-node, rename the build artifact to packages, and add a trigger-deploy job that sends a deployment event to bitwarden/deploy. The new job only runs when github.event_name == 'release', but the workflow still has no release trigger, so the deployment path never runs.

Code Review Details

• ❌ : trigger-deploy can never run because on: has no release: [published] trigger
  • .github/workflows/cd.yml:80
• ❓ : The deployment payload sends only tag, so it is unclear how the receiver finds this run's packages artifact (no run_id is sent)
  • .github/workflows/cd.yml:101

[claude]

❌ CRITICAL: trigger-deploy can never run because the workflow has no release trigger.

Details and fix

The on: block (lines 5-9) still only declares push to main and workflow_dispatch, so github.event_name is never release. The job is always skipped, which means no deployment event ever reaches bitwarden/deploy. The PR description says the job is "Triggered on release: published events", but that trigger was never added.

Add the trigger:

on:
  push:
    branches:
      - main
  release:
    types: [published]
  workflow_dispatch:

Also, github.event.release.tag_name (line 103) only gets a value on release events.

[claude]

❓ QUESTION: How does the receiver find this run's packages artifact when the payload only sends tag?

Details

The PR description says bitwarden/deploy will "Download build artifacts from this workflow run". A cross-repository artifact download usually needs the source run_id (and the repository). Neither is in data. If the receiver looks the run up by tag or branch instead, that works, but the generic artifact name packages gets reused by every push to main. Should "run_id": "${{ github.run_id }}" be forwarded here?