Skip to content

fix(ci): repair CodeQL and read the version from a ref that may predate the task - #29

Merged
ExtraToast merged 1 commit into
mainfrom
fix/pr-filters-and-version-read
Sep 2, 2026
Merged

fix(ci): repair CodeQL and read the version from a ref that may predate the task#29
ExtraToast merged 1 commit into
mainfrom
fix/pr-filters-and-version-read

Conversation

@ExtraToast

Copy link
Copy Markdown
Contributor

Three failures on main, all from the previous change.

CodeQL would not parse. Its pull_request trigger ended up with both branches and branches-ignore, which GitHub rejects — the workflow was invalid and every run failed, showing up named after its own file path.

The exclusion was wrong anyway. For pull_request, branches/branches-ignore match the base branch. release-please and spec-sync target main like everything else, so the filter excluded nothing. Suppressing those runs has to be a job-level if on github.head_ref, which concludes skipped rather than red. head_ref is empty on push, so main builds are unaffected.

printVersion did not exist on the tag being published. The release workflow's verify and publish jobs check out arbitrary refs, and a tag can predate any build task. They now parse the version out of gradle.properties, dropping anything after a # — correct for both the current form and the historical 1.0.0 # x-release-please-version. CI still asks Gradle, since CI always runs against a current checkout.

…te the task

Three failures on main, all from the previous change.

CodeQL would not parse. Its pull_request trigger ended up with both `branches`
and `branches-ignore`, which GitHub rejects, so the workflow was invalid and
every run failed -- visible as a workflow named after its own file path.

The exclusion was wrong anyway. For pull_request events `branches` and
`branches-ignore` match the *base* branch; release-please and spec-sync target
main like every other pull request, so the filter excluded nothing. Suppressing
those runs has to happen in a job-level `if` on github.head_ref, which makes the
run conclude `skipped` rather than red. head_ref is empty on push, so builds of
main are unaffected.

Finally, the release workflow's verify and publish jobs check out arbitrary
refs, and a release tag can predate any build task -- `printVersion` did not
exist on the tag being published, so both jobs failed. They now parse the
version out of gradle.properties, dropping anything after a `#`, which reads
correctly for both the current form and the historical
"1.0.0 # x-release-please-version" one. CI still asks Gradle, because CI always
runs against a current checkout.
@ExtraToast
ExtraToast merged commit 5bbbdf4 into main Sep 2, 2026
6 checks passed
@ExtraToast
ExtraToast deleted the fix/pr-filters-and-version-read branch September 2, 2026 22:01
@github-actions github-actions Bot mentioned this pull request Sep 2, 2026
github-actions Bot added a commit that referenced this pull request Sep 2, 2026
🤖 I have created a release *beep* *boop*
---


<details><summary>1.0.1</summary>

##
[1.0.1](v1.0.0...v1.0.1)
(2026-09-02)


### Bug Fixes

* **ci:** repair CodeQL and read the version from a ref that may predate
the task
([#29](#29))
([5bbbdf4](5bbbdf4))
* stop publishing artefacts named "0.2.x # x-release-please-version"
([#27](#27))
([b01cad2](b01cad2))
</details>

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant