mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge pull request #5969 from Snapcrafter/master
[Translated] 20161115 Making your snaps available to the store using snapcraft.md
This commit is contained in:
Chang Liu
GitHub
commit
cc9e8ef100
@ -1,177 +0,0 @@
|
|||||||
[Translating by Snapcrafter]
|
|
||||||
Making your snaps available to the store using snapcraft
|
|
||||||
============================================================
|
|
||||||
|
|
||||||
### Share or save
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Now that Ubuntu Core has been officially released, it might be a good time to get your snaps into the Store!
|
|
||||||
|
|
||||||
**Delivery and Store Concepts **
|
|
||||||
So let’s start with a refresher on what we have available on the Store side to manage your snaps.
|
|
||||||
|
|
||||||
Every time you push a snap to the store, the store will assign it a revision, this revision is unique in the store for this particular snap.
|
|
||||||
|
|
||||||
However to be able to push a snap for the first time, the name needs to be registered which is pretty easy to do given the name is not already taken.
|
|
||||||
|
|
||||||
Any revision on the store can be released to a number of channels which are defined conceptually to give your users the idea of a stability or risk level, these channel names are:
|
|
||||||
|
|
||||||
* stable
|
|
||||||
|
|
||||||
* candidate
|
|
||||||
|
|
||||||
* beta
|
|
||||||
|
|
||||||
* edge
|
|
||||||
|
|
||||||
Ideally anyone with a CI/CD process would push daily or on every source update to the edge channel. During this process there are two things to take into account.
|
|
||||||
|
|
||||||
The first thing to take into account is that at the beginning of the snapping process you will likely get started with a non confined snap as this is where the bulk of the work needs to happen to adapt to this new paradigm. With that in mind, your project gets started with a confinement set to devmode. This makes it possible to get going on the early phases of development and still get your snap into the store. Once everything is fully supported with the security model snaps work in, this confinement entry can be switched to strict. Given the confinement level of devmode this snap is only releasable on the edge and beta channels which hints your users on how much risk they are taking by going there.
|
|
||||||
|
|
||||||
So let’s say you are good to go on the confinement side and you start a CI/CD process against edge but you also want to make sure in some cases that early releases of a new iteration against master never make it to stable or candidate and for this we have a grade entry. If the grade of the snap is set to devel the store will never allow you to release to the most stable channels (stable and candidate). not be possible.
|
|
||||||
|
|
||||||
Somewhere along the way we might want to release a revision into beta which some users are more likely want to track on their side (which given good release management process should be to some level more usable than a random daily build). When that stage in the process is over but want people to keep getting updates we can choose to close the beta channel as we only plan to release to candidate and stable from a certain point in time, by closing this beta channel we will make that channel track the following open channel in the stability list, in this case it is candidate, if candidate is tracking stable whatever is in stable is what we will get.
|
|
||||||
|
|
||||||
**Enter Snapcraft**
|
|
||||||
|
|
||||||
So given all these concepts how do we get going with snapcraft, first of all we need to login:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft login
|
|
||||||
Enter your Ubuntu One SSO credentials.
|
|
||||||
Email: sxxxxx.sxxxxxx@canonical.com
|
|
||||||
Password: **************
|
|
||||||
Second-factor auth: 123456
|
|
||||||
```
|
|
||||||
|
|
||||||
After logging in we are ready to get our snap registered, for examples sake let’s say we wanted to register awesome-database, a fantasy snap we want to get started with:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft register awesome-database
|
|
||||||
We always want to ensure that users get the software they expect
|
|
||||||
for a particular name.
|
|
||||||
|
|
||||||
If needed, we will rename snaps to ensure that a particular name
|
|
||||||
reflects the software most widely expected by our community.
|
|
||||||
|
|
||||||
For example, most people would expect ‘thunderbird’ to be published by
|
|
||||||
Mozilla. They would also expect to be able to get other snaps of
|
|
||||||
Thunderbird as 'thunderbird-sergiusens'.
|
|
||||||
|
|
||||||
Would you say that MOST users will expect 'a' to come from
|
|
||||||
you, and be the software you intend to publish there? [y/N]: y
|
|
||||||
|
|
||||||
You are now the publisher for 'awesome-database'
|
|
||||||
```
|
|
||||||
|
|
||||||
So assuming we have the snap built already, all we have to do is push it to the store. Let’s take advantage of a shortcut and –release in the same command:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft push awesome-databse_0.1_amd64.snap --release edge
|
|
||||||
Uploading awesome-database_0.1_amd64.snap [=================] 100%
|
|
||||||
Processing....
|
|
||||||
Revision 1 of 'awesome-database' created.
|
|
||||||
|
|
||||||
Channel Version Revision
|
|
||||||
stable - -
|
|
||||||
candidate - -
|
|
||||||
beta - -
|
|
||||||
edge 0.1 1
|
|
||||||
|
|
||||||
The edge channel is now open.
|
|
||||||
```
|
|
||||||
|
|
||||||
If we try to release this to stable the store will block us:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft release awesome-database 1 stable
|
|
||||||
Revision 1 (devmode) cannot target a stable channel (stable, grade: devel)
|
|
||||||
```
|
|
||||||
|
|
||||||
We are safe from messing up and making this available to our faithful users. Now eventually we will push a revision worthy of releasing to the stable channel:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft push awesome-databse_0.1_amd64.snap
|
|
||||||
Uploading awesome-database_0.1_amd64.snap [=================] 100%
|
|
||||||
Processing....
|
|
||||||
Revision 10 of 'awesome-database' created.
|
|
||||||
```
|
|
||||||
|
|
||||||
```
|
|
||||||
Notice that the version is just a friendly identifier and what really matters is the revision number the store generates for us. Now let’s go ahead and release this to stable:
|
|
||||||
```
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft release awesome-database 10 stable
|
|
||||||
Channel Version Revision
|
|
||||||
stable 0.1 10
|
|
||||||
candidate ^ ^
|
|
||||||
beta ^ ^
|
|
||||||
edge 0.1 10
|
|
||||||
|
|
||||||
The 'stable' channel is now open.
|
|
||||||
```
|
|
||||||
|
|
||||||
In this last channel map view for the architecture we are working with, we can see that edge is going to be stuck on revision 10, and that beta and candidate will be following stable which is on revision 10\. For some reason we decide that we will focus on stability and make our CI/CD push to beta instead. This means that our edge channel will slightly fall out of date, in order to avoid things like this we can decide to close the channel:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft close awesome-database edge
|
|
||||||
Arch Channel Version Revision
|
|
||||||
amd64 stable 0.1 10
|
|
||||||
candidate ^ ^
|
|
||||||
beta ^ ^
|
|
||||||
edge ^ ^
|
|
||||||
|
|
||||||
The edge channel is now closed.
|
|
||||||
```
|
|
||||||
|
|
||||||
In this current state, all channels are following the stable channel so people subscribed to candidate, beta and edge would be tracking changes to that channel. If revision 11 is ever pushed to stable only, people on the other channels would also see it.
|
|
||||||
|
|
||||||
This listing also provides us with a full architecture view, in this case we have only been working with amd64.
|
|
||||||
|
|
||||||
**Getting more information**
|
|
||||||
|
|
||||||
So some time passed and we want to know what was the history and status of our snap in the store. There are two commands for this, the straightforward one is to run status which will give us a familiar result:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft status awesome-database
|
|
||||||
Arch Channel Version Revision
|
|
||||||
amd64 stable 0.1 10
|
|
||||||
candidate ^ ^
|
|
||||||
beta ^ ^
|
|
||||||
edge ^ ^
|
|
||||||
```
|
|
||||||
|
|
||||||
We can also get the full history:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ snapcraft history awesome-database
|
|
||||||
Rev. Uploaded Arch Version Channels
|
|
||||||
3 2016-09-30T12:46:21Z amd64 0.1 stable*
|
|
||||||
...
|
|
||||||
...
|
|
||||||
...
|
|
||||||
2 2016-09-30T12:38:20Z amd64 0.1 -
|
|
||||||
1 2016-09-30T12:33:55Z amd64 0.1 -
|
|
||||||
```
|
|
||||||
|
|
||||||
**Closing remarks**
|
|
||||||
|
|
||||||
I hope this gives an overview of the things you can do with the store and more people start taking advantage of it!
|
|
||||||
|
|
||||||
[Publish a snap][2]
|
|
||||||
|
|
||||||
--------------------------------------------------------------------------------
|
|
||||||
|
|
||||||
via: https://insights.ubuntu.com/2016/11/15/making-your-snaps-available-to-the-store-using-snapcraft/
|
|
||||||
|
|
||||||
作者：[Sergio Schvezov ][a]
|
|
||||||
译者：[译者ID](https://github.com/译者ID)
|
|
||||||
校对：[校对者ID](https://github.com/校对者ID)
|
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|
||||||
|
|
||||||
[a]:https://insights.ubuntu.com/author/sergio-schvezov/
|
|
||||||
[1]:https://insights.ubuntu.com/author/sergio-schvezov/
|
|
||||||
[2]:http://snapcraft.io/docs/build-snaps/publish
|
|
||||||
@ -0,0 +1,175 @@
|
|||||||
|
使用 snapcraft 将 snap 包发布到商店
|
||||||
|
|
||||||
|
==================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
现在 Ubuntu Core 已经正式发布，也许是时候让你的 snap 包进入商店了!
|
||||||
|
|
||||||
|
### 交付和商店的概念
|
||||||
|
|
||||||
|
首先回顾一下我们是怎么通过商店管理 snap 包的吧。
|
||||||
|
|
||||||
|
每次你上传 snap 包，商店都会为其分配一个修订版本号，并且商店中针对特定 snap 包 的版本号都是唯一的。
|
||||||
|
|
||||||
|
但是第一次上传 snap 包的时候，我们首先要为其注册一个还没有被使用的名字，并且这很容易去做。
|
||||||
|
|
||||||
|
商店中所有的修订版本都可以释放到多个通道中，这些通道只是概念上定义的，以便给用户一个稳定或风险等级的参照，这些通道有:
|
||||||
|
|
||||||
|
* 稳定
|
||||||
|
|
||||||
|
* 候选
|
||||||
|
|
||||||
|
* 测试
|
||||||
|
|
||||||
|
* 边缘
|
||||||
|
|
||||||
|
理想情况下，如果我们设置了 CI/CD 过程，那么每天或在每次更新源码时都会将其推送到边缘通道。在此过程中有两件事需要考虑。
|
||||||
|
|
||||||
|
首先在开始的时候，你最好制作一个不受限制的 snap 包，因为在这种新范例下，snap 包的大部分功能都能不受限制地工作。考虑到这一点，你的项目开始时 confinement （LCTT注：snapcraft.yaml 中的一个键）将被设置为 devmode（LCTT注：snapcraft.yaml 中 confinement 键的一个可选值）。这使得你在开发的早期阶段，仍然可以让你的 snap 包进入商店。一旦所有的东西都得到了 snap 包运行的安全模型的充分支持，那么就可以将 confinement 修改为 strict。
|
||||||
|
|
||||||
|
好了，假设你在限制方面已经做好了，并且也开始了一个对应边缘通道的 CI/CD 过程，但是如果你也想确保在某些情况下，早期版本 master 分支新的迭代永远也不会进入稳定或候选通道，那么我们可以使用 gadge （LCTT注：snapcraft.yaml 中的一个键）。如果 snap 包的 gadge 设置为 devel （LCTT注：snapcraft.yaml 中 gadge 键的一个可选值），商店将会永远禁止你将 snap 包释放到稳定和候选通道。
|
||||||
|
|
||||||
|
在这个过程中，我们有时可能想要发布一个修订版本到测试通道，以便让有些用户更愿意去跟踪它（一个好的发布管理流程应该比一个随机的日常构建更有用）。这个阶段结束后，如果希望人们仍然能保持更新，我们可以选择关闭测试通道来作为我们只计划发布到候选和稳定通道的一个的时间点。通过关闭测试通道我们将确保通道将沿着稳定列表中的开放通道走下去，在这种情况下是候选通道。如果候选通道跟踪稳定后，那么就可以发布到稳定通道了。
|
||||||
|
|
||||||
|
### 进入 Snapcraft
|
||||||
|
|
||||||
|
那么所有这些给定的概念是如何在 snapcraft 中配合使用的？首先我们需要登录:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft login
|
||||||
|
Enter your Ubuntu One SSO credentials.
|
||||||
|
Email: sxxxxx.sxxxxxx@canonical.com
|
||||||
|
Password: **************
|
||||||
|
Second-factor auth: 123456
|
||||||
|
```
|
||||||
|
|
||||||
|
在登录之后，我们就可以开始注册 snap 了。例如，我们想要注册一个虚构的 snap 包 awesome-database：
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft register awesome-database
|
||||||
|
We always want to ensure that users get the software they expect
|
||||||
|
for a particular name.
|
||||||
|
|
||||||
|
If needed, we will rename snaps to ensure that a particular name
|
||||||
|
reflects the software most widely expected by our community.
|
||||||
|
|
||||||
|
For example, most people would expect ‘thunderbird’ to be published by
|
||||||
|
Mozilla. They would also expect to be able to get other snaps of
|
||||||
|
Thunderbird as 'thunderbird-sergiusens'.
|
||||||
|
|
||||||
|
Would you say that MOST users will expect 'a' to come from
|
||||||
|
you, and be the software you intend to publish there? [y/N]: y
|
||||||
|
|
||||||
|
You are now the publisher for 'awesome-database'
|
||||||
|
```
|
||||||
|
|
||||||
|
假设我们已经构建了 snap 包，接下来我们要做的就是把它上传到商店。我们可以在同一个命令中使用快捷方式和 --release 选项：
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft push awesome-databse_0.1_amd64.snap --release edge
|
||||||
|
Uploading awesome-database_0.1_amd64.snap [=================] 100%
|
||||||
|
Processing....
|
||||||
|
Revision 1 of 'awesome-database' created.
|
||||||
|
|
||||||
|
Channel Version Revision
|
||||||
|
stable - -
|
||||||
|
candidate - -
|
||||||
|
beta - -
|
||||||
|
edge 0.1 1
|
||||||
|
|
||||||
|
The edge channel is now open.
|
||||||
|
```
|
||||||
|
|
||||||
|
如果我们试图将其发布到稳定通道，商店将会阻止我们：
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft release awesome-database 1 stable
|
||||||
|
Revision 1 (devmode) cannot target a stable channel (stable, grade: devel)
|
||||||
|
```
|
||||||
|
|
||||||
|
我们不会搞砸，也不会让我们的忠实用户使用它。现在，我们将最终推出一个值得发布到稳定通道的修订版本：
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft push awesome-databse_0.1_amd64.snap
|
||||||
|
Uploading awesome-database_0.1_amd64.snap [=================] 100%
|
||||||
|
Processing....
|
||||||
|
Revision 10 of 'awesome-database' created.
|
||||||
|
```
|
||||||
|
|
||||||
|
注意，版本号（LCTT注：这里指的是 snap 包名中 `0.1` 这个版本号）只是一个友好的标识符，真正重要的是商店为我们生成的修订版本号（LCTT注：这里生成的修订版本号为 `10`）。现在让我们把它释放到稳定通道:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft release awesome-database 10 stable
|
||||||
|
Channel Version Revision
|
||||||
|
stable 0.1 10
|
||||||
|
candidate ^ ^
|
||||||
|
beta ^ ^
|
||||||
|
edge 0.1 10
|
||||||
|
|
||||||
|
The 'stable' channel is now open.
|
||||||
|
```
|
||||||
|
在这个针对我们正在使用架构最终的通道映射视图中，可以看到边缘通道将会被固定在修订版本 10 上，并且测试和候选通道将会跟随现在修订版本为 10 的稳定通道。由于某些原因，我们决定将专注于稳定性并让我们的 CI/CD 推送到测试通道。这意味着我们的边缘通道将会略微过时，为了避免这种情况，我们可以关闭这个通道：
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft close awesome-database edge
|
||||||
|
Arch Channel Version Revision
|
||||||
|
amd64 stable 0.1 10
|
||||||
|
candidate ^ ^
|
||||||
|
beta ^ ^
|
||||||
|
edge ^ ^
|
||||||
|
|
||||||
|
The edge channel is now closed.
|
||||||
|
```
|
||||||
|
|
||||||
|
在当前状态下，所有通道都跟随着稳定通道，因此订阅了候选、测试和边缘通道的人也将跟踪稳定通道的改动。比如就算修订版本 11 只发布到稳定通道，其他通道的人们也能看到它。
|
||||||
|
|
||||||
|
这个清单还提供了完整的体系结构视图，在本例中，我们只使用了 amd64。
|
||||||
|
|
||||||
|
### 获得更多的信息
|
||||||
|
|
||||||
|
有时过了一段时间，我们想知道商店中的某个 snap 包的历史记录和现在的状态是什么样的，这里有两个命令，一个是直截了当输出当前的状态，它会给我们一个熟悉的结果:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft status awesome-database
|
||||||
|
Arch Channel Version Revision
|
||||||
|
amd64 stable 0.1 10
|
||||||
|
candidate ^ ^
|
||||||
|
beta ^ ^
|
||||||
|
edge ^ ^
|
||||||
|
```
|
||||||
|
|
||||||
|
我们也可以通过下面的命令获得完整的历史记录：
|
||||||
|
|
||||||
|
```
|
||||||
|
$ snapcraft history awesome-database
|
||||||
|
Rev. Uploaded Arch Version Channels
|
||||||
|
3 2016-09-30T12:46:21Z amd64 0.1 stable*
|
||||||
|
...
|
||||||
|
...
|
||||||
|
...
|
||||||
|
2 2016-09-30T12:38:20Z amd64 0.1 -
|
||||||
|
1 2016-09-30T12:33:55Z amd64 0.1 -
|
||||||
|
```
|
||||||
|
|
||||||
|
### 结束语
|
||||||
|
|
||||||
|
希望这篇文章能让你对商店能做的事情有一个大概的了解，并让更多的人开始使用它！
|
||||||
|
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
via: https://insights.ubuntu.com/2016/11/15/making-your-snaps-available-to-the-store-using-snapcraft/
|
||||||
|
|
||||||
|
***译者简介：***
|
||||||
|
> snapcraft.io 的钉子户，对 Ubuntu Core、Snaps 和 Snapcraft 有着浓厚的兴趣，并致力于将这些还在快速发展的新技术通过翻译或原创的方式介绍到中文世界。有兴趣的小伙伴也可以关注译者个人的公众号： `Snapcraft`，近期会在上面连载几篇有关 Core snap 发布策略、交付流程和验证流程的文章，欢迎围观 :）
|
||||||
|
|
||||||
|
|
||||||
|
作者：[Sergio Schvezov][a]
|
||||||
|
译者：[Snapcrafter](https://github.com/Snapcrafter)
|
||||||
|
校对：[校对者ID](https://github.com/校对者ID)
|
||||||
|
|
||||||
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||||
|
|
||||||
|
[a]:https://insights.ubuntu.com/author/sergio-schvezov/
|
||||||
|
[1]:https://insights.ubuntu.com/author/sergio-schvezov/
|
||||||
|
[2]:http://snapcraft.io/docs/build-snaps/publish
|
||||||
Loading…
Reference in New Issue
Block a user