A collection of code for Omniverse.
Project description
Omniverse
- Omniverse
🌌 Omniverse: A cosmic collection of machine learning, deep learning, data
science, math, and software engineering explorations. Dive into the universe of
knowledge! 🚀 To create a detailed Markdown section in the README.md
file for
instructing users on how to build and run the Dockerfile
jupyterbook.Dockerfile
, you should include steps that cover prerequisites,
building the Docker image, tagging it with the Git commit ID, and running the
container. Additionally, to avoid hardcoding variables in the Docker build/run
commands, you can use shell variables and command substitutions.
Building and Running the Jupyter Book Docker Image
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.
Building the Docker Image
-
Set Environment Variables: Set the
GIT_COMMIT_HASH
,IMAGE_NAME
, andIMAGE_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 \ > .
Running the Docker Container
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
.
Stopping the Docker Container
To stop the Docker container:
~/omniverse $ export CONTAINER_ID=$(docker ps --filter ancestor=$IMAGE_NAME:$IMAGE_TAG --format "{{.ID}}")
~/omniverse $ docker stop $CONTAINER_ID
Further Enhancements
This is a relatively simple Dockerfile. Further enhancements can include, but not limited to:
- Add entrypoint script to start the Jupyter Book server.
- Use Docker Compose to manage multiple containers, for example, a container for development of the content and a container for serving the website.
- Current Docker image is used primarily for serving, and users may find it hard to directly develop inside the container. A better approach is to use a Docker image for development, and mount the source code directory to the container. This way, users can develop on their host machine, and the changes will be reflected in the container.
References and Further Readings
Release using GitHub Actions CI/CD Workflows
Semantic Versioning
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.
Format
A Semantic Version number is typically formatted as MAJOR.MINOR.PATCH
, where:
-
MAJOR version:
- Incremented for incompatible API changes or major changes in functionality.
- Indicates that the new version might not be backward compatible with previous major versions.
-
MINOR version:
- Incremented for adding functionality in a backward-compatible manner.
- Indicates new features or improvements which do not break existing functionalities.
-
PATCH version:
- Incremented for backward-compatible bug fixes.
- Focuses on resolving bugs and issues without adding new features or breaking existing functionality.
Example Versioning
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 the1.0.x
series.2.0.0
: A release that makes changes significant enough to potentially break compatibility with the1.x.x
series.
Pre-release and Build Metadata
Semantic Versioning also supports additional labels for pre-release and build metadata:
- Pre-release versions can be denoted with a hyphen and additional identifiers
(e.g.,
2.0.0-alpha
,2.0.0-beta.1
). - Build metadata can be appended using a plus sign and additional identifiers
(e.g.,
2.0.0+build.20230315
).
Release using GitHub Actions CI/CD Workflows
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.
Example Workflow
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).
git commit -am "cicd: bump version to 0.0.19 #38."
git tag -a v0.0.19 -m "Release version 0.0.19"
git push && git push origin v0.0.19
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.
References and Further Readings
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Hashes for omniverse-0.0.19-py3-none-any.whl
Algorithm | Hash digest | |
---|---|---|
SHA256 | 6edfdd776a7bb772e2cd5b927ef6d74e478b0a0899b1bdce00baa3672ec10372 |
|
MD5 | fa3f5a164efc5306ae4814a02b3dfbd8 |
|
BLAKE2b-256 | ca60b285b7b2e25d8ca59517cfe7370a750e53be6077d79addec344c7f43b127 |