Setup GitHub actions example

.github/workflows/publish.yaml

@@ -7,7 +7,7 @@ on:
 
 jobs:
   publish:
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-24.04
     permissions:
       contents: read
       id-token: write # The OIDC ID token is used for authentication with JSR.

MAINTENANCE.md

@@ -6,14 +6,18 @@ This library isn't too large but there are still things to maintain, such as
    - In `.devcontainer/Dockerfile`
    - In `.github/workflows/ci.yaml`
    - In `.github/workflows/publish.yaml`
+   - In `examples/attribute-targeting/updateFlagDefinitionsInKv.yaml`
 2. Github Actions runner version
    - In `.github/workflows/ci.yaml`
    - In `.github/workflows/publish.yaml`
+   - In `examples/attribute-targeting/updateFlagDefinitionsInKv.yaml`
 3. 3rd Party Github Actions
    - In `.github/workflows/ci.yaml`
    - In `.github/workflows/publish.yaml`
+   - In `examples/attribute-targeting/updateFlagDefinitionsInKv.yaml`
 4. Library dependencies
    - In `./src/deps.ts`
+   - In `./src/client.test.ts`
    - In `./src/integration.test.ts`
 
 The emphasis should be on keeping up-to-date with major version changes (to stay

README.md

@@ -60,7 +60,8 @@ You should end up with something like this
 
 ### Upload the JSON File to KV
 
-Create a script called `updateKv.ts` (for use with the Deno CLI) as follows
+Create a script called `updateFlagDefinitionsInKv.ts` (for use with the Deno
+CLI) as follows
 
 ```ts
 import { createKvClient } from "jsr:@grunet/openfeature-for-denodeploy";
@@ -96,7 +97,7 @@ placeholders.
 export URL_TO_KV=<replace with the url to KV>
 export DENO_KV_ACCESS_TOKEN=<replace with your access token> 
 
-deno run --unstable-kv --allow-read=flags.json --allow-env=URL_TO_KV,DENO_KV_ACCESS_TOKEN --allow-net updateKv.ts
+deno run --unstable-kv --allow-read=flags.json --allow-env=URL_TO_KV,DENO_KV_ACCESS_TOKEN --allow-net updateFlagDefinitionsInKv.ts
 ```
 
 This will store the flag definitions JSON into KV in Deno Deploy for your
@@ -147,13 +148,45 @@ definitions' attribute targeting rules for matches.
 
 ## Other Recommendations
 
-There are 2 suggestions I'd recommend to complete the overall workflow
+There are 2 other suggestions I'd recommend to complete the overall workflow
 
 1. Version Control
 2. Automation
 
-Keeping the flag definitions in a VCS has all the usual benefits of keeping
-things in version control.
+Keeping the flag definitions in a version control system has all the usual
+benefits of keeping things in version control.
 
 And automating updates to the flag definitions (e.g. via Github Actions) also
-brings the usual benefits.
+brings the usual benefits. For example, this is what a Github Workflow could
+look like for keeping flag definitions updated in KV
+
+```yaml
+name: Update Flag Definitions in KV
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  update:
+    runs-on: ubuntu-24.04
+    environment: flagDefinitions
+    steps:
+      - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4.1.6
+
+      - uses: denoland/setup-deno@041b854f97b325bd60e53e9dc2de9cb9f9ac0cba # v1.1.4
+        with:
+          deno-version: "1.43.5"
+
+      - name: Update Flag Definitions
+        env:
+          URL_TO_KV: ${{ secrets.URL_TO_KV }}
+          DENO_KV_ACCESS_TOKEN: ${{ secrets.DENO_KV_ACCESS_TOKEN }}
+        run: |
+          deno run --unstable-kv --allow-read=flags.json --allow-env=URL_TO_KV,DENO_KV_ACCESS_TOKEN --allow-net updateFlagDefinitionsInKv.ts
+```
+
+All that's needed is to set `URL_TO_KV` and `DENO_KV_ACCESS_TOKEN` (see above
+for their definitions) as environment secrets in the `flagDefinitions`
+environment (which can be created in Github at Settings > Environments).

examples/attribute-targeting/updateKv.ts → examples/attribute-targeting/updateFlagDefinitionsInKv.ts

@@ -2,7 +2,7 @@
 
 // export URL_TO_KV=<Gotten from https://dash.deno.com/projects/<your project name>/kv>
 // export DENO_KV_ACCESS_TOKEN=<Gotten from https://dash.deno.com/account#access-tokens>
-// deno run --unstable-kv --allow-read=flags.json --allow-env=URL_TO_KV,DENO_KV_ACCESS_TOKEN --allow-net updateKv.ts
+// deno run --unstable-kv --allow-read=flags.json --allow-env=URL_TO_KV,DENO_KV_ACCESS_TOKEN --allow-net updateFlagDefinitionsInKv.ts
 
 // Had to use --allow-net because wildcards aren't allowed and the CLI is reaching out to a URL like "us-east4.txnproxy.deno-gcp.net" (see https://github.com/denoland/deno/issues/6532)
 

examples/attribute-targeting/updateFlagDefinitionsInKv.yaml

@@ -0,0 +1,32 @@
+# Internal note
+# To test this workflow:
+# 1. Copy it to .github/workflows
+# 2. Add a working-directory of examples/attribute-targeting to the Update FLag Definitions step
+# 3. Add URL_TO_KV and DENO_KV_ACCESS_TOKEN as environment secrets
+# 4. Remove the main branch restriction of on:push:
+# Then test by pushing changes to a test branch
+
+name: Update Flag Definitions in KV
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  update:
+    runs-on: ubuntu-24.04
+    environment: flagDefinitions
+    steps:
+      - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4.1.6
+
+      - uses: denoland/setup-deno@041b854f97b325bd60e53e9dc2de9cb9f9ac0cba # v1.1.4
+        with:
+          deno-version: "1.43.5"
+
+      - name: Update Flag Definitions
+        env:
+          URL_TO_KV: ${{ secrets.URL_TO_KV }}
+          DENO_KV_ACCESS_TOKEN: ${{ secrets.DENO_KV_ACCESS_TOKEN }}
+        run: |
+          deno run --unstable-kv --allow-read=flags.json --allow-env=URL_TO_KV,DENO_KV_ACCESS_TOKEN --allow-net updateFlagDefinitionsInKv.ts