Open jackwrfuller opened 8 months ago
When working locally there's usually a need to use the user 1 role to overcome limitations when on the platform. An option to be able to:
in one step would save time and effort
Standardise the repository structure and promote ddev.
I use the lagoon
CLI perfectly adequately to set and delete environment variables, but the embedded SSH commands in there have never worked for me, so I use normal SSH. It would be nice to have a smoother experience there (I know this is probably a lagoon
CLI feature request, but: it would also be nice to have the SSH key be configurable in the config file - another PR I've been meaning to get to).
The other thing I do often with our GovCMS sites is copying files up and down between my computer and various environments, so a quick way to do that in one command would be really helpful too.
Related I hope - I'm the main maintainer of the ahoy
CLI tool now, so @jackwrfuller please feel free to contact me if you would like enhancements, have feature requests, or have found bugs that need to be fixed, or would like to collaborate further.
When working locally there's usually a need to use the user 1 role to overcome limitations when on the platform. An option to be able to:
- identify the user 1 account
- unblock the user 1 account
- set the password of the user 1 account
in one step would save time and effort
This is kind of covered by ahoy login
- I believe this change made it to all SaaS project as part of D10 updates.
login:
usage: Login to a website.
cmd: |
docker-compose exec -T cli drush -y cset tfa.settings reset_pass_skip_enabled true && \
docker-compose exec -T cli drush uinf --uid 1 --field name | xargs docker-compose exec -T cli drush uublk && \
docker-compose exec -T cli drush uli
source: https://github.com/govCMS/scaffold/blob/0bc379423be7defcdf2b80135c90580e0cd874c9/.ahoy.yml#L75
promote ddev.
Is DDev better for local dev than Lando? I have made initial draft a of full GovCMS docker in Lando yml files. I'm keen to see what DDEV looks like. Lando isn't great, especially since it won't dynamically add its magic to the entrypoint, you have to redefine it manually for each service.
My main pain points in Lando is lack of ability to replace/remove yml (you can merge though) and the variables in the .env
files are not injected in the Lando yml files like docker compose.
Is DDev better for local dev than Lando?
My preference is that govcms, for local dev, is less opinionated. The reason I mention DDEV is that it is becoming defacto for Drupal, and so this is an opportunity to govcms to correct a mistake. I too like Lando better but in my experience you could have a native DDEV solution out of the box without blocking Lando usage.
I use the
lagoon
CLI perfectly adequately to set and delete environment variables, but the embedded SSH commands in there have never worked for me, so I use normal SSH. It would be nice to have a smoother experience there (I know this is probably alagoon
CLI feature request, but: it would also be nice to have the SSH key be configurable in the config file - another PR I've been meaning to get to).
that is strange - I can use the lagoon cli ssh to connect to containers and I do see I have a link to my ssh key in my ~/.lagoon.yml - it uses your ssh credentials to fetch the token I thought
It would be really nice for a department to have a script or something that can be applied to a new site to configure it easily with the default modules and configuration used by the department rather than having to work through a checklist and selecting them all in the UI.
Keeping it up to date with new options provided by GovCMS SaaS would be a pain though.
The GovCMS team is constantly searching for ways to improve the platform, our service, and the developer experience. We know that this is only possible with the support of the amazing GovCMS community and would like to thank everyone for their support to date. We undertake many projects that seek to improve the services provided by GovCMS, and one of them is a GovCMS command-line interface (CLI) application.
The original purpose of developing this tool was to:
In keeping with our commitment to community, this tool will be open-source. We recognise the immense value of the GovCMS community and would like to involve you in helping to shape this project. We are therefore requesting the community to contribute their thoughts for what this tool should be and their ideas for what it should do. In particular, we are interested in responses to the following questions:
Contribute your ideas below!