Overview - Ghost

Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
29191
b3cb7bca Added routes_hash continuity test for the activation bridge - getCurrentHash() is md5(JSON.stringify(...)) over the expanded settings, and route-settings.js hardcodes the hash of the expanded default routes ('3d180d52...'). That constant is the only hash value external consumers could compare against, so it must survive the switch from validate.js to parser + activation bridge — this test pins both paths to it - the existing equivalence tests use deepEqual, which is key-order-insensitive; JSON.stringify is not, so hash continuity was untested until now - byte-identical hashes for customized configs are not achievable: validate.js mutates the parsed YAML in place, so its output key order (and hash) depends on the order keys were written in the user's routes.yaml, which a normalized domain model cannot preserve. Customized sites will get a harmless one-time routes_hash re-sync when the read path switches — nothing reads routes_hash except the sync comparison itself - keeps the upcoming FileStore PR free of hash concerns: hashing stays in the service, computed over the bridge output
by Princi Ver...
Succeeded
29191
f4cba0e6 Added routes_hash continuity test for the activation bridge - getCurrentHash() is md5(JSON.stringify(...)) over the expanded settings, and route-settings.js hardcodes the hash of the expanded default routes ('3d180d52...'). That constant is the only hash value external consumers could compare against, so it must survive the switch from validate.js to parser + activation bridge — this test pins both paths to it - the existing equivalence tests use deepEqual, which is key-order-insensitive; JSON.stringify is not, so hash continuity was untested until now - byte-identical hashes for customized configs are not achievable: validate.js mutates the parsed YAML in place, so its output key order (and hash) depends on the order keys were written in the user's routes.yaml, which a normalized domain model cannot preserve. Customized sites will get a harmless one-time routes_hash re-sync when the read path switches — nothing reads routes_hash except the sync comparison itself - keeps the upcoming FileStore PR free of hash concerns: hashing stays in the service, computed over the bridge output
by Princi Ver...
Succeeded
29191
3c64a767 Added routes_hash continuity test for the activation bridge - getCurrentHash() is md5(JSON.stringify(...)) over the expanded settings, and route-settings.js hardcodes the hash of the expanded default routes ('3d180d52...'). That constant is the only hash value external consumers could compare against, so it must survive the switch from validate.js to parser + activation bridge — this test pins both paths to it - the existing equivalence tests use deepEqual, which is key-order-insensitive; JSON.stringify is not, so hash continuity was untested until now - byte-identical hashes for customized configs are not achievable: validate.js mutates the parsed YAML in place, so its output key order (and hash) depends on the order keys were written in the user's routes.yaml, which a normalized domain model cannot preserve. Customized sites will get a harmless one-time routes_hash re-sync when the read path switches — nothing reads routes_hash except the sync comparison itself - keeps the upcoming FileStore PR free of hash concerns: hashing stays in the service, computed over the bridge output
by Princi Ver...