Skip to content
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

v4 with default config (no with) does not include --progress flag #1453

Open
bquorning opened this issue Sep 4, 2023 · 6 comments
Open

v4 with default config (no with) does not include --progress flag #1453

bquorning opened this issue Sep 4, 2023 · 6 comments

Comments

@bquorning
Copy link

After upgrading to actions/checkout@v4 (no with configuration), we see1 show-progress: true listed in the logs, but git fetch is run without the --progress flag.

image

I think this is not the intended behavior of #1067, which says

Note that the default value of this new option is true, which matches the current behavior, so this PR introduces no behavior change unless the new option is explicitly present and set to false.

Footnotes

  1. https://github.com/rubocop/rubocop-rspec/actions/runs/6076842370/job/16485526462

@riseshia
Copy link

riseshia commented Sep 5, 2023

#1454 might fix this

@nedbat
Copy link

nedbat commented Sep 5, 2023

I understand the desire to keep old behavior, but why does anyone need to see dozens of lines of progress percentages? Since @v4 seems to have changed the default (by accident), why no just admit that no progress is the better default and leave it that way?

@bquorning
Copy link
Author

I too prefer the less noisy (accidental) default.

@simonbaird
Copy link
Contributor

simonbaird commented Sep 5, 2023

Ooh, sorry about that. I think the original version of #1067 predates the new options handling and somehow when rebasing and resolving conflicts I didn't notice the way the default value wasn't preserved. (In hindsight an inverted option might have been better, e.g. "hideProgress" instead of "showProgress".)

@cbandera
Copy link

cbandera commented Jan 8, 2025

Hi what is the status of this issue? Has it been fixed in the meanwhile? I'm not sure whether I understand your comments but the referneced pr #1454 does not seem to have been merged.

@riseshia
Copy link

riseshia commented Jan 8, 2025

Based on the threads so far, I concluded that maintainers is not interested in this bug, and I don't want to keep a PR opened long long time, so closed #1454 a few days ago. I still have willing to contribute for this if requested, but leave this for more passionate someone.

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 a pull request may close this issue.

5 participants