Description

These are the workflows which Sentinel relies upon to ship code into production.

Objectives

• Reduce the impact of deployment overhead between commit and production
• Remove manual maintenance/management cycles and reclaim engineering time to be invested toward other tasks
• Minimize the opportunity for human error
• Improve accessibility to infrastructure which supports Lily

<aside> 🟢 Green text indicates planned work that is not implemented yet.

</aside>

Shared Workflows

Shared Sub-workflows

• Approval PR to production (sub-workflow)

Workflow: Deploy new release to Staging

<aside> ❗ Note: Initial deployment requires a long startup time (~45-60m) which must be accounted for on an instance with no prior state.

</aside>

<aside> 💡 calibnet does not require deployments for sentinel-tick or sentinel-locations

</aside>

• $REPO is one of:
  • lily
  • sentinel-tick
  • sentinel-locations
• delivered by FluxCD
  • WHEN tag that is opened in filecoin-project/$REPO and merged into master/main AND all $REPO CI tasks have passed (maybe: AND IF deployment requires no database migration); THEN build docker image using the SHA which results from the merge AND deploy into staging on mainnet and calibnet networks.
    • (maybe: WHEN deployment resolves, THEN the results are pushed to slack.)
    • (failure case) IF the deployment fails AND there was no migration in the release; THEN the previous release state should be restored.
      • (maybe: WHEN deployment resolves, THEN the results are pushed to slack.)

Workflow: Deploy new release to Production

<aside> ❗ Note: Initial deployment requires a long startup time (~45-60m) which must be accounted for on an instance with no prior state.

</aside>