snapcraft构建、测试和发布Snap包，这是一个在Linux中争夺一席之地的包管理系统，它重新构想了您分发软件的方式。一组新的交叉分发工具可用于帮助您构建和分发snap包。接下来我们将介绍如何使用CircleCI2.0来加速这个过程，以及这个过程中可能遇到的一些问题。什么是快照包？什么是snapcraft？Snaps是Linux发行版的软件包，其设计吸取了在Android和物联网设备等移动平台上分发软件的经验教训。snapcraft这个名称包括快照和用于构建它们的命令行工具、这个snapcraft.io网站，以及几乎建立在这些技术之上的整个生态系统。snap包旨在隔离和封装整个应用程序。这些概念实现了snapcraft提高软件安全性、稳定性和可移植性的目标，其中可移植性允许单个snap包不仅可以安装在多个版本的Ubuntu中，还可以安装在Debian、Fedora和Arch等中。安装在发行版中。snapcraft网站对其的描述如下：为每个Linux桌面、服务器、云或设备打包任何应用程序，并直接交付更新。在CircleCI2.0上构建快照包在CircleCI上构建快照使用CircleCI2.0语法，其方式与在本地计算机上的方式大致相同。在本文中，我们将介绍一个示例配置文件。如果你是CircleCI的新手，或者想了解更多关于2.0入门的信息，你可以从这里开始。基本配置版本：2jobs:build:machine:trueworking_directory:~/projectsteps:-checkout-run:command:|sudoaptupdate&&sudoaptinstall-ysnapdsudosnapinstallsnapcraft--edge--classic/snap/bin/snapcraft本例使用machineexecutor安装Managessnapd，运行快照的可执行程序，以及制作快照的snapcraft工具。由于构建过程需要更新的内核，我们使用机器执行器而不是docker执行器。在这里，Linuxv4.4足以满足我们的需求。用户空间依赖上面的例子使用了机器可执行文件，它实际上是一个带有Linuxv4.4内核的Ubuntu14.04(Trusty)虚拟机。如果Trusty存储库可以满足您的项目/快照构建依赖性，那么就可以了。如果您的构建依赖项需要其他版本，例如Ubuntu16.04(Xenial)，我们仍然可以在机器执行器中使用Docker来构建我们的snap包。版本：2jobs:build:machine:trueworking_directory:~/projectsteps:-checkout-run:command:|sudoaptupdate&&sudoaptinstall-ysnapddockerrun-v$(pwd):$(pwd)-tubuntu:xenialsh-c"aptupdate-qq&&aptinlsnapcraft-y&&cd$(pwd)&&snapcraft”，我们再次在机器执行器的虚拟机中安装了snapd，但我们决定在从UbuntuXenial映像构建的Docker容器中安装snapcraft，并使用它来构建我们的snap。这样，在运行snapcraft时，Ubuntu16.04中所有可用的apt包都将可用。测试在我们的博客、文档和Internet上，有很多关于如何对软件代码进行单元测试的文章。搜索你的语言或框架和单元测试或CI以找到大量关于它的信息。在CircleCI上构建snap包，我们最终得到一个.snap文件，这意味着除了创建它的代码之外，我们还可以测试它。Workflow假设我们构建的snap包是一个webapp，我们可以使用测试套件来确保构建的snap可以正确安装和运行，我们也可以尝试安装它或者使用Selenium来测试页面加载，登录，等工作正常。但是这里有个问题，由于snap是为运行在多个Linux发行版上而设计的，这就需要我们的测试套件能够在Ubuntu16.04、Fedora25和Debian9等发行版上正常工作。我们可以通过CircleCI的工作流程有效解决这个问题2.0。在最近的CircleCI2.0beta中添加了工作流，并允许我们通过特定的逻辑流运行离散任务。这样，在用单个任务构建好snap之后，我们就可以开始并行运行snap的发布测试任务，每个任务对应不同发行版的Docker镜像（或者将来会有其他可用的执行器）。这是一个简单的例子：workflows:version:2build-test-and-deploy:jobs:-build-acceptance_test_xenial:requires:-build-acceptance_test_fedora_25:requires:-build-acceptance_test_arch:requires:-build-publish:requires:-acceptance_test_xenial-acceptance_test_fedora_25-acceptance_test_arch在本例中首先构建快照，然后在四个不同的发行版上运行验收测试。如果所有的发布测试都通过了，那么我们就可以运行发布作业来完成剩余的snap任务，然后再将其推送到snap存储。保留.snap包为了测试我们在工作流示例中使用的.snap包，我们需要一种在构建时保留snap的方法。在这里我会提供两种方法：artifact-我们可以在运行构建任务时将snaps保存为CircleCIartifact（LCTT译注：artifact是snapcraft.yaml中的Plugin-specific关键字），然后在下一个任务中检索它。CircleCI工作流有自己的方式来处理共享的工件，相关信息可以在这里找到。SnapStoreChannels-在将snap包发布到snapstore时，有几种渠道可供我们选择。将snap的master分支发布到边缘通道以供内部或用户测试已成为一种普遍做法。我们可以在构建任务中做这个，然后下一个任务可以从边缘通道安装构建的快照包。第一种方法更快，它还允许在将快照上传到用户甚至测试用户的快照存储之前对其进行验收测试。第二种方法的好处是我们可以从snapstore安装snap，这也是CI运行时的测试项目之一。snapstoreauthenticationsnapcraft-config-generator.py脚本可以生成一个storecertificate保存到.snapcraft/snapcraft.cfg（注意：运行public脚本前一定要勾选）。如果您觉得将此文件以明文形式存储在您的存储库中不安全，您可以对该文件进行base64编码并将其存储为私有环境变量，或者您可以加密该文件并将密钥存储在私有环境变量中。下面是一个将存储证书放在加密文件中并在部署阶段使用它来将snap发布到snap存储的示例。-deploy:name:PushtoSnapStorecommand:|opensslaes-256-cbc-d-in.snapcraft/snapcraft.encrypted-out.snapcraft/snapcraft.cfg-k$KEY/snap/bin/snapcraftpush*.snap除了部署任务,工作流示例与之前相同，部署任务只有在验收测试任务通过后才会运行。更多信息AlanPope的论坛帖子：“popey”是一名Canonical员工，他在snapcraft论坛上写了这篇帖子，并启发了作者写这篇博文。snapcraft网站：官方snapcraft网站。snapcraft的CircleCI错误报告：Launchpad上有一个开放的错误报告页面，用于改进CircleCI对snapcraft的支持。同时，它会让这个过程变得更简单、更“正式”。期待您的支持。HowtouseCircleCItobuildaNextcloudsnap：有一篇名为“ContinuousAcceptanceTestingforComplexApplications”的博文也影响了这篇博文。这篇客座文章由CircleCi的开发布道者RicardoFeliciano撰写。如果您也有兴趣做出贡献，请联系ubuntu-iot@canonical.com。原始文章可以在这里找到。
