You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+17-2Lines changed: 17 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,13 +65,28 @@ Examples of when to Request Changes
65
65
66
66
## Style Guide
67
67
68
-
- Avoid using CSS directly. Instead, style through Material UI theming or with CSS-in-JS
68
+
### CSS
69
+
70
+
- Avoid using CSS directly where possible. Instead, style through Material UI theming or with CSS-in-JS
71
+
72
+
### Helm & Openshift
73
+
74
+
- Use Helm charts for deploying applications to Openshift.
75
+
- Deployments to Openshift should be handled by Github Actions. If you need to test, only manually deploy to the `-dev` namespace.
76
+
- Resources for a specific project should be named the same thing as the Helm chart (`{{ .Release.Name }}`).
77
+
...Unless there are multiple resources of a type, in which case they should be suffixed with a unique identifier (e.g. `{{ .Release.Name }}-api`).
78
+
- Define all environment-specific variables in the `values_dev.yaml`, `values_test.yaml`, or `values_prod.yaml` files.
79
+
- Use Vault instead of Secrets for managing sensitive data.
80
+
- Use ConfigMaps for managing non-sensitive configuration data, especially that which might change frequently.
81
+
- You may use hardcoded values in templates if configurability is not predicted to be a concern.
82
+
- NetworkPolicies should be defined for all applications to control traffic flow.
83
+
NetworkPolicies should be defined in the _same_ Helm chart as the application they are _protecting_. (It will not matter if your selectors refer to resources that have not yet been deployed.)
69
84
70
85
## Common Components/Utilities
71
86
72
87
### MET API
73
88
74
-
-`@transational`: Database method decorator. If there is an exception during execution, the entire DB session will be safely rolled back to a point in time just before the decorated function was called. If not, the session will be saved, unless autocommit is set to False. This helps replace most session management boilerplate.
89
+
-`@transactional`: Database method decorator. If there is an exception during execution, the entire DB session will be safely rolled back to a point in time just before the decorated function was called. If not, the session will be saved, unless autocommit is set to False. This helps replace most session management boilerplate.
75
90
-`authorization.check_auth`: Checks a user for one or more roles and for the correct engagement.
76
91
-`schema_utils.validate`: The most commonly used method for validating request data in resources. This method takes the request JSON data and compares it to a JSON file that acts as a schema for incoming requests of that type.
0 commit comments