googleapis / release-please

generate release PRs based on the conventionalcommits.org spec
https://www.conventionalcommits.org
Apache License 2.0
4.8k stars 360 forks source link

release-please ignores commits which contain fenced codeblocks #2020

Closed JakeChampion closed 2 months ago

JakeChampion commented 1 year ago

Based on request, moving issue from release-please-action's issue tracker to the release-please issue tracker -- original issue: https://github.com/google-github-actions/release-please-action/issues/771

TL;DR

Commit message which follows conventional commits gets ignored if it contains a fenced code block

Expected behavior

The commit should be parsed by release please to help figure out if a release is required.

Observed behavior

The commit message is ignored:

commit could not be parsed: 423b0c99367e9e0ffc761f5495c97ed0852267cd feat: implement Fanout for JS SDK

Environment details

Steps to reproduce

  1. Create a commit message which has a fenced code block (An example commit message is at the end of this issue description)
  2. Attempt to run release-place and it will state it can not parse the new commit

Action YAML

on:
  push:
    branches:
      - main
env:
  wasm-tools_version: 1.0.28
name: release-please
jobs:
  release:
    runs-on: ubuntu-latest
    outputs:
      releases_created: ${{ steps.release.outputs.releases_created }}
      pr: ${{ steps.release.outputs.pr }}
    steps:
      - uses: google-github-actions/release-please-action@v3
        id: release
        with:
          release-type: node
          package-name: "@fastly/js-compute"
          changelog-path: "CHANGELOG.md"
          bump-minor-pre-major: true
          bump-patch-for-minor-pre-major: true
          draft: false
          prerelease: false
          token: ${{ secrets.JS_COMPUTE_RUNTIME_GITHUB_TOKEN }}

  update-lock-and-docs:
    runs-on: ubuntu-latest
    needs: release
    if: ${{ needs.release.outputs.pr && !needs.release.outputs.releases_created }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          submodules: true
          ref: release-please--branches--main--components--js-compute
          fetch-depth: 2
          token: ${{ secrets.JS_COMPUTE_RUNTIME_GITHUB_TOKEN }}

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'yarn'

      - run: yarn install --mode=update-lockfile
        working-directory: ./documentation
      - run: npm run docusaurus docs:version "$(npm pkg get version --json --prefix=../ | jq -r)"
        working-directory: ./documentation

      - run: yarn install --mode=update-lockfile
        working-directory: ./documentation/app
      - run: npm run build:files
        working-directory: ./documentation/app

      - name: Committing and push changes
        run: |
          git config user.name "${GITHUB_ACTOR}"
          git config user.email "${GITHUB_ACTOR}@users.noreply.github.com"
          git add .
          git commit -m "chore: add docs for $(npm pkg get version --json | jq -r)"
          git push --force

  publish:
    runs-on: ubuntu-20.04
    needs: release
    if: ${{ needs.release.outputs.releases_created }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          submodules: true

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'yarn'
          registry-url: 'https://registry.npmjs.org'

      - uses: ./.github/actions/cache-crates
        with:
          lockfiles: "runtime/js-compute-runtime/**/Cargo.lock"

      - uses: ./.github/actions/install-rust
        with:
          path: runtime

      - name: Restore wasm-tools from cache
        uses: actions/cache@v3
        id: wasm-tools
        with:
          path: "/home/runner/.cargo/bin/wasm-tools"
          key: crate-cache-wasm-tools-${{ env.wasm-tools_version }}

      - name: "Check wasm-tools has been restored"
        if: steps.wasm-tools.outputs.cache-hit != 'true'
        run: |
          echo "wasm-tools was not restored from the cache"
          echo "bailing out from the build early"
          exit 1

      - name: Cache SpiderMonkey object files
        uses: actions/cache@v2
        id: sm-cache
        with:
          path: |
            runtime/spidermonkey/release
          key: cache-${{ hashFiles(
            'runtime/spidermonkey/build-engine.sh',
            'runtime/spidermonkey/gecko-revision',
            'runtime/spidermonkey/object-files.list',
            'runtime/rust-toolchain.toml'
            ) }}-release

      - name: "Build SpiderMonkey"
        if: ${{ steps.sm-cache.outputs.cache-hit != 'true' }}
        run: |
          cd runtime/spidermonkey/
          bash ./build-engine.sh release

      - name: "Install wasi-sdk-19 (linux)"
        run: |
          set -x
          curl -sS -L -O https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-19/wasi-sdk-19.0-linux.tar.gz
          tar xf wasi-sdk-19.0-linux.tar.gz
          sudo mkdir -p /opt/wasi-sdk
          sudo mv wasi-sdk-19.0/* /opt/wasi-sdk/

      - name: "Install Binaryen (linux)"
        run: |
          set -x
          export BINARYEN_VERSION=105
          curl -sS -L "https://github.com/WebAssembly/binaryen/releases/download/version_${BINARYEN_VERSION}/binaryen-version_${BINARYEN_VERSION}-x86_64-linux.tar.gz" | tar xzf - &&
          echo "$PWD/binaryen-version_${BINARYEN_VERSION}/bin" >> $GITHUB_PATH

      - name: Cache built Rust dependencies
        uses: actions/cache@v3
        with:
          path: runtime/js-compute-runtime/rusturl
          key: engine-cargo-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('runtime/rust-toolchain.toml', 'runtime/js-compute-runtime/**/Cargo.lock') }}
          # We trust cargo to only reuse valid parts of the cache when dependencies change.
          restore-keys: engine-cargo-${{ runner.os }}-${{ runner.arch }}-

      - run: yarn install --immutable

      - run: yarn build

      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}}

      - run: yarn
        working-directory: ./documentation

      - name: Set up Fastly CLI
        uses: fastly/compute-actions/setup@v2
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          cli_version: '7.0.1'

      - run: yarn deploy
        timeout-minutes: 120
        env:
          FASTLY_API_TOKEN: ${{secrets.FASTLY_API_TOKEN}}
        working-directory: ./documentation

