Merge branch 'galaxyproject:dev' into job-completion-email-citation

Author: Syrinx55

.github/workflows/build_container_image.yaml

@@ -250,7 +250,7 @@ jobs:
           sed -i "s/^  tag:.*/  tag: \"${{ needs.build.outputs.tag }}\"/" galaxy/values.yaml
 
       - name: Create Pull Request
-        uses: peter-evans/create-pull-request@v6
+        uses: peter-evans/create-pull-request@v7
         with:
           token: ${{ secrets.GALAXY_HELM_PULL_REQUEST_TOKEN }}
           commit-message: "Update Galaxy to version ${{ needs.build.outputs.version }}"

.github/workflows/jest.yaml .github/workflows/client-unit.yaml.github/workflows/jest.yaml renamed to .github/workflows/client-unit.yaml

@@ -3,11 +3,11 @@ on:
   push:
     paths:
       - 'client/**'
-      - '.github/workflows/jest.yaml'
+      - '.github/workflows/client-unit.yaml'
   pull_request:
     paths:
       - 'client/**'
-      - '.github/workflows/jest.yaml'
+      - '.github/workflows/client-unit.yaml'
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true
@@ -32,6 +32,6 @@ jobs:
       - name: Stage client libs (Gulp)
         run: yarn run gulp client
         working-directory: client
-      - name: Run Unit Tests
-        run: yarn jest
+      - name: Run Vitest Unit Tests
+        run: yarn test
         working-directory: client

client/.eslintrc.js

