Skip to content

Commit 8aaa49f

Browse files
ZaouiAmineZaouiAmine
committed
Understanding Taubyte Built-in CI/CD System
1 parent 38d732a commit 8aaa49f

File tree

1 file changed

+236
-0
lines changed

1 file changed

+236
-0
lines changed

‎content/posts/cicd-taubyte.md‎

Lines changed: 236 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,236 @@
1+
---
2+
title: "Understanding Taubyte's Built-in CI/CD System"
3+
author: Zaoui Amine
4+
featured: true
5+
draft: false
6+
tags:
7+
- tutorials
8+
- cicd
9+
- deployment
10+
- wasm
11+
- cloud
12+
image:
13+
src: /blog/images/cicd-system.png
14+
alt: Understanding Taubyte's Built-in CI/CD System
15+
summary: Taubyte includes a built-in CI/CD system that automatically builds and deploys your code when you push to GitHub. Learn how it works, how to configure builds, and how serverless functions compile to WebAssembly.
16+
date: 2026-01-14T17:00:00Z
17+
categories: [Hand-on Learning]
18+
---
19+
20+
Taubyte comes with a **built-in CI/CD system**. Every time you push changes to the branch your nodes are running on, a build is triggered automatically.
21+
22+
> **Note**: When running Dream locally, manual triggering is required since GitHub can't reach your local nodes.
23+
24+
## How It Works
25+
26+
The build process is defined inside the **`.taubyte` folder**, which lives at the root of your codebase. You'll find this folder in the code of any function, website, or library.
27+
28+
### Folder Contents
29+
30+
| File | Purpose |
31+
|------|---------|
32+
| `config.yaml` | Defines the build workflow |
33+
| `build.sh` | Script executed by the workflow |
34+
| Additional files | Build-specific assets |
35+
36+
## The Configuration File
37+
38+
The `config.yaml` file is simple and powerful. It defines:
39+
40+
1. **Environment**: Docker image and environment variables
41+
2. **Workflow**: Steps to run (each step is a shell script)
42+
43+
### Example config.yaml
44+
45+
```yaml
46+
version: "1.0"
47+
environment:
48+
image: node:alpine
49+
variables:
50+
NODE_ENV: production
51+
PUBSUB_TOPIC: transactions
52+
workflow:
53+
- generate.sh
54+
- test.sh
55+
- build.sh
56+
```
57+
58+
### Configuration Breakdown
59+
60+
| Field | Description | Example |
61+
|-------|-------------|---------|
62+
| `version` | Config format version | `"1.0"` |
63+
| `environment.image` | Docker image for builds | `node:alpine` |
64+
| `environment.variables` | Environment variables | Key-value pairs |
65+
| `workflow` | Ordered list of scripts | `["generate.sh", "test.sh", "build.sh"]` |
66+
67+
## Convention Over Configuration
68+
69+
The CI/CD system relies on **conventions, not heavy configuration**:
70+
71+
- If all steps succeed, the `/out` folder is archived and compressed
72+
- That archive becomes your published asset
73+
- No complex YAML pipelines or configuration files
74+
75+
## Building Serverless Functions
76+
77+
For serverless functions, Taubyte currently supports **WebAssembly only**. We provide specialized containers to make this easy.
78+
79+
### Official Build Containers
80+
81+
| Language | Container | Use Case |
82+
|----------|-----------|----------|
83+
| Go | `taubyte/go-wasi` | Go functions |
84+
| Go (libraries) | `taubyte/go-wasi-lib` | Go libraries |
85+
| Rust | `taubyte/rust-wasi` | Rust functions |
86+
| AssemblyScript | `taubyte/assemblyscript-wasi` | AS functions |
87+
88+
### Go Example
89+
90+
**config.yaml**:
91+
```yaml
92+
version: "1.0"
93+
environment:
94+
image: taubyte/go-wasi
95+
workflow:
96+
- build.sh
97+
```
98+
99+
**build.sh**:
100+
```bash
101+
#!/bin/bash
102+
go mod tidy
103+
tinygo build -o /out/main.wasm -target wasi .
104+
```
105+
106+
### Rust Example
107+
108+
**config.yaml**:
109+
```yaml
110+
version: "1.0"
111+
environment:
112+
image: taubyte/rust-wasi
113+
workflow:
114+
- build.sh
115+
```
116+
117+
**build.sh**:
118+
```bash
119+
#!/bin/bash
120+
cargo build --release --target wasm32-wasi
121+
cp target/wasm32-wasi/release/*.wasm /out/main.wasm
122+
```
123+
124+
## Understanding WASI
125+
126+
**WASI** (WebAssembly System Interface) is a standard that extends WebAssembly beyond the browser. It enables Wasm to run safely and efficiently in server, edge, and cloud environments.
127+
128+
### What WASI Provides
129+
130+
| Capability | Description |
131+
|------------|-------------|
132+
| File access | Read/write files in sandbox |
133+
| Networking | HTTP requests, sockets |
134+
| Randomness | Cryptographic random numbers |
135+
| Environment | Environment variables |
136+
| Clocks | Time and timing functions |
137+
138+
### Why WASI Matters for Taubyte
139+
140+
WASI modules can interact with the outside world in a **controlled, portable way**. This means:
141+
142+
- **Sandboxed execution**: Your code runs in isolation
143+
- **Cross-platform**: Same binary runs on any node
144+
- **Language agnostic**: Go, Rust, or AssemblyScript compile to the same target
145+
- **Consistent behavior**: No platform-specific surprises
146+
147+
## Output Requirements
148+
149+
### For Functions
150+
151+
Your build must output a file at:
152+
```bash
153+
/out/main.wasm
154+
```
155+
156+
This is the WebAssembly binary that gets deployed.
157+
158+
### For Websites
159+
160+
All files must be placed in:
161+
```bash
162+
/out/
163+
```
164+
165+
The entire folder contents become your static site.
166+
167+
### Website Example
168+
169+
**config.yaml**:
170+
```yaml
171+
version: "1.0"
172+
environment:
173+
image: node:18-alpine
174+
variables:
175+
NODE_ENV: production
176+
workflow:
177+
- build.sh
178+
```
179+
180+
**build.sh** (for a React app):
181+
```bash
182+
#!/bin/bash
183+
npm install
184+
npm run build
185+
mkdir -p /out
186+
cp -r build/* /out/
187+
```
188+
189+
190+
## Triggering Builds
191+
192+
### In Production
193+
194+
Builds trigger automatically when you push to GitHub (via webhook).
195+
196+
### In Dream
197+
198+
Manually trigger builds:
199+
200+
```bash
201+
# Build all repositories
202+
dream inject push-all
203+
204+
# Build specific repository
205+
dream inject push-specific <repo-id>
206+
```
207+
208+
## Tips for Faster Builds
209+
210+
1. **Use Alpine images**: Smaller images download faster
211+
2. **Cache dependencies**: Some containers cache npm/go modules
212+
3. **Minimize assets**: Smaller outputs deploy faster
213+
4. **Use libraries**: Compile shared code once, use everywhere
214+
215+
## Common Build Issues
216+
217+
| Issue | Cause | Solution |
218+
|-------|-------|----------|
219+
| `/out/main.wasm` not found | Build output in wrong location | Check `build.sh` output path |
220+
| Docker image not found | Typo in image name | Verify container name |
221+
| Build timeout | Long compilation | Optimize code, split into libraries |
222+
| Missing dependencies | Not in container | Add `npm install` or `go mod tidy` |
223+
224+
## Conclusion
225+
226+
Taubyte's CI/CD system is designed for simplicity:
227+
228+
- **Convention-based**: Minimal configuration required
229+
- **WebAssembly-first**: Portable, secure, fast
230+
- **Automatic deploys**: Push to GitHub, get deployed
231+
- **Built-in containers**: No need to manage build infrastructure
232+
233+
Every push builds and publishes your serverless functions and static websites automatically, keeping deployment simple and seamless.
234+
235+
Next, learn about [working with branches](/blog/posts/branches-taubyte) for feature development and testing.
236+

0 commit comments

Comments
 (0)