Github RepoとPackageの違いと使い分け。

# Distributing Your Jibber Service: Repo vs. GitHub Packages

A quick comparison of two ways to share your GraalVM-native Jibber application with colleagues, and what their local experience looks like in each case.

---

## 1. Distribution via GitHub Repository

#### What you share
- **Source code** (Java + Spring Boot, `pom.xml`/`build.gradle`)
- **Dockerfile.multiarch**
- Any scripts or docs

#### What users must install/configure
1. **GraalVM AOT toolchain**  
   - GraalVM Community or Enterprise  
   - `native-image` plugin (`gu install native-image`)
2. **Build tools**  
   - Maven / Gradle  
3. **Container tooling**  
   - Docker Engine ≥ 20.10 with Buildx + QEMU  
   - OR Podman + binfmt setup  
4. **Optional**: Git, Java IDE, etc.

#### Steps to run locally
```bash
git clone https://github.com/you/jibber.git
cd jibber
```

#### 1) Build native image
```
mvn clean package -Pnative -DskipTests native:compile
```

#### 2) Build container (multi-arch requires Buildx & QEMU)
```
docker buildx build \\
  --file Dockerfile.multiarch \\
  --platform linux/amd64,linux/arm64 \\
  -t ghcr.io/you/jibber:local \\
  .
```

#### 3) Run container
```
docker run -d --name=jibber -p 8080:8080 ghcr.io/you/jibber:local
curl http://localhost:8080/actuator/health
```

User experience
High setup effort: Installing GraalVM, Maven, Docker Buildx/QEMU (especially for beginners)

Build time: Native-image AOT compile can take minutes

Debug & tweak: Full control to modify source & rebuild

Risk of “works on my machine” issues around glibc vs. musl, Docker versions, plugin versions, etc.

## 2. Distribution via GitHub Packages (GHCR)
What you share
Multi-arch container image pushed to GHCR under one tag (e.g. ghcr.io/bull2023x/jibber:latest)

What users must install/configure
Container runtime

Docker Desktop (with WSL 2 / containerd)

OR Rancher Desktop (with nerdctl)

GitHub PAT with read:packages scope (for private images)

No GraalVM or Maven needed

Steps to run locally
```bash
Always show details

# 1) Authenticate (one-time)
echo <PAT> | docker login ghcr.io -u <GHUSER> --password-stdin

# 2) Pull & run
docker pull ghcr.io/bull2023x/jibber:latest
docker run -d --name=jibber -p 8080:8080 ghcr.io/bull2023x/jibber:latest

# 3) Verify
curl http://localhost:8080/actuator/health
(Replace docker with nerdctl if using Rancher Desktop.)
```

User experience
Minimal setup: Just Docker Desktop or Rancher Desktop

Instant start: No local build, seconds to pull & run

Guaranteed consistency: They run exactly the same binary you built in CI

Easy upgrades: docker pull … && docker run …

## 3. Side-by-Side Comparison
| Aspect               | GitHub Repo                               | GitHub Packages (GHCR)                |
| -------------------- | ----------------------------------------- | ------------------------------------- |
| ****Artifacts shared**** | Source code + Dockerfile                  | OCI image (multi-arch)                |
| ****Prerequisites****    | GraalVM, Maven/Gradle, Docker Buildx/QEMU | Docker Desktop / Rancher Desktop, PAT |
| ****Time to run****      | Minutes (build + push)                    | Seconds (pull + run)                  |
| ****OS dependency****    | Host must have correct glibc, Java tools  | Container isolates OS differences     |
| ****Ease of use****      | Moderate–high                             | Very low                              |
| ****Rebuild control****  | Full rebuild from source                  | Read-only binary; no rebuild          |
| ****Troubleshooting****  | Compiler errors, dependency issues        | Container runtime logs only           |



## 4. Recommendation for Beginners
Use GitHub Packages when you want colleagues to “one-line pull & run” without installing GraalVM, Maven, or Buildx/QEMU.

Reserve Repo distribution for when they need to modify the code, debug, or extend the application itself.

By offering both—source in the repo and ready-to-run images on GHCR—you cover both advanced contributors and casual users equally well.