3
此 PR 将支持 git.properties 并在banner.txt 中构建信息变量。这很有用，因此即使命令行应用程序也可以显示只能通过执行器获得的信息。
Q
[spring-projects/spring-boot]在横幅中添加对 git 和构建信息变量的支持
A
回答
8
我采纳了审稿意见。我不是 ASCII 医生专家，无法创建指向另一个页面中的某个部分的链接。如果你知道请告诉我。
9
感谢您的公关。对于可能是利基利益的东西来说，这感觉像是相当多的额外复杂性。将额外的Resource实例作为构造函数参数也是有问题的。三个参数都具有相同的类型很容易将它们混淆。如果我们想添加更多内容，它也会变得笨拙。
我认为这最好在您自己的项目中作为自定义横幅来解决。该横幅可以作为子类实现ResourceBanner。如果ResourceBanner当前缺乏必要的扩展点，我会更倾向于添加这些扩展点而不是此处建议的更改。
让我们看看团队其他成员的想法。
2
@wilkinsona显然这不是我的决定，但是没有REST（或任何其他）接口的短期任务并不是一个利基市场，例如：Spring Cloud Data Flow。这些应用程序还有哪些其他方式来记录 git 和构建信息？如果唯一的问题是构造函数的复杂性，那么可以使用如下构建器样式的解决方案轻松解决它：
ResourceBanner.builder().withBanner(b).withGitInfo(g).withBuildInfo(b).build()你怎么认为？
8
我不认为通过横幅记录信息是使其可用的最佳方式。就我个人而言，我会使用 Actuator 的 JMX 支持和现有的信息端点。我仍然相信执行器不以任何形式提供的应用程序是一个利基市场。
从 API 的角度来看，构建器是一种改进，但它对于减少额外的内部复杂性并没有多大作用，我仍然不相信这是合理的。它还在横幅上留下了构建信息和 git 属性的知识。这些目前仅由执行器处理，因此提议的更改在这两个模块之间引入了概念循环。
3
我希望 Spring Batch、Spring Cloud Data Flow 以及使用 Spring Boot 编写大数据作业不是小众领域；）
6
我希望 Spring Batch、Spring Cloud Data Flow 以及使用 Spring Boot 编写大数据作业不是小众领域
我不是这么说的。您列出的所有内容都不会妨碍您使用 Actuator 并通过 JMX 访问它。
如果您正在寻找要记录的信息，以便将其推送而不是拉出，或者即使在进程不再运行时也可用，那么这可能对任何类型的应用程序都有好处。但是，我仍然认为横幅不是放置它的正确位置。我宁愿在执行器的信息支持中提供一个选项，以记录所有已知的贡献。
8
我明白你的观点，问题是我们如何在没有网络或执行器依赖性的应用程序中重用执行器代码。或者我们应该让执行器即使对于非 Web 应用程序也能工作？
3
或者我们应该让执行器即使对于非 Web 应用程序也能工作？
它已经可以在非 Web 应用程序中运行。如果您添加spring-boot-starter-actuator对其端点的依赖项，则可以通过 JMX 自动使用它。
5
好的，那么对于短期应用程序来说，显示 git 和构建信息的理想解决方案是什么？向 Actuator 添加一个选项以将信息打印到日志中？
8
向 Actuator 添加一个选项以将信息打印到日志中？
可能是的。请提出一个问题来描述您的最终目标，然后我们可以找出实现该目标的最佳方法。
1
感谢您的公关，但我同意安迪的观点，即在横幅中支持这一点所增加的复杂性并不理想。
4
好的，我会提出一个问题，我很高兴将此功能添加到执行器中，除非您想自己做
4