大家好,是时候结束另一个成功的阶段定制配送服务项目,并且我们已经整合了我们在这个阶段开始时计划的大部分特性。这对我和整个团队来说都是一个巨大的学习过程。

要了解项目是关于什么以及过去的进展,请参阅第一阶段的博客文章在这里

前端

过滤器插件

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

  1. 标题

  2. 大多数安装

  3. 相关性

  4. 趋势

滤波器的实现

主要繁重的工作是由插件api完成的,它接受必要的参数,并以json对象的形式返回相关的插件,下面是一个api调用url的例子:const url =https://plugins.必威国际有限公司jenkins.io/api/plugins? params美元

更多细节,请参阅:

社区配置

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

community-config

设计决策

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

在当前存储库中拥有配置:

这允许我们将所有相关配置都放在存储库中,这样用户就不必从不同的存储库中获取这些配置。我们可能会在发布周期和依赖项上有问题,因为它必须与自定义发布服务项目发布一起发生。

将配置放在不同的存储库中:

这使我们能够单独轻松地管理所有配置和相关依赖项,从而避免与当前存储库的任何版本冲突。但是,如果用户找不到这个存储库,就有点困难了。

决定:我们仍然不能完全同意什么是最好的方法,所以现在,我已经包含了url从社区配置被选为配置变量.env文件可以稍后配置,因此它可以由用户来配置。让它可配置的另一个好处是,用户可以决定加载对他的组织也是私有的配置。

更多细节,请参阅:

后端

战争的一代

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

生成战争文件时需要注意的事项

在目前的状态下,战争世代不包括在内casc.ymlgroovy文件如果包含在配置中,则必须从外部添加。有一个问题有待解决在这里.如果您尝试使用jcasc文件配置构建war文件,则war文件生成将向您发出警告。

更多细节,请参阅:

把请求创建

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

更多细节,请参阅:

免责声明:

然而,这个特性现在被搁置了,因为我们正专注于让项目自托管,因此,一旦我们明确了项目由jenkins-infra团队托管的路径,我们就会实现这个特性。必威国际有限公司如果你想参与讨论,这里有拉取请求的链接,公关1和链接:公关2,或者你甚至可以跳进我们的git通道

如果你一直在关注我的博文,我在第二周的博文中提到,拉入包含超过1600个插件的json文件花费的时间比我喜欢的要多一些。我们使用缓存机制解决了这个问题,所以现在文件在你第一次启动服务时就会被拉进来,并在一个临时文件夹中下载。下次想要查看插件卡时,可以直接从临时目录中拉入它们砰!从而减少时间。

详情请参见Pull Request# 90

修正和改进

端口8080

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

更多细节,请参阅:

战争的一代

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

更多细节,请参阅:

  • 战争生成错误处理# 91

  • 添加Github控制器和jwt助手# 66

Dockerfile

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

更多细节,请参阅:

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

更多细节,请参阅:

关于作者
Sladyn Nunes

Sladyn是印度孟买大学计算机科学专业的学生。他参加了Community Bridge 2019,以IDE集成、模式架构改进和配置扩展点的形式为JCasC插件提供开发工具配置为代码插件