Repositories and CI

Use Repositories to find a local checkout, open its files and history, or start a launcher in that directory. In Logonomic and Logonomic Pro, repository details also show supported GitHub and GitLab CI activity.

Start by adding the directories that contain your checkouts. To work with a remote project, clone it with your usual Git tool first.

Contents

• Add your repositories
• Find and select a repository
• Read repository details
• Connect GitHub or GitLab
• Inspect CI
• Run a GitHub Actions workflow
• Maintain discovery paths
• Discovery and connection reference
• Troubleshooting by symptom

Add your repositories

1. Open Paths in the main panel controls, or Configure discovery paths in an empty repository list.
2. In Directory to scan for repositories, enter an existing absolute directory, such as C:\Projects or /home/alex/projects.
3. Set the search depth, then click Add discovery path (the plus button) or press Enter.
4. Wait for the scan to finish, then select a checkout in Repositories.

You can use Browse for a directory instead of typing. Set the depth first: accepting a folder in the picker adds it immediately.

Discovery Paths separates Folders to scan from verified Repository checkouts, grouped under their canonical checkout. Use its vertical scrollbar to reach entries in a longer list.

Each checkout shows its BRANCH, compact M/U counts, and ↑ n ahead / ↓ n behind relative to its configured upstream. See Working-tree status for these counts and unavailable values. Click its folder button to open the checkout in your system's file manager.

Modified shows how long ago the newest tracked or non-ignored untracked project file changed, including uncommitted edits. Hover for the exact local date and time. The scan excludes Git administration, ignored untracked files, symbolic links, directory junctions and nested checkouts.

Use Sort by to choose Name (A–Z), Last modified (newest first) or Last modified (oldest first). Sorting applies to configured checkouts and related-worktree previews within each family. Rows with Modified: Unknown come last in either age order.

Choose the search depth

For example, finding C:\Projects\team\app from C:\Projects needs depth 2. Adding C:\Projects\team\app directly needs depth 0.

Enter a directory path without shell quotation marks. A repository URL or .git file is not a discovery path. Invalid paths or depths produce a message in the editor; correct it and try again.

Discovery stops at each checkout and skips some dependency and temporary directories. If a checkout is missing, add its exact path at depth 0, or check the discovery rules.

Find and select a repository

Type part of a repository name or local path into Filter repositories (* and ?). Matching ignores case. Use * for any amount of text and ? for one character; for example, app*test finds names or paths containing both parts in that order. Ordinary text such as engine needs no asterisks.

Click a repository header to select it and expand its details. Click it again to clear the selection. Selection changes the repository used by panels such as Worktree and Search; existing terminals continue in their own working directories.

Names come from checkout directory names. If names repeat, use the expanded PATH to identify the right checkout. Clear the filter with its clear button or Escape. To search file contents, use Search.

Linked worktree families

Linked worktrees appear beneath their main checkout. Use the family arrow to collapse or expand them; click a checkout's name to select it. Matching worktrees remain visible while filtering, even in a collapsed family.

A main-checkout heading outside your discovery paths serves only as a group label. Select one of its discovered worktrees, or add the main checkout's path to use it directly. Each worktree must be covered by discovery; grouping does not add locations outside that scope.

Read repository details

Click PATH to browse the checkout's files. The actions beneath it open Git Log, LOC History, and Treemap, or prepare a REVIEW ARCHIVE. Click an icon under LAUNCHERS to start that launcher in the checkout; hover it for its name.

See Git, files, and diffs for file and history tasks, Usage, notes, and insights for visualizations, and Launchers, accounts, and add-ons for launcher setup.

Working-tree status

Compact badges use M for modified tracked paths and U for untracked paths: 3 M · 2 U means three tracked changes and two untracked paths. Hover for the full counts when a badge shows 99+. ? marks unavailable status; 0 M · ? U means no tracked changes were found but the untracked count is unknown. A failed status refresh does not leave the checkout labelled Clean.

Ignored files are excluded from these counts. A nested untracked repository can count as one directory rather than every file inside it; select that repository separately to inspect its contents. Use Worktree to identify the changed paths.

Ahead/behind information depends on your last fetch; fetch through your normal Git workflow before relying on it as current remote state.

The compact branch symbol marks a branch different from the locally known default. CI's Default branch label uses the hosting service's default branch, so the two can differ when local remote-tracking information is stale. Each CI run shows its own ref separately.

