gitlab是什么表,gitlab简介和使用

可以使用GitLab包注册表来发布、安装和共享依赖项。当发布依赖项时，会生成多个文件，包括包存档。在GitLab 14.0之前，要删除此类文件，必须使用API。GitLab 14.0 中，现在可以使用UI删除与给定包相关的文件以及包本身。

由于维护整洁的注册表可能具有挑战性，因此目标是通过添加更多关于如何删除未使用文件的选项，让流程更轻松、更高效。

在某些情况下，可能希望更改问题的类型。例如，可能希望将问题升级为事件，以确保团队正确处理问题。要更改问题的类型，请编辑问题并从问题类型选择器菜单中选择问题类型。

GitLab容器扫描现在可以选择使用Grype扫描引擎而非默认的Trivy引擎。这为用户提供了选择容器扫描引擎的灵活性和选择。对两款开源扫描仪进行了比较。但是，由于每台扫描仪都是独一无二的，可能希望自己进行比较以决定哪种扫描仪最适合。用户可以通过设 CI变量来试 Grype扫描仪：

CS_ANALYZER_IMAGE: registry.gitlab /security-products/container-scanning/grype:4。

随着散列存储的引入，将不好发现项目的存储位置。系统管理员能够在项目的管理UI上查找路径，但对于许多项目来说这样做是不切实际的。在新版本中，新添加了公开项目存储信息的API接口。在REST API中，这个接口是

GET /projects/:id/storage.

对GraphQL，该diskPath字段现在在Repository对象中可用。

同期还还发布了GitLab Runner 14.0。新功能包括：

Windows Runners下默认shell为pwsh；

引入Ubuntu风格的runner-helper镜像。

修复一些Bug：

PowerShell不能与FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY设置为 false一起使用;

在shell执行器中永久阻塞Go例程;

失败原因job_canceled可以发送给Rails，失败并返回 500 错误

Gitlab Runner无法解析GitlabURL-Kubernetes 执行器的bug。

GitLab 14.0 包括Mattermost 5.35.3。由于引入了即将推出的新功能所需的后端数据库架构，v5.35 版本的迁移过程的性能受到显著影响。根据数据库的大小、类型和版本，升级时间应该会比平时更长。这可能从几分钟（平均情况）到几小时（最坏情况，仅限 MySQL 5.x）不等。在此过程中，还应该预期数据库 CPU 使用率会出现中度显著峰值。v5.35.3 引入了搜索文件的新功能以及批量用户导入期间使用的密码生成逻辑的一些更改。管理员应立即重置批量导入过程中生成的所有用户的密码，并且其密码甚至一次都没有更改。v5.35.3 还包含高级安全修复，建议升级。

此前，新的GitLab 实例会在安装后默认提示用户输入初始root密码，这意味着匿名用户可以先到达那里设置root密码并进行控制。新版本中，如果用户未提供初始 root 密码，则会随机创建一个。这提高了新部署 GitLab实例的默认安全性。

Omnibus GitLab docker镜像中现在包含 BusyBox，但删除了作为预安装编辑器的vim和nano。BusyBox汇集了许多其他工具的最小版本，通过将BusyBox设为默认编辑器，可以获得许多在容器内部调试时有用的其他工具。

在 GitLab 13.12 及更早版本中，扫描中发现的所有DAS 漏洞都针对发现漏洞的单个URL列出。当修复为单个文件或配置更改时，这可能会产生许多漏洞。例如：每个HTTP响应一起发送的服务器标头的问题将在站点的每个页面上报告，而不是报告为多次出现的单个问题。

为了减少管理漏洞的开销，GitLab将在多个页面上发现的相同漏洞合并到 DAST 报告中的单个报告漏洞中。漏洞详细信息包括发现漏洞的所有URL的列表，而不是在每个页面的漏洞列表和仪表板中创建的单个漏洞。

新的报告功能不会追溯组合以前扫描中发现的漏洞。它仅适用于在 GitLab 14.0 及更高版本中执行的扫描。

添加到GitLab的过期SSH 密钥现在默认禁用。这将有助于使GitLab实例更加安全。以前，添加到GitLab的过期SSH密钥默认启用，除非管理员明确禁用，否则可以使用。

此更改会影响GitLab SaaS上使用的过期SSH密钥。如果密钥已过期或即将过期，需要更新密钥和使用它们的任何服务。我们关于SSH密钥的文档提供了有关如何创建新 SSH 密钥的有用步骤。

自建实例的管理员仍然可以配置允许使用过期的密钥。

自动安全扫描是任何安全开发过程的重要组成部分。有各种各样的工具和技术涵盖了从源代码扫描到部署后应用程序和基础设施扫描的整个SDLC。虽然这些工具中的任何一个的最终目标都是发现已知和潜在的漏洞，但来自任何给定扫描仪的信息可能会有很大差异。确实存在对扫描输出数据进行标准化的努力，但他们往往只关注一类扫描技术，甚至是一组特定的工具。这对需要汇总各种扫描仪发现的安全团队来说是一个巨大的挑战。如果没有统一的方法来标准化不同的发现，查看每个扫描仪输出的独特细节可能是非常麻烦。

GitLab安全报告模式中新的通用详细信息结构优化这个体验，可以轻松地将各种安全扫描器集成到GitLab中。现在，可以进一步使用丰富的格式选项来查找详细信息。新结构可以轻松地将大多数工具的现有输出映射到JSON报告格式，同时自动添加一致的呈现逻辑。在不牺牲提供丰富漏洞发现数据的能力的情况下的灵活性是新结构背后的主要目的。使用预定义数据类型在开放结构中提供详细信息。预定义的类型处理数据验证以及GitLab内的标准化UI呈现。例如，提供整数、URL、表格，甚至 GFM（GitLab Flavored Markdown）。这允许对如何呈现查找细节进行精细控制，同时保持 GitLab 内部的整体体验一致。