Add release pipeline and upgrade toolchain to TypeScript 7
Publish snapshot / snapshot (push) Failing after 1m58s

Publishing infrastructure
- Three Gitea workflows: ci.yml (PRs, non-main pushes), publish-snapshot.yml
  (main -> Gitea under dist-tag @main) and release.yml (tags -> Gitea + npmjs)
- Tag-driven releases as <package-dir>-v<version>; the manifest stays the
  source of truth and release.yml refuses to run if tag and manifest disagree
- Every publish is idempotent: each step checks the registry first, so a run
  that fails on the second registry can simply be re-run
- Hard coverage gate (85% branches) shared by CI, the pre-push hook and local
  runs, since the thresholds live in vitest.config.ts rather than a CI flag
- README.PUBLISH.md documents the whole mechanism

Toolchain
- TypeScript 7 native compiler; drop tsgo and ts-node, use tsx for dev runs
- Biome 1.9 -> 2.x, Vitest 1 -> 4, zod 3 -> 4, inquirer 8 -> 14, pnpm 11.17.0
- Replace inquirer-checkbox-plus-prompt, which is peer-capped at inquirer <9,
  with enquirer's AutoComplete; the CubeSelection contract is unchanged
- Stand in for zod 4's removed z.AnyZodObject with a local AnyObjectSchema

Repo hygiene
- Stop tracking dist/; ignore coverage/, *.tsbuildinfo, .npmrc* and release.json
- Drop package-lock.json in favour of pnpm-lock.yaml

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Benjamin Diedrichsen
2026-07-27 15:17:14 +02:00
parent 736c01216a
commit 587ff2cf47
126 changed files with 6065 additions and 7544 deletions
+82
View File
@@ -0,0 +1,82 @@
# Testing Nopy with Docker
This guide explains how to set up a local Docker container to test `nopy` deployments using the provided `Ubuntu-24LTS.Dockerfile` and `example.nopysession.json`.
## Prerequisites
- Docker installed and running on your machine.
- `nopy` installed and linked (see [README.md](./README.md)).
## 1. Setup SSH Key (Important)
The provided `Ubuntu-24LTS.Dockerfile` contains a hardcoded public SSH key. Before building, you **must** replace it with your own public key to allow SSH access (if needed) or ensure `pyinfra` can connect if it uses SSH transport.
1. Open `Ubuntu-24LTS.Dockerfile`.
2. Locate the line starting with `echo "ssh-ed25519 ...`.
3. Replace the key string with the content of your own public key (usually `~/.ssh/id_ed25519.pub` or `~/.ssh/id_rsa.pub`).
```dockerfile
# Example replacement
RUN mkdir -p /home/testuser/.ssh && \
echo "YOUR_PUBLIC_KEY_HERE" >> /home/testuser/.ssh/authorized_keys && \
...
```
## 2. Build the Docker Image
Run the following command from the `packages/nopy` directory:
```bash
docker build -f Ubuntu-24LTS.Dockerfile -t nopy-test-ubuntu .
```
## 3. Run the Container
Start the container in the background. We explicitly name it `nopy-test-container` because the `example.nopysession.json` is configured to target this specific container name.
```bash
docker run -d \
--name nopy-test-container \
--privileged \
-p 2222:22 \
nopy-test-ubuntu
```
- `--name nopy-test-container`: Matches the host defined in `example.nopysession.json`.
- `--privileged`: Required for some system-level operations (like `criu` or service management) if tested.
- `-p 2222:22`: Maps the container's SSH port to local port 2222 (optional, allows manual SSH connection).
## 4. Deploy using Nopy
Now you can run the example session. Nopy uses `pyinfra`'s `@docker` connector to communicate directly with the container, so SSH keys are not strictly required for the *deployment* itself, but the session is configured to simulate a realistic environment.
```bash
nopy install -l example.nopysession.json
```
If successful, `nopy` will execute the `apt:essentials` cube against the container.
## 5. Manual Verification
You can connect to the container manually to verify changes:
**Via Docker Exec:**
```bash
docker exec -it nopy-test-container bash
```
**Via SSH (if configured):**
```bash
ssh -p 2222 testuser@localhost
# Password: password
```
## 6. Cleanup
To stop and remove the container:
```bash
docker rm -f nopy-test-container
```
+41
View File
@@ -0,0 +1,41 @@
# Nopy Refactoring Plan
This document tracks the major refactoring of the `nopy` package.
## Refactoring Items
### 1. Remove parallel execution
- **Status**: ✅ Completed
- **Goal**: Remove all logic supporting parallel execution of cubes to simplify the execution flow and improve reliability.
- **Context**:
- Parallelism removed from `NopyConfig`, `NopyOptions`, and `executeDeployCalls`.
- `buildExecutionStages` deleted.
- CLI flags `--parallel` and `--concurrency` removed.
- **Proposed Solution**: (Done)
### 2. Rework cube building process & Dependency Resolution
- **Status**: ✅ Completed
- **Goal**: Allow dependencies to be defined as a function of the collected variables.
- **New Signature**: `dependencies?: (variables: CubeVariables) => DependencySpec[]`
- **Architectural Change**: Implement a clean, step-based resolution mechanism using a `BuildContext`.
- **Context**:
- Introduced `BuildContext` in `cubes/dependencies.ts` which handles recursive resolution, variable collection, and hook execution.
- Resolution is now dynamic: variables are collected for a cube before its dependencies are resolved.
- **Proposed Solution**: (Done)
### 3. Remove `env` property from cube Manifest
- **Status**: ✅ Completed
- **Goal**: Remove the `env` property from the cube manifest.
- **Context**:
- `env` removed from `Manifest` and `Env` types.
- Responsibility for defaults shifted entirely to Zod schema defaults and `getDefaults()`.
- **Proposed Solution**: (Done)
### 4. Redesign Manifest and Cube types
- **Status**: ✅ Completed
- **Goal**: Transition from `Env -> Manifest -> Cube` inheritance to a cleaner `Manifest` (specification) and `Cube` (runtime) separation.
- **Context**:
- `Manifest` is now a clean interface with a factory namespace.
- `Cube` is a class encapsulating a `Manifest` and runtime info (`dir`, `deployScript`).
- **Proposed Solution**: (Done)
+21
View File
@@ -0,0 +1,21 @@
# Vagrant
`vagrant ssh-config` to find the SSH port of the machine
`vagrant status --machine-readable` will be executed by pyinfra to get information about available VMs
```ruby
Vagrant.configure("2") do |config|
# DO NOT USE special characters in vm name
config.vm.define "nopytestvm"
config.vm.provider "vmware_desktop" do |vmware|
vmware.gui = false
vmware.allowlist_verified = true
end
config.vm.box = "bento/ubuntu-24.04" # Use Ubuntu 24.04 box
config.ssh.insert_key = false
config.vm.box_check_update = false
config.vm.hostname = "nopytestvm"
end
```