ddev / ddev-ui Goto Github PK

What happened (or feature request):

ddev-ui needs a good solid set of tests that will include at least

• unit tests
• integration tests
• functional tests with actual click scenarios

We all know that getting good testing is a process, not an event, but this issue can serve for first batch. After this goes in and make test does something, then nearly every code change thereafter will be expected to have associated tests in the PR.

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

What happened (or feature request):

ddev-ui should use a trusted ddev version when it executes ddev. I think this would mean detecting the ddev in the path at initial config and asking the user for permission to use this, then storing it as config.

That brings up the issue that we need configuration of some type for ddev-ui, so this may drive that need.

It's possible that in the future we'll want to bundle ddev with ddev-ui. There are lots of tradeoffs in that.

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

What happened (or feature request):

Not critical, but I see these come through when running make clean && make darwin

• npm WARN [email protected] No repository field.
• npm WARN [email protected] No license field.

What happened (or feature request):

Command whitelisting is not correctly implemented, the sudo-prompt library is still accessible to the entire ddev-shell module, and the current sudo command whitelisting currently checks for whitelisted commands, but does not check all arguments for banned characters.

Furthermore, the current approach is to sudo ddev version to confirm user has sudo access prior to allowing them to enter the add site from CMS/add site from existing files flow. The intention here is that we don't want to allow the user to enter information for a site, unpack and create files on their system, only to kick them out during the hostname phase if they don't have sudo access, either leaving them with orphan files on their system or having to do a file deletion on the user's machine. This, however, is causing an additional sudo prompt during the flow when the actual hostname command is run on *nix systems that have tty_tickets disabled, or on windows systems. In short, do we want to risk annoying the user with potentially two sudo prompts, or to annoy them by potentially letting them unpack files onto their system and kick them out of the flow if they don't have sudo.

What you expected to happen:

• The sudo-prompt library needs to be abstracted into a higher level module that implements filtering, and that module to expose only the filtered method to the modules that depend on sudo. This eliminates the chances of accidentally calling the wrong sudo-module from within modules that require sudo.

• The aforementioned abstraction needs to not only check that the command being run is included in the whitelist, but also filter every argument for banned characters.

• A decision needs to be made on when it's appropriate to prompt the user for sudo.

How to reproduce this:

• notice that in ddev-shell.js there is a function named "sudo" that handles the whitelisting and the filtering. However, the full 'sudo-prompt' library has been loaded at this point, and it's public methods freely available to be accidentally called by any function in this module.

• no way to do this through the UI, but should -j ; rm -rf / be passed as an argument to 'hostname', the command would be accepted, and the bad -j argument would not be sanitized.

Remaining actions:

• Review release (product owner)
• Approve release (product owner and release manager)
• Create binaries (any DRUD maintainer)
• Draft release notes (release manager)
• Draft additional announcements for blog, newsletter, etc (not applicable at the moment)
• Create release (release manager)
• Update any package managers to point to new release (release manager)

For additional background information, please see our Product Release instructions here.

What happened (or feature request):

We should really bundle ddev with ddev-ui in the package build, rather than having it be a prereq. That lets us force the version of ddev, which is nice.

When we do it, we should make sure that

• It's versioned properly (that ddev-ui is specifying a working version of ddev
• That the installed ddev is then available via the command-line (is in path) - we don't want people ending up with 2 different ddevs on their machine if we can help it.

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

What happened (or feature request):

Design requirement

What you expected to happen:

• We have a referenceable document that contains all details regarding color, font, spacing, etc.
  • Example: Blue_Door_BrandGuide.pdf
• This document is converted into CSS specific to all base HTML elements (e.g. H1-H6, paragraph, div, etc) and key layout IDs.
• Ideally this is provided in the form of re-usable SASS partials that are organized in a SMACSS hierarchy.

Restrictions:

• Fonts must be websafe and not require special licensing for web/CLI.

What happened (or feature request):

To send out trusted install packages for Windows we'll need a code signing certificate which must be purchased. Link to that page on https://www.electron.build/code-signing#where-to-buy-code-signing-certificate

There seem to be a variety of prices from the various vendors.

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

What happened (or feature request):

Updated A/C - 11/27/18

• DONE: Cypress NPM Install with scripts setup and tied to make.
• DONE: Cypress Sample Test Local
• INPROGRESS: Cypress Sample Test CI
• NEW: Implement First Set of Tests

Given the amount of user interaction on the UI, we probably need a more robust approach for integration testing with sample data.

This epic includes:

• Direct integration testing between ddev-ui and ddev, with real projects. So for example, a test to create a site would actually create a site and verify that it came up correctly.
• Testing of any ddev-ui actions that change anything on the filesystem. So for example, if we take any action (like untarring an archive), test to make sure that happened on the filesystem.
• Actual UI testing.

Remaining actions:

• Review release (product owner)
• Approve release (product owner and release manager)
• Create binaries (any DRUD maintainer)
• Draft release notes (release manager)
• Draft additional announcements for blog, newsletter, etc (not applicable at the moment)
• Create release (release manager)
• Update any package managers to point to new release (release manager)

For additional background information, please see our Product Release instructions here.

What happened (or feature request):

Feature Request

What you expected to happen:

Users can remove the ddev configuration from a repository. This also removes the app containers.

Ultimately, we need to select our implementation strategy for a native app. This needs to consider OS compatibility, flexibility, long term support from the community, license compatibility, development speed gains, etc.

Currently we have drupal and wordpress tarballs checked into source here. The purpose seems to have been for offline use of ddev-ui. We can figure out how to add these during the build (and keep up-to-date that way) or at least find something better than static checked-in tarballs.

Easiest thing is probably to have circleci grab them and package them.

What happened (or feature request):

• Feature request

What you expected to happen:

We need to define the primary navigation elements as well as specify its location and behavior.

in a discussion with @rfay , it was determined that we need to have a conversation about how exec and ssh are handled in the UI. IMO, logically it makes sense to have then in the same UI element as they are virtually identical. However, the very good argument was made that the UI should also match the semantics and commands of the CLI.

What does everyone think?

Heavy related to ddev/ddev#430. Leaving this as a placeholder to remind ourselves that this is a part of v0.0 deliverable.

What happened (or feature request):

STUB. Related to #33 and #34

What happened (or feature request):

What you expected to happen:

ddev-shell wrapper currently does not use promises nor the -j flag in all calls. To ensure consistency of the wrapper and through the entire application, we should be returning a promise and JSON output for all calls.

How to reproduce this:

note that list, describe and hostname in ddev-shell return promises and use the -j flag, but the older start/stop/restart calls do not.

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

N/A

Anything else do we need to know:

N/A

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

1

What happened (or feature request):

ddevShell method of the ddev-shell library currently accepts both sitename and sitepath as arguments. This initially grew out of originally using sitename as a parameter for early calls (ddev start, stop, restart all accept a sitename) but after beginning to implement ddev config, navigating into the working directory first before executing ddev command was added as needed.

What you expected to happen:

As every call that uses sitename also has access to sitepath, sitename will be removed for consistency. Going forward all ddev commands will first change directories to the working directory and execute the ddev command without a sitename argument.

How to reproduce this:

Take a look at https://github.com/drud/ddev-ui/blob/afbf1af82b71d50f7dfef8f8cf9c67c3871914b8/js/ddev-shell.js#L7-L54 ,
both sitename and navigating to path before executing are supported

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

DDEV-UI all versions

Anything else do we need to know:

N/A

Related source links or issues:

N/A

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

1

What happened (or feature request):

We need to have a broader understanding of ddev-ui's code and structure and technologies.

The goal would be to have basic architecture docs that could live on, either in the repo (best case, maybe in a devdocs directory?), or in a linked gdoc or some such.

And we need to try to get more people understanding this, so will meet Nov 1 to start that process.

What happened (or feature request):

Feature Request

What you expected to happen:

• On an app overview page, users can see the current site status (e.g. stopped or running).
• On an app overview page, if the status is "stopped", a user can click a button to trigger a start.
• On an app overview page, if the status is "running", a user can click a button to trigger a stop.
• On an app overview page, if the status is "running", a user can click a button to trigger a restart.
• A success or failure message is displayed to the user at the end of each action.
• The status updates based on the result of each action.

What happened (or feature request):

Feature Request

What you expected to happen:

• On any screen, there is a home button that, when clicked, brings them back to apps dashboard.
• All apps that the ddev CLI is aware of (from running ddev list) is available.
• For each app, the sitename and an image representing the app type is displayed.
• Clicking the site name or the image brings them to the app screen.
• There is a button to open up the site directly from the apps dashboard.

Blockers

• @rickmanelius to provide links to images to use for default state.

What happened (or feature request):

