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

Improved handshaking #10

Merged
merged 10 commits into from
Feb 16, 2024
Merged

Improved handshaking #10

merged 10 commits into from
Feb 16, 2024

Conversation

efrecon
Copy link
Owner

@efrecon efrecon commented Feb 16, 2024

Close #7

Summary by CodeRabbit

  • New Features

    • Implemented a GitHub Actions workflow for automated testing on feature branch pushes.
    • Introduced development guidelines in a new CONTRIBUTING.md file for process signaling within isolated environments.
    • Enhanced script capabilities with new functions for file pattern searching and path existence checking.
    • Added a feature to control sleep time between microVM creations and improved signal handling for cleaner process termination.
    • Improved runner script with secret management, token file handling, and conditions for stopping microVM creation loops.
    • Added informative messages to indicate actions like requesting a runner token.
  • Refactor

    • Adjusted the order of script inclusions and initialization steps across multiple scripts for better operational flow and variable/function availability.
  • Documentation

    • Outlined new development guidelines and best practices for contributors.

A .tkn file, containing the runner registration token is created inside
the microVM. The main orchestrator will wait for the first such token
file for a given runner loop before continuing iterating to the next
runner loop. This slows down startup time slightly, but provides
improved determinism.

Also, when an exit signal is caught, a file with the extension .brk is
created with a secret. This file and the content of the secret are
verified in the runner loop, and, when present and matching, the loop is
stopped instead of a new runner being created.
Add an initial description of the internals of the project's
implementation.
@efrecon efrecon self-assigned this Feb 16, 2024
Copy link
Contributor

coderabbitai bot commented Feb 16, 2024

Walkthrough

The updates introduce a new GitHub Actions workflow for testing, establish guidelines for process signaling in isolated environments, enhance script functionality through reordering and new features, and improve runner management with secure registration and termination. These changes streamline operations, enhance security, and facilitate better control and integration of runners in the orchestrator setup, ensuring a more efficient and secure development workflow.

Changes

File(s) Change Summary
.github/workflows/test.yml Introduces a workflow triggered by feature/ branch pushes, running on a self-hosted runner to display environment storage, process list, and runner variables.
CONTRIBUTING.md Provides development guidelines for process signaling in isolated environments, including runner identification, registration, and secure termination.
base/base.sh, runner/install.sh Moves the inclusion of common.sh after setting directory paths, affecting operation order and the availability of common functions and variables.
lib/common.sh Adds find_pattern function for file pattern searching and updates wait_path to use this new function.
orchestrator.sh, runner.sh, runner/runner.sh Sources lib/common.sh earlier, adjusts runner management logic (including sleep time between microVM creation, runner secret handling, and registration token management), and updates cleanup and debug functionalities. Adds handling for new options and file-based token and secret management.
runner/token.sh Adds a verbose message for runner token request actions.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit-tests for this file.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit tests for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository from git and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit tests.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 3

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 1b13524 and c90637b.
Files selected for processing (9)
  • .github/workflows/test.yml (1 hunks)
  • CONTRIBUTING.md (1 hunks)
  • base/base.sh (2 hunks)
  • lib/common.sh (2 hunks)
  • orchestrator.sh (5 hunks)
  • runner.sh (6 hunks)
  • runner/install.sh (2 hunks)
  • runner/runner.sh (7 hunks)
  • runner/token.sh (1 hunks)
Additional comments: 18
.github/workflows/test.yml (1)
  • 1-24: The workflow file is well-structured and follows best practices for GitHub Actions. It correctly specifies triggers, jobs, steps, and uses appropriate actions like actions/checkout@v4. The use of a self-hosted runner is noted, and the commands in the run step provide useful debugging information. Ensure the self-hosted runner has the necessary permissions and environment setup for these commands to execute successfully.
CONTRIBUTING.md (1)
  • 1-35: The CONTRIBUTING.md file clearly outlines the signaling mechanism between processes in an isolated environment, including runner identification, registration, and termination. The use of a .tkn file for runner registration and a .brk file with a secret for termination signals is a secure and effective method. Ensure that the random string used for the secret is sufficiently unpredictable and securely generated to prevent unauthorized termination signals.
runner/token.sh (1)
  • 112-112: Adding a verbose message before requesting a runner token enhances the script's usability and debuggability by making the action explicit. This is a good practice, especially for operations that involve network requests. Ensure that the TOKEN_PAT used for authorization is securely handled and not exposed in logs or error messages.
