| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The workflow only listened on `main`, so pushes to and PRs against `branch-*` release branches never triggered CI. Add `branch-*` to both the push and pull_request branch filters so release-branch work (version bumps, changelog PRs, cherry-picks) is exercised by the same `make test` job that protects main.
| Back | FazBrowse Home | New Git URL |
Which issue does this PR close?
Rationale for this change
`.github/workflows/build.yml` currently listens on `main` only:
```yaml
on:
push:
branches: [main]
pull_request:
branches: [main]
```
So pushes to `branch-0.1` (and any future `branch-*` release branch) don't trigger CI, and PRs targeting those branches — e.g. release-prep PRs that bump the version or land changelog updates — get merged without the test suite ever running. The first such PR (#89, against `branch-0.1`) made this visible.
What changes are included in this PR?
Add `'branch-*'` (quoted because of the glob) to both trigger lists:
```yaml
on:
push:
branches: [main, 'branch-']
pull_request:
branches: [main, 'branch-']
```
No other changes to the workflow — the same single `make test` job runs.
Are these changes tested?
The change itself is exercised by GitHub Actions accepting the workflow file when this PR is opened (the workflow is re-parsed on every push). The pattern `branch-*` matches `branch-0.1`, `branch-0.2`, etc.; verified by GitHub's filter docs and by the analogous pattern used in several other Apache projects' workflows.
Are there any user-facing changes?
No.