I just cleaned my _Very Messy_™ ~/cylc-run dir and found that the gui waits a long time in this state:

Might we reasonably close it and replace it with a notification that something is happening which doesn't hog the GUI screen?

I just cleaned my __Very Messy__™ ~/cylc-run dir and found that the gui waits a long time in this state:

Might we reasonably close it and replace it with a notification that something is happening which doesn't hog the GUI screen?

I just cleaned my Very Messy™ ~/cylc-run dir and found that the gui waits a long time in this state:

Might we reasonably close it and replace it with a notification that something is happening which doesn't hog the GUI screen?

Context:

The cylc-ui tests rely on mocked data. They test the UI in of itself, but not its interactions with other Cylc components.

We could do with a couple of simple end-to-end system tests to ensure the various bits fit together and act as canary tests to spot breakages before they're released. E.G. open the UI, start a workflow, trigger a task, stop a workflow, that sort of thing. This will catch daft issues like, us accidentally removing a flag to cat-log that the UIS relied on. One way to do this would be use Cypress and point it at a real UI server rather than the mocked offline data.

If you get Cypress to record the video from these test sessions (jamming sleeps in to slow things down) you would get a pretty good walkthrough showing how to start/stop workflow, open logs, trigger tasks, etc. If we could jam in a few captions somehow that would make a pretty good introductory video, with the added bonus that it wouldn't get out of date and could be extended to cover new features as they're added as functional documentation.

We now have a stub workflow for performing nightly system tests. At present, all it does is to check that the relevant components can be installed together (to sniff out any compatibility/metadata issues). This would be the logical home of end-to-end system tests if/when we get around to them:

https://github.com/cylc/cylc-admin/blob/master/.github/workflows/system.yml

Context:

The cylc-ui tests rely on mocked data. They test the UI in of itself, but not its interactions with other Cylc components.

We could do with a couple of simple end-to-end system tests to ensure the various bits fit together and act as canary tests to spot breakages before they're released. E.G. open the UI, start a workflow, trigger a task, stop a workflow, that sort of thing. This will catch daft issues like, us accidentally removing a flag to cat-log that the UIS relied on (hasn't happened but very possible). One way to do this would be use Cypress and point it at a real UI server rather than the mocked offline data.

If you get Cypress to record the video from these test sessions (jamming sleeps in to slow things down) you would get a pretty good walkthrough showing how to start/stop workflow, open logs, trigger tasks, etc. If we could jam in a few captions somehow that would make a pretty good introductory video, with the added bonus that it wouldn't get out of date and could be extended to cover new features as they're added as functional documentation.

We now have a stub workflow for performing nightly system tests. At present, all it does is to check that the relevant components can be installed together (to sniff out any compatibility/metadata issues). This would be the logical home of end-to-end system tests if/when we get around to them:

https://github.com/cylc/cylc-admin/blob/master/.github/workflows/system.yml

Context:

The cylc-ui tests rely on mocked data. They test the UI in of itself, but not its interactions with other Cylc components.

We could do with a couple of simple end-to-end system tests to ensure the various bits fit together and act as canary tests to spot breakages before they're released. E.G. open the UI, start a workflow, trigger a task, stop a workflow, that sort of thing. This will catch daft issues like, us accidentally removing a flag to cat-log that the UIS relied on (hasn't happened but very possible), that sort of thing. One way to do this would be use Cypress and point it at a real UI server rather than the mocked offline data.

If you get Cypress to record the video from these test sessions (jamming sleeps in to slow things down) you would get a pretty good walkthrough showing how to start/stop workflow, open logs, trigger tasks, etc. If we could jam in a few captions somehow that would make a pretty good introductory video, with the added bonus that it wouldn't get out of date and could be extended to cover new features as they're added as functional documentation.

We now have a stub workflow for performing nightly system tests. At present, all it does is to check that the relevant components can be installed together (to sniff out any compatibility/metadata issues). This would be the logical home of end-to-end system tests if/when we get around to them:

https://github.com/cylc/cylc-admin/blob/master/.github/workflows/system.yml

Swapping <v-btn><v-icon :icon="x" /></v-btn> for <svg><line :d="x" /></svg> reduced component mount time ~50% for a real world example:

https://github.com/cylc/cylc-ui/pull/1619/files

Yikes!

Lessons learned:

• Go easy on components when v-for's are involved.
• Maybe don't reach for Vuetify by default, just because it's there doesn't mean we have to use it!
• Nested components are a cost, e.g. <Task /> wraps <SVGTask /> for maintenance reasons. But it would be more efficient to duplicate the code or figure out some fancy import / file-sync approach.

Swapping <v-btn><v-icon :icon="x" /></v-btn> for <svg><line :d="x" /></svg> reduced component mount time ~50% for a real world example:

https://github.com/cylc/cylc-ui/pull/1619/files

Yikes!

Lessons learned:

• Go easy on components in general (Vuetify or other) when v-for's are involved.
• Maybe don't reach for Vuetify by default, just because it's there doesn't mean we have to use it!
• Nested components are a cost, e.g. <Task /> wraps <SVGTask /> for maintenance reasons. But it would be more efficient to duplicate the code or figure out some fancy import / file-sync approach.

Swapping <v-btn><v-icon :icon="x" /></v-btn> for <svg><line :d="x" /></svg> reduced component mount time ~50% for a real world example:

https://github.com/cylc/cylc-ui/pull/1619/files

Yikes!

Lessons learned:

• Go easy on components in general (Vuetify or other) when v-for's are involved.
• Maybe don't reach for Vuetify by default, just because it's there doesn't mean we have to use it! There are lots of trivial things we can do for ourselves.
• Nested components are a cost, e.g. <Task /> wraps <SVGTask /> for maintenance reasons. But it would be more efficient to duplicate the code or figure out some fancy import / file-sync approach.

Nevermind, looks like the memory leak is only in whatever hooks are injected into the code in the development build only. In the production build there does not seem to be a leak