Set up Omnihorn with an AI agent

Before you start

• Never print the key, never write it to a file, never commit it. It goes only into a CI secret.
• Windows is the only shipped target. If the repository builds for macOS or Linux only, tell the human and stop.
• Only do what is listed. Do not invent Omnihorn features or flags.

The steps

1. 1

   Find the Windows build output

   Identify the framework and the command that produces the Windows app. The upload is the folder that runs on a clean PC: the .exe plus its DLLs and data files. Use the table below as a starting point and confirm by reading the repository’s build scripts.

2. 2

   Check the folder is complete

   Build it locally if you can. The folder must contain the executable and everything it loads at run time. A single .exe that needs a missing DLL will install but fail to start. Do not upload source code, .pdb files you do not need, or secrets.

3. 3

   Choose how releases will be uploaded

   If the repository uses GitHub Actions, write a workflow (next step). For GitLab or another CI, follow the CI/CD guide’s command-line section. If there is no CI, tell the human to drag the folder into the dashboard (Builds, New build) and stop here.

4. 4

   Write the workflow

   Create .github/workflows/release.yml from the template below. Replace the build step with the real build command and set path to the output folder. Always keep the branches: filter.

5. 5

   Store the key as a repository secret

   Run gh secret set OMNIHORN_API_KEY and paste the key when prompted (or ask the human to do it under Settings, Secrets and variables, Actions). Confirm with gh secret list. Do not echo the key.

6. 6

   Commit on a branch and push

   Commit only the workflow and any build-script changes. Push to a branch that the workflow’s branches: filter matches. Open the run and read the job summary: it lists the version, the branch and what happened to the channels.

7. 7

   Verify the build is active

   The job must finish with status active. If it fails, use the troubleshooting guide, fix the cause, and run again. Do not retry blindly more than twice.

8. 8

   Hand back to the human

   Give the human the checklist at the end of this page. Two things remain for them: confirm which channel ships to users, and press Build installer on the app’s Installer tab (installers are built on request, not on every upload).

Where common frameworks put the Windows output

Workflow template

name: "Release"

on:
  push:
    branches: [main, 'release/**']

jobs:
  release:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4

      # Replace with the repository's real build; its output must end up in ./dist
      - name: Build
        run: echo "Replace this step with your build command"

      - uses: Ivorn-Technologies/upload-build@v1
        with:
          api-key: ${{ secrets.OMNIHORN_API_KEY }}
          path: ./dist
          # Optional: also assign the build to an existing channel once it is active.
          # channel: production

Version: by default Omnihorn reuses the last base version and appends its own build counter (1.4.0+build.42). To set it from a tag, see the CI/CD guide.

Report back with this checklist

1. Which folder is uploaded, and the command that produces it.
2. The workflow file path, and that OMNIHORN_API_KEY exists as a repository secret (name only, never the value).
3. The run URL and the build’s version and status from the job summary.
4. What the human still has to do: confirm the shipping channel (Channels tab, production by default) and press Build installer (Installer tab).

If it fails

More cases are in Troubleshooting. Humans who prefer to read the full story can start at the quickstart.