Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Portable attachment provenance and exact rerun metadata

未关闭
  • 哪里不对？
#68 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃
技术栈
json
领域
testing-qa

调研方向

Start with CTRF section 12.3 and the linked capture and serialization code in TestResultCapture.cs and CtrfReportEngine.JsonTestWriter.cs. Review the relationship to #61 and PR #57. Done means the issue's questions about portable attachment provenance, integrity metadata, and exact rerun metadata have clear guidance on standardized fields versus namespaced extra data.

由索引模型根据 Issue 内容生成。

描述

Producer context

Microsoft.Testing.Platform produces reports in local development, CI shards, multi-module runs, and retry processes. The CTRF report can then be merged and retained after the producing machine is gone.

For attachments, MTP currently emits the attachment name, MIME type, and the producer's absolute local file path:

Section 12.3 now clearly resolves one question: attachments[].path may be a URL or file path, has no prescribed URI/path semantics, and must be treated as opaque. That permits MTP to emit an artifact URI instead of a local path when one is available.

Two portability gaps remain.

Questions

Attachment provenance and integrity
  1. When both a producer-local path and a durable artifact URI exist, is path expected to contain only the durable reference, with the local path moved to namespaced extra, or is a standardized way to carry both desirable?
  2. Is there an intended representation for a content digest (algorithm plus hash) so consumers can verify, deduplicate, or retrieve content-addressed attachments? attachmentId identifies a reference instance, so it does not appear to be a content identity.
  3. Would portable artifact metadata belong directly on Attachment, or should producers use a namespaced object under attachments[].extra?
Exact rerun / reproduction metadata

A failed test is not always reproducible from name, suite, and testId alone. MTP may need the test application/module, target framework, architecture, filter or UID, working directory, relevant runner options, and a safe reference or digest for configuration/runsettings. The exact original command line can also contain secrets and machine-local paths.

  1. Does exact rerun/reproduction metadata belong in CTRF as a standardized object, or is it intentionally producer-specific extra data?
  2. If standardized, should it describe a redacted invocation (executable, arguments, workingDirectory, configuration references) or a higher-level portable recipe (module, test selector, target, environment/configuration digests)?
  3. How should this relate to the pre-v1 environment/initiator redesign being discussed in #61 and to the provenance/derivation work explicitly left out of scope by PR #57?

Why these belong together

Both questions determine whether a CTRF document remains actionable after it leaves the worker that produced it: can a consumer retrieve and verify the evidence, and can it reproduce the failing execution without parsing framework-specific prose or logs? We are not proposing a specific schema yet; guidance on first-class fields versus namespaced extra would unblock a correct MTP mapping.

主要语言
没有语言数据
星标
100
派生
4
平均合并
1 小时 3 分钟
30 天内合并 PR
2

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ctrf-io/ctrf 的其他 Issue

查看 ctrf-io/ctrf 的全部 Issue

相似的 Issue

更多 Testing & QA Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。