c89d2de376
* Init prebuilds list * Text size and color tweaks * Dropdown filtering UI * wip changes * File renames and such * Filter by state * fix path * Add configuration ID filtering * Prebuild list error state * Protobuf sorting definition * API-level sorting * Simplify pagination * Fix undefined inference * Dashboard adopt sort behavior * make sorting required * Move ordering 🤷♂️ This will most definetely not solve anything, but... * Hopefully fix sorting 🤷♂️ * less `as` * Simplify state check * Repeated sorting * Sort out sorting Sorry :/ * Configuration dropdown WIP * Make configuration filter disableable * Use in in SQL * Minor styling adjustements * Nav item * Rename menu item * Const 🤷♂️ * Always display filter reset opt * Add prebuild link to prebuild settings * Simplify * Don't throw errors All my homies hate throwing in `server` * FF hook * Name failed to load state * typo * Better unknown inference * Add ConfigurationField component to display repository name and link * Do not retry configuration load * Move prebuild utils * Unify sort types * Refactor PrebuildTable to use arrow function syntax for mapping prebuilds * fix imports * Widen triggered column * Widen even more * Shorten status labels * Init ws db tests * Rename list item comp accordingly T'was an oopsie doopsie * Test configuration ids and branches filtering
Public API TypeScript Common
Overview
This package serves as a bridge for code conversion between two distinct Gitpod packages: @gitpod/gitpod-protocol and @gitpod/public-api. Its primary responsibility is to ensure seamless translation of application data structures from the gitpod-protocol format to the public-api gRPC format, and vice versa.
Allowed Usage
Use this package exclusively for tasks that require data structure from @gitpod/gitpod-protocol and @gitpod/public-api. It's important not to introduce dependencies on this package from gitpod-protocol or public-api to ensure changes in one package don't trigger rebuilds of unrelated components such as ws-manager-bridge and supervisor-frontend.
Golden tests
Golden tests are used to test the output of a function against a known good output. The output is stored in a file with the same name as the test file but with a .golden extension. The test will fail if the output does not match the golden file.
We use golden tests for public api data conversion functions. We put the fixtures input and golden results in the ../fixtures folder.
See example below:
it("toOrganizationMember", async () => {
await startFixtureTest("../fixtures/toOrganizationMember_*.json", async (input) =>
converter.toOrganizationMember(input),
);
});
it will run the test for each file matching the glob pattern ../fixtures/toOrganizationMember_*.json. The test will fail if the output does not match the ../fixtures/toOrganizationMember_*.golden files.
How to veirfy golden files
yarn test
How to update golden files
yarn test:forceUpdate
How to generate input json files
node scripts/new-fixtures.js [your_testing_name] [the_number_of_input_files]