Skip to content

update-scheduled-release-version mistakenly reports success when failure happens #15

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rwinch opened this issue Jan 26, 2024 · 1 comment
Labels
type: bug A general bug

Comments

@rwinch
Copy link
Contributor

rwinch commented Jan 26, 2024

The update-scheduled-release-version reports success when a step fails See https://github.com/spring-projects-experimental/spring-boot-testjars/actions/runs/7672549320/job/20913290023

When fails on Get Next Release Milestone

image

@sjohnr sjohnr added the type: bug A general bug label Jun 4, 2024
@jhl221123
Copy link

jhl221123 commented May 11, 2025

Hi @rwinch,

Regarding #15 and its relation to spring-projects/spring-security#16764:

The issue seems to be that when a Gradle task (like getNextReleaseMilestone or checkMilestoneIsDueToday) fails, wrapping its execution directly within echo "key=$(./gradlew ...)" >> $GITHUB_OUTPUT causes the step to (incorrectly) report success because the echo command itself succeeds.

My tests confirm that changing the script to first assign the Gradle output to a variable, and then separately echoing that variable to $GITHUB_OUTPUT, allows the step to correctly fail when the Gradle task fails.

Proposal:
In update-scheduled-release-version.yml, modify steps executing Gradle tasks from:

run: echo "result=$(./gradlew -q taskName ...)" >> $GITHUB_OUTPUT

To something like:

run: |
  result_task=$(./gradlew -q taskName ...)
  echo "result=$result_task" >> $GITHUB_OUTPUT

This ensures the step fails if ./gradlew fails, while preserving the output mechanism.

I'm available to submit a PR for this. What are your thoughts?

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants