chore(deps): bump sentry-sdk from 1.16.0 to 1.17.0 in /appcontainer

[dependabot]

Bumps sentry-sdk from 1.16.0 to 1.17.0.

Release notes

Sourced from sentry-sdk's releases.

1.17.0

Various fixes & improvements

• New: Monitor Celery Beat tasks with Sentry Cron Monitoring.

  With this feature you can make sure that your Celery beat tasks run at the right time and see if they where successful or not.

  Warning Cron Monitoring is currently in beta. Beta features are still in-progress and may have bugs. We recognize the irony. If you have any questions or feedback, please email us at crons-feedback@sentry.io, reach out via Discord (#cronjobs), or open an issue.

  Usage:

  # File: tasks.py
  from celery import Celery, signals
  from celery.schedules import crontab
  import sentry_sdk
  from sentry_sdk.crons import monitor
  from sentry_sdk.integrations.celery import CeleryIntegration
  1. Setup your Celery beat configuration
  app = Celery('mytasks', broker='redis://localhost:6379/0')
  app.conf.beat_schedule = {
  'set-in-beat-schedule': {
  'task': 'tasks.tell_the_world',
  'schedule': crontab(hour='10', minute='15'),
  'args': ("in beat_schedule set", ),
  },
  }
  2. Initialize Sentry either in celeryd_init or beat_init signal.
  #@​signals.celeryd_init.connect
  @​signals.beat_init.connect
  def init_sentry(**kwargs):
  sentry_sdk.init(
  dsn='...',
  integrations=[CeleryIntegration()],
  environment="local.dev.grace",
  release="v1.0.7-a1",
  )
  3. Link your Celery task to a Sentry Cron Monitor

... (truncated)

Changelog

Sourced from sentry-sdk's changelog.

1.17.0

Various fixes & improvements

• New: Monitor Celery Beat tasks with Sentry Cron Monitoring.

  With this feature you can make sure that your Celery beat tasks run at the right time and see if they where successful or not.

  Warning Cron Monitoring is currently in beta. Beta features are still in-progress and may have bugs. We recognize the irony. If you have any questions or feedback, please email us at crons-feedback@sentry.io, reach out via Discord (#cronjobs), or open an issue.

  Usage:

  # File: tasks.py
  from celery import Celery, signals
  from celery.schedules import crontab
  import sentry_sdk
  from sentry_sdk.crons import monitor
  from sentry_sdk.integrations.celery import CeleryIntegration
  1. Setup your Celery beat configuration
  app = Celery('mytasks', broker='redis://localhost:6379/0')
  app.conf.beat_schedule = {
  'set-in-beat-schedule': {
  'task': 'tasks.tell_the_world',
  'schedule': crontab(hour='10', minute='15'),
  'args': ("in beat_schedule set", ),
  },
  }
  2. Initialize Sentry either in celeryd_init or beat_init signal.
  #@​signals.celeryd_init.connect
  @​signals.beat_init.connect
  def init_sentry(**kwargs):
  sentry_sdk.init(
  dsn='...',
  integrations=[CeleryIntegration()],
  environment="local.dev.grace",
  release="v1.0.7-a1",
  )

... (truncated)

Commits

• d65cc68 Updated changelog
• 79e3316 release: 1.17.0
• f7b0684 Add support for Sentry Crons to Celery Beat (#1935)
• 251e27d Add decorator for Sentry tracing (#1089)
• e952020 Added top level API to get current span (#1954)
• 3e67535 feat(profiling): Add profiler options to init (#1947)
• 2c8d277 Start a real http server instead of mocking libs (#1938)
• dad343e feat(profiling): Set active thread id for quart (#1830)
• a135fd6 🎨 Fix type annotation for ignore_errors in sentry_sdk.init() (#1928)
• f8aa25a Update get_json function call for werkzeug 2.1.0+ (#1939)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[thekaveman]

@angela-tran the terraform plan failed here, message is a 403 on trying to access the keyvault (specifically for the slack-benefits-notify-email secret): https://calenterprise.visualstudio.com/CDT.OET.CAL-ITP/_build/results?buildId=39935&view=logs&j=5af648c4-4294-55a7-6072-dd70820d3dba&t=42899ae2-6397-58a2-7641-cec3214b180b&l=35

Any idea what could be wrong here? #1318 ran at almost the same time as was fine?

[angela-tran]

@thekaveman Hmm, yeah I'm not sure what changed to cause this error to start showing. #1314 just started failing today on terraform plan as well. I manually re-ran the pipeline for #1318 too, and it failed (https://calenterprise.visualstudio.com/CDT.OET.CAL-ITP/_build/results?buildId=39962&view=results).

[angela-tran]

I've found a lead on why this started failing. Someone from CDT set up IP address restrictions on our dev and test Key Vaults. (You can see this by looking at the Activity Log for the Key Vaults, filtering on last week.)

This article supports my theory since it shows the same error message and matches the behavior where a different IP address is being used by the pipeline and is therefore blocked every time.

[angela-tran]

Here's an interesting StackOverflow discussion on a workaround... my guess though is that we don't want to have to do it this way.

https://stackoverflow.com/questions/57940062/azure-devops-build-pipeline-cant-get-secrets-from-key-vault-when-secured-with-v

[angela-tran]

Tested this upgrade locally - Sentry alert sent successfully and went through Login.gov flow and Courtesy Card flow