releases_created is defaulting to true

[Danwakeem]

TL;DR

We noticed when upgrading from v3 to v4 that the releases_created output is defaulting to true even when no release was created.

Expected behavior

I would expect releases_created to be set to false if no release was created.

Observed behavior

releases_created was set to true when no release was created.

Action YAML

name: Deploy

run-name: Deploy - ${{ startsWith(github.event.head_commit.message, 'chore(main)') && 'prod' || github.event.inputs.stage == '' && 'dev' || github.event.inputs.stage }}

permissions:
  id-token: write
  contents: write
  pull-requests: write
  packages: read

on:
  push:
    branches:
      - main
      - 'rel_*'
  workflow_dispatch:
    inputs:
      stage:
        description: 'Stage to deploy to - for example, "dev" or "prod"'
        required: true
        default: 'dev'
        type: choice
        options:
          - dev
          - dev1
          - qa
          - qa1
          - test
          - prod

env:
  RELEASE_PREFIX: 'chore(main): release'
  NODE_AUTH_TOKEN: ${{ github.token }}

jobs:
  deploy:
    name: Deploy - ${{ startsWith(github.event.head_commit.message, 'chore(main)') && 'prod' || github.event.inputs.stage == '' && 'dev' || github.event.inputs.stage }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20.x'
          cache: 'yarn'
          registry-url: 'https://npm.pkg.github.com'

      - name: Deploy - ${{ github.event.inputs.stage == '' && 'dev' || github.event.inputs.stage }}
        if: ${{ !startsWith(github.event.head_commit.message, env.RELEASE_PREFIX) }}
        run: echo "Deploying Dev"

      - uses: google-github-actions/release-please-action@v4
        id: release

      - name: Deploy - Production
        if: ${{ steps.release.outputs.releases_created }}
        run: echo "Deploying prod"

Log output

https://github.com/Danwakeem/release-please-dont/actions/runs/8473993661/job/23219475874

Additional information

We were upgrading from v3 to v4 when we noticed this happening. We were aware that the output for this action had changed and we were incorrectly using releases_created but the issue was that we were gating production deployments off of this flag. So the fact that it defaulted to true unexpectedly was the issue we observed.

Worth noting when we switch to release_created this flag was working as expected.

I recreated our deployments in this repo if you wanna check out our deploy workflow.

[beeme1mr]

Hey @Danwakeem, there's an issue open with some possible workaround. It's not ideal but it's better than nothing.

[Danwakeem]

Ahh thank you @beeme1mr I didn't find that when I did a search for whatever reason. Thank you!