The current verbiage of errors, dialogs, and prompts in DDEV-UI have been made up on the fly and may not be the most user friendly. Also, minor things such as rules regarding capitalization (i.e. "A Prompt Was Shown." vs "A prompt was shown" need to be decided and applied throughout the application.

What happened (or feature request):

I downloaded and compiled the latest version at cf1fd34f. When I finish running make clean && make darwin, I go to the following directories.

1. ddev-ui/dist/mac/ddev-ui.app
2. ddev-ui/dist/ddev-ui-0.2.0-dev.dmg
3. ddev-ui/dist/ddev-ui-0.2.0-dev-mac.zip

When I then click on the app icon and look at the finder window to see the version, I see 2 different results. The first shows "0.2.0-5-gdce7c1e" while the latter two show "0.2.0-dev". For testing purposes, I want to ensure accurate reporting. It should be noted that the version number for item 1 refers to an older commit dce7c1e.

When I visit https://github.com/drud/ddev-ui/blob/master/package.json, I can see the "v0.2.0-dev" version highlighted, which is fine but I still don't know what commit this ties to from a debugging perspective. Also, why the difference between the two locations? It should be noted that the file sizes are exact.

So two questions:

1. How can I target the most recent commit (or is it the most recent commit)?
2. Is there supposed to be a difference between the two locations? That is, is the disk image supposed to be for main releases while the one in the /dist folder the latest commit (or a commit specified in the codebase)?

What happened (or feature request):

package-lock.json is generated by the build, which gives a stern warning telling us to check it in, and it would seem reasonable. However, if we check it in, it gets overwritten, causing our build versions to have -dirty on them because the source code has been altered.

We need to find out how this is supposed to work and make it work that way. If this is a lock, we need to get it to lock :)

During the prototype phase, @andrew-c-tran is relying on a thin node server that is running command line exec calls and waiting for/parsing the output before returning the data back. In the future, we would prefer a more persistent connection (potentially through a websocket approach) so that we are using a more robust solution with real time status updates.

What happened (or feature request):

• Adherence to our development policy of test driven development.

What you expected to happen:

Given our selection of React.js and Electron, we need to ensure that we have the following mechanisms in place:

• Makefile to create binaries OS specific binaries on the localhost OS.
• Makefile option flag to run tests locally on the localhost OS.
• Unit tests for features at the React.js layer.
• Behavior tests for features at the Electron layer.
• CircleCI integration to create build artifacts and run test suite for each PR.

For the purposes of this ticket, we do not need complete test coverage. Rather, the goal is to ensure we have example tests at both the unit and integration layer.

Anything else do we need to know:

It might be worth reviewing the above with the SRE team regarding how they approached this with the ddev CLI.

