Jenkins lockable-resources插件实际用途与场景示例说明

这个插件本质就是给Jenkins加了一套全局的资源排队锁机制，你可以把所有「不能同时被多个任务操作」的东西，不管是实体硬件还是逻辑上的配额/环境，都抽象成可锁定的资源，由插件统一调度谁能占用、谁要排队，从根源避免并发抢资源导致的各种问题。

先解答你好奇的「为什么资源列表里会有手机」 #

这根本不是什么奇怪的设计，移动端CI场景里实体测试机是最常用的锁对象之一：做自动化测试的时候，测试机是直接插在构建节点上的，一台手机同一时间只能装一个测试包、跑一套测试脚本，要是两个流水线任务同时往同一台手机上推包、调测试指令，不仅测试直接失败，还经常把手机上的测试环境搞挂，要人工重启恢复，当然需要加锁。

它到底锁什么，解决什么冲突 #

• 它不锁定Jenkins本身的任何内部组件，所有可锁的资源都是你自己定义的：你只需要在插件配置页给资源起个名字、设好总数量就行，插件不会实际操作你对应的硬件/环境，只负责做「占用-排队-释放」的调度。
• 解决的就是多个Jenkins任务并发操作同一个有限资源时，导致的任务失败、数据混乱、环境污染问题，锁的粒度可以细到你能想到的任意维度，比Jenkins自带的节点并发限制灵活得多。

几个最常见的实际使用场景 #

• 实体硬件外设类：就是官方举例的打印机、测试手机、专用测试工控机这类。比如接在构建节点上的标签打印机，两个任务同时触发打印的话，不同任务的标签内容会混打，出来的面单/标识全是错的，给打印机建个单独的锁资源，打印前先拿锁，打完自动释放，就不会出问题。
• 共享测试环境类：这是日常用得最多的场景，很多人以为这个插件只能锁硬件，其实80%的场景都是锁逻辑资源。比如你们团队只有一套集成测试环境的数据库，跑测试的时候会清空库、造专属测试数据，两个测试任务同时跑的话会互相改数据，两边的测试结果都不可信。你不需要去数据库层面做什么复杂配置，只要建一个名叫test-env-db的资源，所有跑集成测试的任务执行前先抢这个锁，抢到了才能操作数据库，跑完释放，问题直接解决。
• 配额限制类：比如你们云账号的弹性IP配额只有10个，或者第三方测试接口的并发调用上限是5次/分钟，你可以直接在插件里建对应数量的同名资源，每个需要占配额的任务拿一个资源，占满了就自动排队，从Jenkins层就把配额卡死，不会出现超配额导致的调用失败。

最基础的用法示例 #

声明式流水线里直接用lock步骤包裹需要独占资源的逻辑就行，出了代码块范围锁会自动释放，不需要手动写释放逻辑：

pipeline {
    agent any
    stages {
        stage('iOS自动化测试') {
            steps {
                // 申请1台空闲的iOS测试机，最多等待15分钟，超时则任务失败
                lock(resource: 'ios-test-*', quantity: 1, timeout: 15) {
                    // 只有成功拿到锁之后，才会执行下面的测试步骤
                    sh 'ideviceinstaller -i ./build/app.ipa'
                    sh 'xcodebuild test -destination "id=${LOCKED_RESOURCE_NAME}"'
                }
                // 执行到这里锁已经自动释放，其他排队的任务可以抢占资源
            }
        }
    }
}

注意别把这个插件和Jenkins自带的节点并发数配置搞混：节点并发数只能控制单台构建节点上同时跑多少个任务，如果你的资源是跨节点共享的（比如全团队共用的一套测试环境、网络打印机），或者单台节点上接了多个同类型资源（比如一台构建服务器插了8台测试手机），节点并发限制根本做不到这么细的粒度，这时候就必须用Lockable Resources来做调度。

内容的提问来源于stack exchange，提问作者gek