The branch list

Expand Branches (N) to inspect branch names. L marks a local branch, R a locally known remote-tracking branch, and a dot marks the current local branch. Paired local/upstream branches appear together; remote-only entries keep names such as origin/topic.

This list is for inspection. Use Git Log's Prune action to delete an eligible merged branch, or your normal Git tools to switch, create, or merge branches.

A terminal activity marker on a repository row is separate from Git status. Hover it for session notices and counts; click an actionable notice to reveal the associated terminal.

Connect GitHub or GitLab

Choose which Git remote supplies the checkout's hosted project details and CI:

1. Select and expand the checkout in Repositories.
2. Under its path, open Hosting remote and choose an existing remote.
3. Wait for the chosen name and repository details to refresh; read any error beneath Hosting remote. Then expand GitHub Actions or GitLab CI.

If saving fails, the previous choice is retained.

The default is origin. The saved choice belongs to that checkout; linked worktrees can choose different hosting remotes. For example, choose upstream to read the upstream project's CI while origin points to your fork. Configure Git fetch and push destinations with your usual Git tools.

If the chosen remote is missing or its host is unsupported, select a suitable existing remote or repair its URL with Git. Logonomic reports the problem rather than choosing another remote. If the wrong project appears, check Hosting remote and that remote's URL. Normal HTTPS and SSH remotes are supported, including nested GitLab namespaces. Custom SSH aliases are not automatically recognized. A disabled selector can indicate a checkout or saved-settings problem; read its error before retrying.

GitHub.com and GitLab.com integration is available in Logonomic and Logonomic Pro. Self-managed GitLab integration is available in Logonomic Pro. Ordinary Git use with any host is available in every edition. GitHub Enterprise Server has no built-in integration. See Features by edition for the full reference.

Logonomic does not bundle or install gh or glab. Install only the CLI for the hosting integration you want to use; ordinary Git work does not require either. Provider CLI sign-in is separate from SSH keys or credentials used by Git, and from AI launcher accounts. After installing a CLI or changing the environment used to start Logonomic, restart Logonomic so it can use the change.

GitHub.com

1. Install GitHub CLI (gh) using its official installation instructions and make it available on Logonomic's PATH.

2. Under the same operating-system account, run:

   gh auth login --hostname github.com
   gh auth status --hostname github.com
   

3. Sign in with an account that can read the project and its Actions data. Running workflows also requires submission permission.

4. Select the checkout in Repositories and expand GitHub Actions.

See the GitHub CLI authentication manual for login options.

GitLab.com

1. Install GitLab CLI (glab) 1.87 or newer using its official installation instructions and make it available on Logonomic's PATH.

2. Run:

   glab version
   glab auth login --hostname gitlab.com
   glab auth status --hostname gitlab.com
   

3. Sign in with an account that can read the project and CI information.

4. Select the checkout and expand GitLab CI.

See GitLab CLI login for login options.

Self-managed GitLab in Logonomic Pro

Install glab 1.87 or newer, then authenticate to your instance:

glab auth login --hostname gitlab.example.com
glab auth status --hostname gitlab.example.com

Replace the example with your host. The integration requires an HTTPS API endpoint and credentials stored for that host. A generic GITLAB_TOKEN, GITLAB_ACCESS_TOKEN, or OAUTH_TOKEN environment variable is not used to authenticate self-managed instances.

If the instance uses a separate SSH host, a nondefault HTTPS port, or a relative URL root, follow Advanced GitLab host configuration before selecting the checkout.

Respond to a sign-in badge

Hover GitHub sign-in or GitLab sign-in in the status bar for the suggested CLI command. Run it in a terminal, then click the badge to retry access. Clicking a CI badge does not run the interactive CLI login.

If the host also needs ordinary Git authentication, the badge can open a Git credential-helper window. Check the taskbar if that window appears behind Logonomic. Still refused calls for checking the account's repository permissions as well as its credentials. Dismissing the badge hides it until the host is needed again.

Inspect CI

Select the repository and expand GitHub Actions or GitLab CI. Each run shows its latest available status, title, ref, and shortened commit ID. Use the circular-arrow refresh button to check for updates, or click a workflow name / Pipeline to open the hosting website for full history, job logs, and provider actions.

