Initial feedback

[ehmatthes]

Replying here to this issue from the main django-simple-deploy repo:

This is almost ready to go moving along for the configuration-only deployment, but feel free to start giving some feedback.

https://github.com/funkyrailroad/dsd-render

One thing to note is that the production settings are handled in a different file like in the CodeRed plugin, as opposed to in the same file like the Fly.io plugin. (I named it settings_render.py)

There's also some more work to do with the tests e.g. getting them to pass for the other package managers and adding tests for the render-specific files.

It's also just using the sqlite3 db locally in the instance, and that is deleted on each new deploy.

This looks great! I should have some time this week to run this and offer more specific feedback.

I just removed the requirement for having Poetry and Pipenv installed when running integration tests. If you pull recent changes for your django-simple-deploy repo, you should be able to run the local tests, and everything should pass except one:

(.venv) django-simple-deploy$ uv pip install -e ~/projects/dsd-render
Resolved 12 packages in 2ms
      Built dsd-render @ file:///Users/eric/projects/dsd-render
Prepared 1 package in 388ms
Installed 1 package in 1ms
 + dsd-render==0.1.0 (from file:///Users/eric/projects/dsd-render)
(.venv) django-simple-deploy$ pytest
========== test session starts ==========
platform darwin -- Python 3.12.11, pytest-8.4.1, pluggy-1.6.0
rootdir: /Users/eric/projects/django-simple-deploy
configfile: pytest.ini
collecting ... 

--- To run the full set of tests, Poetry should be installed. ---
  Instructions for installing Poetry can be found here:
  https://python-poetry.org/docs/#installation



--- To run the full set of tests, Pipenv should be installed. ---
  Instructions for installing Pipenv can be found here:
  https://pipenv.pypa.io/en/latest/install/#installing-pipenv

collected 55 items                                                                                                                                                                                       

tests/integration_tests/platform_agnostic_tests/test_console_output.py ss                                                                                                                          [  3%]
tests/integration_tests/platform_agnostic_tests/test_found_existing_file.py s                                                                                                                      [  5%]
tests/integration_tests/platform_agnostic_tests/test_git_status_checks.py .............                                                                                                            [ 29%]
tests/integration_tests/platform_agnostic_tests/test_project_inspection.py s                                                                                                                       [ 30%]
tests/integration_tests/platform_agnostic_tests/test_valid_cli_commands.py .                                                                                                                       [ 32%]
tests/unit_tests/test_deploy_messages.py ...                                                                                                                                                       [ 38%]
tests/unit_tests/test_git_status_utils.py ...........                                                                                                                                              [ 58%]
tests/unit_tests/test_utils.py .................                                                                                                                                                   [ 89%]
test_render_config.py .F....
...

[ehmatthes]

Notes - first run through

• For now, install directly from this repo: uv pip install git+https://github.com/funkyrailroad/dsd-render.git
• Will this work if someone already has active projects on Render?
• "Create a Blueprint in Render and give it a name" (and click Deploy)
• State an estimate for how long the deploy step might take? I started wondering if it was hanging. It took more than 3 minutes, less than 11 minutes.
• I think we can write ALLOWED_HOSTS = [".onrender.com"] for now, and skip the step of updating ALLOWED_HOSTS.
• "The project is configured to automatically redploy for each push to the remote." This was not true for me, but we can clarify that message.
• Add a quick note about how to destroy the project, for people just testing or experimenting.

[ehmatthes]

This is fantastic! This is the first time I've used a plugin that someone else wrote. I've stood on a couple stages and said that using django-simple-deploy should be a great way to learn how a new platform works. I can't describe how nice it was to just follow the Quick Start, see everything work, and then read through the git diff. It was so much nicer than trying to read through the platform's docs.

Do you want help with anything at this point, or do you have a clear direction on this for now? I'm happy to help in any way you like.

[ehmatthes]

Some commentary here as well: https://fosstodon.org/deck/@ehmatthes/115299439733151639

[funkyrailroad]

Nice, thanks for the feedback. I'll keep those points in mind as well. I have a pretty clear direction right now but I will be in touch. I was finding the CLI to be almost irrelevant, but the API is great so I'll be leaning on that much more going forward.

[funkyrailroad]

I just made some updates, most are summarized here #2

All the tests pass, including the python test_deployed_app_functionality.py from dsd_sample_blog_reqtxt.

However the whitenoise package isn't included in the requirements yet, so that's not being tested.

I've checked some of your boxes above, I'll respond to one other here:

Will this work if someone already has active projects on Render?

In general yes, but there will probably be an issue if somebody already has a project/service with the same name and in the same region. Also if they're already maxing out how many projects/services they can have in their account. There will also be an issue if the account already has a free postgres created, because they only let you have one free postgres. Right now it will grab the free postgres if it has the same name that it's expecting, but probably error in an unhandled way if there's a free database with some other name.

[ehmatthes]

All right, this all looks good so far. Do you want any help, or do you still have good clarity about how to keep moving this forward?

[funkyrailroad]

I'm open to suggestions, what would you most like to see?

I'm thinking I'll add the static file handling, incorporate some basic error handling, and then start working on the fully automated deployment. I'm not sure if I'll be able to fully automate it for free-tier accounts, because free-tier services cannot be created with the API. There's also a specific Render page for deploying a Django app, so I can give that a closer look and see what else I can incorporate.

[ehmatthes]

I'm open to suggestions, what would you most like to see?

One of the critical requirements to move towards a 1.0 release is getting an e2e test to run. That's pretty challenging if you need to click on a dashboard at all. So I think the best next move might be to sort out a fully automated workflow that doesn't prioritize the free tier.

Note that "fully automated" here doesn't necessarily mean supporting the --automate-all flag. You can have a configuration-only workflow that can be automated in the e2e test. For example, see the config-only instructions for dsd-railway, and the utility function that carries out those steps during an e2e tests of the config-only workflow.

There's a lot of other work that can be done, but you really want an e2e test before tackling most of the other pre-1.0 tasks.

If you want help with any of this, please say so!

[funkyrailroad]

Sounds good, I'll be able to make some headway on this again this week.

[funkyrailroad]

Here's something I noticed, because Render requires a git repository url for the service creation, I'll also have to create a remote repository for the test deployment. I could do this with the GitHub CLI tool, thoughts on that? Being able to delete the repository for cleaning up after the test might be a little scary in terms of granting permissions though.

To get around never granting deletion permissions, I could create the repo on the first test run, and then just continually set that created repo as the remote url of the test project and force push for any subsequent test runs.

[ehmatthes]

Sorry to take a bit to get back to you.

To get around never granting deletion permissions, I could create the repo on the first test run, and then just continually set that created repo as the remote url of the test project and force push for any subsequent test runs.

Yes, that's exactly what I was thinking. You can manually make that repo, and then build the test around it. I think you could --reset-hard the repo to its original state, and maybe you check that the state is correct at the start of the test. I imagine you need to destroy the remote Render resources after the test, because those will accrue charges.

How does that sound?

[funkyrailroad]

No problem!

Ok, so manually make the repo and not worry about anything with the GitHub CLI tool? Then that would just be some extra setup required to run the test suite for this particular plugin?

Yes I'd also make it destroy the resources after the test too.

[ehmatthes]

Ok, so manually make the repo and not worry about anything with the GitHub CLI tool? Then that would just be some extra setup required to run the test suite for this particular plugin?

That's how I'd approach it to start. There aren't going to be more than a handful of people running e2e tests for a while. I'd write a brief doc about test setup. People can fork/clone your public test repo, so they have full control of resetting it. You can put those instructions in a full RtD site, in the root README, the tests/README, or just in the docstring of the main e2e test file or conftest file.

All that really matters for starting out, especially in pre-1.0 work, is that you can run some e2e tests.