[pull] master from nocodb:master

.do/deploy.template.yaml

@@ -0,0 +1,24 @@
+spec:
+  name: nocodb
+  services:
+  - name: nocodb
+    image:
+      registry_type: DOCKER_HUB
+      registry: nocodb
+      repository: nocodb
+      tag: latest
+    run_command: "./server/scripts/digitalocean-postbuild.sh"
+    instance_size_slug: "basic-s"
+    health_check:
+      initial_delay_seconds: 10
+      http_path: /api/health
+    envs:
+    - key: NODE_ENV
+      value: "production"
+    - key: DATABASE_URL
+      scope: RUN_TIME
+      value: ${postgres.DATABASE_URL}
+  databases:
+    - name: postgres
+      engine: PG
+      production: false

.github/COMMIT_CONVENTION.md

@@ -0,0 +1,130 @@
+## Git Commit Message Convention
+
+> This is adapted from [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/).
+
+## Summary
+
+The Conventional Commits specification is a lightweight convention on top of commit messages.
+It provides an easy set of rules for creating an explicit commit history;
+which makes it easier to write automated tools on top of.
+This convention dovetails with [SemVer](http://semver.org),
+by describing the features, fixes, and breaking changes made in commit messages.
+
+The commit message should be structured as follows:
+
+---
+
+```
+<type>[optional scope]: <description>
+[optional body]
+[optional footer(s)]
+```
+---
+
+<br />
+The commit contains the following structural elements, to communicate intent to the
+consumers of your library:
+
+1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in Semantic Versioning).
+1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in Semantic Versioning).
+1. **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`](http://semver.org/#summary) in Semantic Versioning).
+A BREAKING CHANGE can be part of commits of any _type_.
+1. _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `build:`, `chore:`,
+  `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
+1. _footers_ other than `BREAKING CHANGE: <description>` may be provided and follow a convention similar to
+  [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
+
+Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE).
+<br /><br />
+A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.
+
+## Examples
+
+### Commit message with description and breaking change footer
+```
+feat: allow provided config object to extend other configs
+
+BREAKING CHANGE: `extends` key in config file is now used for extending other config files
+```
+
+### Commit message with `!` to draw attention to breaking change
+```
+feat!: send an email to the customer when a product is shipped
+```
+
+### Commit message with scope and `!` to draw attention to breaking change
+```
+feat(api)!: send an email to the customer when a product is shipped
+```
+
+### Commit message with both `!` and BREAKING CHANGE footer
+```
+chore!: drop support for Node 6
+
+BREAKING CHANGE: use JavaScript features not available in Node 6.
+```
+
+### Commit message with no body
+```
+docs: correct spelling of CHANGELOG
+```
+
+### Commit message with scope
+```
+feat(lang): add polish language
+```
+
+### Commit message with multi-paragraph body and multiple footers
+```
+fix: prevent racing of requests
+
+Introduce a request id and a reference to latest request. Dismiss
+incoming responses other than from latest request.
+
+Remove timeouts which were used to mitigate the racing issue but are
+obsolete now.
+
+Reviewed-by: Z
+Refs: #123
+```
+
+## Specification
+
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed
+  by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space.
+1. The type `feat` MUST be used when a commit adds a new feature to your application or library.
+1. The type `fix` MUST be used when a commit represents a bug fix for your application.
+1. 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(parser):`
+1. A description MUST immediately follow the colon and space after the type/scope prefix.
+The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_.
+1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
+1. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
+1. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of
+ a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the
+  [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
+1. A footer's token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate
+  the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.
+1. A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer
+  token/separator pair is observed.
+1. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the
+  footer.
+1. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g.,
+_BREAKING CHANGE: environment variables now take precedence over config files_.
+1. If included in the type/scope prefix, breaking changes MUST be indicated by a
+  `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section,
+  and the commit description SHALL be used to describe the breaking change.
+1. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: updated ref docs._
+1. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
+1. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
+
+## Why Use Conventional Commits
+
+* Automatically generating CHANGELOGs.
+* Automatically determining a semantic version bump (based on the types of commits landed).
+* Communicating the nature of changes to teammates, the public, and other stakeholders.
+* Triggering build and publish processes.
+* Making it easier for people to contribute to your projects, by allowing them to explore
+  a more structured commit history.

.github/CONTRIBUTING.md

@@ -0,0 +1,39 @@
+# NocoDB Contributing Guide
+
+Thanks for spending your time to contribute! The following is a set of guidelines for contributing to NocoDB. 
+
+## Table of Contents
+
+- [Pull Request Guidelines](#pull-request-guidelines)
+- [Development Setup](#development-setup)
+  * [Committing Changes](#committing-changes)
+  * [Applying License](#applying-license)
+
+## Pull Request Guidelines
+
+- When you create a PR, you should fill in all the info defined in this [template](https://github.com/nocodb/nocodb/blob/master/.github/PULL_REQUEST_TEMPLATE.md).
+
+- We adopt [Gitflow Design](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow). However, we do not have release branches. 
+
+- The `master` branch is just a snapshot of the latest stable release. All development should be done in dedicated branches (e.g. `feat/foo`, `fix/bar`, `enhancement/baz`). All approved PRs will go to `develop` branch. **Do not submit PRs against the `master` branch.**
+
+- Checkout a topic branch from the relevant branch, e.g. `develop`, and merge back against that branch.
+
+- Multiple small commits are allowed on the PR - They will be squashed into one commit before merging.
+
+- If your changes are related to a special issue, add `ref: #xxx` to link the issue where `xxx` is the issue id. If your changes are meant to solve the issue, then add `closes: #xxx` instead.
+
+- If your changes doesn't relate to any issues, we suggest you to create a new issue first and ask for assignment. Also, it'd be better to discuss the design or solutions with the team members via Discord first. 
+
+## Development Setup
+
+Please refer to [Development Setup](https://docs.nocodb.com/engineering/development-setup).
+
+### Committing Changes
+
+We encourage all contributors to commit messages following [Commit Message Convention](/.github/COMMIT_CONVENTION.md).
+
+### Applying License
+
+We require a CLA (Contributor License Agreement). This is a one-time process. Please click this [link](https://cla-assistant.io/nocodb/nocodb) to agree to the CLA for nocodb/nocodb. 
+

.github/FUNDING.yml

@@ -0,0 +1,13 @@
+# These are supported funding model platforms
+
+github: [ nocodb ]
+# patreon: # Replace with a single Patreon username
+# open_collective: # Replace with a single Open Collective username
+# ko_fi: # Replace with a single Ko-fi username
+# tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+# community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+# liberapay: # Replace with a single Liberapay username
+# issuehunt: # Replace with a single IssueHunt username
+# otechie: # Replace with a single Otechie username
+# lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
+# custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

.github/ISSUE_TEMPLATE/--bug-report.yaml

@@ -0,0 +1,60 @@
+name: 🐛 Bug Report
+description: Report a bug in NocoDB
+title: "🐛 Bug: "
+labels: [Type : Bug]
+body:
+- type: markdown
+  attributes:
+    value: |
+      Thank you for taking the time to fill out this bug report! ❤️
+
+- type: checkboxes
+  attributes:
+    label: Please confirm that the bug report does ***not*** already exist
+    description: We kindly ask you [to search the open issues](https://github.com/nocodb/nocodb/issues?q=is%3Aissue+sort%3Acreated-desc+) and ensure the bug has not already been reported before.
+    options:
+    - label: I confirm there is no existing issue for this bug.
+      required: true
+
+- type: textarea
+  attributes:
+    label: Steps to reproduce
+    description: A clear and concise example on how to reproduce the issue. Please make sure to provide all relevant technical details.
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: Desired Behavior
+    description: Describe the solution you'd like. A clear and concise description of what you want to happen.
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: Project Details
+    description: Click on <kbd>…</kbd> button next to a base in the NocoDB sidebar on the left and select <kbd>Copy Base Info</kbd> (see the [docs](https://docs.nocodb.com/FAQs#how-to-check-my-project-info-) for details) and paste the result below.
+    placeholder: |
+      Or manually fill in following info:
+
+      ```
+      NocoDB used as docker : true / false
+      NocoDB version : 
+      Database used in NC_DB URL  : mysql | pg | sqlite3 / (defaults to sqlite3 if empty)
+      Project was created  by clicking : New Project | New Project by connecting to external database
+      Database on which spreadsheet is created : mysql | pg | sqlite3 / (defaults to sqlite3 if empty)
+      OS on which NocoDB is running : 
+      Node.js version if running as node : 
+      Database version : 
+      ```
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: Attachments
+    description: Add relevant attachments here.
+    placeholder: |
+      Drag & drop relevant images or videos here.
+  validations:
+    required: false

.github/ISSUE_TEMPLATE/--feature-request.yaml

@@ -0,0 +1,38 @@
+name: 🔦 Feature request
+description: Suggest a new/missing feature for NocoDB
+title: "🔦 Feature: "
+labels: [Type : Feature]
+body:
+- type: markdown
+  attributes:
+    value: |
+      Thank you for taking the time to fill out this feature request report! ❤️
+
+- type: checkboxes
+  attributes:
+    label: Please confirm that the feature request does ***not*** already exist
+    description: We kindly ask you [to search the open issues](https://github.com/nocodb/nocodb/issues?q=is%3Aissue+sort%3Acreated-desc+) and ensure the feature has not already been requested before.
+    options:
+    - label: I confirm there is no existing issue for this feature request.
+      required: true
+
+- type: textarea
+  attributes:
+    label: Use case
+    description: Describe the use case for the requested feature. A clear and concise description of the end result you're interested in.
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: Suggested solution
+    description: Describe the solution you'd like. A clear and concise description of what you want to happen.
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: Additional context
+    description: Add more context about the problem the requested feature intends to solve.
+  validations:
+    required: false