mirror of
https://github.com/harvester/harvester-ui-extension.git
synced 2026-11-15 05:16:16 +08:00
* chore(deps): bump @rancher/shell to 3.0.13 (#1130) Clears 26 of the 54 open Dependabot alerts (axios, dompurify, serve-static, and drops vulnerable send / @tootallnate/once copies). 3.0.13 ships the flat-config ESLint 10 toolchain, so lint now routes through the @rancher/shell launcher (keeping the legacy .eslintrc on ESLint 7); a prelint step installs an ESLint-7-compatible eslint-plugin-jest into the isolated toolchain. Conflicts resolved: yarn.lock (yarn.lock regenerated with yarn install; package.json keeps the release branch dependencies) Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> (cherry picked from commit00584f1d19) * feat: Add a unit test target (jest) to the UI extension and run it in CI (#1192) - Introduce test targets. - Adding additional tests. Related to: https://github.com/harvester/harvester/issues/11892 Signed-off-by: Volker Theile <vtheile@suse.com> (cherry picked from commit71141b257a) Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * chore(deps): bump @rancher/shell to 3.0.14 (#1208) * chore(deps): bump @rancher/shell to 3.0.14 3.0.14 resolves [[name]] tokens in translations from values registered as l10n globals, which the standalone UI needs to pick the product name. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: save cloud-config template edits with @rancher/shell 3.0.14 The YamlEditor of shell 3.0.14 no longer emits onChanges, so editing a template saved its old cloud config. Copy the text from update:value, which both shell versions emit. Jest transforms @replit/codemirror-vim-core, an ESM-only dependency of the new YamlEditor, like the dashboard does. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: keep the YAML editor heights with CodeMirror 6 The min-height rules targeted the CodeMirror 5 element, so the editors shrank to their text. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: reject IP ranges the network settings don't support The CIDR check of @rancher/shell 3.0.14 also accepts short forms such as 10.1/16, extra parts and IPv6, so the VM migration, RWX and storage network settings saved them. Use a strict IPv4 CIDR check of our own. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: keep the look of the file selector buttons The FileSelector of @rancher/shell 3.0.14 no longer takes button classes and renders a medium secondary button. Pass the variant and size that match the previous primary and secondary buttons. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: keep Enter in a migration wizard field on the same step The Wizard of @rancher/shell 3.0.14 renders its step headers as submit buttons, so Enter in a text field clicked the first one and jumped back to step 1. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: show the created message after a restore, upgrade or upload Since @rancher/shell 3.0.14, save() no longer shows the message for resources with a generated name; callers show it with notifyGeneratedName(). Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * refactor: fold the logging output buffer with the CodeMirror 6 helpers The YAML editor of @rancher/shell 3.0.14 is CodeMirror 6, and its CodeMirror 5 methods are deprecated. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: keep the shell's table views off in standalone @rancher/shell 3.0.14 turns its table views on for every list in the standalone UI, as the server has no ui-configurable-tables feature and the default is on. The table views drop the filters the lists put in the table header, which also left the Images list empty. Add the feature, disabled, to the management store in standalone only. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: reject zero-padded octets in IP ranges Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> --------- Conflicts resolved: package.json, yarn.lock (yarn.lock regenerated with yarn install; package.json keeps the release branch dependencies) Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> (cherry picked from commitd6f6f7c54c) * feat: use the SUSE Virtualization product name on Prime (#1202) * feat: switch the product name with Rancher Prime Use a [[Harvester]] token for the product name in the translations, so Rancher 2.16 fills it from the l10n global that harvester-manager registers: SUSE Virtualization on Rancher Prime, Harvester otherwise. Rancher before 2.16 shows the tokens as written, so on those hosts (and standalone) the extension resolves them to Harvester itself. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * feat: switch the standalone product name with the server flavor Standalone has no Rancher Prime, so register the [[Harvester]] l10n global from the server-flavor setting instead: SUSE Virtualization on prime, Harvester otherwise. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: point the network policy banner to the documentation Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * feat: use the SUSE theme in standalone Prime Standalone Prime kept the harvester brand and only overrode the primary colour, so the rest of the palette and the fonts didn't match Rancher Prime. Switch the ui-brand setting to suse in the store when the server flavor is prime, which makes the shell load the SUSE theme. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: keep the SUSE theme after a brand setting change event The watcher also reads the setting's value, so a change from the server loaded into the same object switches the brand back to suse. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> --------- Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> (cherry picked from commit6e0e0237ef) --------- Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> Signed-off-by: Volker Theile <vtheile@suse.com> Co-authored-by: Volker Theile <vtheile@suse.com>
# Agents.md
This folder contains files used to construct a single root `AGENTS.md`
We do this because
- The single commonality between almost all AI tools is that they look for a root `AGENTS.md`
- Having the information in a single place for all AI tools is better than duplicating and maintaining the information in multiple files for each AI tool
## Process
1. Add files to or update files in `./docs/agents.md/agents`, `./docs/agents.md/personas`, `./docs/agents.md/contributors`.
2. Each file must
- Start markdown headers at the `##` level
- End in a new line
- Order contents in AGENTS.md by giving an optional number prefix
3. Run `yarn agents:generate`.
- Take the contents of `./docs/agents.md/template_agents.md`
- Insert the contents of the agents, personas and contributors files
- Output to `./AGENTS.md`
4. Commit all changes, including root `./AGENTS.md` and any files that link to it
## Guidance
### Examples
When referencing code or configuration it's good to include an example
## Future Tasks
- Add real world examples when referencing code
- Create a GH workflow to monitor `agents.md` folder files in a PR, if changed run generate script and add new AGENTS.md to PR
- Discuss
- Three multi AI tool related questions
- Questions
- how AI specific patterns, like co-pilot instructions, can be expressed in a way to be adopted by or reduce duplication with the root agents.md
- how AI tool specific metadata code can be included
- multiple agents vs personas approach works
- Proposal
- Generic information applicable to all AI tools is added to the root `agents.md`
- Agent, instruction or other AI specific files or patterns can be used in files specific to that AI tool. They must not contain duplicate information to the root `agents.md`
- The root `agents.md` continues to be AI tool agnostic
- How can folder specific agents be used
- Proposal
- `agents.md` are added to folders as long as most LLMs can make use of them and they do not duplicate information in the root `agents.md`
## Test Prompts
To validate LLMs are picking up information consider running the following prompts.
### Information
Can they provide correct information?
- `what's this project about?`
- `can you tell me the process for fixing a github issue in this repo?`
- `what makes a good software developer?`
- `what should never be done in this project?`
- `what are the folders in this project for?`
- `what are the env vars i could use when running e2e tests?`
### Actions
Can they use the information in their actions?
Pending