自定义分发服务:第二阶段Blogpost

在前一阶段，我们实现了向配置中添加插件的功能，以及通过搜索栏搜索这些插件的功能。有时候我们会根据插件的使用情况、受欢迎程度、星级等来过滤这些插件。因此，我们为这些插件添加了一组特定的过滤器。我们目前只支持四种主要的过滤器。它们是:

该项目的一个主要可交付成果是用户能够共享由他们开发的配置，这样他们就可以在社区中广泛使用。例如，我们看到很多jenkins配置涉及在AWS和kubernete必威国际有限公司s等平台上运行。因此，对于社区来说，有一个地方可以找到并运行这些配置是非常好的。

这里采取的主要设计决策是在存储库中包含配置还是在一个全新的存储库中。让我们来谈谈这两种方法。

生成和下载战争文件的功能终于实现了，这个功能花了这么长时间才完成的原因是我们在实现战争生成及其测试方面遇到了一些困难。然而，这已经完成，现在可以成功测试。

这一功能包含在我选择GSoC后创建的设计文件中。它包括通过服务的前端创建拉取请求的能力。这个特性背后的用户故事是这样的如果我想与社区共享一个配置，但我不太知道如何使用github或我不想通过终端来做它．该特性包括创建一个bot，用于处理存储库中拉取请求的创建。这个机器人必须由jenkins组织在这个存储库中安装，机器人将处理其余的工作。必威国际有限公司

更多细节,请参阅:

端口8080现在有一个消息，而不是在spring-boot tomcat服务器设置中默认出现的白标签错误消息。结果是，它需要覆盖一个特定的类，并插入一个定制消息

更多细节,请参阅:

到目前为止，当您生成war文件时，如果在生成过程中出现错误，服务不会抱怨，它只会吞下错误并返回已损坏的文件战争文件，但是现在我们增加了一个错误支持功能，当出现错误时，它会提醒你，目前的错误不是很有用，但我们正在努力使它在未来更有用。

更多细节,请参阅:

这个阶段的主要里程碑之一是拥有一个可以自托管的项目，不用说我们需要dockerfile即docker-compose。Yml使用一些命令来旋转项目。我们在这里遇到的主要问题是，让两个容器彼此通信存在一些问题。让我给你们一点背景知识。我们的docker-compose使用两个独立的dockerfile来构建，一个用于服务的后端，另一个用于服务的前端。后端通过代理url(即localhost:8080)对前端进行api调用。现在我们必须改变这一点，因为两个容器之间的网桥通过后端服务器名称(即应用服务器．为了弥合这一差距，我们有这个公关，以确保docker组成工作完美。

更多细节,请参阅:

然而，上面的方法有一个小缺点，现在整个项目仅仅依赖于docker组合，不能使用简单的组合运行npm和maven因为代理是不同的。为了解决这个问题，我决定采用多环境方法，在这里我们有多个环境文件，这些环境文件选择了正确的代理并在构建时插入它，为了进一步详细说明，我们有两个环境文件(使用env-cmd库).env和docker.env我们插入正确的文件，这取决于你想如何构建项目。例如，如果你想使用dockerfile来运行它，在hood下面运行的命令是这样的-NPM——env-cmd -f docker。env启动脚本．

更多细节,请参阅:

git频道链接
GSoC提议
设计文档
每天的笔记
演示