Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't clone dkan for moduledev init if already there #5

Open
dafeder opened this issue Aug 22, 2022 · 2 comments
Open

Don't clone dkan for moduledev init if already there #5

dafeder opened this issue Aug 22, 2022 · 2 comments
Assignees

Comments

@dafeder
Copy link
Member

dafeder commented Aug 22, 2022

https://github.com/GetDKAN/dkan-ddev-addon/blob/e092657465b1752103d66bc91dbb49590718e58a/commands/host/dkan-init#L47

Check if /dkan already exists. If it does, don't run git clone.

Also, we should detect the version constraint from the git repo. See

https://github.com/GetDKAN/dkan-tools/blob/master/src/Command/InitCommands.php#L243

for how this was done in dkan-tools

@paul-m paul-m self-assigned this Aug 25, 2022
@paul-m
Copy link
Collaborator

paul-m commented Aug 26, 2022

Because of the way ddev delights in demolishing your project directory if you say ddev composer create (which we do), I can either figure out how and what to backup before we do this, or we can just warn the user and abort if there's anything in the directory that might get destroyed.

Let's postpone here and work on #9 instead, which addresses the issue of not demolishing anything during dkan-init.

After that we can swing back through this issue and ensure that we can specify a branch for moduledev.

@paul-m
Copy link
Collaborator

paul-m commented Sep 19, 2022

Un-postponing in support of WCMS-11097

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants