S163 docs review #592
S163 docs review #592
Conversation
|
@aperez-worklytics AWS stuff complaining... I made a couple tries, but not able to fix missing |
| - `PSOXY_GITHUB_CLIENT_ID` with `App ID` value. **NOTE**: It should be `App Id` value as we are going to use authentication through the App and **not** *client_id*. | ||
| - `PSOXY_GITHUB_PRIVATE_KEY` with content of the `gh_pk_pkcs8.pem` from previous step. You could open the certificate with VS Code or any other editor and copy all the content *as-is* into this variable. | ||
| - `${var.config_parameter_prefix}GITHUB_CLIENT_ID` with `App ID` value. **NOTE**: It should be `App Id` value as we are going to use authentication through the App and **not** *client_id*. | ||
| - `${var.config_parameter_prefix}GITHUB_PRIVATE_KEY` with content of the `gh_pk_pkcs8.pem` from previous step. You could open the certificate with VS Code or any other editor and copy all the content *as-is* into this variable. |
There was a problem hiding this comment.
Yes, this is something we need to solve but it's complicated. The value you want here is specific to each proxy deployment.
By default, it's PSOXY_GITHUB_ for the whole thing; but this is just what's for the default case.
Both the PSOXY_ prefix can differ and the GITHUB_ prefix for the lambda (cloud function).
- The former is to support customers putting the SSM parameters in some hierachy, esp when deploying to a shared AWS account; they might use
people-analytics/worklytics/for example in AWS case (which conventionally uses /-style hierarchies). - The latter may vary if multiple instances of GitHub connectors for example, which we want/need to support. in which case they may have several distinct proxy deployments of the same source kind. (eg, we have people who have multiple GitHub organizations, such as one for their open source stuff, and another one for in-house)
I've tried to solve, but the logic that we use to generate the prefix value is in the aws-psoxy-rest/gcp-psoxy-rest modules atm, and as I recall I get cyclic dependency if I try to output from there to fill as a variable to worklytics-connectors- modules. Avoiding that may be a bigger refactor - splitting out the logic that defines the identifiers for each proxy instance independently at the top level of our examples, at the cost of adding an additional clone of the repository to the dependency footprint.
Other approach is to leave this parameterized, and the value of external_token_todo is a template to be evaluated later, once the
Fixes
Features
.
Change implications
CHANGELOG.md? noterraform plan/applythat isn't obviously a no-op? noalpha, requires major version change no