ref(dashboards) Remove constraints on dashboard widget (#22420)

Remove the name constraints on dashboard widgets and widget queries.
These contraints are hard to pre-validate, and don't seem like they will
help people make better dashboards, as the unique name rules are
somewhat arbitrary.

Update migration checking workflow.

1. Checkout master
2. Run migrations
3. Checkout branch
4. Generate SQL for migrations

This flow should result in the new migrations having not run so we can
more reliably generate SQL for them. Longer term we will fix the migration action.

.github/workflows/migrations.yml

@@ -11,7 +11,10 @@ jobs:
     timeout-minutes: 8
 
     steps:
+      # Checkout master to run all merged migrations.
       - uses: actions/checkout@v1
+        with:
+          ref: master
 
       # Until GH composite actions can use `uses`, we need to setup python here
       - uses: actions/setup-python@v2
@@ -40,6 +43,11 @@ jobs:
         run: |
           sentry upgrade --noinput
 
+      # Checkout the current ref
+      - uses: actions/checkout@v1
+        with:
+          clean: false
+
       - name: Get changed migration files
         id: file
         run: |

migrations_lockfile.txt

@@ -10,7 +10,7 @@ auth: 0008_alter_user_username_max_length
 contenttypes: 0002_remove_content_type_name
 jira_ac: 0001_initial
 nodestore: 0001_initial
-sentry: 0140_subscription_checker
+sentry: 0141_remove_widget_constraints
 sessions: 0001_initial
 sites: 0002_alter_domain_unique
 social_auth: 0001_initial

src/sentry/migrations/0141_remove_widget_constraints.py

@@ -0,0 +1,40 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.29 on 2020-12-03 14:58
+from __future__ import unicode_literals
+
+from django.db import migrations
+
+
+class Migration(migrations.Migration):
+    # This flag is used to mark that a migration shouldn't be automatically run in
+    # production. We set this to True for operations that we think are risky and want
+    # someone from ops to run manually and monitor.
+    # General advice is that if in doubt, mark your migration as `is_dangerous`.
+    # Some things you should always mark as dangerous:
+    # - Large data migrations. Typically we want these to be run manually by ops so that
+    #   they can be monitored. Since data migrations will now hold a transaction open
+    #   this is even more important.
+    # - Adding columns to highly active tables, even ones that are NULL.
+    is_dangerous = False
+
+    # This flag is used to decide whether to run this migration in a transaction or not.
+    # By default we prefer to run in a transaction, but for migrations where you want
+    # to `CREATE INDEX CONCURRENTLY` this needs to be set to False. Typically you'll
+    # want to create an index concurrently when adding one to an existing table.
+    atomic = True
+
+
+    dependencies = [
+        ('sentry', '0140_subscription_checker'),
+    ]
+
+    operations = [
+        migrations.AlterUniqueTogether(
+            name='dashboardwidget',
+            unique_together=set([('dashboard', 'order')]),
+        ),
+        migrations.AlterUniqueTogether(
+            name='dashboardwidgetquery',
+            unique_together=set([('widget', 'order')]),
+        ),
+    ]

src/sentry/models/dashboard_widget.py

@@ -70,7 +70,7 @@ class DashboardWidgetQuery(Model):
     class Meta:
         app_label = "sentry"
         db_table = "sentry_dashboardwidgetquery"
-        unique_together = (("widget", "name"), ("widget", "order"))
+        unique_together = (("widget", "order"),)
 
     __repr__ = sane_repr("widget", "type", "name")
 
@@ -92,6 +92,6 @@ class DashboardWidget(Model):
     class Meta:
         app_label = "sentry"
         db_table = "sentry_dashboardwidget"
-        unique_together = (("dashboard", "order"), ("dashboard", "title"))
+        unique_together = (("dashboard", "order"),)
 
     __repr__ = sane_repr("dashboard", "title")