Auto-install hawkeye in ensure-hawkeye-exists.sh

[harshitsinghbhandari]

Summary

scripts/ensure-hawkeye-exists.sh previously checked for hawkeye and exited 1 with a message asking the contributor to install it manually. Since make pre-commit doesn't run the installer either, every fresh contributor hits the same wall on their first commit — make pre-commit succeeds, but the very next commit attempt fails on make check with no signal from the earlier step that anything was missing.

This change makes ensure-hawkeye-exists.sh install hawkeye when it's missing, by exec-ing the existing scripts/install-hawkeye.sh. "Ensure" now does what the name suggests.

If you'd prefer the install to stay opt-in (e.g. so contributors stay in explicit control of curl | sh flows), I'm happy to convert this to an alternative shape — having make pre-commit depend on a target that installs hawkeye, or having make pre-commit print a clear note that hawkeye must be installed separately.

Fixes #1642.

Test plan

• Delete .local/bin/hawkeye, run scripts/ensure-hawkeye-exists.sh — installs hawkeye and exits 0.
• Run scripts/ensure-hawkeye-exists.sh when hawkeye is already present — prints "hawkeye found!" and exits 0 (unchanged).
• make check succeeds after a single end-to-end make pre-commit + commit cycle on a fresh checkout.

[jglogan]

Hi @harshitsinghbhandari! Thanks for filing the issues and the PRs. Let me look over your worktree hook fix first, and then I'll think a bit more regarding the curl | sh issue.

[harshitsinghbhandari]

Thanks for taking a look! Happy to reshape this PR toward either approach based on what you think makes sense — keeping ensure-hawkeye-exists.sh as a pure check and routing the install through a Makefile target / contributor doc is just as viable.

[jglogan]

If you'd prefer the install to stay opt-in (e.g. so contributors stay in explicit control of curl | sh flows)

@harshitsinghbhandari This is a good point. curl | sh is considered by plenty of people to be a security anti-pattern.

I'm not a fan of it myself, and we shouldn't be doing it without their knowledge. What do you think about the following UX:

• The ensure script UX is interactive by default (telling the user what it's going to run and giving them the chance to bail)
• The ensure script reads an environment variable that allows the user to say yes non-interactively
• The existing pre-commit make target runs the ensure script, similarly to the license/format targets.

We'd need to double-check that any non-interactive workflows (I'm thinking mainly about our Git workflows where each build runs on a freshly imaged machine) explicitly install hawkeye non-interactively so that subsequent steps that run the license/format checks don't stall waiting for input.

[harshitsinghbhandari]

@jglogan — agreed on all three points. Here's the plan:

scripts/ensure-hawkeye-exists.sh:

• If hawkeye is missing, print exactly what would be downloaded and from where (https://github.com/korandoru/hawkeye/releases/download/v6.5.1/...), then prompt [y/N].
• Two ways to skip the prompt (matches convention in most tools):
  • CLI flag: --auto-install (or -y)
  • Env var: HAWKEYE_AUTO_INSTALL=1
  • Precedence: flag > env var > prompt (default).
• If declined, exit 1 with the original "please run install-hawkeye.sh" message.

Makefile:

• pre-commit target runs ./scripts/ensure-hawkeye-exists.sh after installing the hook, so contributors hit the consent prompt at make pre-commit time.
• check-licenses / update-licenses left as-is.

CI / GitHub Actions:

• Export HAWKEYE_AUTO_INSTALL=1 at the workflow level in any job that runs make check, so license/format checks don't stall.

Will push the implementation shortly.

[jglogan]

• If hawkeye is missing, print exactly what would be downloaded and from where

What would be downloaded and where, and that what's downloaded will be passwd into sh.

[jglogan]

Left one comment about describing to the user what the hawkeye installer does.

[harshitsinghbhandari]

Applied your suggestion in d19291d. The prompt is now:

Checking existence of hawkeye...

hawkeye is not installed.

scripts/install-hawkeye.sh will install it by running:

    curl -LsSf https://github.com/korandoru/hawkeye/releases/download/<version>/hawkeye-installer.sh | sh

and performs the installation by passing the downloaded content to `sh`.

(See scripts/install-hawkeye.sh for the pinned version.)

Proceed with install? [y/N]

[github-actions]

Code Coverage

Tier	Line Coverage
Unit	34.63%
Integration	19.75%
Combined	53.75%

[jglogan]

@harshitsinghbhandari Looks good, thank you for cleaning this up!

[LiamAshdown]

@harshitsinghbhandari

I think it's ill-mannered to not declare your using AI.

Your Github Activity clearly shows you're mass creating pull requests across various open source projects with no human interaction.

@jglogan Would it be possible to add a checkbox to declare usage of AI?

[harshitsinghbhandari]

Hey @LiamAshdown
fair concern, but I would like to push back on the assumption of "no human interaction." I do use AI tooling, but I review every PR I open. I'm a student contributing to open source while working under a maintainer of one of these projects, so the work is supervised and the output is something I stand behind and I'd appreciate the benefit of the doubt before "ill-mannered" gets thrown around.

Judging quality by the tool used rather than by the change itself isn't a standard I think we should set,
but I agree with you that disclosure is the right way. A checkbox to declare AI usage at PR time sounds reasonable, and I'd be happy to tick it on mine.

[LiamAshdown]

@harshitsinghbhandari

I apologise for coming across condescending. I understand and support AI should be apart of the developer's toolset. It's unfortunate there's an ever increasing wave of AI generated pull requests with no thought behind it, plaguing open source projects. And then for a human who took the time to review the merge request and leave feedback to only then be greeted with AI generated replies by the contributor - it's just another level of disrespect.

Anyway, I didn't mean to turn this into a debate.

But thank you for supporting my suggestion, take care!