Describe the bug
In CI there are 3 scenarios:
-
Ephemeral runner/s
State caching is wasted IO here, it will be deleted with the runner.
-
Persistent runners
Each runner gets its own cache. Each deployment might run on a different runner getting either no cache or a stale cache.
-
Persistent runner (singular) or explict state handling.
Once you've run into the this the first time and find the docs you might use your CI provider's caching action to save/load the state between pipeline runs. The recommendation is to key a hash of the app host's (full) path, CI runners paths often include things like a build/run number, so this is likely to miss.
Additionally, the docs make it sound like the caching is only used for collecting user input interactively - but I definedly ran into problems running in CI (where there is no input) with stale state - so it'd be great if the docs could be clearer about what's actually in the state and what happens if it's missing or stale.
Expected Behavior
Deployment works reliably out of the box in CI, without unexpectedly relying on state.
Anything else?
I feel like the safest option would be requiring an opt in to deployment state caching when CI is detected, or even when !interactive.
Future work might be to allow for the state to be stored in/with each environment, eg. in an Azure Storage account or ARM metadata.
Describe the bug
In CI there are 3 scenarios:
Ephemeral runner/s
State caching is wasted IO here, it will be deleted with the runner.
Persistent runners
Each runner gets its own cache. Each deployment might run on a different runner getting either no cache or a stale cache.
Persistent runner (singular) or explict state handling.
Once you've run into the this the first time and find the docs you might use your CI provider's caching action to save/load the state between pipeline runs. The recommendation is to key a hash of the app host's (full) path, CI runners paths often include things like a build/run number, so this is likely to miss.
Additionally, the docs make it sound like the caching is only used for collecting user input interactively - but I definedly ran into problems running in CI (where there is no input) with stale state - so it'd be great if the docs could be clearer about what's actually in the state and what happens if it's missing or stale.
Expected Behavior
Deployment works reliably out of the box in CI, without unexpectedly relying on state.
Anything else?
I feel like the safest option would be requiring an opt in to deployment state caching when CI is detected, or even when !interactive.
Future work might be to allow for the state to be stored in/with each environment, eg. in an Azure Storage account or ARM metadata.