Latest runs across refs means the results can come from a different branch or tag from your checkout. Default branch names the service's default; it does not identify the displayed run's ref.

• Matches checkout commit means the run's full commit ID matches the selected checkout's commit. It does not cover uncommitted changes.
• Different commit means the run belongs to another commit.
• Comparison unavailable means Logonomic could not compare the commit IDs.

Hover the ref/commit or comparison text for the full commit IDs. Updated (or Created) describes the run's time from the hosting service. Last checked says when Logonomic last successfully read that target's history; hover the time for exact timestamps.

The collapsed summary's Oldest check is the oldest successful check among the loaded targets. A checked count such as 2/3 checked means one loaded target has not been checked successfully. Refreshing or a failed refresh keeps the last known result and its check time visible. A partial refresh can update some targets while others retain older information; inspect each target's Last checked and error.

Most statuses follow the provider's terminology. Action required or Blocked means you should open the provider website. Partial, Unavailable, or Not checked means some history is missing or could not be refreshed; read any error and refresh. No run means the provider reported no runs for that target at its last successful check.

GitHub Actions workflows and history

Active workflows appear in the list. Use More to load further workflows. Logonomic checks the latest run of each loaded workflow across refs. Open the workflow page for its full history.

A workflow may have status and a browser link without a manual-run button. Manual submission has separate requirements, described below.

GitLab CI pipelines

GitLab shows one Pipeline entry when the project's CI/CD feature is enabled. It uses the latest pipeline by ID and links to the project's pipelines page. Pipeline history is independent of the CI configuration in the selected checkout or on the remote default branch, including when that configuration moves or is removed.

No run means GitLab reported no pipelines. An access or loading failure appears as an error; read the message and refresh after correcting the problem.

Use GitLab's website or CLI to submit, retry, or cancel pipelines and enter variables. Those actions are not available in Logonomic's GitLab panel.

Run a GitHub Actions workflow

The form runs the branch or tag entered in Execution ref on the remote. Local and unpushed changes are not included.

To run a workflow from Logonomic:

1. Select the checkout and expand GitHub Actions.
2. Click the workflow's rocket button, Configure and run workflow.
3. Review Execution ref (branch or tag). The form suggests a remote branch corresponding to the selected checkout when one can be identified; otherwise it starts with the remote default branch. Enter the pushed branch or tag you intend to run.
4. Wait for that ref's workflow definition to load, review its inputs, then fill them out and click Submit once. Required inputs have an asterisk.
5. Read the outcome and submitted Execution ref beneath the workflow, then refresh or open GitHub to follow the run.

The rocket appears for an active workflow when your account can submit Actions runs. Open its form to choose the execution ref and inspect that ref's inputs.

The branch or tag in Execution ref supplies the workflow definition and inputs. Its definition must declare workflow_dispatch with supported inputs, and the workflow file must also exist on the remote default branch. Push the intended commits first and ensure the branch or tag exists on the remote. An unreadable definition or a ref without manual dispatch leaves Submit unavailable; read the message, correct the ref or workflow, and refresh CI.

String and environment inputs use text fields; enter an environment name directly. Number inputs use a decimal point. Boolean inputs use switches, and choices use lists. Defaults come from the selected ref's workflow definition. See Workflow form limits if Submit is unavailable.

Changing Execution ref reloads the inputs. An entered value stays when its input name and type still match; a choice also needs to remain in the new list. Other inputs start with the new definition's initial values, and removed inputs leave the form. Review the resulting inputs before submitting.

Each checkout and workflow keeps its unfinished execution ref and input values while Logonomic remains open. Collapse CI, select another repository, open another workflow's form, or refresh CI, then return to the workflow and open its form to continue. Reset clears that workflow's draft and restores the suggested ref and initial input values. Closing Logonomic ends these drafts.

Before submitting, Logonomic checks the project, access and workflow definition again. A changed project or an input that was removed or changed type can stop submission. Read the message, refresh CI and review the form before trying again.

Read the submission outcome before retrying

Only one submission can be pending at a time. Switching repositories or closing the form does not cancel a submitted run; cancel it on GitHub if needed.

Maintain discovery paths

In Paths, click an existing path to edit it, or use Browse for a replacement directory. Press Enter or move focus away to save; Escape abandons a path edit. Edit the adjacent depth separately. Accepted changes save immediately.

