Docker image for Ninox-on-premise solution
3.1K
nvm use
If not found then
nvm install then nvm use to install the correct NodeJS version
echo "//registry.npmjs.org/:_authToken={ninox_npm_token}" > ~/.npmrc
npm run bootstrap
The command above will install all the dependencies and build the local dependent packages. Tt's recommended on the first use.
However you can install dependencies only for a specific package by changing your working directory to the package directory and running npm install.
To start the server and the client you need to run the following commands:
# Terminal 1
npm run core:start
# Terminal 2
npm run server:start
# Terminal 2
npm run client:start
To run a private cloud locally for easier development, you can use npm run client:watch:web:private. And for public cloud you can run npm run client:watch:web:dev.
To start the ninox server, you need to create server-config.json first, and then run the server command from the root folder:
npm run server:build: runs the server build scriptnpm run server:start: runs the server dev scriptnpm run server:start:dev:debug: runs the start:dev script under ninox-server with --inspect-brk flag.npm run server:test: runs the server test script.diff: shows the diff of all packages since the last releaserelease: creates a new release, also it will bump the version of all packages and add the changes to the changelog file.With all the client scripts in the mono-repo, you can run them from the root by prefixing them with client:.
To run client:watch:web:dev from root you can simple run npm run client:watch:web:dev
The same as ninox-client all core scripts are prefixed with core:
To run the ninox-core build script from the root folder, you to run npm run core:build
For instructions on how to run the iOS app, please refer to the Ninox iOS app README
For instructions on how to run the Mac app, please refer to the Ninox Mac app README
prettier:check: runs prettier check for all packagesprettier:fix: runs prettier write for all packages except the ignore files in the .prettierignorelint: runs the eslint check script for all packagesThe setup_deployment_workflows job in the CircleCI pipeline is responsible for generating dynamic configurations for deployment workflows. This job can be triggered based on specific conditions or parameters.
The setup_deployment_workflows job will run for all merges to the main or release branches. But the deployment will be pending approval. To trigger deployment go to the Circle CI build find the build job and click on the "Needs Approval" and then Approve the deployment for the latest change.
The setup_deployment_workflows job will run if:
Include #deploy-staging in your commit message:
git commit -m "<Your commit message> #deploy-staging"
If there are no file changes, yet the deployment is required, you can use the --allow-empty flag:
git commit -m "<Your commit message> #deploy-staging" --allow-empty
[NO LONGER SUPPORTED]
Tilt is an amazing tool for running services locally, using Kubernetes, docker-compose, or even run local resources as our setup for this project. If you are tired of splitting your terminal, and all the time you need to open the package.json to search for a specific script, Tilt will solve all your troubles. Just a single command: tilt up and all magic happens in your browser. Now, there's no need to locate a terminal or doing some crazy search for logs or even remembering all the commands.
Installing the tilt binary is a one-step command.
macOS/Linux
curl -fsSL https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.sh | bash
Windows
iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.ps1'))
Use the following command to build the image, replacing "my-token" with the actual NPM token you want to use:
export NPM_TOKEN=my-token
docker build --build-arg NPM_TOKEN=${NPM_TOKEN} --platform=linux/amd64 -t ninoxdb .
You can verify that the docker works by running the service as such:
docker container run -d \
--name ninoxdb \
-v NX-DATA:/var/nxdb \
-p 80:8080 ninoxdb
Navigate to your browser and use your local ninox! You can inspect the logs with
docker logs ninoxdb -f
For specific package managers (Homebrew, Scoop, Conda, asdf), see the Installation Guide.
Starting tilt is so simple:
cd ninox
tilt up
Tilt will open a browser showing the web UI, a unified view that shows you resources status and logs. Your terminal will also turn into a status box if you’d like to watch your server come up there.
We opt to use Gitflow Workflow that helps with continuous software development and implementing the DevOps best practice of continuous delivery.
development branch is created from masterrelease branch is created from development. (e.g. release/3.5.0)feature branches are created from development. (e.g. feature/DN-111[-set-up-code-style])bugfix branches are create from development. (e.g. bugfix/DN-112[-fix-rendering-issue])release branch is done it is merged back into development and mastermaster is detected a hotfix branch is created from master (e.g. hotfix/3.5.1)hotfix is complete it is merged to both development and master.Let us imagine a feature ticket in Jira with an ID DN-123 assigned to you, something like Setting up OAuth 2.0 within Ninox Server, and let us assume that you have the mono repo cloned somewhere in your machine.
The first thing to do is to checkout to the development branch and make a pull from the origin
git checkout development
git pull
Then you create your feature branch from the development branch as follow:
git checkout -b feature/DN-123-setting-up-oauth2
All magic happened, and you finished the implementation, congratulation! Now it's time to create a pull request in Github by pushing your feature branch and providing a meaningful title for your PR, something like feat(server): [DN-123] Setting up Oauth 2.0 within Ninox Server and assign a reviewer to the PR.
git push origin -u feature/DN-123-setting-up-oauth2
ℹ️ Note: As a reviewer, I need to ensure that the PR title and branch name respect our naming conventions as a part of your review.
After fixing all review feedbacks, now your feature is ready to be merged into the development branch. The same procedure applies to bugfix.
The pull request title must follow the conventional commits guide. It's a specification for adding human and machine-readable meaning to our commit messages.
A title must contain the following structural elements:
feat: a PR of the type feat introduces a new feature to the codebase (this correlate with MINOR in Semantic Versioning).fix: a PR of the type fix patches a bug in your codebase (bugfix or a hotfix branch) (this correlates the PATCH in Semantic Versioning).BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.ℹ️ Note: A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(server|core|client):
⚠️ As a part of a review, the reviewer needs to ensure that the branch name and PR title follow our conventions.
x in worskpace ynpm run x --workspace=y
ex.: npm run start --workspace=@ninox/ninox-client
docker pull ninoxdatabase/ninox-on-premise