-
Notifications
You must be signed in to change notification settings - Fork 0
Building With Private Repositories
This guide covers how to build Dynamic Devices Yocto layers when recipes access private repositories, such as the eink-spectra6 userspace library.
Some recipes in the meta-dynamicdevices layers access private GitHub repositories that require SSH key authentication. The build system uses kas-container which runs in Docker, so SSH keys must be properly forwarded from the host to the container.
Ensure you have SSH keys configured for GitHub access:
# Test GitHub SSH access
ssh -T git@github.comExpected output:
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
If this fails, you need to:
- Generate SSH keys:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com" - Add the public key to your GitHub account
- Test the connection again
The SSH agent must be running and have your key loaded:
# Start SSH agent (if not running)
eval "$(ssh-agent -s)"
# Add your SSH key
ssh-add ~/.ssh/id_rsa # or your specific key file
# Verify key is loaded
ssh-add -lExpected output:
4096 SHA256:... your_email@example.com (RSA)
The Dynamic Devices build scripts automatically handle SSH key forwarding:
# Build with automatic SSH forwarding
KAS_MACHINE=imx93-jaguar-eink ./scripts/kas-build-base.shWhat happens automatically:
- ✅ Detects SSH agent (
$SSH_AUTH_SOCK) - ✅ Forwards SSH agent to container (
--ssh-agent) - ✅ Mounts SSH directory (
--ssh-dir ~/.ssh) - ✅ Sets proper permissions in container
- ✅ Handles GitHub host key verification
You can verify SSH access works in the container:
# Enter container shell
./scripts/kas-shell-base.sh
# Inside container, test GitHub access
ssh -T git@github.comProblem: Container doesn't trust GitHub's host key.
Solution: This is handled automatically by kas-container's SSH forwarding.
Problem: SSH key not accessible in container.
Diagnosis:
# Check SSH agent on host
echo $SSH_AUTH_SOCK
ssh-add -l
# Check SSH access on host
ssh -T git@github.comSolutions:
- Ensure SSH agent is running:
eval "$(ssh-agent -s)" - Add your key:
ssh-add ~/.ssh/id_rsa - Verify key permissions:
chmod 600 ~/.ssh/id_rsa
Problem: SSH agent not running.
Solution:
# Start SSH agent
eval "$(ssh-agent -s)"
# Add key
ssh-add ~/.ssh/id_rsa
# Verify
echo $SSH_AUTH_SOCKDebug in container:
# Enter container
./scripts/kas-shell-base.sh
# Check SSH agent in container
echo $SSH_AUTH_SOCK
ssh-add -l
# Test GitHub access
ssh -T git@github.comEnsure correct permissions on host:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/known_hostsIf you use multiple SSH keys, ensure the correct one is loaded:
# List loaded keys
ssh-add -l
# Add specific key
ssh-add ~/.ssh/id_rsa_github
# Test with specific key
ssh -i ~/.ssh/id_rsa_github -T git@github.comYou can use SSH config for complex setups:
# ~/.ssh/config
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa_github
IdentitiesOnly yesFor automated builds in GitHub Actions:
- name: Setup SSH Agent
uses: webfactory/ssh-agent@v0.7.0
with:
ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
- name: Build with Private Repos
run: |
KAS_MACHINE=imx93-jaguar-eink ./scripts/kas-build-base.shFor GitLab CI/CD:
before_script:
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
build:
script:
- KAS_MACHINE=imx93-jaguar-eink ./scripts/kas-build-base.shFor Jenkins with SSH Agent plugin:
sshagent(['github-ssh-key']) {
sh 'KAS_MACHINE=imx93-jaguar-eink ./scripts/kas-build-base.sh'
}The following recipes access private repositories:
| Recipe | Repository | Purpose |
|---|---|---|
eink-spectra6 |
git@github.com:DynamicDevices/eink-spectra6.git |
Spectra 6 E-Ink display userspace library |
spi-lib |
git@github.com:DynamicDevices/spi-lib.git |
SPI library for radar presence detection |
When creating recipes for private repositories:
-
Use SSH protocol:
SRC_URI = "git://git@github.com/DynamicDevices/my-private-repo.git;protocol=ssh;branch=${SRCBRANCH}"
-
Disable mirror tarballs:
BB_GENERATE_MIRROR_TARBALLS = "0"
-
Use machine features for conditional inclusion:
COMPATIBLE_MACHINE = "${@bb.utils.contains('MACHINE_FEATURES', 'my-feature', '${MACHINE}', 'null', d)}"
- Use Deploy Keys: For CI/CD, use repository-specific deploy keys instead of personal SSH keys
- Limit Key Access: Use keys with minimal required permissions
- Key Rotation: Regularly rotate SSH keys used in CI/CD
- Audit Access: Monitor repository access logs
The kas-container SSH forwarding:
- ✅ Mounts SSH directory read-only
- ✅ Uses temporary SSH agent socket
- ✅ Doesn't persist SSH keys in container images
- ✅ Isolates SSH access to build process only
A: SSH keys provide better security and are easier to manage in containerized build environments. Personal access tokens have broader permissions and are harder to scope appropriately.
A: Yes, but recipes that depend on private repositories will be skipped. Use machine features to control which recipes are included:
# Build without E-Ink support (skips eink-spectra6)
MACHINE_FEATURES:remove = "el133uf1"A: Check the build logs for SSH-related errors, or look for recipes with protocol=ssh in their SRC_URI.
A: Yes, the same principles apply to GitLab, Bitbucket, or any SSH-based Git service. Just ensure your SSH keys are configured for the appropriate service.
- KAS Container Documentation
- GitHub SSH Key Setup
- Yocto Fetcher Documentation
- Build Scripts: See scripts/ folder in project root for build automation
For additional support with private repository builds, please open an issue with details about your SSH setup and any error messages.