https://github.com/hagicode-org/vendered
https://github.com/hagicode-org/vendered
Last synced: 27 days ago
JSON representation
- Host: GitHub
- URL: https://github.com/hagicode-org/vendered
- Owner: HagiCode-org
- Created: 2026-05-05T07:14:52.000Z (about 2 months ago)
- Default Branch: main
- Last Pushed: 2026-05-16T06:07:00.000Z (about 1 month ago)
- Last Synced: 2026-05-16T06:20:11.282Z (about 1 month ago)
- Language: JavaScript
- Homepage:
- Size: 165 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# vendered
This repository stores vendored build inputs and CI automation.
- `packages/code-server/` contains the vendored code-server integration.
- `packages/code-server/upstream/` is a Git submodule pointing to `https://github.com/coder/code-server.git`.
- `packages/omniroute/` contains the vendored OmniRoute integration.
- `packages/omniroute/upstream/` is a Git submodule pointing to `https://github.com/diegosouzapw/OmniRoute.git`.
- `.github/workflows/code-server-artifacts.yaml` is the shared vendored pipeline. It resolves one vendored version/tag per run, then builds `code-server` and OmniRoute in parallel, validates both package families, and publishes one shared GitHub Release result.
- `packages/code-server/scripts/build-artifacts.mjs` and `packages/code-server/scripts/verify-startup.mjs` are the Node entrypoints for the build and post-build verification flow.
- `packages/code-server/templates/code-server-config.yaml` and `packages/omniroute/templates/omniroute-config.yaml` are the packaged YAML config templates. Deployment is expected to copy one of these templates into a runtime `config.yaml`, fill in the values, and pass it to the packaged CLI with `--config`.
- `packages/omniroute/scripts/build-artifacts.mjs` and `packages/omniroute/scripts/verify-startup.mjs` are the OmniRoute package-local build and packaged-entry verification entrypoints. The OmniRoute verify step now performs a real `pm2`-managed startup smoke test against the packaged release and waits for `/api/monitoring/health` before publication.
## Terminal usage for published packages
The files under `packages/*/scripts/*.mjs` are maintainer build and verification entrypoints. End users should run the extracted release archives from the GitHub Release assets instead of invoking those repo-local scripts directly.
### code-server
After extracting a published `code-server---` archive, start it from a terminal with the packaged wrapper:
```bash
./bin/code-server --help
./bin/code-server --bind-addr 0.0.0.0:8080 .
```
On Windows, use `.\bin\code-server.cmd`.
If you need the direct Node entrypoint for troubleshooting, use `node ./out/node/entry.js --help` from inside the extracted archive. Do not treat repo-local build scripts as runtime entrypoints.
### OmniRoute
After extracting a published `omniroute---` archive, start it from a terminal with the top-level wrapper:
```bash
./omniroute.sh --help
./omniroute.sh
./omniroute-reset-password.sh
```
On Windows, use `.\omniroute.cmd` or `.\omniroute-reset-password.cmd`.
If you need the direct Node CLI entrypoints, use `node ./bin/omniroute.mjs --help` and `node ./bin/reset-password.mjs` from inside the extracted archive. Do not start the packaged OmniRoute release from `scripts/*.mjs`; those files are support scripts, not supported runtime entrypoints.
## Runtime contract
The vendored terminal programs are designed to run as:
`pm2` -> packaged wrapper -> Node entrypoint
That contract applies to both package families:
- `code-server`: use `./bin/code-server` on Unix-like systems or `.\\bin\\code-server.cmd` under Windows PM2.
- `omniroute`: use `./omniroute.sh` on Unix-like systems or `.\\omniroute.cmd` under Windows PM2.
PM2 should not point directly at `out/node/entry.js`, `bin/*.mjs`, `app/server.js`, or support scripts. Those internal entrypoints are still present in the archive, but the supported runtime surface is the wrapper layer because it is what the packaged verification flow exercises.
## YAML configuration
Both package families ship YAML templates inside the release archive:
- `templates/code-server-config.yaml`
- `templates/omniroute-config.yaml`
The supported deployment flow is:
1. Extract the release archive.
2. Copy the package template to a writable runtime path such as `./config.yaml`.
3. Fill in the YAML values.
4. Start the packaged wrapper through PM2 and pass `--config ./config.yaml`.
The verification scripts enforce this design by materializing a config file from the packaged YAML template and then performing a real PM2-managed wrapper startup check before publication.
## Release versioning
Published builds use a UTC date-based version in `YYYY.MMDD.RRRR` form, where:
- `YYYY` is the UTC year
- `MMDD` is the UTC month and day
- `RRRR` is the zero-padded GitHub Actions run number
For example, the first qualifying workflow run on 2026-05-05 would produce `2026.0505.0001` and tag the repository as `v2026.0505.0001`.
## GitHub Release publication
After both package families finish their per-platform build and verification jobs, the shared workflow creates or updates one repository release tagged with `v` and uploads both the `code-server` and OmniRoute `.zip`, `.tar`, and `.7z` archives from that same run. Asset names stay package-specific so both package families share one vendored release/tag without clobbering one another's archives. Publication still happens automatically on `push` to `main`, and it can also be triggered manually with `workflow_dispatch`. The shared workflow also has a daily schedule, but scheduled runs stop after build and verification so publication remains explicit.
The GitHub release job uses the workflow's built-in `GITHUB_TOKEN`, so no extra repository secret is required.