ci: downgrade link check image

.markdown-link-check.json

@@ -5,9 +5,6 @@
         },
         {
           "pattern": "localhost"
-        },
-        {
-          "pattern": "^https://expressjs.com/"
         }
     ],
     "aliveStatusCodes": [200, 206]

flagd-demo/assets/scripts/intro_foreground.sh

@@ -1,9 +1,9 @@
 #!/bin/bash
 
-DEBUG_VERSION=12
+DEBUG_VERSION=13
 GITEA_VERSION=1.19
 TEA_CLI_VERSION=0.9.2
-FLAGD_VERSION=0.4.5
+FLAGD_VERSION=0.11.5
 
 # Download and install flagd
 wget -O flagd.tar.gz https://github.com/open-feature/flagd/releases/download/flagd%2Fv${FLAGD_VERSION}/flagd_${FLAGD_VERSION}_Linux_x86_64.tar.gz
@@ -153,7 +153,7 @@ tea login add \
 # Clone the template repo
 tea repo create --name=flags --branch=main --init=true > /dev/null 2>&1
 git clone http://openfeature:openfeature@0.0.0.0:3000/openfeature/flags
-wget -O ~/flags/example_flags.flagd.json https://raw.githubusercontent.com/open-feature/flagd/main/config/samples/example_flags.flagd.json
+wget -O ~/flags/example_flags.flagd.json https://raw.githubusercontent.com/open-feature/flagd/refs/tags/flagd/v${FLAGD_VERSION}/samples/example_flags.flagd.json
 cd ~/flags
 git config credential.helper cache
 git add -A
@@ -163,4 +163,4 @@ git push
 # ---------------------------------------------#
 #       🎉 Installation Complete 🎉           #
 #           Please proceed now...              #
-# ---------------------------------------------#
+# ---------------------------------------------#

flagd-demo/finish.md

@@ -1,42 +1,13 @@
 
 ## Congratulations! 🎉
-In this tutorial you have built an OpenFeature compliant feature flag backend using flagd.
+
+In this tutorial, you have built an OpenFeature compliant feature flag backend using flagd.
 
 You now have a pure GitOps feature flagging system. You can change only a JSON file and your application will automatically leverage the changes.
 
 This is just the beginning. flagd is capable of a lot more, such as providing multiple flag sources, local file usage or retrieval over HTTPS or gRPC.
 
 ## What's Next?
 
-In this tutorial, interaction with the flagd API was via `curl`{{}}. In reality, you wouldn't want your application becoming reliant on flagd - that's the entire premise of OpenFeature. Your application should be able to say "getAFlag" without caring about the backend system (flagd in this case).
-
-To achieve this, OpenFeature offers [language specific flagd providers](https://github.com/open-feature/flagd/blob/main/docs/usage/flagd_providers.md) which interact and "translate" to flagd code for you. If you are using Kubernetes - use the OpenFeature Operator which handles all of this complexity for you. Follow the [OpenFeature Operator hands-on tutorial](https://killercoda.com/open-feature/scenario/openfeature-operator-demo) or read the [OFO docs](https://github.com/open-feature/open-feature-operator/tree/main/docs).
-
-For example, in Golang, your application code would look like this:
-
-```
-package main
-
-import (
-	"github.com/open-feature/go-sdk-contrib/providers/flagd/pkg"
-   	"github.com/open-feature/go-sdk/pkg/openfeature"
-)
-
-func main() {
-    openfeature.SetProvider(flagd.NewProvider(
-        flagd.WithHost("flagDHost"),
-        flagd.WithPort(8013),
-    ))
-
-    // Get an openFeature client
-    client := openfeature.NewClient("myApp")
-
-    // Get flag values
-    value, err := client.BooleanValue(
-		context.Background(), "myFlagValue", false, openfeature.EvaluationContext{},
-	)
-}
-```
-
-- [Get started with flagd](https://github.com/open-feature/flagd)
+- [Get started with flagd](https://flagd.dev/)
 - Questions? [Join the community](https://openfeature.dev/community/)

flagd-demo/step3.md

@@ -8,15 +8,15 @@ curl -X POST {{TRAFFIC_HOST1_8013}}/schema.v1.Service/ResolveString \
   -d '{"flagKey": "headerColor", "context": {} }'
 ```{{exec}}
 
-This should return `red` because the `defaultVariant` is set to `red` in Git ([see here]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L95)).
+This should return `red` because the `defaultVariant` is set to `red` in Git ([see here]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L96)).
 
 ## Change Flag Color
 
 Using GitOps, change the `defaultVariant` from `red` to `yellow`:
 
 Open the Editor and find this file: `~/flags/example_flags.flagd.json`{{}}
 
-Change the `defaultVariant`{{}} (line `95`{{}}) from `red`{{}} to `yellow`{{}}.
+Change the `defaultVariant`{{}} (line `96`{{}}) from `red`{{}} to `yellow`{{}}.
 
 Change back to Tab 2 and commit these changes to your Git repository by clicking this text:
 
@@ -27,7 +27,7 @@ git commit -m "update header color"
 git push
 ```{{exec}}
 
-[Line 95]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L95) should now be `"defaultVariant": "yellow",`
+[Line 96]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L96) should now be `"defaultVariant": "yellow",`
 
 ## Retrieve the Flag Value Again
 
@@ -37,4 +37,4 @@ This time you should receive `yellow`.
 curl -X POST {{TRAFFIC_HOST1_8013}}/schema.v1.Service/ResolveString \
   -H "Content-Type: application/json" \
   -d '{"flagKey": "headerColor", "context": {} }'
-```{{exec}}
+```{{exec}}

flagd-demo/step5.md

@@ -1,34 +1,26 @@
-So far you've seen a very basic feature flag. But often you need more flexibility *within* a given flag rule.
+So far, you've seen a very basic feature flag. But often, you need more flexibility *within* a given flag rule.
 
 For this, OpenFeature provides a concept of targeting rules. Targeting rules allow you to be more specific in *who* receives a given flag value.
 
-For example, look at [targetedFlag]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L126-L149). 
+For example, look at [fibAlgo]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L70-88). 
 
 The rules can be read like this:
 
