feat: one-command install, aap-bridge lifecycle, and configurable ports - #176
Open
antonysallas wants to merge 1 commit into
Open
antonysallas wants to merge 1 commit into
antonysallas wants to merge 1 commit into
Conversation
…ports
Installing meant cloning the repository and running `make setup` - a developer
workflow that builds a .venv inside the checkout, installs requirements-dev.txt,
and runs `pre-commit install`. Someone who only wants to run a migration needs
none of it and should not have to keep a source tree on disk.
This adds one command to set AAP Bridge up, one to operate it afterwards, and
one to remove it.
Install
-------
`scripts/install.sh` asks how you want to run AAP Bridge - the `aap-bridge`
command on this machine, or the CLI, API engine, Web UI, and PostgreSQL in
containers - then checks prerequisites, installs what is missing, and ends with
a configured workspace. `--cli` / `--containers`, or AAP_BRIDGE_MODE, skips the
question. Neither journey leaves a source checkout behind.
The container path resolves registry.redhat.io access before it builds anything
rather than warning and then failing five minutes later, verifies every image it
needs, rebuilds only what is out of date (images carry the source revision they
were built from), captures build output to <workspace>/logs/install.log, and
starts and verifies the stack. A failed build is resumable.
An existing workspace is a normal thing to find - a reinstall, an upgrade, a
second run after a failure. The installer inspects it before installing anything
and offers to use it as-is, reconfigure the settings without touching migration
data, or choose another directory.
Operate
-------
Both installations put the same `aap-bridge` command on PATH:
aap-bridge the CLI, interactively
aap-bridge doctor system, workspace, database, services, AAP
aap-bridge status what is running
aap-bridge stop / start pause and resume, keeping state
aap-bridge logs
aap-bridge uninstall
For a container installation these run a launcher in the workspace; how AAP
Bridge is deployed is chosen once, at install time, rather than remembered at
every invocation.
`aap-bridge init` writes a self-contained workspace: .env at mode 0600,
config/config.yaml, and the artifact directories. `aap-bridge doctor` checks the
system, workspace, database, services, and both AAP connections in one place;
`--fix` repairs safe local problems and never touches remote systems.
Uninstall
---------
`scripts/uninstall.sh`, also reachable as `aap-bridge uninstall`, removes the
containers, images, and command while keeping the migration workspace by
default. Removing the data as well is a separate choice that must be typed out
in full, because it destroys the only copy of the API tokens and the migration
state. Only images this installer built are removed - never the UBI, Node.js, or
PostgreSQL images they are built from, which other applications may use.
Ports
-----
AAP_BRIDGE_DB_PORT (15432), AAP_BRIDGE_API_PORT (8000), and AAP_BRIDGE_UI_PORT
(8080) are settings recorded in the workspace .env. The installer checks all
three before starting anything and offers a free port when one is taken; a
service whose port is in use starts and then never answers, which is not
something a user can diagnose from the outside.
Fixes carried by the same change
--------------------------------
- Migration artifacts - exports/, xformed/, schemas/, reports/, and the log -
resolve against the workspace root rather than the working directory, so one
migration's files stay together whichever directory a command is run from.
`schema generate`, `prep`, and `migrate` also ignored paths.* entirely and
wrote to fixed relative directories.
- `aap-bridge report` built its statistics from a block of hardcoded zeros. It
now reads the state database - totals, a per-resource-type breakdown, and the
errors behind any failures - and writes into the workspace's reports/ by
default.
- The container workflow could not complete: the CLI container could not write
to a bind-mounted workspace under rootless Podman, and `init` inside a
container fell through to asking for an external PostgreSQL connection string
while the stack it was configuring already contained one.
- Ctrl-C or EOF at any prompt printed a full traceback rather than "Cancelled".
Supersedes the AAP_BRIDGE_API_PORT change, whose commits are included here and
extended to cover the other two published ports.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
antonysallas
force-pushed
the
feat/one-command-install
branch
from
August 22, 2026 14:44
bd3dc96 to
2215822
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why this change
Until now, installing AAP Bridge meant cloning the repository and running
make setup.That workflow is useful for development, but it also:
.venvinside the repositoryNone of that is needed for someone who only wants to run a migration.
This PR adds:
aap-bridgecommand to use and manage it afterwardsBoth command-line and container-based installations are supported.
How to test this PR
Because
scripts/install.shis not onmainyet, the normal published URL will return 404.Option 1 — test using
curlRun the installer from this branch and tell it to use the same branch as its source:
curl -LsSf https://raw.githubusercontent.com/antonysallas/aap-bridge/feat/one-command-install/scripts/install.sh \ | AAP_BRIDGE_REPO=https://github.com/antonysallas/aap-bridge.git \ AAP_BRIDGE_REF=feat/one-command-install shThe two environment variables are important during PR testing. Without them, the installer would use
main, which does not contain these changes yet.Option 2 — test from a local checkout
From a checkout of this branch:
AAP_BRIDGE_SOURCE=$PWD sh scripts/install.shThis uses the local source directly and skips cloning the repository.
Test a specific installation mode
To skip the interactive installation-mode question:
or:
Using
/tmp/aap-testkeeps test data separate from your normal$HOME/aap-migrationworkspace.Uninstall
After testing:
The uninstaller lets you either:
Container installation note
The container installation builds three AAP Bridge images.
It also needs access to
registry.redhat.io. If you are not already logged in, the installer detects this and offers to run the Podman login for you.What changed
One installer
scripts/install.shnow asks how AAP Bridge should run:You can skip this question with:
or with
AAP_BRIDGE_MODE.One command after installation
Both installation modes put
aap-bridgeonPATH.Common commands are:
For container installations, these commands use the workspace launcher internally.
The user chooses the deployment method once during installation and does not need to remember different commands afterwards.
One workspace
By default, AAP Bridge uses:
aap-bridge initcreates:.envwith permissions0600config/config.yamlIf setup is run again against an existing workspace, the installer detects it and offers to:
Other fixes included in this PR
Migration paths now use the workspace
Migration artifacts such as:
now resolve from the workspace instead of the shell's current working directory.
Previously,
schema generate,prep, andmigratealso ignored the configuredpaths.*values and wrote to fixed relative directories.Reports now use real migration data
aap-bridge reportpreviously built its statistics from hardcoded zero values.It now reads statistics from the migration state database and writes reports to the workspace
reports/directory by default.Container workflow fixes
The container workflow previously could not complete successfully because:
initinside the container incorrectly asked for an external PostgreSQL connection stringBoth issues are fixed in this PR.
Configurable ports
The three published container ports can now be configured through the workspace
.env:AAP_BRIDGE_DB_PORTAAP_BRIDGE_API_PORTAAP_BRIDGE_UI_PORTBefore starting services, the installer checks whether these ports are available.
If a port is already in use, it offers the next available port instead of starting a service that cannot be reached.
This supersedes #172, which added support for configuring
AAP_BRIDGE_API_PORT. Those commits are included here and extended to PostgreSQL and Web UI ports.Testing completed
The following have been tested:
8080and15432curl | shcancellation paths, including clean exit without curl errorskacl-verifyChangelog
Entries were added under Unreleased in:
CHANGELOG.mddocs/reference/changelog.md