Release v0.15.0

[ircwaves]

⚠️ Deprecations

• Both the CIRRUS_FAILED_TOPIC_ARN and CIRRUS_INVALID_TOPIC_ARN SNS Topics
  have been deprecated, and the CIRRUS_WORKFLOW_EVENT_TOPIC_ARN Topic should
  be used by subscriptions which need to act on failed or invalid workflows.

Fixed

• Incorrect function already_processing corrected to
  skipping(state="PROCESSING",...). ([fix: dne already_processing, instead skipping with state=PROCESSING #267])
• payload_id was not passed properly to StateDB for logging, via the state
  change decorator. Updated the decorator to be a Descriptor, which may make
  type checking happier. ([fix: passing payload_id into statedb decorator #270])
• added function cirrus.lib2.utils.cold_start to move overhead of boto
  client/resource cache instantiation out of lambda function execution. ([added function 'cirrus.lib2.utils.cold_start' #272])

Added

• cirrus-<stage>-workflow-event SNS topic, and
  WorkflowEventManager class for managing workflow event actions. ([Workflow event class #261])
  The actions managed by this class include:

  • updating state of workflows in StateDB

  • announcing interactions cirrus has with a payload to the
    cirrus-<stage>-workflow-event
    Note: To use this topic, existing deployments will need to add the following
    to their environment in both their cirrus.yml file:

    CIRRUS_WORKFLOW_EVENT_TOPIC_ARN: !Ref WorkflowEventTopic

    and add the Topic to their cloudformation/resources.yml file:

    # SNS Topic for any cirrus interactions with a workflow
    WorkflowEventTopic:
      Type: "AWS::SNS::Topic"
      Properties:
      TopicName: "#{AWS::StackName}-workflow-event"

• Testing of python 3.12. ([Workflow event class #261])

• SfnStatus string enum added for StepFunctions execution status
  strings. ([Workflow event class #261])

• Added check of status returned from AWS calls to update the StateDB table,
  which raises a RuntimeError including the response if the write fails.
  This addresses Issue [statedb needs to check dynamo responses and raise errors for non-success #202]. ([Migrate timestream calls to events #263])

Changed

• Moved StateEnum to cirrus.lib2.enums module for use across lib2 and
  builtins. ([Workflow event class #261])
• Migrated management of timeseries (EventDB) events from StateDB to
  WorkflowEventManager. ([Migrate timestream calls to events #263])
• Provide option to pass in timestamp to WorkflowEventManager state-change
  functions. ([Migrate timestream calls to events #263])

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.95%. Comparing base (75eb288) to head (fbb5e8f).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #273   +/-   ##
=======================================
  Coverage   82.95%   82.95%           
=======================================
  Files          57       57           
  Lines        3033     3033           
=======================================
  Hits         2516     2516           
  Misses        517      517           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jkeifer]

and add the Topic to their cloudformation/resources.yml file:

# SNS Topic for any cirrus interactions with a workflow
WorkflowEventTopic:
  Type: "AWS::SNS::Topic"
  Properties:
  TopicName: "#{AWS::StackName}-workflow-event"

It looks like WorkflowEventTopic was added to the builtin resources so this should not be necessary, right?

[ircwaves]

It looks like WorkflowEventTopic was added to the builtin resources so this should not be necessary, right?

It isn't necessary, but with the deprecation of the failed topic, it seems reasonable to me to put it in there. Open to other interpretations though.

[jkeifer]

My point is that by virtue of it being in the builtin cloudformation resources it will be included in all cirrus >=0.15.0 projects' cloudformation stacks with no action on the project's part. Reprhased: you do not need to put that resource definition in your project resources to have that topic created because it is in the builtin resource set.

So telling users to add that to their project configuration is redundant and merely copies the builtin resource that would be deployed regardless.