[feature request] Ability to choose at which point do safeguards run.

[igalklebanov]

AFAIK, safeguards currently execute right at the end, before service is updated remotely.

This is painful if there are time consuming operations happening before that. E.g. serverless-webpack. You'll wait a LOT of time only to be told the deployment won't go through.

I'd love to configure some of my safeguards to run before webpack. E.g. a unit tests and coverage guard.

There are dirty workarounds... which I don't like. like serverless-hooks-plugin and pre package hook.

[medikoo]

@igalklebanov Safeguards are meant to inspect state that is to be deployed, and as plugins are free to influence the state, this validation happens at last possible stage.

I assume we may add some customization option, through which you could override name of the lifecycle event when validation should happen as e.g.:

custom:
  safeguards:
    lifecycleEvent: other:event # defaults to 'before:deploy:deploy'

Still implementation wise that's problematic, as by design currently plugins attach to hooks before the service config is fully resolved (so e.g. referencing safeguards configuration via some variable, will not work)

Also it'll be good to introduce a breaking change upfront so policies are not put directly on custom.safeguards but on custom.safeguards.policies

[igalklebanov]

@medikoo I see.

Can source code, environment variables, current git branch, etc. be considered as state to-be-deployed, or are we strictly talking about serverless configuration?

I like the proposed interface change. Would also add:

custom:
  safeguards:
    lifecycleEvent: other:event # defaults to 'before:deploy:deploy'
    policies:
       myPolicy:
          lifecycleEvent: 'some:serverless:hook' # overrides global lifecycleEvent, defaults to global lifecycleEvent.

...to allow more flexibility in case someone has multiple policies that he wants to be executed in different lifecycle events.

[medikoo]

Can source code, environment variables, current git branch, etc. be considered as state to-be-deployed, or are we strictly talking about serverless configuration?

Sorry, I don't understand this question. Can you elaborate?

to allow more flexibility in case someone has multiple policies that he wants to be executed in different lifecycle events.

Do we have a valid real world use case, or it's more a nice to have? If it's the latter, to not overcomplicate I wouldn't consider this at this point (as it'll significantly increase a complexity of implementation)

[igalklebanov]

@medikoo

Sorry, I don't understand this question. Can you elaborate?

I'm just trying to understand your definition of what should be inspected (state to be deployed) by a safeguard. Since a serverless deployment is a combination of configuration (serverless.yml), project source code, environment variables, context (e.g. which git branch are you (or the CI job) is on), etc.

[medikoo]

I'm just trying to understand your definition of what should be inspected (state to be deployed) by a safeguard

Generated CloudFormation template to be deployed for AWS. AFAIK it's the only thing against which safeguards validate