Log output

✔ Looking for latest release on branch: main with prefix: js-compute
❯ Fetching merge commits on branch main with cursor: undefined
❯ Found latest release pull request: 513 version: 1.11.2
❯ Fetching releases with cursor undefined
❯ found release for js-compute Version {
  major: 1,
  minor: 11,
  patch: 2,
  preRelease: undefined,
  build: undefined
}
❯ found release for js-compute Version {
  major: 1,
  minor: 11,
  patch: 1,
  preRelease: undefined,
  build: undefined
}
❯ SHA not found in recent commits to branch main, skipping
❯ found release for js-compute Version {
  major: 1,
  minor: 11,
  patch: 0,
  preRelease: undefined,
  build: undefined
}
❯ SHA not found in recent commits to branch main, skipping
❯ found release for js-compute Version {
  major: 1,
  minor: 10,
  patch: 1,
❯ Found 1761 files
❯ Backfilling file list for commit: 72195e250b9a2632c89cdaac7776e1a51344cb42
❯ Found 13 files
❯ Backfilling file list for commit: a573654c1acda4975d02bf8d6c6349d130713583
❯ Found 1 files
✔ PR #513 has many files, backfilling
❯ Backfilling file list for commit: 0cc3ed1b8f78f813491541f599d5c70359e00bab
❯ Found 581 files
✔ PR #511 has many files, backfilling
❯ Backfilling file list for commit: edbb470e24be4ff40c253576b60fc47fd9859c73
❯ Found 581 files
✔ PR #510 has many files, backfilling
❯ Backfilling file list for commit: 893a084a36f17aeed1a0b409984d4663e57467fa
❯ Found 581 files
✔ PR #508 has many files, backfilling
❯ Backfilling file list for commit: 6c7d08e21005f4d792b4401efb531e96aa4e2d62
❯ Found 581 files
✔ PR #500 has many files, backfilling
❯ Backfilling file list for commit: e3f4bdd65fd0b268e0b99243f78c036c9f022522
❯ Found 580 files
❯ Backfilling file list for commit: a30842971db1891ca857aed6dd8946ebaeb2cc02
❯ Found 2 files
✔ Splitting 10 commits by path
✔ Building candidate release pull request for path: .
❯ type: node
❯ targetBranch: main
❯ commit could not be parsed: 53a30122adbd82e62926a0a4829f81b5ed7f46eb feat: implement Fanout for JS SDK
❯ commit could not be parsed: ef09f3191533f65943b061ad90de7a634d707f61 Rename c-dependencies to runtime (#514)
❯ commit could not be parsed: 10b3db70c85aad2a030fb1b9f3ed3e8c57585508 update docs for 1.10 and 1.11
❯ commits: 9
✔ Considering: 9 commits
❯ component: 
❯ pull request title pattern: undefined
✔ No user facing commits found since 0cc3ed1b8f78f813491541f599d5c70359e00bab - skipping

Additional information

This is the commit message which failed to parse via release-please but does parse via commitlint for conventional commit format -- I have had to escape the fenced code blocks here, but in the actual commit message they are not escaped:

feat: implement Fanout for JS SDK

Below is a product description of Fanout:

------

Fanout is a publish/subscribe message broker operating at the Fastly edge, powered by [Pushpin](https://pushpin.org/). This makes it easy to build and scale realtime/streaming applications which push data instantly to browsers, mobile apps, servers, and other devices.

Without Fanout, clients make short-lived HTTP requests to Fastly, and Fastly responds with a resource from cache or an origin server. When a request is passed to Fanout, it keeps that connection open indefinitely, assigns the connection to one or more channels, and waits for data to be published to those channels. Origin servers or Fastly services may use an API to publish data to a channel, and Fanout will distribute that data to all the clients which have a subscription to that channel.

Any regular HTTP request may be upgraded into an event-driven response using a transport such as Server-Sent-Events, or Long-Polling. If the request from the client is a WebSocket request, the resulting stream is bidirectional.

This architecture has some nice advantages over more proprietary streaming services:

- Integrated into your Fastly service, so any pre-processing you do to requests to your Fastly service (e.g. for authentication), you can do to streaming requests too.
- Any HTTP client or server can be used - including serverless / functions-as-a-service.
- Any HTTP response can be turned into an evented stream (e.g. a progressive JPEG, a log file, or an API endpoint that performs asynchronous operations).
- No need to use a separate domain for streaming data.

-----

Most JavaScript Compute Services have an entry function which looks like this:
\`\`\`js
addEventListener("fetch", event => event.respondWith(handleRequest(event)));
\`\`\`
Where `handleRequest` contains the logic for the application.

With this in mind, I wanted to design a Fanout API which works with this type of entry function.
What I landed on was a function which returns a JS Response, this JS Response has some internal slots set to indicate it's a Fanout response, if the JS Response is then given to `event.respondWith` then instead of calling `fastly_http_resp_send_downstream` we call `fastly_http_req_redirect_to_grip_proxy` which is the Fanout hostcall.

This is what it looks like in an application:
\`\`\`js
import { createFanoutHandoff } from "fastly:fanout";

addEventListener("fetch", (event) => event.respondWith(handleRequest(event)));

async function handleRequest(event) {
  try {
    const url = new URL(event.request.url);
    if (url.pathname === '/stream') {
      return createFanoutHandoff(event.request, 'fanout');
    } else {
      return new Response('oopsie, make a request to /stream for some fanout goodies', { status: 404 });
    }
  } catch (error) {
    console.error({error});
    return new Response(error.message, {status:500})
  }
}
\`\`\`

Co-authored-by: Trevor Elliott <telliott@fastly.com>
gigi commented 8 months ago

Hi there! We have the same issue. Is it possible to fix?

patricebender commented 7 months ago

We seem to have the same problem. We need to manually maintain changelog entries for those cases. We use the code fences quite frequently in our PR descriptions but this issue came up only once with this PR.

@chingor13 we really like release-please but this problem is quite annoying and bears the chance to have an incomplete changelog. Any chance that this gets a higher priority?