-- By default, everyone receieves the flag `first` with the value of `AAA` **except**...
-- When an `email` key is present containing `@openfeature.dev`, the returned flag is `second` with a value of `BBB`.
-- When an `userAgent` key is present containing `Chrome`, the returned flag is `third` with a value of `CCC`.
+- By default, everyone receives `recursive` **except**...
+- When an `email` key ends with `@faas.com,` the returned variant is `binet` is returned.
 
 Try this out now:
 
-This command should return the `first` variant with a value of `AAA`.
+This command should return the `recursive` variant with a value of `recursive`.
 ```
 curl -X POST {{TRAFFIC_HOST1_8013}}/schema.v1.Service/ResolveString \
   -H "Content-Type: application/json" \
-  -d '{"flagKey": "targetedFlag", "context": {} }'
+  -d '{"flagKey": "fibAlgo", "context": {} }'
 ```{{exec}}
 
-This command should return the `second` variant with a value of `BBB`.
+This command should return the `binet` variant with a value of `binet`.
 ```
 curl -X POST {{TRAFFIC_HOST1_8013}}/schema.v1.Service/ResolveString \
   -H "Content-Type: application/json" \
-  -d '{"flagKey": "targetedFlag", "context": { "email": "me@openfeature.dev" } }'
+  -d '{"flagKey": "fibAlgo", "context": { "email": "me@faas.com" } }'
 ```{{exec}}
-
-This command should return the `third` variant with a value of `CCC`.
-```
-curl -X POST {{TRAFFIC_HOST1_8013}}/schema.v1.Service/ResolveString \
-  -H "Content-Type: application/json" \
-  -d '{"flagKey": "targetedFlag", "context": { "userAgent": "Chrome 1.2.3" } }'
-```{{exec}}

flagd-demo/step6.md

@@ -1,10 +1,10 @@
 Need *even more* flexibility? Fractional evaluations allow for even more powerful flag targeting.
 
-Look at the [headerColor]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L88-L125) flag.
+Look at the [headerColor]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L89-120) flag.
 
 The available variants are `red`, `blue`, `green` and `yellow`. The `defaultVariant` should now be `yellow` (you changed it from `red` in the previous step).
 
-So everyone receives `yellow`, right? No. There is a [targeting rule]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L97-L125) which can be read like this:
+So everyone receives `yellow`, right? No. There is a [targeting rule]({{TRAFFIC_HOST1_3000}}/openfeature/flags/src/branch/main/example_flags.flagd.json#L98-L119) which can be read like this:
 
 Everyone receives the `defaultVariant`{{}} of `yellow`{{}} **except**...
 
@@ -58,4 +58,4 @@ Finally, prove that the `defaultVariant` is working (request the flag value with
 curl -X POST {{TRAFFIC_HOST1_8013}}/schema.v1.Service/ResolveString \
   -H "Content-Type: application/json" \
   -d '{"flagKey": "headerColor", "context": { } }'
-```{{exec}}
+```{{exec}}

makefile

@@ -2,4 +2,4 @@ ROOT_DIR := $(dir $(realpath $(lastword $(MAKEFILE_LIST))))
 .PHONY: linkcheck
 
 linkcheck:
-	find . -name \*.md -print0 | xargs -0 -n1 docker run --rm -i -v $(CURDIR):/tmp -w /tmp ghcr.io/tcort/markdown-link-check:stable -c .markdown-link-check.json
+	find . -name \*.md -print0 | xargs -0 -n1 docker run --rm -i -v $(CURDIR):/tmp -w /tmp ghcr.io/tcort/markdown-link-check:3.13.5 -c .markdown-link-check.json