Closed matt-graham closed 3 weeks ago
I'm 👍 , but reluctant to approve before we have some regression tests (https://github.com/UCL-ARC/python-tooling/issues/329) since there's a lot of changes here that could be susceptible to human error (e.g., missing or adding "/" characters from URLs)
I'm 👍 , but reluctant to approve before we have some regression tests (https://github.com/UCL-ARC/python-tooling/issues/329) since there's a lot of changes here that could be susceptible to human error (e.g., missing or adding "/" characters from URLs)
Isn't it enough the tests we currently have, all pass? We do do a cookiecut operation in CI, right? Which is working...
Tests were previously failing since #432 was merged in as the passed configs now need to use github_owner
rather than github_username
- now fixed and have also updated tutorial to make more consistent with new github_owner
variable name.
Let's make v1.0.0
of the template when this is in.
Though its not exposed to user now we have longer prompts rather than using variable names directly, I think
github_username
is a bit of a misnomer given that it can be either a user or organization name, hence I thinkgithub_owner
would be a better choice.We also currently manually construct the GitHub repository URL in lots of different bits of the template and also the qualified repository name in a few places. We can use double underscore prefixed (rendered) private variables in the cookiecutter config to generate the repository URL and qualified name once and then reuse elsewhere to avoid the repetition. This would also make it simpler to later switch to supporting alternative repository hosting options such as GitLab in future (which is the rational for naming the variables
__repo_name
and__repo_url
rather than__github_repo_name
and__github_repo_url
).