文韬武略的专栏

在 GitLab 项目或 Group 的 Settings → CI/CD → Variables 中添加以下内容：KEYSTORE_BASE64：将 .keystore 文件转成 base64 字符串后存储KEY_ALIAS⚠️：这些变量需要设置为 “Protected” 且 “Masked”，确保不会被打印在日志中。你可以使用命令行工具将 .keystore 文件转换成 base64 字符串，非常简单。以下是在 Windows、macOS、Linux 下的操作方法。

打开 Runner 的配置文件（通常位于 /etc/gitlab-runner/config.toml 或 ~/.gitlab-runner/config.toml）。如果发现 limit 被设置为 1，可以重新注册 Runner 或修改 config.toml 删除该限制。如果使用 docker executor，可以调整 concurrent 并确保 Docker 有足够资源。如果使用 shell executor，确保 Runner 所在机器的 CPU 和内存足够支持多个任务。

最近在死磕 Gitlab CI/CD，遇到的问题实在是多，还好现在都有各种 AI 了，不然真是难顶。

随着模块化集成度越来越高，公司的 App 产品越来越多，为了避免不断的复制粘贴代码，有必要将一些功能模块集成起来，直接引入到需要的模块中，减少代码的维护成本。我们可以通过在 GitLab CI 中，使用 CI/CD 任务，在创建 tag 版本时自动上传 Android Library 到 Maven 私有仓库。

在Android应用中接入Sentry可以帮助你捕获和监控应用中的错误和异常。Sentry 是一个开源的错误跟踪工具，支持多种平台，包括 Android。特别是能够私有化部署。

各个 IDE 不是都有格式化工具吗？为什么要使用 Spotless 呢？开发团队中，成员可能有不同的编码习惯，例如缩进方式、空格数量、行尾格式等。这会导致代码风格不统一，影响代码的可读性和维护性。Spotless 提供了一种自动化的方式，统一格式化代码，避免手动调整。通过 Spotless，可以根据团队规范强制执行一致的代码风格，减少代码审查中的无关问题。手动格式化代码会浪费开发时间，尤其是当团队规模较大时。Spotless 在构建或提交代码时自动运行格式化规则，无需开发者手动调整。

通过配置 lint.xml 文件，你可以自定义 Lint 的检查规则，并使其适应项目的需求。常见的 Lint 规则包括资源检查（未使用的资源、硬编码文本）、安全问题（不安全的 Intent）以及性能问题（日志记录等）。根据项目的具体需求，合理启用或禁用这些规则有助于提升代码质量。

Android开发过程中持续集成是一项非常重要和必要的工作。持续集成指的是通过自动化的方式将开发、测试和部署过程整合在一起，实现代码的自动构建和测试，并快速反馈给开发人员，从而加快软件开发周期，提高软件质量和稳定性。以下是持续集成的重要性和必要性：提高开发效率和质量：持续集成可以自动构建和测试代码，快速检测出问题，并及时反馈给开发人员，这样可以减少手动测试的工作量，提高效率和质量。降低错误率：持续集成可以避免由于手动构建和测试过程中的疏忽而引入错误，保证了代码的准确性和可靠性，降低了错误率。