lib/common.sh (2)
  • 79-85: The find_pattern function is a useful addition for searching file patterns within a directory. It correctly uses find with appropriate options to limit the search depth and match the specified pattern. Ensure that the function is used in a secure context, especially when handling user-supplied input to prevent potential path traversal or injection vulnerabilities.
  • 97-98: Modifying the wait_path function to use find_pattern for path existence checking is a logical improvement. It makes the function more versatile and efficient by leveraging the newly added find_pattern. Ensure that the timeout mechanism is tested thoroughly to prevent infinite loops or premature timeouts in scenarios with high system load or slow file system operations.
runner/install.sh (1)
  • 32-33: Moving the inclusion of common.sh to after setting INSTALL_ROOTDIR in runner/install.sh is appropriate, as it ensures that INSTALL_ROOTDIR is available to any functions or variables defined within common.sh that might depend on it. This change improves the script's modularity and initialization sequence. Ensure that all functions and variables from common.sh are indeed not needed before this point in the script.
base/base.sh (1)
  • 33-34: Moving the inclusion of common.sh to after resolving BASE_ROOTDIR in base/base.sh ensures that BASE_ROOTDIR is defined before any functions or variables from common.sh are accessed. This change is consistent with best practices for script initialization and modularity. Verify that there are no dependencies on common.sh before this point in the script.
runner.sh (4)
  • 32-33: Sourcing lib/common.sh at the beginning of runner.sh ensures that shared functions and variables are available throughout the script. This is a good practice for maintaining modularity and reusability of code. Confirm that lib/common.sh does not depend on any variables or settings defined later in runner.sh.
  • 88-89: Setting a default value for RUNNER_SECRET using random_string is a secure and effective way to generate a unique secret for each runner instance. Ensure that the random_string function generates sufficiently unpredictable and secure strings to prevent unauthorized access or termination signals.
  • 119-120: Handling the -S option to allow specifying RUNNER_SECRET provides flexibility for use cases where a predefined secret is necessary. Ensure that this option is documented and that users are aware of the security implications of using predictable secrets.
  • 205-214: The logic for checking a break condition based on RUNNER_SECRET is well-implemented. It ensures that the runner loop can be securely terminated by verifying the content of the .brk file against the secret. This approach adds an additional layer of security by preventing unauthorized termination. Ensure that the handling of the .brk file and the secret is secure and does not expose them to unauthorized access.
orchestrator.sh (3)
  • 32-34: Sourcing lib/common.sh earlier in the script is a good practice for ensuring that all functions and variables defined in common.sh are available to the rest of the script. This change should improve the maintainability and modularity of the script by centralizing common functionality.
  • 168-174: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [171-193]

Updating the trap command in the cleanup function to reset the trap (trap - INT TERM EXIT) before performing cleanup actions is a good practice. It prevents the trap from being triggered multiple times in case of multiple signals. However, ensure that all resources that need to be cleaned up are correctly handled in the cleanup function to avoid resource leaks.

  • 259-266: The logic modification for waiting before starting the next runner, which includes waiting for the runner token to be ready or sleeping for a specified time, is a thoughtful addition. It helps in managing the pace of runner creation and ensures that the system is not overwhelmed. The use of wait_path and find_pattern from lib/common.sh for waiting on the token file is a good example of leveraging common functionality. However, ensure that error handling is in place for cases where the token file does not become available within the expected timeframe.
runner/runner.sh (4)
  • 33-35: Sourcing ../lib/common.sh correctly ensures that the script can use the common functions and variables. It's important to maintain the relative path accuracy to avoid sourcing errors, especially when the script is executed from different directories.
  • 217-222: Storing the runner registration token in a file if RUNNER_TOKENFILE is set is a secure way to handle sensitive information. It reduces the risk of token exposure compared to passing tokens directly through command-line arguments or environment variables. Ensure that the file permissions are set appropriately to restrict access to the token file.
  • 228-267: The modifications in the runner_unregister function, including handling storing and reading the runner token from a file and creating a break file under specific conditions, are well thought out. These changes improve the script's robustness in managing runner lifecycle events. However, ensure that error handling is robust, especially for file operations like reading from or deleting the token file, to avoid potential script failures.
  • 405-409: Updating trap signals in the script to handle termination signals more gracefully is a good practice. It ensures that the runner is unregistered cleanly from GitHub before the script exits, which helps in maintaining a clean state. The distinction between breaking the microVM creation loop on INT or TERM signals versus regular EXIT signals is a thoughtful detail.

orchestrator.sh Show resolved Hide resolved
runner/runner.sh Show resolved Hide resolved
runner/runner.sh Show resolved Hide resolved
@efrecon efrecon merged commit 72e9218 into main Feb 16, 2024
7 checks passed
@efrecon efrecon deleted the feature/verbose-token branch February 16, 2024 22:23
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.

Add verbose logging to token
1 participant