mirror of
https://gitlab.com/openstapps/openstapps.git
synced 2026-01-09 19:22:51 +00:00
fix: build
This commit is contained in:
@@ -42,6 +42,6 @@ Please consult the [Docker documentation](https://docs.docker.com/engine/referen
|
||||
|
||||
## Further resources
|
||||
|
||||
* [An Exhaustive Guide to Writing Dockerfiles for Node.js Web Apps](https://blog.hasura.io/an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-bbee6bd2f3c4)
|
||||
* [Docker and Node.js Best Practices
|
||||
](https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md)
|
||||
- [An Exhaustive Guide to Writing Dockerfiles for Node.js Web Apps](https://blog.hasura.io/an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-bbee6bd2f3c4)
|
||||
- [Docker and Node.js Best Practices
|
||||
](https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -2,11 +2,11 @@
|
||||
|
||||
## Required tools/packages
|
||||
|
||||
* [SSH](https://docs.gitlab.com/ee/ssh/README.html)
|
||||
* [Git](https://docs.gitlab.com/ee/gitlab-basics/start-using-git.html)
|
||||
* [Docker](https://docs.gitlab.com/ee/user/project/container_registry.html) & Docker-Compose
|
||||
* Node.js & NPM - be sure to install the "Fermium" (14.x) LTS version, might need a [PPA](https://github.com/nodesource/distributions/blob/master/README.md#installation-instructions) or use NVM
|
||||
* [NVM](https://github.com/creationix/nvm#installation) - if you want to use multiple different versions of node
|
||||
- [SSH](https://docs.gitlab.com/ee/ssh/README.html)
|
||||
- [Git](https://docs.gitlab.com/ee/gitlab-basics/start-using-git.html)
|
||||
- [Docker](https://docs.gitlab.com/ee/user/project/container_registry.html) & Docker-Compose
|
||||
- Node.js & NPM - be sure to install the "Fermium" (14.x) LTS version, might need a [PPA](https://github.com/nodesource/distributions/blob/master/README.md#installation-instructions) or use NVM
|
||||
- [NVM](https://github.com/creationix/nvm#installation) - if you want to use multiple different versions of node
|
||||
|
||||
Example for Debian based distributions:
|
||||
|
||||
@@ -16,13 +16,13 @@ apt install ssh git docker docker-compose nodejs
|
||||
|
||||
## IDE - recommended choices
|
||||
|
||||
* [VSCode](https://code.visualstudio.com/)
|
||||
* [Webstorm](https://www.jetbrains.com/webstorm/download/) - Educational or OpenSource License **cannot** be used
|
||||
- [VSCode](https://code.visualstudio.com/)
|
||||
- [Webstorm](https://www.jetbrains.com/webstorm/download/) - Educational or OpenSource License **cannot** be used
|
||||
|
||||
## Optional helpful tools
|
||||
|
||||
* Curl - for executing HTTP requests on the command line
|
||||
* Postman or Insomnia - for executing HTTP requests with a GUI
|
||||
- Curl - for executing HTTP requests on the command line
|
||||
- Postman or Insomnia - for executing HTTP requests with a GUI
|
||||
|
||||
## Before you start (Windows only)
|
||||
|
||||
@@ -31,8 +31,8 @@ Depending on your preferred settings you could consider applying `git config cor
|
||||
|
||||
## Clone starter repositories
|
||||
|
||||
* [Minimal deployment](https://gitlab.com/openstapps/minimal-deployment) - contains backend, database, minimal connector, copy (from api) and app
|
||||
* [Minimal connector](https://gitlab.com/openstapps/minimal-connector) - an example connector to learn the principles of connector development
|
||||
- [Minimal deployment](https://gitlab.com/openstapps/minimal-deployment) - contains backend, database, minimal connector, copy (from api) and app
|
||||
- [Minimal connector](https://gitlab.com/openstapps/minimal-connector) - an example connector to learn the principles of connector development
|
||||
|
||||
```shell
|
||||
git clone git@gitlab.com:openstapps/minimal-deployment.git
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
|
||||
## Possible branch names
|
||||
|
||||
* `master`
|
||||
* `develop`
|
||||
* `$ID-$TITLE`
|
||||
- `master`
|
||||
- `develop`
|
||||
- `$ID-$TITLE`
|
||||
|
||||
### `master`
|
||||
|
||||
@@ -22,4 +22,4 @@ Development of features, bugfixes or refactoring is done in branches referencing
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Git - A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
|
||||
- [Git - A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
|
||||
|
||||
@@ -16,6 +16,6 @@ Inline comments should not explain what code from external projects is doing. Ad
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Commit guidelines](COMMITS.md)
|
||||
* [TypeScript coding guidelines](https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines)
|
||||
* [Licensing guidelines](LICENSING.md)
|
||||
- [Commit guidelines](COMMITS.md)
|
||||
- [TypeScript coding guidelines](https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines)
|
||||
- [Licensing guidelines](LICENSING.md)
|
||||
|
||||
@@ -5,24 +5,24 @@
|
||||
Commit subjects should match the following template:
|
||||
|
||||
> `TYPE`: `SUBJECT`
|
||||
>
|
||||
>
|
||||
> `DESCRIPTION`
|
||||
|
||||
### `TYPE`
|
||||
|
||||
`TYPE` can have one of the following values:
|
||||
|
||||
| value | meaning |
|
||||
| --- | --- |
|
||||
| build | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
|
||||
| ci | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
|
||||
| docs | Documentation only changes |
|
||||
| feat | A new feature |
|
||||
| fix | A bug fix |
|
||||
| perf | A code change that improves performance |
|
||||
| refactor | A code change that neither fixes a bug nor adds a feature |
|
||||
| style | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
|
||||
| test | Adding missing tests or correcting existing tests |
|
||||
| value | meaning |
|
||||
| -------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| build | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
|
||||
| ci | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
|
||||
| docs | Documentation only changes |
|
||||
| feat | A new feature |
|
||||
| fix | A bug fix |
|
||||
| perf | A code change that improves performance |
|
||||
| refactor | A code change that neither fixes a bug nor adds a feature |
|
||||
| style | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
|
||||
| test | Adding missing tests or correcting existing tests |
|
||||
|
||||
These are the [types](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#type), that angular uses. They are easily adaptable for all TypeScript based web related projects.
|
||||
|
||||
@@ -56,5 +56,5 @@ conventional-changelog -p angular -i CHANGELOG.md -s -r 0
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Recommendations on commit messages](https://chris.beams.io/posts/git-commit/)
|
||||
* [Versioning](VERSIONING.md)
|
||||
- [Recommendations on commit messages](https://chris.beams.io/posts/git-commit/)
|
||||
- [Versioning](VERSIONING.md)
|
||||
|
||||
@@ -10,17 +10,17 @@ Code is annotated with [TypeDoc](https://typedoc.org/), which then can be used t
|
||||
|
||||
Please follow these guidelines to reduce redundance:
|
||||
|
||||
* The purpose of inline documentation is to explain what the line of code actually does without explaining syntax or external references. Example:
|
||||
- The purpose of inline documentation is to explain what the line of code actually does without explaining syntax or external references. Example:
|
||||
|
||||
```typescript
|
||||
// extend the template by the properties of the base template
|
||||
templateBase.properties = mergeObjects(
|
||||
templateBase.properties,
|
||||
templates['base.template.json'].mappings._default_.properties
|
||||
templates['base.template.json'].mappings._default_.properties,
|
||||
);
|
||||
```
|
||||
|
||||
* Follow the [recommendations](http://typedoc.org/guides/doccomments/) of `typedoc`, because it is used to generate documentation. Do not denote the types again in the documentation (`@param` and `@returns`), because they are already "documented" in the code itself. Example:
|
||||
- Follow the [recommendations](http://typedoc.org/guides/doccomments/) of `typedoc`, because it is used to generate documentation. Do not denote the types again in the documentation (`@param` and `@returns`), because they are already "documented" in the code itself. Example:
|
||||
|
||||
```typescript
|
||||
/**
|
||||
@@ -39,8 +39,8 @@ async get<T>(key: string): Promise<T> {
|
||||
|
||||
### Inline Comments `//`
|
||||
|
||||
* Start inline comments with a lowercase letter and a space after the `//`
|
||||
* Place the comment above the line that it is referencing
|
||||
- Start inline comments with a lowercase letter and a space after the `//`
|
||||
- Place the comment above the line that it is referencing
|
||||
|
||||
```typescript
|
||||
// lorem ipsum
|
||||
@@ -49,14 +49,14 @@ const lorem;
|
||||
|
||||
### Doc Comments `/**`
|
||||
|
||||
* Start with a capital letter
|
||||
* Keep the first line short
|
||||
* The first line should not end with a period, nor should it consist of multiple sentences
|
||||
* The first line should be easily scannable
|
||||
* If you want to comment more than one line, do a short summary in the first line, then continue after a blank line with the more detailed description
|
||||
* Document all parameters in functions using `@param`
|
||||
* `@param` must not contain a type annotation, just `@param name description`
|
||||
* Do not include `@return`, as it is redundant information
|
||||
- Start with a capital letter
|
||||
- Keep the first line short
|
||||
- The first line should not end with a period, nor should it consist of multiple sentences
|
||||
- The first line should be easily scannable
|
||||
- If you want to comment more than one line, do a short summary in the first line, then continue after a blank line with the more detailed description
|
||||
- Document all parameters in functions using `@param`
|
||||
- `@param` must not contain a type annotation, just `@param name description`
|
||||
- Do not include `@return`, as it is redundant information
|
||||
|
||||
```typescript
|
||||
/**
|
||||
@@ -81,4 +81,4 @@ The path `.gitlab/issue_templates` can contain markdown files which act as templ
|
||||
|
||||
## Further resources
|
||||
|
||||
* [GitLab issue templates](https://gitlab.com/help/user/project/description_templates.md)
|
||||
- [GitLab issue templates](https://gitlab.com/help/user/project/description_templates.md)
|
||||
|
||||
@@ -6,4 +6,4 @@ Issues keep a discussion of the topic, are related to a [branch](BRANCHING.md),
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Always start with an issue](https://about.gitlab.com/2016/03/03/start-with-an-issue/)
|
||||
- [Always start with an issue](https://about.gitlab.com/2016/03/03/start-with-an-issue/)
|
||||
|
||||
@@ -45,4 +45,4 @@ If the file is updated in a new year after its creation, the `<year>` should be
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Coding style](CODING.md)
|
||||
- [Coding style](CODING.md)
|
||||
|
||||
@@ -7,8 +7,8 @@ A merge request can also gather the work of multiple issues.
|
||||
Merge requests are used to merge the changes to the main branches (`master`, `develop`). Every merge request needs to be reviewed/commented by at least 2 other developers before they can be accepted. This ensure that all guidelines are followed and that the scope of the issue is matched.
|
||||
|
||||
Before any merge of an `issue`-branch into the according `master`-branch, the commits of the `issue`-branch shall be tidied up.
|
||||
Unstage your commits from the `issue`-branch (`git reset master`). Create your new commit(s) and push them to the remote repository (`git push --force`).
|
||||
Unstage your commits from the `issue`-branch (`git reset master`). Create your new commit(s) and push them to the remote repository (`git push --force`).
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Commits](COMMITS.md)
|
||||
- [Commits](COMMITS.md)
|
||||
|
||||
@@ -33,5 +33,5 @@ For the contents and purpose of `.editorconfig`, `tsconfig.json` and `tslint.jso
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Coding style](CODING.md)
|
||||
* [Versioning](VERSIONING.md)
|
||||
- [Coding style](CODING.md)
|
||||
- [Versioning](VERSIONING.md)
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## NPM
|
||||
|
||||
All projects that use the [OpenStApps configuration](https://gitlab.com/openstapps/configuration) and implement the automatic publishing via GitLab CI can simply be published to the NPM registry by using the appropriate job. It uses the `NPM_AUTH_TOKEN` that is a [protected variable](https://gitlab.com/groups/openstapps/-/settings/ci_cd) of the OpenStApps group. To trigger this job, a new tag has to be created (on the master branch):
|
||||
All projects that use the [OpenStApps configuration](https://gitlab.com/openstapps/configuration) and implement the automatic publishing via GitLab CI can simply be published to the NPM registry by using the appropriate job. It uses the `NPM_AUTH_TOKEN` that is a [protected variable](https://gitlab.com/groups/openstapps/-/settings/ci_cd) of the OpenStApps group. To trigger this job, a new tag has to be created (on the master branch):
|
||||
|
||||
### Use current [master branch](BRANCHING.md)
|
||||
|
||||
@@ -19,8 +19,8 @@ npm version (major|minor|patch)
|
||||
|
||||
After these steps there should 2 new commits:
|
||||
|
||||
* A version commit
|
||||
* A changelog commit
|
||||
- A version commit
|
||||
- A changelog commit
|
||||
|
||||
Also a new git tag should be created.
|
||||
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
|
||||
We use semantic version through `npm`.
|
||||
|
||||
* `npm version patch`: For fixes/patches
|
||||
* `npm version minor`: For new features
|
||||
* `npm version major`: For breaking changes in the API
|
||||
- `npm version patch`: For fixes/patches
|
||||
- `npm version minor`: For new features
|
||||
- `npm version major`: For breaking changes in the API
|
||||
|
||||
Or directly with `git tag vMAJOR.MINOR.PATCH`.
|
||||
|
||||
@@ -12,4 +12,4 @@ This tag is set on the `develop`- (if present) or on the `master`-[branch](BRANC
|
||||
|
||||
## Further resources
|
||||
|
||||
* [Commit guidelines](COMMITS.md)
|
||||
- [Commit guidelines](COMMITS.md)
|
||||
|
||||
Reference in New Issue
Block a user