add argument: integration testing

This commit is contained in:
Willy Kloucek
2021-06-15 08:55:20 +02:00
parent a218627df2
commit ba438022f0

View File

@@ -17,12 +17,12 @@ We want to accelerate and simplify extension development by removing the necessi
* The solution should be easily maintainable.
* It should always be up-to-date.
* The solution should be easy to use.
* The solution should be easy to use.
## Considered Options
* Use [boilr](https://github.com/tmrts/boilr)
* Create a template git repository.
* Create a template git repository.
* Use [ocis-hello](https://github.com/owncloud/ocis-hello/) as a "template"
## Decision Outcome
@@ -46,10 +46,10 @@ Chosen option: "[option 1]", because [justification. e.g., only option, which me
We have a boilr template already. [boilr-ocis-extension](https://github.com/owncloud/boilr-ocis-extension/)
This approach is nice because it provides placeholders which can be filled during the generation of a new extension from the template. It also provides prompts for the placeholder values during generation.
* Good, because with the placeholders it is hard to miss values which should be changed
* Bad, because maintaining is more complex
* Good, because with the placeholders it is hard to miss values which should be changed
* Bad, because maintaining is more complex
### Template git repository
### Template git repository
Create a git repository with an extension containing the boilerplate code.
@@ -61,5 +61,6 @@ Create a git repository with an extension containing the boilerplate code.
We have the ocis-hello repository which acts as an example extension containing a grpc and http service and a web UI. It also demonstrates the usage of the settings service.
* Good, because it contains a bit more code than just the plain boilerplate
* Good, because the integration into oCIS is already tested for the Hello extension (eg. with Proxy and Settings). This will ensure, that the example extension is up to date.
* Bad, because if you don't require all features you have to delete stuff