Apio Repositories¶
Apio uses GitHub repositories under the FPGAwars organization for its source code, documentation, daily builds, and runtime packages.
Apio applications
| Repository | Application | Comments |
|---|---|---|
| fpgawars/apio | Apio CLI | Command line tool |
| fpgawars/apio-vscode | Apio IDE | Vs Code extension |
Apio packages
| Repository | Package name | Comments |
|---|---|---|
| fpgawars/apio-definitions | definitions |
|
| fpgawars/tools-drivers | drivers |
Windows only |
| fpgawars/apio-examples | examples |
|
| fpgawars/tools-graphviz | graphviz |
Windows only |
| fpgawars/tools-oss-cad-suite | oss-cad-suite |
|
| fpgawars/tools-verible | verible |
Utilities
| Repository | Description |
|---|---|
| fpgawars/apio-workflows | Provides common functionalities for Apio's workflows. |
For easier tracking and maintenance, all bug reports and discussions are consolidated in the main Apio repository: fpgawars/apio, which also serves as the project’s homepage.
Repositories dependencies¶
The following diagram shows the dependencies between the repos. At build time, the apio-workflows repos provides common actions to the build workflows in the the other repos. At runtime, the Apio IDE app loads the Apio CLI app, which loads the individual Apio packages that are used on that platform.
Repository branches¶
Apio repositories use the branch main as the main branch. Avoid other names such as master, and develop.
Daily build workflows¶
The Apio repositories contain build workflows, typically at .github/workflows/build-pre-release.yaml which builds the content of the repo and publish it as a temporary pre-release that is deleted after a few days.
-
To make a release permanent, edit it in the Github dashboard and turn off the Set as a pre-release checkbox.
-
To make an permanent release the official latest release, edit it in the Github dashboard and check the Set as the latest release checkbox.
Note that making a release permanent latest doesn't necessary make it used, and in most cases it needs to be 'published' as outlined in the table
| Build type | Publishing |
|---|---|
| Apio packages such as 'examples' or 'oss-cad-suite' | • Update the packages versions in the relevant apio remote config files for the new packages to be picked up. |
| Apio CLI | • Publish in the various 'markets' such as PyPi. |
| Apio IDE | • Publish in the VS Code market. |
Guidelines for daily build workflows¶
- Each repo should build it's own stuff.
- The build workflow should not be triggered by a push but only daily on cron, and manually from the github dashboard.
- An automatic daily build should create a new pre-release with name and tag
yyyy-mm-dd(based on current UTC time). - The daily build should run on cron at midnight UTC (
cron: "0 0 * * *") to reduce the chance of overwriting a manual build with same date. - Only a few N pre-releases should be kept (use automatic cleanup in the build daily workflow).
- If the build workflow deals with binaries (e.g. verible or oss-cad-suite packages), it should run virus scan (e.g. ClamAV).
- The builds should be from the latest commit of the repo (down the road we can add manual sha overrides).