Migrate to golang 1.20 and fix typos (#39)

docs/installation.md

@@ -1,14 +1,14 @@
 ## Installation
 
-The current version of the docs doesn't cover the details of running the Telefonistka instance beyond listing its [configuration options](#server-configuration) and noting that its `/webhook` endpoint needs to be accessable from Github(Cloud or private instance)
+The current version of the docs doesn't cover the details of running the Telefonistka instance beyond listing its [configuration options](#server-configuration) and noting that its `/webhook` endpoint needs to be accessible from Github(Cloud or private instance)
 
 The Github side of the configuration can be done via a creation of an GitHub Application(recommended) or by configuring a webhook + github service account permission for each relevant repo.
 
 ### GitHub Application
 
 * Create the application.
   * Go to GitHub [apps page](https://github.com/settings/apps) under "Developer settings" and create a new app.
-  * Set the Webhooks URL to point to your running Telefonistka instance(remember the `/webhook` URL path), use HTTPS and set `Webhook secret` (pass  to instace via `GITHUB_WEBHOOK_SECRET` env var)
+  * Set the Webhooks URL to point to your running Telefonistka instance(remember the `/webhook` URL path), use HTTPS and set `Webhook secret` (pass  to instance via `GITHUB_WEBHOOK_SECRET` env var)
   * Provide the new app with read&write `Repository permissions` for `Commit statuses`, `Contents`, `Issues` and `Pull requests`.
   * Subscribe to `Issues` and `Pull request` events
   * Generate a `Private key` and provide it to your instance with the  `GITHUB_APP_PRIVATE_KEY_PATH` env variable.
@@ -47,15 +47,15 @@ Behavior of the bot is configured by YAML files **in the target repo**:
 
 Pulled from `telefonistka.yaml` file in the repo root directory(default branch)
 
-Configuration keys:  
+Configuration keys:
 
 |key|desc|
 |---|---|
-|`promotionPaths`| Array of maps, each map describes a promotion flow|  
+|`promotionPaths`| Array of maps, each map describes a promotion flow|
 |`promotionPaths[0].sourcePath`| directory that holds components(subdirectories) to be synced, can include a regex.|
-|`promotionPaths[0].conditions` | conditions for triggering a specific promotion flows. Flows are evatluated in order, first one to match is triggered.|
-|`promotionPaths[0].conditions.prHasLabels` | Array of PR labels, if the triggering PR has any of these lables the condition is considered fulfilled. Currently it's the only supported condition type|
-|`promotionPaths[0].promotionPrs`|  Array of structs, each element represent a PR that will be opened when files are changed under `sourcePath`. Multiple elements means multiple PR will be opened|  
+|`promotionPaths[0].conditions` | conditions for triggering a specific promotion flows. Flows are evaluated in order, first one to match is triggered.|
+|`promotionPaths[0].conditions.prHasLabels` | Array of PR labels, if the triggering PR has any of these labels the condition is considered fulfilled. Currently it's the only supported condition type|
+|`promotionPaths[0].promotionPrs`|  Array of structures, each element represent a PR that will be opened when files are changed under `sourcePath`. Multiple elements means multiple PR will be opened|
 |`promotionPaths[0].promotionPrs[0].targetPaths`| Array of strings, each element represent a directory to by synced from the changed component under  `sourcePath`. Multiple elements means multiple directories will be synced in a PR|
 |`dryRunMode`| if true, the bot will just comment the planned promotion on the merged PR|
 |`autoApprovePromotionPrs`| if true the bot will auto-approve all promotion PRs, with the assumption the original PR was peer reviewed and is promoted verbatim. Required additional GH token via APPROVER_GITHUB_OAUTH_TOKEN env variable|
@@ -105,10 +105,10 @@ toggleCommitStatus:
 
 ## Component Configuration
 
-This optional in-component configuration file allows overriding the general promotion configuration for a specific component.  
-File location is `COMPONENT_PATH/telefonistka.yaml` (no leading dot in file name), so it could be:  
-`workspace/reloader/telefonistka.yaml` or `env/prod/us-central1/c2/wf-kube-proxy-metrics-proxy/telefonistka.yaml`  
-it includes only two optional configuration keys, `promotionTargetBlockList` and `promotionTargetAllowList`.  
+This optional in-component configuration file allows overriding the general promotion configuration for a specific component.
+File location is `COMPONENT_PATH/telefonistka.yaml` (no leading dot in file name), so it could be:
+`workspace/reloader/telefonistka.yaml` or `env/prod/us-central1/c2/wf-kube-proxy-metrics-proxy/telefonistka.yaml`
+it includes only two optional configuration keys, `promotionTargetBlockList` and `promotionTargetAllowList`.
 Both are matched against the target component path using Golang regex engine.
 
 If a target path matches an entry in `promotionTargetBlockList` it will not be promoted(regardless of `promotionTargetAllowList`).

docs/modeling_environments_in_gitops_repo.md

@@ -5,22 +5,22 @@ More thorough articles can be found in the  [external resources section](#extern
 
 ## Terminology
 
-`Environment(env)`: a distinct part of your Infrastructure that is used to run your services and cloud resources to support some goal. For example, `Production` is used to serve actual customers, `Staging` could be used to test how new version of services interact with the rest of the platfrom, and `Lab` is where new and untested changes are initial deployed to.
+`Environment(env)`: a distinct part of your Infrastructure that is used to run your services and cloud resources to support some goal. For example, `Production` is used to serve actual customers, `Staging` could be used to test how new version of services interact with the rest of the platform, and `Lab` is where new and untested changes are initial deployed to.
 Having a production and at least one non-production environment is practically assumed.
 
 `Failure domain(FD)`: These represent a repeatable part of your infrastructure that you *choose* to deploy in gradual steps to control the "blast radius" of a bad deploy/configuration. A classic example could be cloud regions like `us-east-1` or `us-west-1` for a company that runs a multi-region setup.
 Smaller or younger companies might not have such distinct failure domains as the extra "safety" they provide might not be worth the investment.
 
 In some cases I will use the term `envs` to refer to both Environments and Failure domains as from the perspective of the IaC tool, the GitOps pipeline/controller and Telefonistka they are the same.
 
-`Drift`: in this context, drift describes an unwanted/unintended difference between environment/FDs that is present in the Git state, for example a change that was made to the `Staging` environment but wasn't promoited to `Prod`
+`Drift`: in this context, drift describes an unwanted/unintended difference between environment/FDs that is present in the Git state, for example a change that was made to the `Staging` environment but wasn't promoted to `Prod`
 
 ## Available Methods
 
 ### Single instance
 
 All envs are controlled from a single file/folders, a single git commit change them all *at once*.
-Even if you have per env/FD paramater override files(e.g. Helm value files/Terraform `.tfvars`), any change to the shared code(or a reference to a versioned artifact hosting the code) will be applied the all envs at once(GitOps!), somewhat negating the benefits of maintaining multiple envs.
+Even if you have per env/FD parameter override files(e.g. Helm value files/Terraform `.tfvars`), any change to the shared code(or a reference to a versioned artifact hosting the code) will be applied the all envs at once(GitOps!), somewhat negating the benefits of maintaining multiple envs.
 
 ### Git Branch per Env/FD
 

go.mod

@@ -1,17 +1,16 @@
 module github.com/wayfair-incubator/telefonistka
 
-go 1.18
+go 1.20
 
 require (
 	github.com/alexliesenfeld/health v0.6.0
-	github.com/bradleyfalzon/ghinstallation/v2 v2.1.0
+	github.com/bradleyfalzon/ghinstallation/v2 v2.2.0
 	github.com/go-test/deep v1.1.0
 	github.com/google/go-github/v48 v48.2.0
-	github.com/google/go-github/v50 v50.0.0
 	github.com/hexops/gotextdiff v1.0.3
 	github.com/migueleliasweb/go-github-mock v0.0.16
 	github.com/prometheus/client_golang v1.14.0
-	github.com/shurcooL/githubv4 v0.0.0-20221229060216-a8d4a561cc93
+	github.com/shurcooL/githubv4 v0.0.0-20230215024106-420ad0987b9b
 	github.com/sirupsen/logrus v1.9.0
 	golang.org/x/oauth2 v0.5.0
 	gopkg.in/yaml.v2 v2.4.0
@@ -20,14 +19,12 @@ require (
 require (
 	github.com/beorn7/perks v1.0.1 // indirect
 	github.com/cespare/xxhash/v2 v2.1.2 // indirect
-	github.com/golang-jwt/jwt/v4 v4.4.3 // indirect
+	github.com/golang-jwt/jwt/v4 v4.5.0 // indirect
 	github.com/golang/protobuf v1.5.2 // indirect
-	github.com/google/go-github/v41 v41.0.0 // indirect
-	github.com/google/go-github/v45 v45.2.0 // indirect
+	github.com/google/go-github/v50 v50.1.0 // indirect
 	github.com/google/go-querystring v1.1.0 // indirect
 	github.com/gorilla/mux v1.8.0 // indirect
 	github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect
-	github.com/pierrec/lz4 v2.6.1+incompatible // indirect
 	github.com/prometheus/client_model v0.3.0 // indirect
 	github.com/prometheus/common v0.37.0 // indirect
 	github.com/prometheus/procfs v0.8.0 // indirect