Selectively disabling migrations

[cpmills1975]

I'm building a new instance of NetBox and, like everything I do, I'm trying to build it via an Ansible playbook in an idempotent way with no user involvement - my playbook even deploys the VM and configures the underlying OS prior to installing Postgres, NetBox and nginx.

I'm stuck between a rock and a hard place with installing my scripts. I keep all of these in a locally hosted git server and am currently cloning those, and a bespoke plugin, before running the upgrade.sh script. The bespoke plugin requires some python modules which I add to the local_requirements.txt hence why I am cloning them prior to running the upgrade. I can't just add the git repo as a data store because authentication is by SSH key, not username and password hence my desire to clone them and import them from the local file system.

When running the upgrade.sh script, one of the migrations loads my scripts and adds a reference to them in the DB. The problem is, my script looks for a specific tenant in the DB and by design fails if this is not found. At the time of running the migration, this tenant obviously isn't in the DB meaning the import fails and the migrate process falls flat on its face. In previous versions of NetBox, I could clone these scripts confident that they would just run when needed. The referencing of scripts in the DB has made this much much more complicated.

Is there a way to selectively run the migrations and skip this particular one? I get that I'll have to either build some process to import my scripts later and/or import them manually, but right now, I can't get NetBox up and running with my scripts pre-added to the system prior to installation.

[arthanson]

See https://docs.djangoproject.com/en/4.2/ref/django-admin/#migrate you can use the --fake to tell it to mark that the migration has already been run.

[cpmills1975]

Thanks. I'll have to give this a go. I was wondering whether the process could be made slicker - i.e the 'migration' of scripts from living solely in the file system to having a reference in the database could be removed from the Django migrations and moved instead to perhaps a management command with suitable documentation to help with the upgrade process. This would allow the migrations to run to completion even when the scripts contains errors.