This document explains how to use and customize the Development Mode Toggle workflow, which lets you enable or disable a “development mode” on a self-hosted GitHub Actions runner. It is particularly aimed at developers contributing to NI’s (National Instruments) LabVIEW-based open-source projects.

In LabVIEW-centric projects, “development mode” usually refers to a runner state that enables additional debugging or specialized project setup. For instance, you might need to install a specific set of dependencies before running your workflow. Turning “dev mode” on/off allows you to toggle these specialized settings quickly.

• Makes it easy for collaborators to set a self-hosted runner (their own machine or a shared one) to a special “development” state without manually toggling environment variables or editing configurations.
• Can be triggered manually (via workflow_dispatch) or from other workflows (via workflow_call).
• Lets you quickly switch back to a testable state when you’re done coding so you can install the final VI Package to test your change.
• Allows collaborators to experiment with or update the order of operations in the underlying PowerShell scripts on their own fork, then propose those changes via pull requests.

Note: Contributors who fork this repository can keep their local copy of .github/workflows/toggle-dev-mode.yml and its associated PowerShell scripts up to date by frequently pulling changes from the upstream repository. Likewise, if they make improvements to the scripts in their fork, they can open a pull request to merge those improvements back upstream.

You do not need to copy/paste the entire workflow snippet here, as it’s already in your repo (“Development mode toggle”). Instead, here is a conceptual usage overview:

1. Triggering Manually

   • Go to the “Actions” tab on your (or your fork’s) GitHub repository.
   • Select the “Toggle Development Mode” workflow.
   • Click “Run workflow” and choose either enable or disable from the dropdown.
   • This will execute the PowerShell scripts (Set_Development_Mode.ps1 or RevertDevelopmentMode.ps1) on the target self-hosted runner (your personal machine or a shared machine).

2. Important Note for Testing

   • If your system is set to dev mode (enable), you wont be able to open the icon editor after you install the VI Package.
   • Once you finish coding or making changes, switch back (disable) to a normal testable state to be able to install the VI Package and test your change.

3. Triggering from Another Workflow

   • Use a workflow_call reference (detailed examples below).
   • Pass the input parameter mode set to enable or disable.
   • The runner that calls it will be the one switched into (or out of) dev mode.

Below are three ways to invoke this workflow. Each approach sets mode to either enable or disable.

If you have another workflow file (e.g., my-other-workflow.yml) in the same repo, you can reference “Development mode toggle” by its local path:

# my-other-workflow.yml
name: "My Other Workflow"

on:
  workflow_dispatch:

jobs:
  call-dev-mode:
    runs-on: [self-hosted, iconeditor]
    steps:
      - name: Invoke Dev Mode Toggle (enable)
        uses: ./.github/workflows/toggle-dev-mode.yml
        with:
          mode: enable

1. uses: ./.github/workflows/toggle-dev-mode.yml – Tells GitHub to run a local reusable workflow found in your repo.
2. with: – Passes inputs to that workflow. Here, mode: enable.

If you store “Development mode toggle” in a separate public repo, you can reference it by the GitHub org/repo and the specific path/branch:

name: "Cross-Repo Dev Mode Toggle"

on:
  workflow_dispatch:

jobs:
  remote-dev-mode:
    runs-on: [self-hosted, iconeditor]
    steps:
      - name: Use remote Dev Mode Toggle
        uses: <owner>/<repo>/.github/workflows/toggle-dev-mode.yml@main
        with:
          mode: disable

1. Replace <owner>/<repo> with the actual GitHub account and repository name (for example, ni/my-shared-workflows).
2. The suffix @main indicates which branch/ref to fetch. You can also use a tag or commit SHA.
3. Inputs like mode are passed the same way.

If a collaborator forked your original repo, they might keep the workflow in their own fork. They can reference that fork directly:

name: "Forked Dev Mode Example"

on:
  workflow_dispatch:

jobs:
  forked-workflow-call:
    runs-on: [self-hosted, iconeditor]
    steps:
      - name: Call Dev Mode Toggle from My Fork
        uses: <your-fork>/<repo>/.github/workflows/toggle-dev-mode.yml@my-feature-branch
        with:
          mode: enable

Here, you might see something like githubuser/labview-icon-editor-fork/.github/workflows/toggle-dev-mode.yml@feature-xyz. Again, you pass the mode input as needed. Whenever upstream changes are made to the scripts, the fork owner can pull to update their local .github/workflows/toggle-dev-mode.yml file.

All “dev mode” logic resides in two PowerShell scripts:

• Set_Development_Mode.ps1 – Called when mode is enable.
• RevertDevelopmentMode.ps1 – Called when mode is disable.

These scripts currently do things like update environment variables, configure LabVIEW paths, or install certain dependencies. To change how “dev mode” behaves, edit those scripts directly.

Collaborators are free to:

1. Modify Set_Development_Mode.ps1 or RevertDevelopmentMode.ps1 on their forks.
2. Enable dev mode on their self-hosted runner (via their fork), capturing the GitHub Actions logs as proof that their changes worked as intended.
3. Open a Pull Request to merge these script changes back into the upstream repository, referencing the successful action logs as additional evidence.

• Refer to your README.md for details on setting up your runner (LabVIEW requirements, etc.).
• GitHub Docs: https://docs.github.com/en/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow