Merge pull request #11 from ConductionNL/dev-barry

All entities + annotations + relations added

.env

@@ -23,11 +23,16 @@ APP_BUILD=dev
 # The description for this api
 APP_DESCRIPTION='Naast deze JSON rest API is er ook een [graphql](/graphql) interface beschikbaar.'
 
+# The urls on wich this api is available
+TRUSTED_PROXIES=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
+TRUSTED_HOSTS=^(.+\.)?conduction\.nl$|^(.+\.)?huwelijksplanner\.online$|^(.+\.)?larping\.eu$|^(.+\.)?common-ground\.nl$|^(.+\.)?trouwplanner\.online$|^(.+\.)?zaakonline\.nl$|localhost
+
 ##################################################
 # Documentation settings
 ##################################################
 
-APP_DEMO=arc.zaakonline.nl
+APP_DOMAIN=conduction.nl
+APP_DEMO=pc.zaakonline.nl
 APP_REPRO=https://github.com/ConductionNL/Proto-component-commonground
 
 ##################################################
@@ -42,7 +47,7 @@ CONTAINER_REPRO=https://hub.docker.com/repository/docker/conduction/arc-php
 # Notifcation settings
 ##################################################
 
-NOTIFICATION_ENABLED=false
+NOTIFICATION_ENABLED=falsedxfddxf
 NOTIFICATION_PROVIDER=sasd
 NOTIFICATION_ENABLED_AUTHORIZATION=sasd
 

.github/deploy.yml

@@ -0,0 +1,4 @@
+# View examples and documentation at https://deliverybot.dev/docs/
+production:
+  environment: production
+  production_environment: true

.github/workflows/dockerimage.yml

@@ -98,7 +98,7 @@ jobs:
         if: failure()
         run: helm install --name $APP_NAME-$APP_ENV ./api/helm  --kubeconfig="kubeconfig.yaml" --namespace=$APP_ENV  --set settings.env=$APP_ENV,settings.debug=1 
       - name: Rollout new containers
-        if: (contains( github.ref, 'master' ) || contains( github.ref, 'staging' ) || contains( github.ref, 'development' )) && steps.kubeconfig.outputs.success == 'true' && steps.helm-install.success == 'true'
+        if: (contains( github.ref, 'master' ) || contains( github.ref, 'staging' ) || contains( github.ref, 'development' )) && steps.kubeconfig.outputs.success == 'true' && success()
         run: |
             kubectl rollout restart deployment/$APP_NAME-php --kubeconfig="kubeconfig.yaml"  --namespace=$APP_ENV
             kubectl rollout restart deployment/$APP_NAME-nginx --kubeconfig="kubeconfig.yaml"  --namespace=$APP_ENV
@@ -107,17 +107,22 @@ jobs:
         if: (success() || failure())
         id: releasecode
         run: |
-            echo "##[set-output name=releasename]$APP_BUILD-$GITHUB_SHA"
-            
+            export RELEASE=$APP_BUILD-$(git rev-parse --short $GITHUB_SHA)
+            echo "##[set-output name=releasename]$RELEASE"
+      - name: Print release name
+        if: (success() || failure())
+        run: echo $RELEASENAME
+        env:
+            RELEASENAME: ${{ steps.releasecode.outputs.releasename }}
       - name: Create Release
         if: contains( github.ref, 'master' ) && steps.kubeconfig.outputs.success == 'true' && ( success() || failure() )
         id: create_release
         uses: actions/create-release@v1
         continue-on-error: true
         env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
+            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
         with:
-          tag_name: ${{ steps.releasecode.releasename }}
-          release_name: ${{ steps.releasecode.releasename }}
-          draft: false
-          prerelease: false
+            tag_name: ${{ steps.releasecode.outputs.releasename }}
+            release_name: ${{ steps.releasecode.outputs.releasename }}
+            draft: false
+            prerelease: false

INSTALLATION.md

@@ -4,6 +4,7 @@ This document dives a little bit deeper into installing your component on a kube
 ## Setting up helm
 
 
+
 ## Setting up tiller
 Create the tiller service account:
 
@@ -18,39 +19,45 @@ $ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --service
 
 Now we can run helm init, which installs Tiller on our cluster, along with some local housekeeping tasks such as downloading the stable repo details:
 ```CLI
-$ helm init --service-account tiller --kubeconfig="api/helm/kubeconfig.yaml"
+$ helm init --service-account tiller --kubeconfig="kubeconfig.yaml"
 ```
 
 To verify that Tiller is running, list the pods in the kube-system namespace:
 ```CLI
-$ kubectl get pods --namespace kube-system --kubeconfig="api/helm/kubeconfig.yaml"
+$ kubectl get pods --namespace kube-system --kubeconfig="kubeconfig.yaml"
 ```
 
 The Tiller pod name begins with the prefix tiller-deploy-.
 
 Now that we've installed both Helm components, we're ready to use helm to install our first application.
 
+
+## Setting up ingress
+We need at least one nginx controller per kubernetes kluster, doh optionally we could set on up on a per namebase basis
+
+helm install stable/nginx-ingress --name loadbalancer --kubeconfig="kubeconfig.yaml"
+
 ## Setting up Kubernetes Dashboard
 After we installed helm and tiller we can easily use both to install kubernetes dashboard
 ```CLI
-$ helm install stable/kubernetes-dashboard --name dashboard --kubeconfig="api/helm/kubeconfig.yaml" --namespace="kube-system"
+$ helm install stable/kubernetes-dashboard --name dashboard --kubeconfig="kubeconfig.yaml" --namespace="kube-system"
 ```
 
 But before we can login to tiller we need a token, we can get one of those trough the secrets. Get yourself a secret list by running the following command
 ```CLI
-$ kubectl -n kube-system get secret  --kubeconfig="api/helm/kubeconfig.yaml"
+$ kubectl -n kube-system get secret  --kubeconfig="kubeconfig.yaml"
 ```
 
 Because we just bound tiller to our admin account and use tiller (trough helm) to manage our code deployment it makes sense to use the tiller token, lets look at the tiller secret (it should look something like "tiller-token-XXXXX" and ask for the corresponding token. 
 
 ```CLI
-$ kubectl -n kube-system describe secrets tiller-token-xxxxx  --kubeconfig="api/helm/kubeconfig.yaml"
+$ kubectl -n kube-system describe secrets tiller-token-xxxxx  --kubeconfig="kubeconfig.yaml"
 ```
 
 This should return the token, copy it to somewhere save (just the token not the other returned information) and start up a dashboard connection
 
 ```CLI
-$kubectl proxy --kubeconfig="api/helm/kubeconfig.yaml"
+$kubectl proxy --kubeconfig="kubeconfig.yaml"
 ```
 
 This should proxy our dashboard to helm making it available trough our favorite browser and a simple link
@@ -65,16 +72,16 @@ $ helm dependency update ./api/helm
 ```
 If you want to create a new instance
 ```CLI
-$ helm install --name arc-dev ./api/helm  --kubeconfig="api/helm/kubeconfig.yaml" --namespace=dev  --set settings.env=dev,settings.debug=1
-$ helm install --name arc-stag ./api/helm --kubeconfig="api/helm/kubeconfig.yaml" --namespace=stag --set settings.env=stag,settings.debug=0
-$ helm install --name arc-prod ./api/helm --kubeconfig="api/helm/kubeconfig.yaml" --namespace=prod --set settings.env=prod,settings.debug=0 
+$ helm install --name pc-dev ./api/helm  --kubeconfig="api/helm/kubeconfig.yaml" --namespace=dev  --set settings.env=dev,settings.debug=1
+$ helm install --name pc-stag ./api/helm --kubeconfig="api/helm/kubeconfig.yaml" --namespace=stag --set settings.env=stag,settings.debug=0
+$ helm install --name pc-prod ./api/helm --kubeconfig="api/helm/kubeconfig.yaml" --namespace=prod --set settings.env=prod,settings.debug=0
 ```
 
 Or update if you want to update an existing one
 ```CLI
-$ helm upgrade arc-dev ./api/helm  --kubeconfig="api/helm/kubeconfig.yaml --namespace=dev  --set settings.env=dev, settings.debug=1" 
-$ helm upgrade arc-stag ./api/helm --kubeconfig="api/helm/kubeconfig.yaml --namespace=stag --set settings.env=stag, settings.debug=0" 
-$ helm upgrade arc-prod ./api/helm --kubeconfig="api/helm/kubeconfig.yaml --namespace=prod --set settings.env=prod, settings.debug=0" 
+$ helm upgrade pc-dev ./api/helm  --kubeconfig="api/helm/kubeconfig.yaml" --namespace=dev  --set settings.env=dev,settings.debug=1
+$ helm upgrade pc-stag ./api/helm --kubeconfig="api/helm/kubeconfig.yaml" --namespace=stag --set settings.env=stag,settings.debug=0
+$ helm upgrade pc-prod ./api/helm --kubeconfig="api/helm/kubeconfig.yaml" --namespace=prod --set settings.env=prod,settings.debug=0
 ```
 
 Or del if you want to delete an existing  one

README.md

@@ -14,7 +14,7 @@ Keeping in form with international standardization calendars are based on the [s
 - [Securing this component](SECURITY.md)
 - [Design considerations](DESIGN.md)
 
-A hosted version of the OAS documentation and an demo version of the API can be found on http://vrc.zaakonline.nl
+A hosted version of the OAS documentation and an demo version of the API can be found on http://arc.zaakonline.nl
 
 ## Features
 This repository uses the power of the [commonground proto component](https://github.com/ConductionNL/commonground-component) provide common ground specific functionality based on the [VNG Api Strategie](https://docs.geostandaarden.nl/api/API-Strategie/). Including  

TUTORIAL.md

@@ -12,7 +12,7 @@ For the steps considering the generation of resources (or entities as symfony ca
 
 ## Setting up your enviroment
 
-You can install docker-desktop from [the docker website](). 
+You can install docker-desktop from [the docker website](https://hub.docker.com/editions/community/docker-ce-desktop-windows). 
 
 
 ## Generating your component (repository/codebase)
@@ -26,7 +26,7 @@ After that you should be redirected to your own brand new repository.
 We ran a fork of the base Common Ground component, that means that we copied the code of the original project into a new repository. By doing so we made sure we have all the necessities for our component, including security and compliance with international standards. 
 
 ## Spinning up your component
-Before we can spin up our component we must first get a local copy from our repository, we can either do this through the command line (example here) or use a Git client. 
+Before we can spin up our component we must first get a local copy from our repository, we can either do this through the command line  or use a Git client. 
 
 For this example we're going to use GitKraken but you can use any tool you like, feel free to skip this part if you are already familiar with setting up a local clone of your repository.
 
@@ -35,7 +35,7 @@ Open gitkraken press "clone a repo" and fill in the form (select where on your l
 You can now navigate to the folder where you just installed your code, it should contain some folders and files and generally look like this. We will get into the files later, lets first spin up our component!
 
 Open a command window (example) and browse to the folder where you just stuffed your code, navigating in a command window is done by cd, so for our example we could type 
-cd c:\repos\common-ground\my-component (if you installed your code on a different disk then where the cmd window opens first type <diskname>: for example D: and hit enter to go to that disk, D in this case). We are now in our folder, so let's go! Type docker-compose up and hit enter. From now on whenever we describe a command line command we will document it as follows:
+cd c:\repos\common-ground\my-component (if you installed your code on a different disk then where the cmd window opens first type <diskname>: for example D: and hit enter to go to that disk, D in this case). We are now in our folder, so let's go! Type docker-compose up and hit enter. From now on whenever we describe a command line command we will document it as follows (the $ isn't actually typed but represents your folder structure):
 
 ```CLI
 $ docker-compose up
@@ -45,8 +45,9 @@ Your computer should now start up your local development environment. Don't worr
 
 Open your browser type http://localhost/ as address and hit enter, you should now see your common ground component up and running.
 
-### trouble shooting
+### Trouble shooting
 When spinning up components we make extensive use of the cashing of docker, and use volumes to represent server disks. When running in to unexpected trouble always remember to clear your local docker vm with the -a command (removing image cash)
+
 ```CLI
 $ docker system prune -a
 ```
@@ -62,7 +63,7 @@ You can now access your api at http://localhost:8080/, as you can see it's pre-l
 
 First let's remove the resources currently in the api, we can do that by just removing the resources form our code base, navigate to the folder where you stored your code and open the folder api/src/Entity , you can find the example entities (the symfony name for resources) there. Just delete all the php files in that folder.
 
-Next let's add our own entities, we can do this in two ways, we can do old fashioned coding, but we can also use the build in maker bundle of the proto component, to quickly generate our entities for us (without the fuss of actual coding).
+Next let's add our own resources, we can do this in two ways, we can do old fashioned coding, but we can also use the build in maker bundle of the proto component, to quickly generate our entities for us (without the fuss of actual coding).
 
 Let's open a new command line window and navigate to our root folder, exactly like we did under "spinning up your component". And then lets fire up maker bundle (make sure that your component is still running in your other command window). We can do so by the following command:
 
@@ -170,7 +171,7 @@ class Organisation
 
 Keep in mind that we need to add the assert annotation to our class dependencies under 'use'.  
 
-More inforation on using validation can be found at the [symfony website](https://symfony.com/doc/current/validation.html), but it is als worth nothing that tis component comes pre packed with some typical NL validators like BSN. You can find those [here]().
+More information on using validation can be found at the [symfony website](https://symfony.com/doc/current/validation.html), but it is als worth nothing that tis component comes pre packed with some typical NL validators like BSN. You can find those [here]().
 
 ## Using UUID
 As default doctrine uses auto increment integers as identifiers (1,2, etc). For modern web applications we however prefer the use of UUID's. (e.g. e2984465-190a-4562-829e-a8cca81aa35d). Why? Wel for one it is more secure integer id's are easily guessable and make it possible to "ask" endpoint about resources that you should not know about. But UUID's also have a benefit in future proofing the application. If we in the future want to merge a table with another table (for example because two organisations using a component perform a merger) then we would have to reassign al id's and relations if we where using int based id's (both tables would have a row 1,2 etc) with UUID's however the change of doubles range somewhere in the billions. Meaning that it is likely that we only need to either reidentify only a handful of rows or more likely none at al! Turning our entire migration into a copy paste action.
@@ -199,20 +200,9 @@ with
 
 ```PHP
 //...
-	/**
-	 * @var \Ramsey\Uuid\UuidInterface
-	 *
-	 * @ApiProperty(
-	 * 	   identifier=true,
-	 *     attributes={
-	 *         "openapi_context"={
-	 *         	   "description" = "The UUID identifier of this resource",
-	 *             "type"="string",
-	 *             "format"="uuid",
-	 *             "example"="e2984465-190a-4562-829e-a8cca81aa35d"
-	 *         }
-	 *     }
-	 * )
+	/** 
+	 * @var \Ramsey\Uuid\UuidInterface The UUID identifier of this resource
+	 * @example e2984465-190a-4562-829e-a8cca81aa35d
 	 *
 	 * @Groups({"read"})
 	 * @ORM\Id

api/.env

@@ -27,8 +27,8 @@ CONDUCTION_COMMONGROUND_BAG_APIKEY=!ChangeMe!
 #APP_NAME='arc'
 APP_DESCRIPTION='Naast deze JSON rest API is er ook een [graphql](/graphql) interface beschikbaar.'
 APP_SECRET=!ChangeMe!
-TRUSTED_PROXIES=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
-TRUSTED_HOSTS='^(.+\.)?localhost|api$'
+#TRUSTED_PROXIES=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
+#TRUSTED_HOSTS='^(.+\.)?localhost|api$'
 ###< symfony/framework-bundle ###
 
 ###> symfony/framework-bundle ###

api/config/packages/twig.yaml

@@ -14,14 +14,18 @@ twig:
         app_version: '%env(APP_VERSION)%'
         app_env: '%env(APP_ENV)%'
         app_debug: '%env(APP_DEBUG)%'
+        app_domain: '%env(APP_DOMAIN)%'
         app_demo: '%env(APP_DEMO)%'
         app_repro: '%env(APP_REPRO)%'
         app_description: '%env(APP_DESCRIPTION)%'
 
         app_auth: '%env(AUTH_ENABLED)%'        
         app_audittrail: '%env(AUDITTRAIL_ENABLED)%'        
         app_notification: '%env(NOTIFICATION_ENABLED)%'
-        app_health: '%env(HEALTH_ENABLED)%'
+        app_health: '%env(HEALTH_ENABLED)%'        
+
+        trusted_hosts: '%env(TRUSTED_HOSTS)%'
+        trusted_proxies: '%env(TRUSTED_PROXIES)%'
 
         nlx_outway: '%env(NLX_OUTWAY)%'
         nlx_inway: '%env(NLX_INWAY)%'

api/helm/Chart.yaml

@@ -4,4 +4,4 @@ description: ''Naast deze JSON rest API is er ook een [graphql](/graphql) i
 name: arc
 version: 0.1.0
 home: https://common-ground.dev
-icon: https://common-ground.dev/logo-250x250.png
+icon: https://common-ground.dev/logo-250x250.png

api/helm/templates/configmap.yaml

@@ -16,6 +16,7 @@ data:
   app-version: {{ .Values.settings.version | quote }}
   app-repro: {{ .Values.settings.repro | quote }}
   app-demo: {{ .Values.settings.demo | quote }}
+  app-domain: {{ .Values.settings.domain | quote }}
   app-description: {{ .Values.settings.description | quote }}
 
   app-auth: {{ .Values.settings.authorisationEnabled | quote }}