that the primary use of the purge action is to purge the outer CDN (and the inner CDN).
i think that keeping the inner CDN in sync with the content/code especially with github is something that needs to happen automatically and in that sense i would rather separate that from this action. i am worried that if we get to a place where we require purging on commits for the inner CDN we will start making the initial hurdle for someone to get started with a helix project higher.
so in my mind this is acceptable complexity for someone who goes live with a helix project on a real domain, but not for someone who is in development.
that the primary use of the purge action is to purge the outer CDN (and the inner CDN).
i think that keeping the inner CDN in sync with the content/code especially with github is something that needs to happen automatically and in that sense i would rather separate that from this action. i am worried that if we get to a place where we require purging on commits for the inner CDN we will start making the initial hurdle for someone to get started with a helix project higher.
so in my mind this is acceptable complexity for someone who goes live with a helix project on a real domain, but not for someone who is in development.