-
Notifications
You must be signed in to change notification settings - Fork 1.2k
ci: cross-platform matrix + paths-ignore + concurrency #556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
eabcaf9
21d710b
776831f
cfabff7
4e47b84
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,7 +12,7 @@ function wait(ms: number): Promise<void> { | |
| return new Promise((r) => setTimeout(r, ms)); | ||
| } | ||
|
|
||
| describe("FilesystemWatcher", () => { | ||
| describe("FilesystemWatcher", { retry: 2 }, () => { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🧩 Analysis chain🌐 Web query:
💡 Result: Vitest 4.1.6 “retry” configuration syntax (for test retries) is: 1) As a number (retries all failures) - In vitest config, set test.retry to a number meaning “how many times to retry the test if it fails”. Default is 0. [1] Example: export default defineConfig({ test: { retry: 3, }, }) [2][1] 2) As an object (fine-grained control; available since Vitest 4.1) The object supports these fields: [2][1] - count?: number The number of times to retry the test if it fails. Default is 0. [2][1] - delay?: number Delay in milliseconds between retry attempts. Default is 0. [2][1] - condition?: RegExp | ((error: TestError) => boolean) Controls which failures should trigger a retry: [2][1] - If RegExp, it is tested against the error message. [1] - If function, it’s called with the TestError; return true to retry. [1] Example (RegExp condition): export default defineConfig({ test: { retry: { count: 2, condition: /ECONNREFUSED|ETIMEDOUT/i, }, }, }) [3] Example (CLI flags mentioned in the retry feature commit; same options map to config fields): - --retry= - --retry - --retry.count - --retry.delay - --retry.condition [3] Notes on the function condition: - Vitest docs note that functions can only be used in test files, not in vitest.config.ts, because configuration is serialized when passed to worker threads. [2][1] So, in Vitest 4.1.6, the retry configuration is either: - test: { retry: } or - test: { retry: { count?: , delay?: , condition?: <RegExp|function> } } [1] Citations:
Remove invalid retry syntax and configure retries in vitest.config.ts instead. The 🤖 Prompt for AI Agents |
||
| let root: string; | ||
| const originalFetch = globalThis.fetch; | ||
| let captured: Array<{ url: string; body: unknown; headers: Record<string, string> }>; | ||
|
|
@@ -49,7 +49,7 @@ describe("FilesystemWatcher", () => { | |
| w.start(); | ||
| try { | ||
| writeFileSync(join(root, "notes.md"), "hello world\n"); | ||
| await wait(800); | ||
| await wait(1500); | ||
| expect(captured.length).toBeGreaterThanOrEqual(1); | ||
| const obs = captured[captured.length - 1]; | ||
| expect(obs.url).toBe("http://localhost:3111/agentmemory/observe"); | ||
|
|
@@ -87,7 +87,7 @@ describe("FilesystemWatcher", () => { | |
| w.start(); | ||
| try { | ||
| unlinkSync(join(root, "old.md")); | ||
| await wait(800); | ||
| await wait(1500); | ||
| const deletes = captured.filter( | ||
| (c) => (c.body as { data: { changeKind: string } }).data?.changeKind === "file_delete", | ||
| ); | ||
|
|
@@ -116,7 +116,7 @@ describe("FilesystemWatcher", () => { | |
| w.start(); | ||
| try { | ||
| writeFileSync(join(root, "node_modules", "ignored.js"), "x"); | ||
| await wait(800); | ||
| await wait(1500); | ||
| const matches = captured.filter((c) => | ||
| (c.body as { data: { files: string[] } }).data?.files?.some((f) => f.includes("ignored.js")), | ||
| ); | ||
|
|
@@ -136,7 +136,7 @@ describe("FilesystemWatcher", () => { | |
| w.start(); | ||
| try { | ||
| writeFileSync(join(root, "secret.md"), "bearer test\n"); | ||
| await wait(800); | ||
| await wait(1500); | ||
| expect(captured.length).toBeGreaterThanOrEqual(1); | ||
| const headers = captured[captured.length - 1].headers as Record<string, string>; | ||
| expect(headers.authorization).toBe("Bearer shhh"); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
Repository: rohitg00/agentmemory
Length of output: 913
🏁 Script executed:
Repository: rohitg00/agentmemory
Length of output: 398
🏁 Script executed:
Repository: rohitg00/agentmemory
Length of output: 46
🏁 Script executed:
Repository: rohitg00/agentmemory
Length of output: 2527
🏁 Script executed:
Repository: rohitg00/agentmemory
Length of output: 4506
🌐 Web query:
GitHub Actions version pinning best practices security supply chain💡 Result:
To secure your supply chain against malicious updates or compromised maintainer accounts, the industry-standard best practice for GitHub Actions is to pin all actions to their full-length commit SHA [1][2][3]. Why Pinning to SHA is Critical GitHub Actions referenced by tags (e.g.,
@v4) or branches are mutable, meaning they can be updated or moved by the repository owner at any time [4][5]. If an action's repository is compromised, an attacker can force-push new code to an existing tag, causing all workflows using that tag to automatically execute the malicious code [6][7][5]. Pinning to a full-length commit SHA ensures that your workflow always executes the exact, immutable code you have audited and trusted [4][3]. Best Practices for Implementation 1. Use Full-Length Commit SHAs: Always use the full 40-character commit SHA rather than a short hash [3]. 2. Include Version Comments: To maintain readability and track which version the SHA corresponds to, append the version tag as a comment in your workflow file [1][2]: uses: actions/checkout@b4ffde6 # v4.1.1 3. Enforce via Policy: Organizations can enforce this practice at the enterprise or organization level by configuring GitHub Actions policies to require full-length commit SHAs for all actions [6][3]. 4. Automate Updates: Use Dependabot to manage your pinned actions [8]. When configured for GitHub Actions, Dependabot will monitor for updates and open pull requests to bump your pinned SHAs to newer, secure versions [8][9]. 5. Be Aware of Transitive Dependencies: Pinning your direct action dependencies does not automatically pin the actions they call internally [10]. Be cautious when using complex actions that pull in many transitive dependencies, as these can also be targets for supply chain attacks [10]. Additional Security Considerations - Trust and Verification: If you must use tags for convenience, only do so for actions from highly trusted, verified creators [3]. - Monitor for Compromise: Even with pinning, stay informed about security advisories for the actions you use [4][11]. - Platform Controls: Leverage GitHub's evolving security features, such as immutable releases (which prevent tags from being moved) and organization-level execution policies, to further harden your CI/CD environment [6][12][5].Citations:
Pin GitHub Actions to immutable commit SHAs.
Line 56 and Line 59 use mutable major tags (
@v6). These should be pinned to full-length commit SHAs to prevent supply-chain attacks; if the upstream repository is compromised, tag-based references will execute malicious code pushed to that tag.Suggested change
📝 Committable suggestion
🧰 Tools
🪛 zizmor (1.25.2)
[error] 56-56: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 59-59: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents