Theaninova/openstapps
1
0
Fork 0
mirror of https://gitlab.com/openstapps/openstapps.git synced 2026-03-07 23:32:15 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix: build

Browse Source
This commit is contained in:
Thea Schöbl
2023-03-14 18:04:29 +01:00
parent 3792a14e90
commit fd740b3091
185 changed files with 21932 additions and 71486 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
configuration/projectmanagement/project-docs/workflow/BRANCHING.md
View File

@@ -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/)

6
configuration/projectmanagement/project-docs/workflow/CODING.md
View File

@@ -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)

28
configuration/projectmanagement/project-docs/workflow/COMMITS.md
View File

@@ -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)

28
configuration/projectmanagement/project-docs/workflow/DOCUMENTATION.md
View File

@@ -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)

2
configuration/projectmanagement/project-docs/workflow/ISSUES.md
View File

@@ -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/)

2
configuration/projectmanagement/project-docs/workflow/LICENSING.md
View File

@@ -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)

4
configuration/projectmanagement/project-docs/workflow/MERGING.md
View File

@@ -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)

4
configuration/projectmanagement/project-docs/workflow/PROJECT.md
View File

@@ -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)

6
configuration/projectmanagement/project-docs/workflow/PUBLISHING.md
View File

@@ -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.

8
configuration/projectmanagement/project-docs/workflow/VERSIONING.md
View File

@@ -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)