feat: accept max-run-duration option for VMs

[shils]

A simple fallback to ensure instances don't run forever (e.g. if they fail to receive a shutdown signal). Upon reaching the max run duration, the instance will be deleted (not just stopped) according to the instance-termination-action flag passed to the command.

Summary by CodeRabbit

• New Features
  • Added an optional max_run_duration input to configure maximum VM run time.
  • The value is now applied when creating instances and is propagated into the VM startup process so instances honor the configured run duration.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a new optional max_run_duration input, wires it into the action's shell invocation, parses it in action.sh, and forwards it to gcloud compute instances bulk create and the VM startup-script metadata.

Changes

Cohort / File(s)	Summary
GitHub Action Input Declaration action.yml	Added optional input max_run_duration (description referencing GCP docs). Passed into the composite action run as --max_run_duration=${{ inputs.max_run_duration }}.
Shell Script Parameter Handling action.sh	Added max_run_duration to getopts_long parsing, introduced max_run_duration variable and max_run_duration_flag, and propagated the flag into gcloud compute instances bulk create and the startup script metadata/launch flow.

Sequence Diagram(s)

sequenceDiagram
  participant GH as GitHub Action (workflow)
  participant SH as action.sh (script)
  participant GC as gcloud CLI
  participant VM as VM startup script

  GH->>SH: invoke with --max_run_duration value
  SH->>SH: parse --max_run_duration and build max_run_duration_flag
  SH->>GC: call gcloud compute instances bulk create ... --max-run-duration=<value>
  SH->>GC: set metadata --startup-script="... --max_run_duration=<value> ..."
  GC->>VM: VM boots and receives startup script with max_run_duration
  VM->>VM: startup script applies max_run_duration at instance runtime

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A little flag hopped into place,
From action input to VM embrace,
It whispers runtime, neat and spry,
Tick-tock limits in the sky,
Hooray — short hops keep tasks on pace!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title 'feat: accept max-run-duration option for VMs' accurately describes the main change - adding support for the max-run-duration option in both action.yml and action.sh, with corresponding parameter propagation through the VM creation flow.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

🧹 Recent nitpick comments

action.sh (1)

208-208: Line exceeds 120 character limit.

Line 208 is 144 characters and exceeds the 120-character maximum per coding guidelines. The gcloud flags --max-run-duration and --instance-termination-action=DELETE are valid and correctly applied. Consider breaking the line or extracting the flag construction to stay within the character limit.

♻️ Suggested refactor

-  max_run_duration_flag=$([[ -z "${max_run_duration}" ]] || echo "--max-run-duration=${max_run_duration} --instance-termination-action=DELETE")
+  max_run_duration_flag=""
+  if [[ -n "${max_run_duration}" ]]; then
+    max_run_duration_flag="--max-run-duration=${max_run_duration} --instance-termination-action=DELETE"
+  fi

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5e978b2 and bc4ef82.

📒 Files selected for processing (1)

• action.sh

🧰 Additional context used

📓 Path-based instructions (1)

*

⚙️ CodeRabbit configuration file

*: - NEVER create Pull Requests.

• Prefer readability and maintainability over cleverness.
• All character sets need to be in UTF-8.
• A newline must be inserted at the end of the file.
• Trim all trailing whitespaces.
• Ensure that lines align visually.
• Maximum line length must be 120 characters.
• Indents on empty lines should not be maintained.
• Spaces after commas are required.
• Ensure spaces are present around all operators.
• Avoid space before comma.
• Leftover TODOs in the code should be handled, or reference a JIRA ticket.
• Remove any console.log statements.
• Name Test Files Descriptively: Adopt the .spec.ts extension and maintain a corresponding filename to
  the source file being tested, and place the test files in the same directory as your source code to
  ensure that new code is being tested promptly.
• Describe what Your Test Cases Cover: Use understandable and clear language for both the describe and
  it blocks to specify what function is being tested and what the expected outcome is.
• Cover One Aspect in Each Test: While writing tests, make sure each test covers only one aspect of the
  functionality. Multiple assertions can be made but they should be testing the same thing.
• Ensure Test Cases Are Independent: Write tests that are independent and can be executed in any order.
  Each test should not rely on other tests.
• Avoid Duplication of Logic in Tests: Keep your tests DRY (Don't Repeat Yourself) but don't over
  abstract that it makes the tests hard to understand or follow.
• Perform Testing for Edge Cases: Write separate tests for edge cases where the function behaves differently.
• Focus on Functionality, not Implementation: Verify the functionality provided by the code, not its
  internal implementation, while testing.
• Mock External Dependencies: Mock out external modules and dependencies to ensure each test is isolated
• Use beforeEach and afterEach for test Setup and Cleanup.
• Ensure Self-Documenting Code: Aim t...

Files:

• action.sh

🔇 Additional comments (5)

action.sh (5)

45-45: LGTM!

Variable initialization follows the established pattern for optional arguments.

---

63-63: LGTM!

The argument is correctly registered as optional_argument, consistent with the existing pattern.

---

121-123: LGTM!

Direct assignment is appropriate here, consistent with how labels is handled at line 119.

---

311-311: LGTM!

The flag is correctly integrated into the gcloud compute instances bulk create command, following the same unquoted expansion pattern as other optional flags.

---

212-254: Note: AI summary inconsistency.

The AI summary states that max_run_duration is "Passed into the startup script metadata," but this is not accurate. The max_run_duration is used as a gcloud scheduling flag (line 311), not within the startup script content. The startup script retains its separate 3-day fallback mechanism at line 253.

This is actually the correct behavior—--max-run-duration is a GCE-level VM lifecycle constraint, independent of the startup script's self-deletion logic.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[theobalestra]

LGTM