Click Remove discovery path to stop searching that path. This leaves its files and terminals intact. Locations covered by another discovery path remain listed. A location with an open terminal can remain marked to be removed until its last terminal closes.

Use Rescan paths after adding or moving checkouts, reconnecting a drive, or changing search scope. Directory changes can also update the list automatically. Wait for a scan to finish before selecting another repository. Rescanning searches local directories; fetch remote changes with Git.

A path marked (missing) is still configured. Restore its directory or drive, replace the path, or remove it.

Add related worktrees outside discovery

1. Open Discovery Paths from Paths and let discovery finish.
2. Click Find related worktrees to preview Git-registered checkouts outside your configured paths that belong to already-discovered repositories.
3. Select the completed, available entries you want, then click Add to Discovery Paths (n). They are added as exact discovery paths at depth 0.

During the scan, Find related worktrees reads Checking.... Registered entries appear as they are checked. Progress shows the current path and stage, with location, file or checkout counts as those steps run. Rows marked Checking checkout... become selectable once their checks finish and they are available.

Cancel stops the scan and keeps completed results. Clicking Add to Discovery Paths (n) during a scan stops it, then checks that only the selected worktrees are still registered before adding them.

The preview groups checkouts under their canonical checkout. Each candidate shows the path, branch, status, and source checkout after Related to. Choices start unchecked. Missing, unavailable, bare, and prunable entries cannot be selected; their status explains why. Available locked checkouts can be selected. For a failed or partial addition, see Troubleshooting by symptom.

Discovery and connection reference

Understand what discovery includes

Discovery recognizes ordinary checkouts, linked worktrees, and submodules, but stops descending when it finds a checkout. Add a nested submodule or clone explicitly if you want its own row. Bare repositories have no worktree to browse.

When searching below a configured path, discovery skips:

• Names beginning with . or _.
• node_modules, build, fetched_libs, worktrees, codex_scratch, and scratch.
• Symbolic-link child directories.

To include an excluded folder, add that folder itself as a discovery path. To include one checkout beneath it, add the checkout at depth 0. Separate clones remain separate repositories; linked worktrees are grouped as locations of one repository.

Repair discovery configuration

An unreadable or malformed configuration produces an error naming its file. Correct permissions or restore a valid copy, then restart Logonomic. To reset discovery, back up that file before removing it, restart, and add your paths again.

For managed configuration, edit the profile's repo_discovery.json while Logonomic is closed:

{
  "discovery_roots": [
    { "path": "C:/Projects", "depth": 1 },
    { "path": "D:/Work/team", "depth": 2 }
  ]
}

Use existing absolute paths and integer depths from 0 through 32. An omitted depth defaults to 1. The error message identifies the active profile's file location.

CLI environment settings

For GitHub.com, Logonomic supports stored gh credentials or GH_TOKEN / GITHUB_TOKEN; GH_CONFIG_DIR selects the CLI configuration location.

For GitLab.com, it supports stored glab credentials or GITLAB_TOKEN, GITLAB_ACCESS_TOKEN, or OAUTH_TOKEN; GLAB_CONFIG_DIR selects the configuration location. These variables must be present in the environment used to start Logonomic. Self-managed GitLab uses its stored host credentials instead.

Advanced GitLab host configuration

For an instance such as https://gitlab.example.com:8443/gitlab, configure the CLI entries for each transport host used by your selected hosting remotes and for the canonical GitLab host. They must identify the same HTTPS API instance, including its port and relative root.

Check each relevant entry:

glab config get api_host --host HOST
glab config get api_protocol --host HOST
glab auth status --hostname HOST

Use GitLab CLI's --api-host, --api-protocol, and --ssh-hostname login options and your administrator's addresses. See the connection guide for certificate setup.

For an SCP-style remote such as [email protected]:group/project.git, the local ssh command must also be available. The project's advertised clone address must agree with the chosen Hosting remote.

Workflow form limits

The GitHub form supports string, number, boolean, choice, and environment inputs, with up to 25 inputs and 100 options per choice. A required text input must be nonempty, and numbers must be finite. An unsupported or unreadable definition leaves Submit unavailable. Choose another pushed ref or correct the workflow definition, then refresh CI. Submission requires a repository YAML definition at the selected ref and a workflow file on the default branch.

Troubleshooting by symptom