[00:51:20] Hullo. I am trying to deploy a Django app as a new tool using the new and recommended Buildpack container image way. During the "toolforge build start " run, after successfully installing dependencies, it tries to inspect the Django configuration by running "manage.py help collectstatic", but fails with: [00:51:21] KeyError: 'SECRET_KEY' [00:51:22] However, I did set the SECRET_KEY envvar using "toolforge envvars create", and it shows correctly when using this as the tool: [00:51:24] $ toolforge envvars show SECRET_KEY [00:51:25] name value [00:51:27] SECRET_KEY (redacted here) [00:51:28] Any thoughts on why the envvars isn't found in the container? [00:51:51] can you give us the tool name / GitLab repo? [00:52:09] my general feeling is that the environment variable isn’t being pulled into the Django config automatically but I don’t know much Django [00:52:30] sure, it's "gutendex", at https://gitlab.wikimedia.org/toolforge-repos/gutendex [00:53:47] I'm not a Python hacker either — I am setting up an instance of someone else's app. But it's a fairly vanilla Django setup, and its settings.py includes the line: [00:53:48] SECRET_KEY = env('SECRET_KEY') [00:55:11] hmm, but the `env` initialization from `environ.Env(…)` doesn’t mention `SECRET_KEY`? [00:55:21] I could imagine that it only imports the listed variables from the environment (trying to confirm) [00:57:31] huh. Let me try that locally. (Previously I ran the up locally fine, but not using environment variables, but a .env file...) [00:57:58] hm, no, it appears to import even unlisted env vars [00:58:39] and I’m suspicious that you’re calling `.read_env()` on `environ.Env` and not on the `env` instance you just created, but as far as I can tell in a REPL, that also works o_O [00:58:46] I feel like I should let someone who knows more about Django take over ^^ [00:59:00] yeah, I just checked, by only defining SECRET_KEY, and it moved on and complained about DATABASE_NAME... [00:59:48] meh. Maybe I should just re-implement this little API in Ruby :) [01:00:18] ok, sounds like that’s the right fix then? and you “just” need to also define DATABASE_NAME and everything else? (unless I’m misunderstanding something) (re @abartov: yeah, I just checked, by only defining SECRET_KEY, and it moved on and complained about DATABASE_NAME...) [01:01:20] well yeah, but I thought the (only?) way to define environment variables in these automated container images (that get recreated from repos on code update) was through "toolforge envvars"? [01:01:45] (ok according to https://django-environ.readthedocs.io/en/latest/api.html#environ.Env.read_env `read_env()` is a class method and therefore calling it the way you’re doing is in fact correct, my bad. but also, that method is responsible for reading .env _files_; environment variables are apparently used by default anyway) [01:02:07] If I can make the "toolforge build start" process run a little shell script of mine first, I'm all set. Can I? [01:02:31] not as far as I know, but I don’t understand what the problem is now [01:03:03] that’s correct, though the environment variables aren’t really tied to the container image itself, but rather to the tool environment where the image is run as a web service (re @abartov: well yeah, but I thought the (only?) way to define environment variables in these automated container images (that get recreated...) [01:03:18] the problem is there is no .env file (because we don't want to put the secrets in the repo), and despite setting everything using the envvars mechanism, the Django process does not see SECRET_KEY etc. [01:03:48] right, and envvars work fine for me on another (Ruby-based) tool. (re @lucaswerkmeister: that’s correct, though the environment variables aren’t really tied to the container image itself, but rather to the tool enviro...) [01:04:30] I thought your earlier message meant that SECRET_KEY worked now, but it sounds like I misunderstood, sorry (re @abartov: the problem is there is no .env file (because we don't want to put the secrets in the repo), and despite setting everything usin...) [01:04:50] no, just before it I said I was testing *locallly* [01:05:08] because I had previously tested the app on my dev machine using .env file and not actual env vars. [01:05:34] oh wait, I missed a crucial part of your initial message [01:05:38] the error happens *at build time* [01:05:42] yes! [01:05:48] I’m pretty sure it’s expected that toolforge envvars aren’t available then [01:05:54] huh. [01:05:56] only at run time [01:06:22] well, it wasn't my idea to run that manage.py as part of the build. It seems to have been deduced somehow. [01:06:25] to me it sounds odd that the app would require the full production config to build itself / determine its dependencies, but again, I’m not a Django person, maybe this is normal :) [01:08:19] this is the precise section of log: [01:08:19] [...] [01:08:21] Successfully installed Django-4.2.26 asgiref-3.11.0 defusedxml-0.7.1 django-cors-headers-4.3.1 django-environ-0.11.2 djangorestframework-3.15.2 inflection-0.5.1 mysqlclient-2.2.7 psycopg2-binary-2.9.10 six-1.16.0 sqlparse-0.5.4 [01:08:22] [step-build] 2025-11-29T00:40:16.269848568Z [01:08:24] [step-build] 2025-11-29T00:40:16.269938017Z [Generating Django static files] [01:08:25] [step-build] 2025-11-29T00:40:16.402752657Z [01:08:27] [step-build] 2025-11-29T00:40:16.402812647Z [Error: Unable to inspect Django configuration] [01:08:28] [step-build] 2025-11-29T00:40:16.402828289Z The 'python manage.py help collectstatic' Django management command [01:08:30] [step-build] 2025-11-29T00:40:16.402838989Z (used to check whether Django's static files feature is enabled) [01:08:31] [step-build] 2025-11-29T00:40:16.402849848Z failed (exit status: 1). [01:08:53] sounds like the build process is trying to be very clever :/ [01:09:00] I don't know where it comes from. The repo has no mention of 'collectstatic', so I'm guessing it's a standard Django thing. [01:09:08] yeah [01:09:47] my feeling is you could solve this by defining default values for all envvars, including SECRET_KEY, in settings.py [01:10:00] okay, what if I add a dummy .env file just to get the build to pass, and— [01:10:10] heh, great minds... [01:10:27] and then either accept the risk that the app will run with an unsafe secret key if the envvar happens to be unset at runtime, or try to somehow determine in settings.py if you’re in the build or in the real runtime and throw a “no secret key defined!” error in the latter case [01:10:34] yeah, a .env file sounds like it would do the same thing ^^ [01:11:13] or add more os.environ.setdefault() lines like https://gitlab.wikimedia.org/toolforge-repos/gutendex/-/blob/695a07d001/manage.py#L6, for that matter [01:11:33] yeah, good idea. And there's no risk here — it's just a read-only RESTful API wrapper over a large catalog file that's public anyway. No auth or user data at all. [01:11:41] ok, sounds good [01:11:54] thank you for thinking through this with me! [01:12:18] I’m signing off for tonight, excited to find out tomorrow from real Django devs what nonsense I said ;) [01:12:19] good luck! [03:55:42] Hi. I'm deploying a tool to Toolforge using the new GitLab CI system, and I got the following error: [03:55:42] gotten_deployment='{"messages":{"info":[],"warning":["You are using a beta feature of Toolforge."],"error":["Unable to find namespace tool-jjpmaster-bot-enwb-t2 or config jjpmaster-bot-enwb-t2-config for jjpmaster-bot-enwb-t2"]}}' [03:55:42] The name of the tool is "jjpmaster-bot-enwb-t2". Does anyone know what this could be? [04:42:14] !help [04:42:14] If you don't get a response in 15-30 minutes, please email the cloud@ mailing list -- https://wikitech.wikimedia.org/wiki/Help:Cloud_Services_communication