š Omniverse: A cosmic collection of machine learning, deep learning, data science, math, and software engineering explorations. Dive into the universe of knowledge! š
The tiered structure of the blogs is as follows:
represents raw,
unfiltered and maybe wrong thoughts.
represents
organized thoughts, but still chaotic and potentially incorrect.
represents structured knowledge, but not necessarily correct.
represents
refined knowledge, and is polished and correct.
represents mastery of
the subject.Currently our .github/workflows/nvidia-docker.yaml workflow is used to build
and push the Docker image to Docker Hub. To use it, follow the below steps.
cd </path/to/project> # i.e. go to omniverse dir first so we can call pwd
chmod -R 777 $PWD # need for mkdir etc
docker run --gpus all -it --user 2222:2222 --shm-size=16g -v $PWD:/workspace gaohn/omniverse-nvidia:6140759e
The -shm-size is needed because if your virtual machine has say, 8 CPU cores,
then you would likely use 8 workers in the dataloading, and you would require
more shared memory.
This section provides detailed instructions on how to build the Dockerfile
(docker/documentation/jupyterbook.Dockerfile) and run the Docker image. The
image provides a containerized environment for building and serving the Jupyter
Book website.
[!WARNING] This section is only tested on macOS Ventura 13.4.1.
First, ensure you are in the root directory of the repository, if not, change directories to the root directory:
~/ $ cd <path/to/omniverse>
Replace <path/to/omniverse> with the actual path to your repository's root
directory.
Set Environment Variables: Set the GIT_COMMIT_HASH, IMAGE_NAME, and
IMAGE_TAG environment variables. These will be used to tag your Docker
image uniquely.
~/omniverse $ export GIT_COMMIT_HASH=$(git rev-parse --short HEAD)
~/omniverse $ export IMAGE_NAME=omniverse
~/omniverse $ export IMAGE_TAG=$GIT_COMMIT_HASH
Build the Image: Execute the following Docker command to build the image, specifying the Dockerfile path and assigning the tag based on the previously set environment variables.
~/omniverse $ docker build \
> --file docker/documentation/jupyterbook.Dockerfile \
> --tag $IMAGE_NAME:$IMAGE_TAG \
> .
To run the Docker container:
~/omniverse $ docker run \
> --publish 80:80 \
> $IMAGE_NAME:$IMAGE_TAG
This command will start a container from the built image, mapping port 80 of the
container to port 80 on the host machine. The website should now be
accessible at http://localhost:80.
To stop the Docker container:
~/omniverse $ export CONTAINER_ID=$(docker ps --filter ancestor=$IMAGE_NAME:$IMAGE_TAG --format "{{.ID}}")
~/omniverse $ docker stop $CONTAINER_ID
This is a relatively simple Dockerfile. Further enhancements can include, but not limited to:
The conventional way to name software versions is by following Semantic Versioning (SemVer). Semantic Versioning is a widely adopted system for versioning software in a way that conveys meaning about the underlying changes. It helps in managing dependencies and avoiding compatibility issues.
A Semantic Version number is typically formatted as MAJOR.MINOR.PATCH, where:
MAJOR version:
MINOR version:
PATCH version:
1.0.0: The first stable release of a software.1.0.1: A subsequent release that includes bug fixes but no new features.1.1.0: A release that introduces new features but is still backward
compatible with the 1.0.x series.2.0.0: A release that makes changes significant enough to potentially
break compatibility with the 1.x.x series.Semantic Versioning also supports additional labels for pre-release and build metadata:
2.0.0-alpha, 2.0.0-beta.1).2.0.0+build.20230315).Follow the guide here for detailed instructions on how to release a Python package using GitHub Actions CI/CD workflows.
One thing that is not mentioned in the guide, but is a good practice, is to do all the necessary pre-release checks before releasing your package, that includes all the pre-merge checks, and additional checks such as running tests, linting, and building the documentation. This ensures that the release is of high quality and is ready to be used by others.
Furthermore, we add a release-docker workflow to build and publish a Docker
image to Docker Hub. The workflow is triggered when a new release is published
to PyPI. This approach is inspired by
langchain's workflow
for publishing a Docker image via GitHub Actions. The rationale behind
incorporating a Docker release alongside the PyPI release is to ensure the
package omniverse is able to be imported and used across different platforms.
Update the version field in pyproject.toml to the new version, and commit
the changes to the main branch (or any other branch that satisfies the
on.push.branches condition in the workflow).
VERSION="0.0.63"
git commit -am "cicd: bump version to #$VERSION [#38]." && \
git tag -a v$VERSION -m "Release version $VERSION" && \
git push && \
git push origin v$VERSION
Then the workflow will be triggered, and the package will be published to PyPI. It is worth noting that we will do a pre-release check before publishing the package.
To use a custom domain with GitHub Pages and with Jupyter Book, we would need to follow the instructions given here.
Add Custom Domain to GitHub Pages Settings:
Go to your GitHub repository.
Click on "Settings".
Scroll down to the "GitHub Pages" section.
In the "Custom domain" box, enter your custom domain (e.g.,
gaohongnan.com) and save.
You might see the "improperly configured" error, which is expected at this stage since the DNS hasn't been set up yet.
Make sure you add your custom domain to your GitHub Pages site before configuring your custom domain with your DNS provider. Configuring your custom domain with your DNS provider without adding your custom domain to GitHub could result in someone else being able to host a site on one of your subdomains. From GitHub documentation
Modify DNS Settings at Domain Registrar:
www subdomain: Set up the CNAME record pointing to your
GitHub Pages URL.Wait and Check:
Enforce HTTPS:
In essence, you temporarily accept the error message in your GitHub Pages settings after adding the custom domain. After you've configured the DNS settings at your domain registrar and they've propagated, the error in GitHub Pages settings should clear up.
The main goal of GitHub's recommendation is to make sure you've shown intent to use the domain with GitHub Pages before setting it up with your DNS provider, to prevent potential subdomain takeovers. By adding the custom domain in the repository settings (even if it throws an error initially), you've asserted this intent.
FAQs
A collection of code for Omniverse.
We found that omniverse demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago.Ā It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Browserslist-rs now uses static data to reduce binary size by over 1MB, improving memory use and performance for Rust-based frontend tools.
Research
Security News
Eight new malicious Firefox extensions impersonate games, steal OAuth tokens, hijack sessions, and exploit browser permissions to spy on users.
Security News
The official Go SDK for the Model Context Protocol is in development, with a stable, production-ready release expected by August 2025.