This is premature until we select a technology (see #1), but ideally, we pick a technology, approach, and testing system right at the onset of v0.1 when the prototype is behind us and we're starting to build against the product roadmap.

What happened (or feature request):

• Feature request

What you expected to happen:

End-users can access information from ddev describe.

What happened (or feature request):

We have a considerable amount of WIP in the form of ddev-ui PRs and branches that is making it difficult to review issues atomically because different changes are spanning multiple areas. It would be of value to do some clean-up as soon as #21 is completed and use this as a meta issue to prioritize and drive them to a completion point.

What happened (or feature request):

Current local development requires the electron app to be closed, rebuilt, and relaunched to see any updated code changes. In addition, this local development process has no code quality standards or guidelines.

What you expected to happen:

Hot Reloading to facilitate easier and faster local development, coupled with automated linting should make development faster while ensuring code standards are upheld.

Hi @andrew-c-tran. I've been asked to get a better sense of the timeline (with a granularity on the order of +/- one week). What this would entail is taking the DDEV UI roadmap that was generated here and starting to pull out a more robust set of acceptance criteria and get the high/low LOE in this feature document.

Acceptance criteria:

• Review and confirmation that this feature list is still comprehensive.
• Acceptance criteria (2-5+ bullets per feature)
• Assignment (when the functionality doesn't fall solely on Andrew).
• High/low LOE (on the order of days).
• Summation of LOE range and average.

What happened (or feature request):

Feature Request

What you expected to happen:

Acceptance Criteria:

• ddev GUI has a v0.0 release available here
• ddev GUI binaries for release v0.0 are available for every OS that the ddev CLI supports.
• Each application successfully launches on the local OS.
• ddev logo is displayed at the top along with a clickable link to the ddev GitHub project page at the bottom.

What happened (or feature request):

• Feature request

What you expected to happen:

• We need a place to surface general errors that might affect specific sites.
• We probably don't need to have this information ever present, but only surface this (and other error messages) when it's pertinent.

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

What happened (or feature request):

Feature request

What you expected to happen:

• On the dashboard showing all apps, there is an "add app" button.
• When a user clicks this button, the user is directed to an "add application" screen.
• On the "add application" screen, the user is presented an option to "add from distribution".
• When clicking the "add from distribution" button, the user is brought to a new screen.
• The "add from distribution screen" displays a logo and name for Drupal 7, Drupal 8, and WordPress.
• When a user clicks one of these 3 buttons, they are prompted with a text field to name the project.
• Based on the selection, a git clone w/squashed history is performed with the repo pulled and stored in ~/User/git/SITENAME
• Based on the selection, ddev config uses known docroot and app type values.
• ddev start is triggered.
• Once ddev start completes, the user is prompted with a link to the site.

What happened (or feature request):

Over in ddev/ddev#476 we're going to make ddev config (the base command) work with flags and skip the interactive path.

However, ddev-ui will still have to support ddev config pantheon which is also an interactive command, but the pantheon version will have to retrieve a list of sites from pantheon.

Currently, ddev config pantheon has its own interactive process which

• Checks to make sure the directory name matches a project on pantheon
• Has the user choose an environment (dev/prod/etc)

We'll need to support that behavior, and mods to ddev will be required to allow it.

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

What happened (or feature request):

This repo is currently at 340MB even though though there's just a few text files in it.

This is a result of the dist directory having been accidentally checked in at some point:

/tmp/bigstuff.sh
All sizes are in kB's. The pack column is the size of the object, compressed, inside the pack file.
size   pack   SHA                                       location
81430  32930  9baa226d807acf22ae24c01f1c0a638c15362440  dist/linux-unpacked/ddev-ui
78835  32152  6764e5fa6cf310a8589d4b433bf7ea8eec58ce3f  dist/win-unpacked/DDEV-UI.exe
70165  29002  314df91bf92784d17817b5213d4528649948f282  dist/mac/DDEV-UI.app/Contents/Frameworks/Electron  Framework.framework/Versions/A/Electron                 Framework
51776  51170  16a2c7ea6f5e8f1399307fd4a80c7e55be65eefc  dist/DDEV-UI-0.1.0-x86_64.AppImage
47360  47217  eff6efa4caca536aa58646d0e0330c283ba27867  dist/DDEV-UI-0.1.0.dmg
45267  45089  2a079772f063c7deb5c2c27f082cc1211655386e  dist/DDEV-UI-0.1.0-mac.zip
33793  33699  fc217b9a8137e062a52d226aa6af5887359150a8  dist/DDEV-UI                                       Setup                                                   0.1.0.exe
20644  7426   6a5259c3ed8395736daded17b81feb9650aa6a51  dist/linux-unpacked/libnode.so
18213  6962   53bae9cdee3d7cccf71702972065b8f834aa08ac  dist/win-unpacked/node.dll
17991  6738   3cf2e64a4cdb7667b960d95c3e13d6d14619f498  dist/mac/DDEV-UI.app/Contents/Frameworks/Electron  Framework.framework/Versions/A/Libraries/libnode.dylib

It's definitely worth cleaning these commits out of there. A monster repo haunts us in performance forever, including in circleci.

I used the script in https://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/ to track the bit hashes.

There are some good cleaning resources at https://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository

It's worth considering just reducing this repo back to a few commits and force-pushing it as well. But a cleanup should be do-able.

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

What happened (or feature request):

Feature request

What you expected to happen:

In addition to removing the configuration, users can remove files and/or the database.

Related source links or issues:

• Delete configuration #17

What happened (or feature request):

Currently the code has inline tests for CMS type, and we are going to be expanding our CMS types very soon. We don't want inline code because it means we have to edit multiple places to add a new CMS.

We may want to have ddev emit a list of supported CMSs? Maybe in ddev version, and ddev-ui could get the list from that? But there will still be custom code to download specific tarballs...

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

Feature Request

With the introduction of JSON endpoints in the CLI, we need a version checking mechanism to error out when a < 0.9.4 version is detected as ddev list and ddev describe is critical for any sort of UI functionality. We've agreed that string parsing is fragile, and as such should not be supported.

What you expected to happen:

Discussion is needed on how to error out. This is a show stopper, text parsing of ddev-list and ddev-describe is to be completely removed. If an incompatible version is detected, how do we want to error out and show the customer? Do we simply show a warning and exit? Do we launch a browser window to ddev download site? etc.

Related source links or issues:

Initial version check discussion brought up in #18

What happened (or feature request):

Now that the verbiage has been standardized as per ddev/ddev#526, some time needs to be taken to update all the verbiage in the UI to be consistent, and replace all use of site/app with project.

To ensure consistency between our API needs #2 and our features #7, we need to sanity check by ensuring we have a way to map each feature to a screen.

Attempting to get this issue summary to an actionable/reviewable state while linking to private conversations to help paint the trail.

• Here's a Slack thread where instructions on how to test were provided https://drud.slack.com/archives/C45DF87JT/p1504297914000271.
• The overall intention was to replicate ddev CLI commands as noted here (#9 (comment)).
• @rfay @tannerjfco and @beeradb provided initial feedback here https://drud.slack.com/archives/C45DF87JT/p1504298498000201.

So to make this actionable:

• Test the ddev-ui Readme.md Installation instructions.
• Add 2 working test sites via the CLI to prepare for tests.
• Systematically work through and briefly test each ddev CLI command.
• Document any bugs/issues/ideas that come about during testing.
• As long as each function is at least present and usable, consider the prototype "complete".

What happened (or feature request):

• Feature request

What you expected to happen:

• The ability to run ddev exec commands directly through the GUI.

While this is currently slated for v0.7 on the roadmap, it might affect the UI and we should at least have a plan for where this will live and how this might function.

What happened (or feature request):

• Feature Dependency

What you expected to happen:

In order to create an initial draft of a ddev UI roadmap (#6), we need to get a basic feature inventory of what we anticipate in a 1.0 version. Then we can group these by category, refine the acceptance criteria from the perspective of end-user value, etc.

Proposed acceptance criteria:

• Google spreadsheet provisioned, sharedw/ team, and stored in ddev-UI drive folder.
• Fields: category, label, short description, acceptance criteria, LOE, milestone.
• Review with team to determine any obvious gaps or potential enhancements.

Related source links or issues:

• META ddev-ui Roadmap Creation
• Define ddev Roadmap and Features Out to 2.0 (contains feature lists)
• GUI Proposal (contains feature lists)

What happened (or feature request):

• Feature request

What you expected to happen:

The DDEV UI connects with DDEV CLI through an API. To that end, debugging can be a challenge because it's not always apparent to the end-user where the source of the issue is coming from. To that end, DDEV UI needs to surface this information to the end-user in a variety of levels.

1. Top-level CLI issues. This would be related to things like Router Status Reporting #41
2. Top-level GUI issues. This might be something akin to not being able to reach the CLI, not having a proper version of the CLI to interact with, etc.
3. Terminal Output, Normal Mode: Show the normal terminal output that is coming through as ddev CLI is running commands.
4. Terminal Output, Verbose Mode: Essentially toggling on/off debug mode for DDEV CLI and reporting that output.

From a visual perspective, we need to do this in a way that doesn't overwhelm the interface, particularly items related to 3 and 4. Items related to 1 and 2 will probably take up less real estate and should be surfaced more prominently.

What happened (or feature request):

Feature Request

What you expected to happen:

When creating a new app, an end-user can specify an existing repo located on the OS file system.

Related source links or issues:

• Add App from CMS Distribution #14

What happened (or feature request):

I noted when building linux and windows artifacts that we get a full directory full of stuff, but it's not usable as far as I can tell. It needs an installer I guess, but we definitely have to make it easy for people to use.

What you expected to happen:

I thought we'd end up with useable artifacts out of the box.

I did test and

• if I grab everything in the linux tarball, unzip it into a directory, and then run ./DDEV-UI in that directory, it seems to work.

How to reproduce this:

Look at the contents of the artifacts we produce, for example on https://circleci.com/gh/drud/ddev-ui/30#artifacts/containers/0

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

What happened (or feature request):

To have a signed distributable .app or .dmg that our devs will be comfortable with, we need to have Apple Developer credentials. This is a bit of a lengthy process, so it's important to get it started.

• Get D-U-N-S number, which is required before beginning with Apple. Note: rfay began the D-U-N-S request process today for DRUD Techology, that may be good enough. Also requested that @ahufferd do it, before I realized that my simple search would be considered an application. D-U-N-S can verify by phone with the Rockmont office at tel:303.839.8500
• Sign up as an organization with Apple. It's important that at least 2 team members be on there. It's $99/year/dev. As I remember, the org can invite members from outside the org.

There are multiple facets to this ticket.

• Assistance in testing the prototype (should not require extensive documentation, but rather "here's how you'd kick this off to kick the tires).
• Location of documentation. For example, our readthedocs page is entirely ddev CLI focused. How we would modify this to include the GUI would be good to consider. And if we want to consider a completely different section to describe the GUI (or a different set of docs altogether), that would be something to consider.