Hubs

Hubs

  • Hubs Foundation
  • Docs
  • GitHub
  • Help

›For Developers

Introduction

  • Welcome
  • Getting Started With Hubs
  • Building Scenes with Spoke
  • Creating Custom Avatars
  • Hosting Events in Hubs

Setting Up Your Hub

  • Beginner’s Guide to CE
  • Set up SMTP email service
  • Download and install doctl
  • What’s next?
  • Troubleshooting and FAQs
  • How to back up your Hubs instance
  • Managing Your Hub's Content
  • Frequently Asked Questions
  • Contact Us

Hubs Fundamentals

  • Create and Join Rooms
  • Hubs Features
  • Sharing Avatar Links Privately
  • User Settings
  • Room Settings
  • Controls
  • Discord Bot
  • Troubleshooting
  • FAQ

Spoke Documentation

  • Create Project
  • User Interface
  • Spoke Controls
  • Adding Content
  • Architecture Kit
  • Grid
  • Skyboxes
  • Lighting and Shadows
  • Physics and Navigation
  • Publish Scenes

For Creators

  • Advanced Avatar Customization
  • Linking Hubs Rooms
  • Using the Blender glTF Exporter
  • Blender Add-on Components
  • Optimizing Scenes
  • Introduction to Behavior Graphs

For Developers

  • System Overview
  • Build a Custom Client
  • Contributing
  • Hubs Query String Parameters
  • GitHub Workflows

Hubs Client development

  • Hubs Client development Basics
  • Core Concepts for Gameplay Code
  • Hubs Client development Interactivity
  • Hubs Client development Networking

Hubs Admin Panel

  • Introduction
  • Getting Started
  • Importing Content
  • Customizing Themes
  • Managing Content
  • Adding Administrators
  • Limiting Access
  • Recipe: Permissive Rooms
  • Recipe: Enable Scene Editor
Edit

GitHub Workflows

Custom Docker Build Push

In some repositories you will find a GitHub Workflow/Action named custom-docker-build-push for building custom docker images and pushing them to a docker/container registry of your choice. Simply run this Action on any branch, with the appropriate details filled in (either through the predefined defaults or by the overrides), and you will end up with a docker image of that branch that can be used in any Community Edition instance.

The Action allows you almost complete control over where your docker images are sent and how they are tagged. The details required for this to work can either be provided at runtime or by preset defaults that you set up.

Options/Setup

The following properties can be configured/overridden. Any values that are manually specified for that run will always be used. Any fields not passed values will fall back on predefined variables/secrets (if they have been created).

Options:

  • The branch the workflow will run on. [REQUIRED]
    • This has to be manually specified each time when running the Action.
  • The registry base URL. [REQUIRED]
    • This is used to specify which docker/container registry to push to.
    • Common values include: docker.io for Docker Hub, and ghcr.io for GitHub. For other registries, check their documentation on what to put here.
    • Create a repository variable named REGISTRY_BASE_URL to set a default registry to use.
  • The registry username. [REQUIRED]
    • The username of the account for the registry you want to push to.
    • Create a repository secret named REGISTRY_USERNAME to set a default username to use.
  • The registry password. [REQUIRED]
    • The password of the account (or the access token) for the registry you want to push to.
    • Create a repository secret named REGISTRY_PASSWORD to set a default password/access token to use.
  • The registry namespace. [REQUIRED]
    • This is often the same as the username, but some registries allow you to manually specify a namespace.
    • Create a repository variable named REGISTRY_NAMESPACE to set a default namespace to use.
  • The image tag. [OPTIONAL]
    • This is basically the name of your image.
    • The default value of this is the branch name.
    • When the workflow is run, two images/tags will be pushed to the registry, one will be the <image_tag_value>-latest and the other will be the <image_tag_value>-<action_run_number>, e.g. my-cool-branch-latest and my-cool-branch-42
  • The name of the Dockerfile [OPTIONAL]
    • This has been preset and you shouldn't need to change it unless you've changed the name/location of the Dockerfile in your code. If you have changed the name/location of your Dockerfile you will need to specify this each and every time you run the Action or update the default in the GitHub workflow file.
  • The code path. [OPTIONAL]
    • The path to the code you want built. Used for only building a specific part of the repository.
    • This doesn't usually need to be filled/changed.
  • The build cache.
    • Using the build cache will speed up subsequent builds of your images, but can sometimes cause problems with registries.
    • This is enabled by default, but if you run into problems building, you can disable it. The build will be slower, but it should hopefully work.
    • Example error to watch out for: buildx failed with: ERROR: failed to solve: error writing manifest blob: failed commit on ref "sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx": unexpected status from PUT request to https://xx.xxxxxxx.xxx/xx/namespace/repository/manifests/buildcache: 400
← Hubs Query String ParametersHubs Client development Basics →
  • Custom Docker Build Push
    • Options/Setup
Hubs
Docs
IntroductionSetting Up Your HubHubs FundamentalsSpoke DocumentationFor CreatorsFor DevelopersAdministration
Community
Discord Chat
More
HubsSpokeGitHub
Copyright © 2024–2025 Hubs Foundation. Hubs Documentation available under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license.