Closed ehmatthes closed 9 months ago
fly open
on the quick start, to avoid the warning about deprecating fly open
.ALLOWED_HOSTS
entry._get_deployed_project_name()
as an example._get_deployed_project_name()
deploy()
, validate_platform()
, prep_automate_all()
, deploy helpers, validate helpers, any other methods._select_project_name()
.
sd_utils
for import statement._create_flyio_app()
using --json
--json
in call to fly apps create
._get_region()
to create app in appropriate region? (No need, apps don't have regions.)
_get_region()
currently being used? My guess is it's being used to create db? (Correct)self.app_name
is already set, use the region associated with that app when creating db?_create_db()
_check_db_exists()
.--json
in _check_db_attached()
. (Not possible. Clean up string parsing instead.)_attach_db()
._confirm_create_db()
._attach_db()
.self.app_name
and self.deployed_project_name
are used interchangeably?validate_platform()
Current logic around creating an app with --automate-all
was inconsistent. _get_deployed_project_name()
was not running for automated runs. _get_deployed_project_name()
can do the work of creating an app during automated runs.
_create_flyio_app()
from validate_platform()
to _get_deployed_project_name()
._add_dockerfile()
sd.git_path
and sd.project_root
? (Maybe, ie if it's a nested project.)path.exists()
, instead of os.listdir
.Closed by #282.
The work to stabilize Fly deployments introduced more complex behavior in some methods, and introduced new methods. I can make a release without refactoring, because that work had external changes. This should be only internal changes, so I can do this work as a separate set of tasks.
_get_deployed_project_name()
._create_flyio_app()
using--json
._create_db()
._check_db_attached()
.--json
.--pre-existing-app
. Callplatform_utils.create_project()
twice; add both of these to cache; destroy both of these at end of test run. See comment in #263.