DEVOPS
Dropbox Latest-Release Restore Verifier
After each GitHub release is published, downloads the matching build artifact from Dropbox, checks its integrity, and confirms the release is restorable.
How it runs
The automated pipeline, trigger to output.
- TriggerGitHub release publishedGitHub
- ActionDownload matching artifact from DropboxDropbox
- LogicVerify checksum, size, and file integrity
- ActionPage on-call if verification failsPagerDuty
- OutputPost restore-verification result to SlackSlack
What it does
Proves that the artifact backing your newest release can actually be restored. When a GitHub release is published, it locates the corresponding artifact in Dropbox, downloads it, validates the checksum against the release notes, and verifies the file is non-empty and well-formed. A clean check is recorded; a failed check raises an alert immediately.
When to use it
Use it when Dropbox is your build-artifact store and you need a continuous guarantee that the latest release is recoverable. It turns 'we think the build is there' into a verified, logged fact at release time rather than during an incident.
How it works
- 1A GitHub release-published event triggers the run.
- 2Resolve the expected artifact path in Dropbox from the release tag.
- 3Download the artifact from Dropbox.
- 4Branch: compare the computed checksum and size against the values in the release; verify the file opens.
- 5If verification fails, page on-call via PagerDuty with the tag and reason.
- 6Post a pass/fail restore-verification note to Slack with the checksum and artifact path.
Set it up
What you configure once, before turning it on.
- 1Connect GitHubRepos, issues, pull requests, actions.
- 2Connect DropboxFiles and folders.
- 3Connect PagerDutyIncidents, on-call, escalations.
- 4Connect SlackChannels, DMs, threads, mentions.
- 5Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 6Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 7Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More DevOps workflows
Hugging Face Spaces idle-runtime sweep with auto-pause
On a schedule, scans all Hugging Face Spaces for ones running idle past a threshold, pauses them to stop billing, and posts a Slack summary with the estimated monthly savings.
Slack-approved pause for idle Hugging Face Spaces
On a daily scan it finds idle paid Spaces and posts an interactive Slack approval; on approve it pauses the Space and logs the decision to a GitHub issue audit trail.
Generate a weekly de-flake report and assign Linear cleanup tickets
On a weekly schedule, aggregates the current quarantine manifest and recent flake history, builds a prioritized report.
Block costly Hugging Face Space hardware upgrades in PR review
When a pull request changes a Space's hardware config, it estimates the new monthly cost and posts a GitHub PR comment that flags upgrades crossing a budget ceiling.
Auto-release tests from quarantine once they prove stable
Triggered by a webhook from a nightly stability runner, checks whether quarantined tests have passed enough consecutive runs, removes the stable ones from quarantine in GitHub.
Quarantine a test on demand from a PR comment command
Triggered when an engineer comments a quarantine command on a pull request, validates the test name, commits the quarantine change to that PR branch, opens a tracking issue.
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.