按照预定的版本计划，前天GitLab官方博客宣布GitLab 12.8发布。新版本继续加强DevOps功能及其生命周期的管理，包括了日志浏览器、NuGet软件包和遵从性活动等。更详细功能，请随虫虫一起来学习。
在对事件进行分类或验证服务状态时，需要能够从整个应用程序中浏览Kubernetes Pod日志。此前日志的浏览非常麻烦，只能看到有限的日志，无法来回回溯访问过也不支持日志搜索。无法使用Pod Logs进行有意义的分析，只能用于简单的故障排除用例。
现在，新的Log Explore支持汇总所有日志到一个位置进行交互。其强大的功能包括日志过滤，按照时间筛选以及支持全文搜索，可快速获取所需的信息。日志记录类别从minimal移到viable。
对GitLab自建实例，可以一键安装Elastic stack安装到Kubernetes集群上，所有日志将被自动收集和汇总。
GitLab 12.8引入了使用弹性堆栈的日志聚合。附加Kubernetes集群后，可以安装Elastic堆栈，其中包含一个带有Filebeat（轻量级日志传送器）的Elasticsearch实例。启用后，GitLab会自动收集所有应用程序日志并将其显示在UI上。
通过日志汇聚，可以查看跨多个服务和基础架构的汇总Kubernetes日志，及时返回，进行无限滚动以及搜索应用程序日志。如果要对应用程序事件进行分类或验证服务状态，并且需要浏览整个应用程序中的日志并进行全文搜索，这将非常有用。可以帮助了解影响应用程序性能的因素，并解决出现的任何问题。
Windows具有庞大，活跃且不断发展的开发社区。尽管GitLab已经具有针对C/ C++，Java和Node.js的内置软件包管理，但是使用c#和.NET应用程序仍需要借助外部的工具来保存和管理其二进制文件。
GitLab 12.8中新增加了NuGet存储库，以支持对C#和.NET应用的管理。可以在通过一个地方私下和公开地管理和共享项目二进制文件。现在，开发人员可以从其源代码，CI/CD管道以及生成的程序包都可以通过NuGet来交互管理，从而以更少的精力更快地完成工作。
为了支持正在计划大量相关工作并在团队的多个里程碑，冲刺和迭代中对其进行管理的用户，新版本将为高级客户发布单级Epics。
启动一个Epic，创建和添加相关问题，设置开始日期和截止日期，并使用拖放Epic Tree快速组织它。
明确定义问题依存关系变得更加容易。新版本中可以将问题标记为已阻止或被其他问题阻止。通过这种新的依赖关系构造，现在比以往任何时候都更容易理解可能需要额外关注的问题（被阻止），或者识别将产生高回报的问题（被阻止）！由于现在可以表示团队之间的依存关系，因此协作效率也得到了提高。
给定工作流程阶段中进行的问题越多，完成任何给定问题所花费的时间就越长。进行看板的团队通常使用进行中的工作（WIP）限制，这是提高吞吐量的一种行之有效的方法。
从12.8版本开始，可以根据发行版中每个列表的最大发行量来设置WIP限制。如果超出限制，列表背景颜色将变为红色。
被阻止的问题需要注意。在查看问题面板时能够区分哪些问题被阻止，这样可以快速确定确定团队进度的瓶颈。消除任务进展的障碍，从而提高团队的效率比。
新版本中，可以对环境设置到期时间，以在特定的空闲时间后自动停止。这对于短暂的环境（例如用于Review Apps的环境）特别有用，可以避免浪费资源。设置在主配置文件.gitlab-ci.yml文件，格式为auto_stop_in: 1 week。也支持在GitLab UI中覆盖该设定。用户还可以通过UI固定其特定环境并保持该环境的运行（无论该设置如何）来禁用自动停止。
通过防止出现许多陈旧环境的情况，不会通过保持基础结构资源的运行而浪费它们。还将获得回退的开发时间，否则这些时间将花费在手动停止环境上。
网页和应用程序的可访问性已成为当今软件开发人员日益关注的问题。然而，其可访问性测试通常是在软件开发过程的后期的问题。如果提前完全完成，通常这是一个手动且不一致的过程。开发团队通常缺乏产品经理或产品设计师的明确要求，概述了构建应用程序时要遵循的可访问性标准。
从GitLab 12.8开始，可以在Review App中自动扫描并获得有关可访问性问题的报告。通过使可访问性问题的反馈回路更加紧密，从而节省了开发时间，因此可以最大程度地影响所有用户对应用程序的访问。
支持为每个合并请求下载报告。
现在，可以指定项目中的作业依赖于另一个管道中的作业所产生的最新工件，这使得设置彼此之间具有工件依赖关系的跨项目管道变得更加容易。
例如，可能需要构建可执行二进制文件的管道。在此之前，即使库没有更改，也必须在每次构建二进制文件时都重新构建二进制文件所依赖的所有库。这样会有大量时间和算力的浪费，并且还需要使用API密钥，cURL和安全变量的脆弱组合来进行变通。
新版本中，可以通过needs: 工作中指定artifacts: true，就可通过拉库管道所产生的镜像，并最终可执行的管道可用，而不需要重建。
代码审查是每个成功项目的基本做法，并且可以使用批准规则来确保合适的人员审查每个更改。在练习连续交付或从事较高风险的项目时，这一点尤其重要。以前，添加更多限制性批准要求以保护默认分支将对每个分支施加相同的要求。这迫使所有合并请求都满足相同的批准要求，无论是将错误修复程序合并master到发行分支还是两个功能分支之间。
GitLab 12.8通过在在项目级别设置的合并请求批准规则可以根据合并请求的目标分支有选择地要求来解决这个问题。这样允许限制性批准规则准确地在需要时应用，甚至允许将不同的批准规则应用于不同的分支（例如稳定版本分支）。
Git存储库中的每个提交都有一个作者，但是没有经过Git的验证，这意味着创建看起来是由其他人创作的提交很容易。提交签名可以用来对提交者验证。这对于敏感项目和某些商业环境非常重要。
在Git 2.19中，OpenGPG签名和验证支持已扩展为包括使用X.509证书的S / MIME支持，对于大型组织而言，管理这些证书将更为友好。
新版本中引入了新的实例级设置，通过将项目设置中的某些合并请求批准设置放入"管理区域"，以防止不必要的更改来合并请求批准设置。这将使管理员更好地控制其部署，并允许他们在部署代码时保持职责分离。
通过在实例级别启用这些设置，将强制自我管理实例中的所有项目采用这些设置，只有管理员才能为单个项目更改它们。这项新的强制执行功能可确保只有经过批准的部署才能投入生产，并使GitLab项目进入更合规的状态。
调查显示，用户需要导航到Package Registry UI，以验证使用哪个版本的软件包或验证其管道是否正确构建了该版本。由于没有在用户界面中显示有关软件包构建方式的任何信息，因此用户被迫需要在应用程序的多个不同区域之间切换。
在GitLab 12.8， GitLab管道构建将显示pipeline_id，branch以及commit在包注册表的用户界面。这将帮助用户了解软件包的构建方式，并在出现问题时更轻松地进行故障排除！
到目前为止，为受保护环境配置访问级别的用户需要通过"设置" UI（而非CLI）更新开发者和维护者权限。对于想要从命令行工作并需要在组之间维持相同级别的环境访问的用户而言，这效率不高。
在新版本中，维护人员可以在使用API添加或删除对受保护环境的访问时节省时间，而不是在"设置" UI中拥有更新权限。
尽管可以配置.gitlab-ci.yml文件，新版本在环境页面增加了Enable Review Apps按钮以提高便捷性；如果使用Kubernetes，并且要启用Review Apps，需要到.gitlab-ci.yml中的YAML代码段启用。
指定一个空needs:数组可用于向GitLab指示该作业没有前身，并且无论它处于什么阶段，它都可以立即开始。可以使用它在DAG管道中建立更灵活的关系，加快速度并提高效率。
Geo仅在高级和终极层可用。以前，当尝试使用Starter或Core许可证在管理员界面中启用Geo时，会显示该许可证无效或者不太有用。新版本中提供了一条更清晰的消息，指出正在使用哪个许可证，使用Geo需要哪个许可证，并且还提供了一个链接来管理许可证。
为了提高自建实例和Gitlab在线仓库组的可见性，在新版本中，添加了管理员操作来创建，阻止或删除用户，并在自建实例日志中增加了用户名更改事件。
这些新的审核事件将帮助注重合规性的组织保持职责分离，访问管理和不可否认性。
度量标准图表上的y轴值以前总是从零开始。这使用户难以检测到度量标准图表上的细微变化。从12.8版开始，y轴值将根据数据自动缩放。
当有许多特定环境时，它们可能会变得很麻烦。现在，通过下拉菜单中的新搜索栏，可以在指标仪表板中快速找到想要查看的环境。
在可视化指标时，用户通常喜欢为不同的指标选择不同类型的可视化。为了帮助实现这一目标，新版本在监视仪表板上添加了柱形图作为新的可视化选项，以便按需显示数据。
有一个已知的Docker问题，其中具有绝对URI的所有请求的基于Ceph的存储都会影响Docker垃圾回收过程。由于DigitalOcean中使用Ceph，因此用户使用DigitalOcean进行存储，它将阻止用户运行垃圾回收。这导致这些用户的存储成本更高。
在GitLab 12.8中，通过更新Ceph的驱动程序以支持最新版本的API来解决了该问题。这使使用DigitalOcean进行GitLab容器注册表存储的任何组织都可以运行垃圾收集并降低其存储成本。
默认情况下，从GitLab服务台发送的电子邮件来自GitLab Support Bot。很多时候，问题的发起者不经意会向GitLab发送电子邮件，这令人困惑。
现在可以为Service Desk用户配置名称。这样可为用户提供与品牌相匹配的可识别名称。
使用GitLab CI / CD安装Kubernetes应用程序是一种在安装前自定义应用程序的好方法。
在GitLab 12.8中，新模板可用于使用GitLab CI/CD 安装JupyterHub和Elastic Stack。通过GitLab CI/CD安装应用程序将另外启用版本控制和对已安装图表的访问控制。
随着Knative接近1.0版，由于尚未解决Knative升级过程中的许多问题，许多GitLab用户需要构建Knative的旧版本。出现问题是因为gitlabktl API更改导致的新版本仅支持特定版本的Knative。由于GitLab Serverless位于Alpha中，因此选择不提供向后兼容性。
解决此问题的方法是使用的固定版本gitlabktl。尽管这一直是可能的，但要弄清楚却并非易事。新版本文档中添加了一组清晰的说明，以帮助发现和执行。
长期以来，GitLab支持替代语法突出显示主题，以供在代码审查过程中浏览存储库中的文件或查看差异时使用。但是代码编辑器区域不支持使用此首选项，尽管这是Web IDE最需要的功能。
Web IDE现在在代码区域中支持Dark语法突出显示首选项。从该主题开始，将继续扩展对Web IDE中语法突出显示首选项的支持。深色主题将会扩展到Web IDE的其余部分，包括文件树和侧边栏。
管道的建立涉及大量Docker镜像构建，但是，其中许多镜像仅在需要存在很短的。此前，还必须依靠通过Container Registry API或使用用户界面删除镜像。
在12.8中，为所有新项目引入Docker标签过期策略。这项新功能使用户可以按名称识别标签，选择保留标签的版本以及定义何时应删除标签。例如，可以设置一个策略，该策略将删除所有与策略正则表达式（如Git SHA）匹配的标记名称，始终保留至少五张图像，并删除任何30天以上的图像。
Geo通过将数据复制到本地Geo节点来帮助分布式团队，并且还用于灾难恢复。如今，Geo尚不支持 GitLab的某些功能。比如开箱即用的所有即将发布的功能。为了实现这些功能的支持，方便GitLab社区中的开发人员更轻松地贡献需要复制和验证的新数据类型。通过标准化了Geo中使用的技术流程，以将Geo扩展到GitLab的其他部分，并且将为GitLab开发人员社区奠定坚实的技术基础，以为Geo的未来功能和改进做出贡献。有效地，未来的开发工作将更快，更高效。在12.8版本中，合并了重要的打包文件第一次迭代，从而为这项工作奠定了技术基础。在下一次迭代中，将添加对包文件复制和验证的支持。
为了验证其NPM软件包已上传或查找软件包的正确版本，用户希望使用软件包元数据。NPM标签可用于提供别名而不是版本号，从而使查找包变得更容易。例如，一个项目可能会选择有发展的多个数据流，并使用不同的标签为每个数据流，如stable，beta，dev，或canary。
在GitLab 12.8中，可在GitLab NPM注册表中支持NPM分发标签。可以支持添加，删除和列出与注册表中托管的任何程序包关联的标签，从而更快，更轻松地查找和发现程序包。
扩展了新规则语法，现在可以定义允许失败的管道规则。这在设置工作行为时为用户提供了更大的灵活性，并使将其他项目迁移到更易于理解的新语法变得更加容易。
管道故障电子邮件中的日志长度已从10行增加到30行，这使得查看更多跟踪信息变得更加容易，并且更可能将完整的错误消息包含在电子邮件中。
应用程序中管理错误非常困难，无需记住在修复错误后也要关闭GitLab问题。解决相关Sentry错误后，GitLab问题现在自动关闭。它消除了额外的手动工作，并避免了哪些问题仍然存在的困惑。
以前，重复显示板仅包含默认指标。通过12.8中的这一新增强功能，现在在克隆支持自定义指标和默认指标的默认仪表板时，将包括自定义指标。
GitLab管理员现在可以使用一个新的基础项目来了解其GitLab实例的运行状况，该项目将添加到" GitLab实例管理员"组下。创建用于可视化和配置关键指标以监视GitLab实例。
对事件进行故障排除时，同时查看日志和指标很重要。新版本中在查看度量标准图表时，无需保留GitLab控制台，就可以在保留上下文的同时直接向下导航到日志浏览器。
GitLab容器注册表用户界面允许查看，发现和管理项目的镜像。问题在于，删除标签是GitLab上执行效果最差的操作，有些请求最多需要60秒才能完成。这导致页面加载时间变慢，并且支持请求的数量增加。
在GitLab 12.8中，此功能的性能提高了约70%。将大大改善页面加载时间和可靠性。
在问题的"设计"选项卡中查看设计时，可以在图像的任何区域上放置注释标记并附加注释。这对于进行兴趣点讨论非常有用。但是，由于提供了反馈并上传了新修订，因此有时需要将徽标移动到新位置。此版本允许拖动徽章，可以
拖放评论到徽章之后。或者将其他人的徽章移到合适的位置。
进行版式修订后，移动徽标以匹配新的设计。
当CI/CD作业部署到Kubernetes环境时，作业详细信息页面现在将显示用于该部署的Kubernetes命名空间。可以使用详细信息页面来验证工作负载是否已部署到正确的目的地。
Gitlab项目将变得更快。在GitLab 12.8中，当在目录之间浏览时，文件列表和提交数据将被更新，无需重新加载整个页面，减少了不必要的页面加载。
与空格相比，制表符不仅仅是某些选项的优先事项。对于使用制表符的人来说，正确的制表符宽度无关紧要。特别是对于制表符最常见的C和Go项目，重要的是，可以将制表符宽度配置为与本地首选项相匹配，以进行最佳的代码审查。
现在，GitLab提供了Tab宽度用户首选项，用于在Markdown中查看包括差异，CI日志和渲染代码块的代码时使用。
现在提供了安全漏洞的实例级视图。使用此仪表板可以查看所有组和项目中可能存在的安全问题的概述。
除了查看项目中的漏洞列表以及一段时间内的漏洞趋势之外，还可以查看所有组中按其安全报告字母等级分类的项目，以便快速决策哪个项目最需要注意。
合并请求（MR）是一种优雅而强大的变更管理工具，用于记录变更和批准。发布团队使用MR来跟踪部署，而基础架构团队则使用MR来实践GitOps。
此外，对于拥有特定公司政策来管理其运营以遵守合规性框架（例如SOC 2，ISO 27001，GDPR，SOX，HIPAA或PCI-DSS）的组织而言，跟踪所有MR活动对于组织而言至关重要。规范其运营的公司政策。
政策合规治理一些用例包括：
所有MR都有一个相关的问题，其中包含有关更改的详细信息；
所有MR均由非作者审核和批准；
所有MR均通过质量检查和安全测试；
所有MR都有一个相关的问题，其中包含有关更改的详细信息；
所有MR均由非作者审核和批准；
所有MR均通过了质量检查和安全测试；
要求的任何例外都需要单独批准。
以前，GitLab用户缺少有效管理其GitLab环境的变更管理和合规性的必要工具。项目级别的活动仅限于单个项目，没有简单的方法可以在组级别查看这些信息。缺乏控制力和洞察力增加了潜在风险，降低了用户在GitLab中管理合规性的能力。
遵守法规的组织需要可见性。随着将更多的组，项目和用户添加到GitLab，这变得更加困难，这可能使得难以适当地管理风险和合规性。
在GitLab 12.8中，新添加了一个组级别的仪表板，给组所有者一个合规性意见，重点是汇总组中每个项目的所有最新合并请求（已批准和合并）。群组所有者可以查看其所有合并请求活动，并在必要时采取措施。
Gitlab 12.8新添加了强大的合规性管理—— 合规性仪表板，该仪表板提供了对组中每个项目的最新合并请求的视图。目前可用的功能，可以实现一处管理发布和GitOps的代码更改审核。同样，这使注重合规性的组织更容易快速了解哪些项目可能面临更大的风险，因此需要格外注意。
新版本中实现对Container Network Security的初步支持，可以帮助用户防止横向安全攻击。现在，可以在由GitLab管理的Kubernetes群集中配置网络策略，以限制Kubernetes Pod之间的通信。
网络策略可以控制Pod和Internet之间的通信，并且可以防止未经授权的Pod与同一Kubernetes集群中的其他Pod通信。在多应用程序群集中，此功能还支持不同应用程序之间的网络分段。
用户首次创建发布条目时，会在审核的情况下获取元数据的快照以作为证据。从12.8开始，将会在发布结束日期自动拍摄发布证据的其他快照。通过提供第二个快照，可以将发布的开始状态与其结束状态进行比较。这使审核团队可以更好地了解这两个时间点之间的变化。
新版本将支持对Golang模块依赖扫描。但该功能当前处于Alpha状态，数据库仅包含2019年及以后的Go Module漏洞定义。
要管理对GitLab组的访问权限，需要了解这些组中执行操作所使用的凭据。
在GitLab 12.8中，凭据清单从自建实例扩展到了GitLab。现在，组管理帐户的所有者可以查看其组中存在的SSH凭据和个人访问令牌。清单会显示用户，凭证类型和到期日期，以便可以做出有关访问和密码轮换的操作。
通过使用最新的漏洞来不断更新漏洞数据库，确保GitLab的扫描仪始终扫描到最新的漏洞，从而保护安全。
2020年2月，对已知漏洞，在漏洞发布后的2.2天内将其添加到了数据库中。
Omnibus GitLab新版本中包括PostgreSQL 11作为PostgreSQL的可选版本。GitLab 12.8包含Mattermost 5.19，这是开源的Slack-alternative。此版本的Mattermost包括使用GitLab，一个Webex插件，在DigitalOcean上一键安装Mattermost的一键安装以及安全更新，从而加快了开发周期。
Omnibus GitLab软件包现在引入PostgreSQL 11。PostgreSQL 11发行版包括对分区的增强和其他性能改进，在GitLab 13.x中以此为基础来提高其整体速度和响应能力。PostgreSQL 11已通过Omnibus GitLab进行了完整的测试，以进行新安装和升级，包括HA配置。正在对Geo进行测试。
GitLab 12.8可以选择升级到PostgreSQL 11。有关升级的说明，请参阅升级说明。新安装和从9.6的自动升级仍将默认为PostgreSQL10。PostgreSQL 11将在GitLab 12.10中去除，而最低要求的PostgreSQL版本在GitLab 13.0中去除。
建议不使用Geo的实例的管理员尽早升级到PostgreSQL 11，以从性能改进中受益并为在GitLab 13.0中删除PostgreSQL 9.6和10.x做准备。
在GitLab 12.8的GitLab Omnibus中引入了Git 2.24的补丁版本，并改进了Git packfile的重用性。
当客户端获取或克隆客户端时，服务器通过尽可能重用现有的packfile来进行响应更加有效。这些改进实现了一种用于重用packfile的新的更智能的算法，该算法在提供克隆或获取的成本与生成的packfile的质量之间做出了更好的折衷。
GitLab Runner 也一并发布了12.8版本。主要亮点包括：
Kubernetes执行者应通过HostAliases公开服务
Bump Go至1.13.7
添加对X-GitLab-Trace-Update-Interval标头的支持
支持来自GitLab API的速率限制标头
更多信息，请参考可以在GitLab Runner更新文档。
在GitLab 12.8中，将在问题，项目，里程碑等方面性能都有了大幅度的改善。主要包括：
从用户通知设置中删除N + 1；
从Todos页面上删除Gitaly通话；
将外键约束添加到Epics表；
修复Blob搜索API降级；
ES索引字段长度的应用限制；
按截止日期和位置排序时优化问题搜索；
按重量排序时优化问题搜索；
合并请求，尤其是"更改"选项卡，是查看和讨论源代码的地方。以前，随着提议的更改变得更大，差异将缓慢加载，并且在完全加载之前无法读取。
在12.8中，文件更改列表会立即加载，并且差异会逐渐加载，因此几乎可以立即开始阅读差异，而不必等待页面完全加载。
GitLab 12.8对项目的导入和导出进行了重大改进，从而大大缩短了执行时间并提高了可靠性。
新版本中项目导出的完成速度提高了四倍，内存占用量减少80%。以前，大型项目可能会由于超出导出作业的内存限制而无法导出。新版本中，这些任务将有可能获得成功。
由于大大减少了数据库调用，项目导入速度提高了约50%。将来，还计划通过切换到以换行符分隔的JSON来减少导入所需的内存。
取决于磁盘上Git存储库中packfile的结构，克隆可能会占用大量CPU和内存，因为Git可能需要即时构建和压缩packfile。当大型存储库被同时克隆多次时（例如在并行CI管道中），可能会占用大量CPU和内存。但是，如果触发了packfile的重用，则Git不会立即构建响应，而是直接从磁盘流式传输packfile，从而消除了克隆中大多数CPU和内存的使用。
在GitLab 12.8中，当重新打包存储库时，将创建一个包含所有可访问分支和标签的增量岛核心，以便在克隆Git存储库时触发packfile重用。GitLab自动为活动存储库执行重新打包，但是也可以通过单击项目"常规设置"中的" 运行内务处理"来手动触发它们。注意，将浅克隆策略用于CI时，不会触发packfile重用。
对于在许多项目中构建许多图像的组织，删除旧的，未使用的图像和标签很重要。容器注册表垃圾回收需要很长时间才能运行，并且在此过程中会低效地消耗资源。这使得具有大型注册表的实例难以运行垃圾收集，并导致存储成本增加。
在GitLab 12.8中，对于使用S3进行存储的实例，垃圾收集的性能有了显着改善。这些改进优化了算法的mark和sweep阶段。通过对15,000张图片的测试，mark阶段从25分钟变为90秒。sweep阶段从20分钟变为3秒。
通过HTTP启用了对Git协议v2的支持。它先前在GitLab 11.4中支持，但由于Git 2.21之前的Git版本中的安全问题而被禁用。
开发人员每天要多次获取引用，以检查当前分支是否位于远程分支之后。Git协议v2是对Git 有线协议的主要更新，该协议定义了客户端（计算机）和服务器（GitLab）之间如何通信克隆，获取和推送。新的Wire协议提高了fetch命令的性能，并支持将来的协议改进。
此前，对提取命令的所有响应都包括存储库中所有引用的列表。例如，获取单个分支的更新（例如git fetch origin master）还将检索所有引用的完整列表。对于大型项目，这可能会超过100,000个引用和数十兆字节的数据。
Git 2.18.0支持新增加了对Git v2的支持。要启用v2，请运行git config --global protocol.version 2。
在运行垃圾回收以删除旧的未使用的映像时，用户经常会遇到一个问题，即由于Docker清单损坏而导致进程失败。要解决此问题，管理员必须手动从对象存储中删除损坏的文件，这很慢且存在风险。
在12.8中，任何损坏的清单都将作为垃圾收集过程的一部分被删除。如果在垃圾回收期间发现一个错误的链接文件（大小为零字节或校验和无效），而不是停止垃圾回收器，它将记录一条警告消息并忽略它。如果与无效链接文件相关的sweepBlob与另一个有效链接文件没有关联，则这些Blob 将在阶段中删除。此更新使垃圾收集过程更加可靠和高效。
Kubernetes 1.16删除了一些API，Auto DevOps中deploymentApiVersion设置的默认值extensions/v1beta1已经去除。
默认值将在GitLab 13.0中d更改为apps/v1。
变化日期： 2020年5月17日
为了利用PostgreSQL 11中改进的性能和功能（例如分区），计划在GitLab 13.0中要求PostgreSQL的最低版本为11。为此，12.8中开始支持PostgreSQL 11，并在Omnibus 版本中自带PostgreSQL 11。目前还支持和打包了PostgreSQL 9.6和10.x，将在GitLab 13.0中删除。
通过要求最低版本的PostgreSQL 11，可以使用其最新功能，而无需维护多套代码版本。未来，Gitlab将保持每年一次的PostgreSQL升级节奏，要求的最低版和最新版本差不超过二。
变化日期： 2020年5月22日
GitLab Runner 13.0中，Go v1.10.8将删除向后移植的os.Expand。以包括Go v1.11中引入的行为更改。
删除日期： 2020年5月22日
GitLab Runner 13.0中，将恢复为使用默认的TOML解析器。
变化日期：2020年5月22日
GitLab Runner 13.0中，将删除11.10中引入的旧版构建目录缓存功能标志。
删除日期： 2020年5月22日
GitLab Runner 13.0中，将支持用于为使用字符串数组定义Docker服务的旧配置结构。
变化日期： 2020年5月22日
GitLab Runner 13.0中，将删FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL对shell执行程序标志的支持。
删除日期： 2020年5月22日
GitLab Runner 13.0中，将删除/debug/jobs/list?v=1用于监视的接口。用/debug/jobs/list?v=2取代。
变化日期： 2020年5月22日
在GitLab 11.11中，将不建议将Windows Batch执行程序用于GitLab Runner。在GitLab 13.0中将删除对Windows Batch的支持。
变化日期： 2020年5月22日
下一个小版本中将使用Debian slim作为Python依赖关系扫描的基础图像。通过更改基础镜像来增强对Python的支持。改用Debian slim后，扫描仪将支持更多的Python项目。
由于镜像不再是Alpine Linux，因此apk add
变化日期： 2020年3月22日
Gitlab UX团队发现，用于"严重性和信心"的术语相似但不相同，这导致了很多混乱。在Secure中，将弃用undefinedSecurity Reports（JSON）和漏洞API中的Severity和Confidence属性。
如果正在漏洞API中搜索或期望undefined作为过滤器值，则可以改用。
变化日期： 2020年5月22日
GitLab许可管理在GitLab 13.0中将重命名为GitLab许可合规性。经过用户和分析师的审查，确定这个新名称可以更好地表明该功能的用途，并与现有市场术语保持一致，并减少与GitLab订阅许可功能的混淆。可以在Epic中将许可证管理重命名为许可证合规性中找到有关此问题的研究和工作。作为许可证合规性一部分进行的项目分析将称为许可证扫描。
从GitLab 12.8开始，那些使用许可证合规性提供的模板的人可能会开始使用License-Scanning.gitlab-ci.yml而不是License-Management.gitlab-ci.yml。GitLab 13.0版本的发布后，License-Management.gitlab-ci.yml将被删除，并且使用License Compliance。供应商模板的GitLab 13.0或更高版本上的所有用户都必须使用License-Scanning.gitlab-ci.yml。
如果直接引用作为"许可证合规性"的一部分运行的"许可证扫描"的结果，则还需要使用新的报告类型artifacts:reports:license_scanning代替artifacts:reports:license_management。
变化日期： 2020年5月22日
Omnibus安装的自建实例可以使用包管理器一键升级。
对于CentOS可以使用
sudo yum updata/install gitlab-ce
会自动完成升级过程。
先停止和删除旧的容器
sudo docker stop gitlab
sudo docker rm gitlab
拉取gitlab官方最新的镜像：
sudo docker pull gitlab/gitlab-ce:latest
重新启动容器（启动参数和以前保持一致）即可，比如:
sudo docker run --detach
--hostname gitlab.example.com
--publish 443:443 --publish 80:80 --publish 22:22
--name gitlab
--restart always
--volume /srv/gitlab/config:/etc/gitlab
--volume /srv/gitlab/logs:/var/log/gitlab
--volume /srv/gitlab/data:/var/opt/gitlab
gitlab/gitlab-ce:latest
直接通过：
docker-compose pull
docker-compose up -d
页面更新：2024-05-26
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号