@@ -113,9 +113,17 @@ module.exports = {
     plugins: basePlugins,
     overrides: [
         {
-            files: ["**/*.test.js", "**/*.test.ts", "**/tests/jest/**"],
-            env: {
-                jest: true,
+            files: ["**/*.test.js", "**/*.test.ts", "**/tests/vitest/**"],
+            globals: {
+                vi: "readonly",
+                describe: "readonly",
+                it: "readonly",
+                expect: "readonly",
+                beforeEach: "readonly",
+                afterEach: "readonly",
+                beforeAll: "readonly",
+                afterAll: "readonly",
+                test: "readonly",
             },
         },
         {

client/README.md

@@ -114,13 +114,13 @@ developer-facing API of your new code.
 
 ### Testing Technologies
 
-[Galaxy uses Jest](https://jestjs.io/) for its client-side unit testing
+[Galaxy uses Vitest](https://vitest.dev/) for its client-side unit testing
 framework.
 
 For testing Vue components, we use the [Vue testing
 utils](https://vue-test-utils.vuejs.org/) to mount individual components in a
-test bed and check them for rendered features. Please use jest-based mocking
-for isolating test functionality.
+test bed and check them for rendered features. Please use Vitest's mocking
+capabilities for isolating test functionality.
 
 ### Linting
 
@@ -152,17 +152,17 @@ executing all the client tests:
 
      yarn test
 
-##### Watch and rerun jest unit tests every time a source file changes
+##### Watch and rerun unit tests every time a source file changes
 
 This is incredibly handy, and there are a host of options in the interactive
-terminal this starts for executing Jest tests.
+terminal this starts for executing Vitest tests.
 
-     yarn run jest-watch
+     yarn test:watch
 
 ##### Run only specified test files when a source file changes
 
-    yarn run jest-watch MyModule
+    yarn test:watch MyModule
 
-    yarn run jest-watch Dialog
+    yarn test:watch Dialog
 
-    yarn run jest-watch workflow/run
+    yarn test:watch workflow/run

client/docs/composables.md

@@ -75,9 +75,10 @@ const store = new Vuex.Store({
 The second option is to mock the composable:
 
 ```js
+import { vi } from "vitest";
 import { useCurrentUser } from "@/composables/user";
 
-jest.mock("composables/user");
+vi.mock("composables/user");
 useCurrentUser.mockReturnValue({
     currentUser: {},
 });

client/docs/providers-and-renderers.md

@@ -125,7 +125,7 @@ mandatory markup, just one big empty slot.
 // Testing a renderless component
 
 import { shallowMount } from "@vue/test-utils";
-import { getLocalVue, waitForLifecyleEvent } from "tests/jest/helpers";
+import { getLocalVue, waitForLifecyleEvent } from "@tests/vitest/helpers";
 import DoodadProvider from "./DoodadProvider";
 
 describe("A renderless component", () => {

client/docs/unit-testing/debugging-unit-tests.md

@@ -7,18 +7,18 @@ parameters actually does.
 I've gone ahead and annotated all the options, hopefully this will save some time, at least until VS
 code updates its test extensions again.
 
-#### To debug a single Jest test:
+#### To debug a single Vitest test:
 
-1. Open a jest test (a file that ends with \*.test.js)
+1. Open a vitest test (a file that ends with \*.test.js or \*.test.ts)
 
 1. Make sure the test file is selected, especially if you have multiple files open. This process
    will fail confusingly and without obvious error if you have not launched the debugger with the
-   actual Jest test file selected, and it's easy to accidentally click into another file if you've
+   actual Vitest test file selected, and it's easy to accidentally click into another file if you've
    got a dozen open.
 
 1. Place a breakpoint in the margin of the file. You can place breakpoints anywhere in your source,
-   but you must launch the debugger while the jest file is selected because that is where jest and
-   webpack will start compiling. Alternatively, you can manually override the selected file in the
+   but you must launch the debugger while the vitest file is selected because that is where vitest
+   will start compiling. Alternatively, you can manually override the selected file in the
    configuration definition, like if you're testing the same file over and over again and don't want
    to worry about selecting it.
 
@@ -30,7 +30,7 @@ code updates its test extensions again.
 1. Click on the "Run and Debug" tab from the vscode icons on the left and choose the sample launch
    configuration (defined below) from the dropdown "run and debug". Or just hit F5.
 
-1. Wait a bit, for webpack to compile everything, eventually you should be able to hover over
+1. Wait a bit, for vitest to compile everything, eventually you should be able to hover over
    variables near your breakpoint and see their values in the "Variables" section of the Run and
    Debug pane.
 
@@ -41,28 +41,25 @@ code updates its test extensions again.
     "configurations": [
         {
             "type": "node",
-            "name": "debug selected jest test",
+            "name": "debug selected vitest test",
             "request": "launch",
 
-            // launches version of jest from inside the node_modules
+            // launches version of vitest from inside the node_modules
             // this means you need to have run yarn first
-            "program": "${workspaceFolder}/client/node_modules/jest/bin/jest",
+            "program": "${workspaceFolder}/client/node_modules/vitest/vitest.mjs",
             "args": [
-                // Alias -i.
-                // Normally jest opens up a bunch of workers to run all your tests faster
-                // but we don't want that right now.
-                "--runInBand",
+                // Run tests in a single thread for debugging
+                "--no-threads",
 
-                // finds jest config
-                "--config",
-                "${workspaceFolder}/client/tests/jest/jest.config.js",
+                // Run in watch mode so tests can be re-run
+                "--watch",
 
                 // This is how vscode references the currently selected file
                 "${file}"
             ],
             "cwd": "${workspaceFolder}/client",
 
-            // opens jest output in integrated terminal
+            // opens vitest output in integrated terminal
             "console": "integratedTerminal",
 
             // allows you to place breakpoints right in vscode's gutter

client/docs/unit-testing/readme.md

@@ -1,10 +1,10 @@
-[Galaxy uses Jest](https://jestjs.io/) for its client-side unit testing
+[Galaxy uses Vitest](https://vitest.dev/) for its client-side unit testing
 framework.
 
 For testing Vue components, we use the [Vue testing
 utils](https://vue-test-utils.vuejs.org/) to mount individual components in a
-test bed and check them for rendered features. Please use jest-based mocking
-for isolating test functionality.
+test bed and check them for rendered features. Please use Vitest's mocking
+capabilities for isolating test functionality.
 
 ### Specific test scenarios & examples
 

client/docs/unit-testing/strategies.md

@@ -37,11 +37,12 @@ export function theThingYouReallyCareAbout() {
 
 ```js static
 // myModule.test.js
+import { vi } from "vitest";
 import { theThingYouReallyCareAbout, redirectTo } from "./myModule";
 
-// calling jest.mock on the appropriate import path wraps the exports and gives
+// calling vi.mock on the appropriate import path wraps the exports and gives
 // access to new testing methods like mockImplementation
-jest.mock("./myModule");
+vi.mock("./myModule");
 redirectTo.mockImplementation((url) => {
     console.log(`I would have gone to: ${url}`);
 });

client/docs/unit-testing/writing-tests.md

@@ -23,20 +23,20 @@ The other side of the same coin is to test _only_ the unit in question. If your
 component has a model that uses a service that touches Vuex, which then uses
 Axios to fetch some data -- don't test all that at once. Break things apart and
 mock functionality to isolate testing to units. End to end testing is a
-separate thing that shouldn't be attempted using spec tests in Jest.
+separate thing that shouldn't be attempted using spec tests in Vitest.
 
 Assume nobody cares _how_ your code works, we just need to know that the public
 API you designed _does_ work. If performance problems or new tech necessitate a
 re-write, these tests become a guide for the next implementation.
 
 ### Writing a test file
 
-Jest will try to test any file ending in "\*.test.js". Please place your test
+Vitest will try to test any file ending in "\*.test.js" or "\*.test.ts". Please place your test
 files inside client/src folders right next to whatever files that they are
 testing.
 
-Jest has extensive documentation on the expect API, mocking, and more on the
-[official docs page](https://jestjs.io/docs/en/getting-started.html), which will
+Vitest has extensive documentation on the expect API, mocking, and more on the
+[official docs page](https://vitest.dev/guide/), which will
 be your best resource here.
 
 ```js static
@@ -63,10 +63,10 @@ describe("some module you wrote", () => {
 });
 ```
 
-### Check out the Jest helper functions
+### Check out the Vitest helper functions
 
 We have created some [common helpers for common testing
-scenarios](https://github.com/galaxyproject/galaxy/blob/dev/client/tests/jest/helpers.js).
+scenarios](https://github.com/galaxyproject/galaxy/blob/dev/client/tests/vitest/helpers.js).
 
 ### Mocking API calls