-
Notifications
You must be signed in to change notification settings - Fork 4
/
index.xml
3972 lines (3400 loc) · 543 KB
/
index.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Jenkins 中文社区</title>
<link>https://jenkins-zh.cn/</link>
<description>Recent content on Jenkins 中文社区</description>
<generator>Hugo -- gohugo.io</generator>
<language>zh-CN</language>
<lastBuildDate>Sat, 07 Sep 2019 00:00:00 +0000</lastBuildDate>
<atom:link href="https://jenkins-zh.cn/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>社区捐助</title>
<link>https://jenkins-zh.cn/about/sponsors-list/</link>
<pubDate>Sat, 07 Sep 2019 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/about/sponsors-list/</guid>
<description>社区得以持续、健康地发展，需要很多方面的支持，尤其对于社区的基础运营、活动组织上，资金和物资的捐助是非常重要的。
用途 对于所收到的资金、物资捐助，我们都会用于社区基础设施（域名、服务器等）、线下活动、社区成员奖励。
列表 为了对给予社区捐助的朋友们表示感谢，我们在此列出来：
捐助者 金额（单位：元） 日期 备注 shaw4fatty 19.2 2020-11-24 哔哩哔哩充电🔋 UCloud 2170 2020-04-04 2核2G 2M 80G系统盘 1年，地区北京，台数1台 霍格沃兹测试学院 10,000 2019-11-05 社区捐赠 geshujiang 100 2019-05-11 活动链接 资金去向 用途 金额 日期 申请人 购买梯子帐号（一年） 180 2021.02.22 linuxsuren , yJunS , wst021 open4u域名购买 29 2020.</description>
</item>
<item>
<title>行为规范</title>
<link>https://jenkins-zh.cn/about/code-of-conduct/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/about/code-of-conduct/</guid>
<description>留言 留言之前需要使用 GitHub 账号登陆。大家要注意文明用语，严禁攻击、诋毁、灌水、广告等无关的话。对于违反人，一经发现将会被拉入黑名单。
提问 欢迎每一位朋友在这里提出与 Jenkins 或相关领域的技术问题，但是，在提问之前建议先在搜索引擎和本站中进行搜索。
问题至少要包含如下部分：
场景以及问题是如何发生的，方便阅读的人复现 软件、环境相关版本信息 日志、截图等（建议使用附件的方式） 出于对回答问题者的尊重，请得到解决方案后及时表示感谢，或者从其他地方得到答案后添加相关链接以及说明。
GitHub 请您使用同一个 GitHub 账号来与大家交流，不欢迎使用所谓的“小号”。</description>
</item>
<item>
<title>Jenkins 中文社区议题公开征集</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/07/2021-07-19-call-for-paper/</link>
<pubDate>Mon, 19 Jul 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/07/2021-07-19-call-for-paper/</guid>
<description>Jenkins 中文社区议题公开征集，加入我们，一起聊聊！
Jenkins 中文社区作为开放的技术社区，深受广大 Jenkins 用户和技术爱好者的欢迎。出于对 Jenkins 技术的不断追求以及对开源世界共同的热爱，这里也聚集了一批活跃的社区用户。他们在这里自主学习技术、自由交流实践经验，在逐渐提升自己技术成长的同时，也以在线分享、线下分享和博客等方式，将 Jenkins 相关的知识分享给更多用户和小伙伴，往期更多精彩历史，请前往哔哩哔哩 《Jenkins 系列视频教程～从入门到精通》或 Jenkins 公众号获取。
为了更好地与 Jenkins 用户和爱好者进行分享和交流，也为热爱分享的用户们提供一个专业的平台，Jenkins 中文社区管理团队特发起“议题公开征集计划”，诚邀对 Jenkins、DevOps 相关议题感兴趣的伙伴，共同参与到社区之中。
我们将对公开征集到的议题进行认真的筛选，根据筛选的收集结果来安排在线或者线下活动，为 Jenkins 中文用户提供更多交流的空间。
议题提交通道 您可以通过发送邮件到 admins@jenkins-zh.cn，或者直接提交 issue 到 GitHub https://github.com/jenkins-zh/jenkins-zh/issues/new
议题范围 任何 Jenkins 相关的使用、踩坑经验 杜绝商业产品宣传 议题格式 分享题目： 议题简述： 适合人群： 预计时长： 提议大纲： 另外，为了方便组委会联系您，以及对活动的安排，请您提供如下个人信息：
姓名： 性别： 所在城市： 微信： Q&amp;A 我对 Jenkins 的了解不多，使用时间也不是很久，还可以分享吗？ 我们对难易程度、高深与否没有限制，只要是您的心得体会、实际经验统统可以 分享时长有限制吗？ 从 10 分钟到 1 个小时，都是非常欢迎 议题征集有的截止日期是什么时候？ 本次征集长期有效，组委会根据提交的内容、日期来进行安排 分享是在线呢，还是线下进行？ 如果分享者对在线或者线下分享都可以的话，当某个城市的分享者够三位以上时，我们优先会考虑安排线下活动，其他情况则是在哔哩哔哩直播 让我们一起，共建开放、包容、活跃的 Jenkins 社区，感兴趣的小伙伴不要错过哦～</description>
</item>
<item>
<title>用JCasC配置插件</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/07/2021-07-03-jenkins-JCasC-tutorial-translation/</link>
<pubDate>Sat, 03 Jul 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/07/2021-07-03-jenkins-JCasC-tutorial-translation/</guid>
<description>用 JCasC 配置插件 这个博客是写给任何对用 Jenkins 的 JCasC 配置插件感兴趣的人，具体会讲解如何获得 YAML 格式的配置信息和如何在不通过 Jenkins 的图形界面的情况下更改插件的信息。
如果你是 JCasC 的新手并且想了解关于 JCasC 更多的内容，你可以先去看下列链接中的内容，来更好的理解 JCasC。
JCasC Documentation Overview of JCasC (Video Presentation) Manage JCasC (DevOps World 2018) 概要 下面是大致的步骤：
简要介绍 jenkins.yaml 文件 在 Jenkins 的图形界面上配置插件 下载配置文件 本地更新 JCasC 文件 在 Jenkins 服务器上加载 jenkins.yaml 文件 在图形界面上验证 简要介绍 jenkins.yaml 文件 jenkins.yaml 文件里有 Jenkins 实例的配置信息。 JCasC 插件用.yaml 文件来配置 Jenkins 实例。 jenkins.yaml 文件的默认位置是在 $JENKINS_HOME/jenkins.yaml，Jenkins 服务器在你应用新的配置后会自动从这个位置读取配置文件。 按照以下步骤：Manage Jenkins &gt; Configuration as Code &gt; Download Configuration，下载你的 jenkins.</description>
</item>
<item>
<title>Jenkins X 3.x GA 来了！</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/05/2021-05-07-jenkins-x-3.x-is-here/</link>
<pubDate>Fri, 07 May 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/05/2021-05-07-jenkins-x-3.x-is-here/</guid>
<description>Jenkins X 3.x 正式发布！
我非常激动的向大家宣布 Jenkins X 3.0 GA 版本正式发布啦！
Jenkins X 在 kubernetes 上自动执行 CI/CD，这将帮助你提升:
自动化 CI/CD 流水线可以让你将精力放在应用程序的代码实现上，Jenkins X 会为你的项目自动创建通过 GitOps 管理的 Tekton CI/CD 流水线，这将会使你的流水线在不同仓库中保持更新或者为特定仓库覆盖流水线或步骤变得非常简单。
通过 GitOps 在不同的环境自动升级版本化产物，比如暂存区，准生产，生产环境。不管这些环境是否在同一个 kubernetes 集群中运行或者你为这些环境使用了多集群方式。
环境预览能够让你通过 Pull Requests 提交代码变更，之后会自动创建一个预览环境，在 Kubernetes 上运行你的代码，这样会让你在代码允许合并到主分支之前能更快的得到来自团队的反馈。
ChatOps 在 Pull Requests 进行反馈时可以进行评论，允许/挂起变更，触发一个为其他测试以及 ChatOps 命令而设计的可选流水线。
Demo demo 将会演示如何使用 Jenkins X 进行代码开发
文档 主要改动的文档有:
带有模块化插件以及提升扩展点后的新架构
3.x 开始都做了那些变更
3.x 与 2.x 的对比</description>
</item>
<item>
<title>Jenkins Operator 成为官方子项目</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/04/2021-04-15-jenkins-operator-sub-project/</link>
<pubDate>Wed, 28 Apr 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/04/2021-04-15-jenkins-operator-sub-project/</guid>
<description>我们很高兴的宣布，Jenkins Operator 已正式成为 Jenkins 官方子项目。
这件事意味着什么？ 成为 Jenkins 官方项目的组成部分，也是为了能更好地与 Jenkins 总体路线规划保持一致而迈出的重要一步，这也将会大大增加这个项目被使用的几率。
我们是隶属于 VirtusLab 并专门维护该项目的团队。我们终于可以和这个大社区互动，并参加 Cloud-Native SIG 会议。 这也为每个想为该项目提出建议或参与支持的人提供了平台。
我们坚信，有了社区的支持将大大改善 Jenkins Operator 项目自身以及 Jenkins 生态系统。
填补 Jenkins 与 Kubernetes 间的缝隙 在 Kubernetes 这样的云原生环境中运行 Jenkins 并不是件容易的事。我们希望通过该项目提供的功能使社区能够充分利用 Kubernetes 以及云平台的能力： - 集成云平台原生的监控、存储、安全机制 - Kubernetes 的自动扩容和自我修复机制 - 安全访问 Jenkins 实例 - 声明式配置（Kubernetes Custom Resources） - 全生命周期管理，最终实现自动管理（autopilot）
参与项目，共享发展 邀请您参与贡献该项目，实际体验自动管理 Jenkins 的乐趣！别犹豫，请参与到社区活动中来。与我们一起努力实现您认为有用的功能。也欢迎您提出缺陷、建议或补丁。我们正在积极解决社区提出的问题与建议，并设立了专门的 Slack 互动频道。
本项目原由 VirtusLab 公司设立，并在持续维护中。成为 Jenkins 官方子项目后，我们也正在讨论（Google Groups）创建一个开放式的治理机制来促进沟通和协作。
向我们反馈并引导项目前进 为庆祝我们项目正在开启的新可能性，诚邀您参加一个小调查，助力我们找到正确方向。如您正在使用 Jenkins Operator 或在任何其他环境中运行 Jenkins，请花一点时间填写我们的快速调查表。我们将选择至少三个最有用的答案，送出我们专门设计的T恤，上面印有我们可爱的 Gopher 管家。点击这个链接打开调查问卷（Google Docs），真诚的回复也是对我们项目最好的支持。 另外，如果您还没有用过 Jenkins Kubernetes Operator，欢迎您下载使用。试一试，发现在 Kubernetes 上 运行 Jenkins 的新方式。</description>
</item>
<item>
<title>Jenkins 更新中心证书更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/03/2021-03-31-update-center-certificate-rotation/</link>
<pubDate>Wed, 31 Mar 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/03/2021-03-31-update-center-certificate-rotation/</guid>
<description>2021 年 3 月 29 日，我们会更新 Jenkins 更新中心的证书。当前的证书将会于 2021 年 4 月过期。当新证书启用后，Jenkins 2.178 之前的版本（2018 年）就无法与默认的更新中心以及实验性更新中心通讯。对于自行部署的更新中心，则不会收到影响。对于插件更新，更新中心会支持一年内的 Jenkins core 的版本，2.204 就是最老的版本。
你如果不定期更新的话，请查阅 Jenkins 安全公告，并以此作为依据来更新你的 Jenkins 版本。
哪些人？ 还在使用 Jenkins 2.178 之前版本的用户，将于 2021 年 3 月 29 日证书更新后无法获得任何更新。
对于 Jenkins 开发者，如果使用的 Jenkins 是 2.178 之前的版本的话，在执行 mvn hpi:run 命令测试插件时看不到插件更新。插件开发者可以把最小依赖更新到相对较新的版本。在指导手册“如何选择 Jenkins 版本”中有关于最小 Jenkins 版本的说明。另外，开发者也可以通过参数 mvn -Djenkins.version=2.249.1 hpi:run 来测试更高的版本。
对于运行的 Jenkins 版本高于 2.178 的用户，则不会受到影响。
做了什么？ Jenkins 通过更新中心来检查核心以及插件的更新。该服务使用带有根证书的证书丢元信息做签名。Jenkins 中带有该根证书，因此可以保证更新中心的数据可信。当有更新可用时，会有提示信息出现在 Jenkins 界面上以提醒用户更新。
为什么？ 绑定在 Jenkins 中的根证书创建于 2011 年 4 月，有效期至 2021 年 4 月。这是 2018 年 4 月更新的 Jenkins 核心的根证书。现在，该使用新的根证书了。最新根证书的过期日期为 2028 年 4 月。</description>
</item>
<item>
<title>“Jenkins Docker 镜像重大更新”</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/03/2021-03-29-jenkins-docker-image-update/</link>
<pubDate>Mon, 29 Mar 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/03/2021-03-29-jenkins-docker-image-update/</guid>
<description>从 Jenkins 2.279 和 2.263.4 开始，Jenkins 项目会更新基础操作系统和 Java 的版本，涉及到的镜像包括：jenkins/jenkins:latest 和 jenkins/jenkins:lts。会将 OpenJDK 8u242 替换为 AdoptOpenJDK 8u282，将 Debian 9 (&ldquo;Stretch&rdquo;) 替换为 Debian 10 (&ldquo;Buster&rdquo;)。
为什么？ 我们更改基础镜像，是为了可以有更好的操作系统的支持，以及包含更多 Java 发行版本。
更好的操作系统支持 由 Jenkins 提供的 Docker 镜像依赖于操作系统提供者对于系统安全的维护。
我们的 Docker 镜像已经使用了 Debian 9 (&ldquo;Stretch&rdquo;) 很多年。Debian 9 的安全更新已于 2020 年 7 月 6 日停止更新。Debian 9 长期支持版本的安全更新也将于 2022 年 6 月停止更新。使用 Debian 10 可以让我们得到由操作系统安全团队更好的维护。
更多 Java 发行版 Debian 9 Docker 镜像是基于 openjdk:8-jdk-stretch 的。它的最后一次更新是在一年前，包含 JDK 8u242. 我们需要一个及时维护的 Docker 基础镜像，和 JDK 发布以及操作系统的更新保持一定的节奏，这样控制器就可以运行在最新的 Java 以及操作系统的之上。</description>
</item>
<item>
<title>2020 Google 编程之夏活动总结</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/03/2021-03-24-google-summer-of-code-2020-summary/</link>
<pubDate>Wed, 24 Mar 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/03/2021-03-24-google-summer-of-code-2020-summary/</guid>
<description>随着十月份导师峰会与课题回顾的结束，现在我们宣布 Google 编程之夏 2020 活动在 Jenkins 社区圆满结束。我们谨代表 Jenkins 团队，感谢所有今年参与到此次活动的参与者们: 学生、导师、申请者以及各位贡献者。Google 编程之夏活动的顺利举行离不开 Jenkins 社区各位成员的积极参与。
如果一直关注 Jenkins 博客，你已经看到课题团队创建了很多 GSoC 2020 文章。这里，我们着重聚焦一些此次活动的“高光时刻”。
项目 2020 年，我们有 7 名学生参与进了 Jenkins 导师组织中。有 6 个 Jenkins 项目 1 个 Jenkins X 项目。按照往年惯例，在 GSoC 我们一般将注意力集中于对 Jenkins 用户与社区成员比较重要的问题上。这些项目具有备受期待的新特性以及对后期 Jenkins 长期发展具有关键意义的架构变更。
以下为今年我们参与的项目:
Sladyn Nunes - 自定义 Jenkins 发行版构建服务
Sumit Sarin - 外部指纹存储
Rishabh Budhouliya - Git 插件性能提升
Kezhi Xiong - Jenkins GitHub Checks API 插件</description>
</item>
<item>
<title></title>
<link>https://jenkins-zh.cn/meeting/2021-03-03/</link>
<pubDate>Wed, 03 Mar 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/meeting/2021-03-03/</guid>
<description>活动 场地，Rick 可以帮忙协调 讲师 DevOps 相关的都可以，Tekton、Gitlab CI Jenkins 系列教程 暑期计划 yJunS 是该活动的 owner</description>
</item>
<item>
<title>“Jenkins 贡献者线上峰会 - 二月 23 日至 25 日”</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/02/2021-02-26-jenkins-contributor-summit-online-feb-23-25/</link>
<pubDate>Sun, 21 Feb 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/02/2021-02-26-jenkins-contributor-summit-online-feb-23-25/</guid>
<description>Jenkins 贡献者峰会让 Jenkins 项目目前以及将来的贡献者们能够齐聚一堂。今年我们主持本次线上峰会是为了鼓励全世界的贡献者们相互了解、讨论、规划未来。
此次贡献者峰会将于 2021 年 2 月 23 日至 2 月 25 日举行。此次会议旨在组织社区成员们一起学习、交流、规划 Jenkins 社区未来的发展方向。在 Jenkins 社区里，我们珍视所有形式的贡献并真诚欢迎新成员加入进来。
点击注册加入
会议形式 线上会议能够让会议的时间和主题更加自由。方便贡献者们在一个相对更小的讨论小组里在线上讨论一些特定的议题。
开幕式 开幕式将于 2021 年 2 月 23 日 15 时（北京时间 23 时）开始。在欢迎环节与回顾环节结束后，我们将会听取 Jenkins 各个领域的负责人介绍过去一年的成果以及未来一年的展望。
安全 - Daniel Beck
基础设施 - Olivier Vernin
版本发布 - Tim Jacomb
用户体验 - Félix Queiruga
中文本地化 - 赵晓杰(Rick)
配置即代码 - Tim Jacomb
Google 编程之夏 - Kara de la Marck</description>
</item>
<item>
<title>Jenkins CLI 命令行 v0.0.33</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/02/2021-02-02-jcli-v0.0.33/</link>
<pubDate>Tue, 02 Feb 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/02/2021-02-02-jcli-v0.0.33/</guid>
<description>在某些场景下，我们可能需要增加或者删除流水线参数。如果有相当数量的流水线需要手动处理的话，将会是一件非常无聊、工作量大的事情。现在，你可以通过这个命令来添加参数了：jcli job param init-job --add '[{&quot;name&quot;:&quot;name&quot;,&quot;value&quot;:&quot;my name&quot;,&quot;desc&quot;:&quot;this is a name&quot;}]'
如果从多个不同的任务中删除特定的构建历史，也非常简单：jcli job history init-job -d 1
有时候，下载 jenkins.war 会非常地慢。但是，现在 jcli 可以利用多线程并发下载的方式来加速：
# jcli center download -t 8 start to download with 8 threads, size: 67287051, unit: 8410881 另外，还有一个重要的功能是，jcli 可以通过简单的命令来实现以 Docker 的方式启动 Jenkins：
jcli center start -m docker --image kubespheredev/ks-jenkins --version 2.249.1 --c-user root --port 9090 --setup-wizard=false
截止到编辑本文时，GitHub 上统计到的下载量为：11,168 次。GitHub 上的 Star 数为234(+18)，码云上的 Star 数为251(+23)。
🚀 功能 修复命令 center start 的随机 web 目录参数无效的问题 (#520) 支持删除构建历史 (#519) 支持增加或者删除流水线参数 (#513) 支持在配置文件中添加执行 shell 的项 (#518) 增加用于多线程下载 jenkins.</description>
</item>
<item>
<title>KubeSphere 使用外置 Jenkins</title>
<link>https://jenkins-zh.cn/wechat/articles/2021/01/2021-01-11-exteranl-jenkins-in-kubesphere/</link>
<pubDate>Mon, 11 Jan 2021 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2021/01/2021-01-11-exteranl-jenkins-in-kubesphere/</guid>
<description>相信很多 KubeSphere 的用户之前在以 Jenkins 作为 CI/CD 工具，但是，KubeSphere 默认会安装一个新的 Jenkins，无法直接使用已有的 Jenkins 作为 CI/CD 引擎。这对于希望能上生产，但是又不方便迁移已有流水线的用户来说，还是有很多不方便的地方。本文的目标，就是给大家提供一个让 KubeSphere 可以使用外置 Jenkins 的方案。
限制 该方案并不是一个完美的终极方案，因此，在你开始使用外置 Jenkins 之前，请先评估下面的限制：
KubeSphere 上已有的流水线将会无法使用 如果你已有的 Jenkins 中安装了不兼容的插件，可能会导致部分功能无法使用 不会把旧的 Jenkins 上的流水线迁移到 KubeSphere 上 鉴于方案可能会有如上所属的风险，请*不要*直接在你的生产环境上操作！另外，请确保你有一个备份环境，并且在备份环境上进行如下的方案实施。
实验环境 CentOS Linux release 7.9.2009 (Core) 安装依赖：
yum update -y &amp;&amp; yum install wget curl vim bash-completion -y 安装 KubeSphere 为了不影响已有的业务，我们最好还是找个空白的环境，安装一个新的 KubeSphere 会比较稳妥。下面，我们首先把安装工具 kk 下载好。值得一提的是，KubeSphere 社区为了能够让用户更方便地体验到最新交付的 feature 或者修复的缺陷，提供了每日构建版，也就是所谓的：nightly build。想要体验找个 nightly build 最好的办法是使用最新开发中的的 kk。</description>
</item>
<item>
<title>Jenkins 安全修复 SECURITY-626 的紧急通知</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/12/2020-12-21-jenkins-security-626/</link>
<pubDate>Mon, 21 Dec 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/12/2020-12-21-jenkins-security-626/</guid>
<description>普通用户 检查你的 Jenkins 版本，界面上是否有 SECURITY-626 相关的安全漏洞提醒。如果有的话，建议准备升级。尤其是对于 Jenkins 运行在公有云环境中的用户。
后文，您可以选择性阅读。
开发者（或将 Jenkins 作为 CI/CD 工具集成的厂商、用户） 仔细阅读下面的内容，并根据具体情况做响应的调整。
默认情况下，Jenkins 中的 CSRF Token 只对认证信息以及 IP 地址进行校验。这就导致了一个潜在的安全漏洞，攻击者可以利用另外一个用户的 CSRF Token 进行攻击，而且只要受害者的 IP 地址保持不变，就可以一直有效。
从 Jenkins 2.176.2 开始，CSRF Token 还会检查 Web Session ID 以确保他们是来自于同一个会话。当会话失效后，对应的 Token 也会不可用。
因此，默认情况下，通过 /crumbIssuer/api 这个 API 获取的 Token 将会无法使用。除非，这些 Token 能关联到同一个会话上。
解决方案 安装插件 Strict Crumb Issuer Plugin 后，自定义 Crumb 校验规则 禁用新特性，设置系统属性 hudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID 为 true 案例 KubeSphere 对于开源平台 KubeSphere 的用户来说，已经不用担心这个问题，社区已经在 ks-jenkins 这个项目中修复了这个问题。 参考资料 https://www.</description>
</item>
<item>
<title>Jenkins CLI 命令行 v0.0.31</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/11/2020-11-23-jcli-v0.0.31/</link>
<pubDate>Mon, 23 Nov 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/11/2020-11-23-jcli-v0.0.31/</guid>
<description>截止到编辑本文时，GitHub 上统计到的下载量为：9.4k(+2000)次。GitHub 上的 Star 数为216(+29)，码云上的 Star 数为228(+56)。
很久没有发布 jcli 了。但是，这次绝对值得升级它。让我们一起来看看都有哪些新功能吧。
通常，当你首次安装时，需要给 jcli 添加配置文件。然后，从 Jenkins 界面生成 Token 后还需要写入到配置文件中，这个过程显得很繁琐。但是，从这个版本开始，你可能就不再需要这么做了。因为，已经可以自动地获取 Token 并配置好了。你需要的只是执行下面的命令：
jcli center login
该命令会弹出浏览器，并打开 Jenkins 界面，你只要成功登录 Jenkins 后配置文件就会自动回写好。但是，这里还存在一个限制。那就是，你的电脑必须能够与 Jenkins 所在的服务器双向通信。此外，你还需要安装一个pipeline-restful-api-plugin 插件。
第二个特性，和 Jenkins formula（配方）有关。首先要感谢 @oleg-nenashev 发起并维护着Custom Jenkins WAR packager这个项目。在这个项目的基础上，我们可以生成一个自定义的 Jenkins 发行版。jcli 则执行从已有的 Jenkins 中导出一个配方。而且，还可以把一个配方文件中的插件安装到另外一个 Jenkins 上。具体请参考下面的命令：
jcli plugin formula &gt; formual.yaml # 导出 YAML 格式的配方文件 jcli plugin install --formula formual.yaml # 从配方文件中安装插件 第三个特性，就是可以以 Docker 容器的形式来运行 Jenkins jcli center start -m docker</description>
</item>
<item>
<title>使用 AWS、k3s、Rancher、Vault 和 ArgoCD 在 Kubernetes 上集成 GitOps</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/11/2020-11-04-implementing-gitops-on-kubernetes-using-aws-k3s-rancher-vault-and-argocd/</link>
<pubDate>Wed, 04 Nov 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/11/2020-11-04-implementing-gitops-on-kubernetes-using-aws-k3s-rancher-vault-and-argocd/</guid>
<description>随着 Kubernetes 将自己打造为容器编排的工业标准以来，为你的应用和工具寻找一条能够高效使用声明式模型的途径是成功的关键因素。这篇文章中，我将带领大家在 AWS 上设置一个 k3s Kubernetes 集群，然后集成 ArgoCD 和 Vault 创建一个安全的 GitOps。可以从这里检出基础设施代码和 Kubernetes unbrella 应用代码。
以下是我们将会使用的组件/工具:
AWS &ndash; 底层基础设施云服务方案提供商。它将管理让 Kubernetes 正常运行的虚拟机和网络。并允许通过外部世界进入集群内部。
k3s &ndash; 由 rancher 开发的一套精简版本的 Kubernetes 发行版。它清理了许多 alpha 和云插件，它还允许使用关系型的数据库（这里使用的是 RDS）以替代 etcd 作为后台存储。
Rancher &ndash; 一款以 API 驱动的可以轻松管理 Kubernetes 集群的 UI 工具。
Vault &ndash; Hashicorp 的密钥管理系统。我将会使用集成在 vault 的 Banzai Cloud 的 bank-vault，它会允许通过使用一个 Admission Webhook 的方式将密钥直接注入到 pod 中。这将大大减少你将密钥存储到 Git 仓库的需求。
ArgoCD &ndash; 一款 GitOps 工具允许你使用 Git 维护 Kubernetes 资源的状态。ArgoCD 会自动同步 Kubernetes 资源到你的 Git 仓库中，这样同样可以使集群中的配置清单手动修改后能够被自动恢复。这样能够确保你的声明式部署模型。</description>
</item>
<item>
<title></title>
<link>https://jenkins-zh.cn/meeting/2020-10-28/</link>
<pubDate>Wed, 28 Oct 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/meeting/2020-10-28/</guid>
<description> Jenkins 系列教程 现状 存储 钉钉 片头、片尾 录制周期 反馈 目前收集到的反馈很少，如何才能有更多的反馈？（问卷？） 片尾增加哔哩哔哩的地址，让感兴趣的人关注下（需要简单设计下效果，通过录音来宣传） 单个视频剪辑成多个的话，衔接的不好 </description>
</item>
<item>
<title>使用 Bitbucket 流水线创建最简单的 CI</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-14-setup-the-simplest-ci-with-bitbucket-pipeline/</link>
<pubDate>Wed, 14 Oct 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-14-setup-the-simplest-ci-with-bitbucket-pipeline/</guid>
<description>最近我写了一篇关于 CI 和 CD 之间核心区别的文章，我觉得是时候把这些理论运用到实际当中了。
在我印象中我参与开发的所有项目使用的源码控制平台都是使用的 Artlassian 的 Bitbucket。对于想要寻找一款免费、UI 整洁、能够为追踪你的代码提供了所有必要功能的版本控制系统来说，它是一个再棒不过的选择了。
除了所有版本控制系统提供的基本功能以外，Bitbucket 添加了一些扩展比如集成了 CI/CD 功能，可以让我们推送代码之后将变更更准确的部署上去。
好处就是不需要额外的工具了，只需要 Bitbucket 以及 JavaScript。
配置 Bitbucket 仓库设置完成后，剩下需要完成的工作就是在配置你的仓库允许使用 Pipelines。滚动到 PIPELINE 部分点击 Settings。你会看到如下所示配置:
点击切换开关，你会得到一个配置 bitbucket-pipelines.yml 文件的选项。这个文件将会告诉 Bitbucket 在代码推送到仓库后需要执行哪些命令。点击 “Configure bitbucket-pipeline.yml” 按钮会指引你转到 Pipeline 菜单:
这里你可以选择多种语言模板。我们这里最感兴趣的就是 JavaScript 的。我们可以使用它作为基础然后依据我们自己的喜好进行修改。
修改配置文件 修改模板以及添加一些另外的步骤，我们得到如下文件:
image: node:10.15.3 pipelines: default: - step: name: Deploy caches: - node script: - npm install - npm run build - npm run test - npm run deploy 我们将每一行进行拆分，看看都做了哪些事情:</description>
</item>
<item>
<title>Jenkins 完全系列视频教程制作组招募</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-12-contributors-recruit/</link>
<pubDate>Mon, 12 Oct 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-12-contributors-recruit/</guid>
<description>Jenkins 依托活跃的社区，广大的社区贡献者提供了非常丰富的插件，使得对很多人而言是一款容易上手、资料齐全、易于扩展的开源产品。
哔哩哔哩、各种博客网站上，有很多的文章、视频中介绍到了 Jenkins 的一些知识，有来自个人的总结，也有来自培训机构的资料。这些资料中， 大部分是不会再有二次维护、更新的，而且缺少对插件机制的介绍，以及插件开发实战等高阶部分。
Jenkins 中文社区，作为 Jenkins 的中文用户集中交流的社区，不仅为广大的用户、爱好者提供了微信群这样的及时沟通渠道，而且，还有 责任和义务为大家提供完整、详细且持续维护的视频教程。为了让越来越多的 Jenkins 用户及时收到这份大礼包，我们联合了多家国内社区 联合制作、推广这套系列视频教程。我们的目标是：让每一位新手、有使用经验或者希望深入掌握 Jenkins 开发的用户都可以从这里获益。
当前参与合作的社区有：
TesterHome Kubesphere DevOps中国 云原生技术社区 禅道 志愿者 我们欢迎每一位有热情❤️的小伙伴加入我们的志愿者行列，需要志愿者做的事情包括（不仅限于）如下：
字幕制作 视频剪辑（工具为Openshot) 视频审核 - 讲师会把录制好的视频文件上传到百度网盘 图片设计 - gimp 如果您希望加入志愿者的话，请在下面留言，并说明希望做的事情以及加入理由！！！
讲师 如果您热情于参与社区，如果您已经有一些 Jenkins 相关的经验、心得体会，如果您热衷于分享技术，那么请停下匆忙的脚步👣，加入我们的讲师团队吧！ 心动不如行动，下面是我们的视频录制的流程：
选题，并在下面留言；我们鼓励您选择多个相关度很高的题目，例如：容器相关的。但是为了避免发生选题后时间难以保证产出的情况，建议先选择3以内的题目，完成后再次认领。 根据选题录制10～15分钟的视频，并上传百度网盘。如果某个题目相对较大，需要分成多起，确保符合我们的时长要求。 把录制好的视频发给我们的微信团队 review，根据反馈调整。推荐的录屏软件为：喵影工厂 提供视频中您的署名 视频剪辑，通过后安排发布时间 社区合作 合作、共赢是我们推出公益性 Jenkins 视频教程的基础，贵社区的加入可以让更多的人因此获益。我们会将贵社区的 Logo 放在视频的片尾部分，图片文件请提交 Pull Request 到视频剪辑项目仓库中。 而您需要做的是，在贵社区的微信公众号平台上连续转载每一期的视频。当然，如果您的社区也可以有讲师来分享，或者视频剪辑、图片设计等。
许可证
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
&lt;!&ndash; 在微信公众号等平台上发布该文章时，可以把已经发布过的视频贴在后面。 &gt;</description>
</item>
<item>
<title>Jenkins 长期支持版更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-10-jenkins-release/</link>
<pubDate>Sat, 10 Oct 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-10-jenkins-release/</guid>
<description>2.249.1 (2020-09-09) 自 2.249 以来的变更： Jenkins 2.252 和 2.235.4 的重要安全修复。 (安全公告) 停止预格式化代理日志以防止死锁(由 2.231 引入的缺陷回归)。 (issue 63458) 修复将 API token 复制到剪贴板的按钮(由 2.238 引入的缺陷回归)。 (issue 63274) 将包装选项卡还原为多行，而不是溢出(由 2.248 引入的缺陷回归)。 (issue 63180) 标准化小部件颜色，使其与新调色板一致。 (修复暗黑主题中的面包屑刷新) 空的已安装插件表文本将再次可读(由 2.249 引入的缺陷回归)。 (issue 63276) 在“构建时间趋势”页面中显示构建时间数据(由 2.245 引入的缺陷回归)。 (issue 63232) 在日语文档和消息中用 agent 替换对 slave 的文本引用。 (issue 63166) 修复退格键有时无法从 Mac 上的脚本控制台删除文本的问题 (由 2.248 引入的缺陷回归)。 (issue 63342) 修复正则表达式验证器 UI 位置 (由 2.244 引入的缺陷回归)。 (issue 63308) 防止并发构建删除。 (issue 61687) 自 2.</description>
</item>
<item>
<title>Jenkins 每周版更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-09-weekly-release/</link>
<pubDate>Fri, 09 Oct 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-09-weekly-release/</guid>
<description>2.256 (2020-09-08) 避免在 hudson.FilePath 中的有关匿名类的日志告警。 (issue 63563) 2.255 (2020-08-31) 104 sunny0 cloudy0 storm * 开发者: 忽略不稳定的 UpdateCenter2Test.install 测试。 (pull 4916)
2.254 (2020-08-25) 停止预格式化代理日志以防止死锁（由 2.231 引入的缺陷的回归）。 (issue 63458) “全局/系统读取”权限正式变为“整体可用 (GA) ” 状态。 (pull 4909, JEP-224) 设置 Cross-Origin-Opener-Policy 为 same-origin。 (pull 4910) 通过使用新的浏览器标签打开配置屏幕的内联帮助中的插件链接，避免丢失正在进行的工作。 (issue 63429) 开发者: 从 f:dropdownList 中删除未使用的 description 属性。 (issue 63220) 2.253 (2020-08-18) 基于 Alpine 的 Jenkins Docker 镜像的重大更新。 基于 Alpine 的 Jenkins Docker 镜像现在使用 Alpine 3.</description>
</item>
<item>
<title>GitHub 推出 Codespaces Beta</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-08-github-codespaces/</link>
<pubDate>Thu, 08 Oct 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/10/2020-10-08-github-codespaces/</guid>
<description>这是国庆假期最后一天的早晨，浏览完几份未读的邮件之后，顺手打开 GitHub 看看有没有啥新动态。欣喜地发现 GitHub 又给我们放出来了 一个功能 Codespaces，特地和大家来分享。
关注开源的朋友们，一定都知道国内的代码托管平台 Gitee 在早些时候提供了 WebIDE 的功能，这确实是一个很贴心的举动。当我们希望在线 编辑一些稍微复杂点的文件时，普通的文本框就显得没有那么好用。例如：大量的开源项目文档采用的 Markdown 格式来编写，普通的文本框 就无法提供预览效果。WebIDE 则不同，它可以给我们提供接近本地 IDE 的使用体验，例如：语法高亮、多文件编辑等等。
但是，Gitee 给我们提供的 WebIDE 并不完整，编辑文件只是最基础的功能，对开发者而言没有控制台的 IDE 是没有灵魂的。当时，能猜想到 GitHub 作为全球最大的代码托管平台，肯定是会提供类似的功能。那么，今天大家终于等到了。下面，给大家分享下我在使用 Codespaces 时 的一些体验。
首先，编辑器的入口是非常重要的一点。GitHub 选择 Code 作为入口，也是非常恰当的；虽然，我一开始感觉有点找不到北。 Code -&gt; Open with Codespaces
第一次使用的话，会提示你新建一个 codespace
如果是再次进入 codespace 的话，就可以选择一个已经创建好的
真正让我感到眼前一亮的功能在于它集成了对 PullRequest 和终端控制台的支持，这两点对于一个开源项目的贡献者来说是非常需要的功能。
从下面的图中可以看到，我们可以非常便捷地找到由本人创建的或者所有的 PR，还可以看到 PR 所修改了的文件列表。甚至，项目维护者都可以直接给 PR 添加评论或者 approve。
有点美中不足的是，issues 功能貌似是有点缺陷，无法看到正确的列表。
更强大的地方在于，我们在 Codespace 的终端可以直接执行一些命令。例如：在上图中，我可以通过 GitHub 官方的 CLI 来查看 PR 或者 issues 等。我们无需为 gh 配置凭据信息，Codespace 已经提供了开箱即用的体验。</description>
</item>
<item>
<title>2020年10月 Hacktoberfest 纪念版T恤还是种树</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-27-hacktoberfest/</link>
<pubDate>Sun, 27 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-27-hacktoberfest/</guid>
<description>Hacktoberfest 是由知名云服务商 DigitalOcean 发起的一个推广、支持开源的年度在线活动，任何一个开源爱好者都可以参与到其中。只要在10月份内 向 GitHub 上的任意开源项目提交若干 Pull Request，就算完成活动任务，并将得到由 DigitalOcean、GitHub 等活动赞助商提供的纪念品。纪念品， 通常是限量版T恤、贴纸若干。
那么，Hacktoberfest 这个奇怪的名字是什么意思呢？这不是一个原生的英文单词，是由几个代表着这个活动的核心精神的单词缩写组合而成。其中的 Hacktober 是由 Hackathon（黑客马拉松） 和 October（十月） fest 则是 Festival（节日）的前几个字幕。看到这里，大家应该就明白了吧， Hacktoberfest 就是开源爱好者在每年的十月份通过做开源贡献的方式来传播、庆祝开源。
我本人，今年已经是第三次参与 Hacktoberfest 这个全球规模的在线活动。作为一名开源的忠实拥护者和布道者，在此呼吁每一位开发者、每一位认同平等、 开放、协作观念的人，大家一起来参与 Hacktoberfest、参与开源。
不懂代码？完全没关系，有很多项目或者社区需要您其他方面的技能，包括当不仅限于：文档编写、文档翻译、图片设计、字幕等等。
对 GitHub 不熟悉？没关系，你可以看看我自己录制的一个有关如何使用 GitHub 的视频。https://www.bilibili.com/video/BV14t411M7zv
好了，心动不如行动，赶快点击下面的链接注册报名吧：
活动注册地址 http://dwz.win/RhZ
注册过程中，你大致需要做下面的三件事：
通过 GitHub 登录 选择邮箱、角色（活动组织者、贡献者、项目维护者） 是否接收相关资讯邮件 如果你看到了类似下面的画面，那么，贡献你，已经完成活动注册。万事俱备，只等十月 PR：
开源的方舟你已经登上，接下来再看看到底有哪些项目可以参与，以及了解下今年的活动情况。
2020年，Hacktoberfest 是由三家公司联合组织，包括：DigitalOcean、intel、DEV。其中，intel 是今年新加入的 从需要完成的 PR 数量来看，相比去年少了一个，只需要完成4个即可 从活动奖励上来看，多了一个选项，可以在限量版T恤或者种树之间选择一个（难道他们是向蚂蚁森林学的新技能？） 今年T恤的颜色可以是白色或者蓝色 如何种树？请看这里 https://tree-nation.com/profile/digitalocean 推荐项目（https://github.com/jenkins-zh） Jenkins 简体中文插件 用于41k+的安装量 完善中文本地化词条 Jenkins CLI 是由 Go 语言编写的 Jenkins 命令行客户端 功能完善、文档完善、缺陷修复、Logo 设计等 Jenkins 系列教程 需要擅长设计的同学来帮忙设计封面等 征集社区合作、讲师、志愿者 Jenkins 插件更新中心国内源 需要你来把版本更新自动化 欢迎使用 Go、Java 或者 Python 等语言实现版本自动化更新（目前还是人肉在更新） Jenkins 特定领域发型版定制 FAQ 我可以向自己的仓库提交 PR 吗？答：可以！ 我提交的 PR 必须要合并后才算吗？答：只要提交 PR 即可，除非被标记为无效的。 issues 算数吗？答：不算！ 我可以向 GitHub 以外的平台提交 PR 吗？答：不可以！ 即使我已经努力向各位介绍活动细节了，但如果还有不清楚的地方的话，可以访问下面的官方 FAQ 链接，或者添加社区的微信小助手进群资讯 https://hacktoberfest.</description>
</item>
<item>
<title>GSoC: GitHub Checks API 项目第三阶段总结</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-25-github-checks-api-plugin-project-coding-phase-3/</link>
<pubDate>Fri, 25 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-25-github-checks-api-plugin-project-coding-phase-3/</guid>
<description>这篇文章将介绍 GitHub Checks API 项目在谷歌编程之夏第三阶段的相关工作。
在这个夏天的尾声，GitHub Checks API 项目迎来了它在 GSoC 的最后一段旅程。在这篇文章当中，我将向你们展示我们在这最后一个阶段中的相关工作： - 流水线支持 - Rerun 请求支持 - Git SCM 支持 - 文档的完善
以上的特性已经合并在了最新发布的 Checks API 插件 与 GitHub Checks 插件 的 1.0.0 版本中。
流水线支持 对流水线的支持让用户无需依赖任何 Checks API 的实现就可以直接在他们编写的流水线当中轻松发布 checks。
上图中的 check 可以通过如下脚本实现：
publishChecks name: 'pipeline check', title: 'pipeline ', summary: '# A pipeline check example', text: &quot;## This check is published through the pipeline script&quot;, detailsURL: 'https://ci.jenkins.io' 如果你想要发布 checks 到 GitHub，请安装 GitHub 的实现 并查阅 GitHub API 文档 了解各个参数的相关用途。其中，detailsURL 会拥有一个链接到此次 Jenkins 构建页面的默认值。</description>
</item>
<item>
<title>Jenkins 国内插件源恢复正常啦</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-18-fix-jenkins-plugins-source/</link>
<pubDate>Fri, 18 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-18-fix-jenkins-plugins-source/</guid>
<description>近期，Jenkins 中文社区微信群内有些童鞋提出*国内插件源*无法正常使用了，究竟是什么情况呢？
对比插件源 经过对比，发现原来原始插件源和国内插件源返回的 JSON 内容几乎一致，导致国内插件源下载 URL 都指向了国外插件下载地址，国内有些网络的情况下会有直接下载失败的情况
解决方案 发现插件源与国内插件源下载 URL 一致之后，发现最终原因竟是原有生成插件源的程序替换 URL 未成功，所以我们只要替换掉即可，修复 PR
完美解决 重新将程序打包上传之后，插件源重新生成之后，插件更新基本正常解决。
如何使用 如想知道如是使用国内插件源，请参考此页。源地址替换为插件源地址
欢迎大家通过我们的论坛 或通过添加我们的微信小助手进群交流</description>
</item>
<item>
<title></title>
<link>https://jenkins-zh.cn/meeting/2020-09-16/</link>
<pubDate>Wed, 16 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/meeting/2020-09-16/</guid>
<description> Jenkins 系列教程 教程文字部分 https://github.com/jenkins-zh/jenkins-zh/pull/335/files 联系了部分有合作意愿的社区（会有一个单独的微信群） 在片头、片尾添加logo 讲师合作录制视频 录制周期 情况比较好的话，一周一个视频 时间、人员紧张的话，尽量两周一个视频 视频剪辑 工具，喵影工厂 片头，主题、讲师等 片尾，后期制作的人员以及合作社区等 画面的切换，部分内容的剪辑 媒体账号状态分享 微信公众号 开源中国 B站 论坛 </description>
</item>
<item>
<title>使用 Jenkins 和 Ansible 实现 CI/CD</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-09-ci-cd-with-jenkins-and-ansible/</link>
<pubDate>Wed, 09 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-09-ci-cd-with-jenkins-and-ansible/</guid>
<description>现在是 2018 年。Kubernetes 在容器编排大战中取得了胜利。我们中的一些人怀着羡慕的心情阅读着硅谷创业公司的那些文章（是的，或许你所在的城市已经有了这些创业公司了！），然而读完之后还是回到自己手上运行得还可以的遗留的老系统上工作。
基于主干开发，容器部署至云上，这些虽然都在 DevOps 未来的规划中，但是短期内这些还基本无法落地。
向 DevOps 方向迈出的一步是要消除孤岛（dev，QA，ops），因此我们必须以一种每个角色都能轻松协作的方式来构建我们的代码。
我阅读了很多非常不错的文章，介绍如何使用一些单页面 Javascript 和 Spring Boot 后端构建应用，其中还涉及了配置管理、基础框架、持续集成和持续交付。现在我将结合以上所有内容，为你开展自己的工作提供一些支持和帮助。
准备 我准备了一个 Jenkins 实例，部署了 ssh， 以及一个可运行的 Spring Boot jar，还有一台 RedHat7 的虚拟机，和 Nexus 的制品仓库。所以我想我很高兴不用再部署 EARs 了。
现在我将使用以上的工具构建一个部署流水线，并对所有内容做版本控制，以便团队中的每个人都可以访问所有内容，并了解他们的代码从提交到部署的每个环节（本例中只是到测试环境）。
代码结构如下：
parent +- backend +- frontend +- deployment Jenkinsfile 简单起见，backend——一个简单的 Spring Boot 应用——包含了前端 ReactJS 应用，deployment 中是持续交付相关工具，根目录下的 Jenkinsfile 是这个流水线的声明式描述。
下面我们看一下每个模块！
后端 它继承自 Spring Boot parent：
&lt;parent&gt; &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt; &lt;artifactId&gt;spring-boot-starter-parent&lt;/artifactId&gt; &lt;version&gt;2.0.3.RELEASE&lt;/version&gt; &lt;relativePath/&gt; &lt;/parent&gt; 我们将 frontend 应用放在 dependencies：
&lt;dependencies&gt; .</description>
</item>
<item>
<title>对Jenkinsfile语法说不，开源项目Jenkins Json Build挺你</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-07-jenkins-json-build/</link>
<pubDate>Mon, 07 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-07-jenkins-json-build/</guid>
<description>项目背景 我所在的组织项目数量众多，使用的语言和框架也很多，比如Java、ReactNative、C# .NET、Android、iOS等，部署环境也是多种多样比如Tomcat、K8S、IIS、客户端应用是局域网内企业证书安装等，我们没有专门的配置管理员或构建部署专员，都是开发人员自己在Jenkins中写构建脚本，每个项目都有自己的构建脚本（Scripted Pipelines），但类型相同的项目比如都是Java或都是.NET项目之间，构建脚本其实都很类似，都是靠几个已存在的构建脚本改写出来的，其实开发人员对编写Jenkins构建脚本了解也不多，另外因为没有规则和约束，更没有代码复用的机制，构建部署工作很混乱和难以管理。
项目解决的问题 在上述情况下我们开发了Jenkins-Json-Build项目,该项目适合于有一些编程经验的人员在不需要了解Jenkins构建脚本如何编写的情况下，通过简单的配置Json文件，就可以轻松完成一个项目的获取源码、单元测试、代码检查、编译构建、部署等步骤，实现一个典型的CI过程，又因为此项目使用了Jenkins共享类库（Shared Libraries）机制，构建脚本复用率得到了大幅度提高，并且开发人员可以方便的扩展更多的功能，满足不同构建部署场景的需要，此项目非常适合那些开发人员自己管理构建部署的团队，通过Jenkins-Json-Build项目组织对构建部署过程进行了统一的管理和监督，又让每个项目有足够的灵活性和自主权满足各自项目构建部署的特殊性。
一个Java项目构建示例 构建服务器上需要安装的软件 构建服务器上需要安装Java、Maven和Sonar-Scanner（此项可选）。
JAVA安装 Maven安装 Sonar-Scanner 构建需要依赖的Jenkins插件 JUnit JaCoCo Jenkinsfile文件内容 因为采用pipeline script from SCM构建方式，所以用Declarative Pipeline方式在Jenkinsfile中编写构建脚本：
@Library('shared-library') _ pipeline { agent any parameters { //定义构建参数 choice choices: ['-'], description: '请选择部署方式', name: 'deploy-choice' } stages { stage('初始化') { steps { script{ //加载源码仓库根目录下的jenkins-project.json构建配置文件 runWrapper.loadJSON('/jenkins-project.json') runWrapper.runSteps('初始化') } } } stage('单元测试') { steps { script{ //执行单元测试步骤 runWrapper.runSteps('单元测试') } } } stage('代码检查') { steps { script{ //执行代码检查步骤，比如SonarQube runWrapper.</description>
</item>
<item>
<title></title>
<link>https://jenkins-zh.cn/meeting/2020-09-02/</link>
<pubDate>Wed, 02 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/meeting/2020-09-02/</guid>
<description>媒体账号状态分享 微信公众号 开源中国 B站 开源项目 update-center-mirror 社区职位 暂时没有计划推进</description>
</item>
<item>
<title>DevOps 的打开方式: 构建和部署</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-02-devops-adoption-approach-build-and-deploy/</link>
<pubDate>Wed, 02 Sep 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/09/2020-09-02-devops-adoption-approach-build-and-deploy/</guid>
<description>通过使用 Serverless Jenkins（Jenkins X）为企业在一个实时的云原生项目上通过使用 Kubernetes CI/CD 方法进行构建&amp;部署。
新时期 DevOps 的变革是在专注于作为敏捷协议的一个扩展并且同敏捷协同合作的过程中让开发者、IT 运维、质量保障和业务一道朝着共同的目标让项目更快更好的进行。受竞争日益激烈的市场驱动着，企业需要通过软件传递价值，造就了速度成为了如今软件开发的新规范。拥有正确的企业文化、工具、流程以及 DevOps 最佳实践对加快和提升软件产出的速度至关重要。如今，我们需要为在云、容器、服务网格、微服务、不变的基础架构以及声明性 API 上运行的 Kubernetes 上重新构想 CI/CD。嗯，Jenkins X 就是那款产品；它提供了一种在 Kubernetes 上运行 CI/CD 流水线的方法。Jenkins X 作为一个平台在开发者那里隐藏了 Kubernetes 的复杂性。开发者可以专注于编出高质量的代码和优秀的用户体验而不需要为 Kubernetes 的复杂性大费脑筋。
这是正确打开 DevOps 的博客的系列第二部分。在之前的那篇博客中，主要讨论了文化、计划和设计。我当时指出“DevOps 是一个结果为导向支持敏捷的实践。”现在依然是这样的。
这篇博客中，我将会通过在 Kubernetes 上为云原生应用程序使用最新的 CI/CD 工具也就是 Jenkins X 专注于从运行层面讲解 DevOps。我将会解释基本的概念然后通过构建一条流水线来将理论与实践关联，然后带你学习第一次接触 Jenkins X 需要学习的步骤有哪些。对你来说重要的是理解构建的模块以及为什么它是云原生应用的完美选择。操作说明将会一步步引导你学习 Jenkins X 并会为你提供入门指南。
Jenkins X 是革命性的具有改变现代应用程序与客户交互的潜力。它或许会影响下一代的开发以及部署，类似于 Docker 对不可变容器镜像和 Kubernetes 对容器服务编排的影响那样。
Serverless CI/CD 流水线 Jenkins X 是一款在 Kubernetes 上运行的 CI/CD 流水线，一种部署临时流水线的新方法也被叫做无服务器的流水线。它是 Tekton Pipelines 项目的一部分旨在为声明 CI/CD 类型的流水线提供 Kubernetes 形式的资源。</description>
</item>
<item>
<title>GSoC: GitHub Checks API 项目第一阶段总结</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/08/2020-08-07-github-checks-api-plugin-project-coding-phase-1/</link>
<pubDate>Fri, 07 Aug 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/08/2020-08-07-github-checks-api-plugin-project-coding-phase-1/</guid>
<description>这篇博客将介绍 GSoC 项目 GitHub Checks API Plugin 在一阶段的相关进展。
简单来说，GitHub Checks API 就是一套可高度定制化接受 CI 报告的接口。 CI 工具可以通过该接口反馈信息给特定的 Pull Request，随后，用户便可以直接在 GitHub 的 UI 界面上直观的浏览 CI 报告。
更激动人心的是，它可以针对指定的代码行进行注释，这类似于开发者平时在代码审查时留下的评论。
同时，在 Jenkins 这边，Warnings Next Generation Plugin 能通过源代码视图实现类似的功能。
因此，通过使用 GitHub Checks API 将这些信息直接反馈给 GitHub 能使 Jenkins 对 GitHub 用户更加友好。
阶段一实现的相关特性 在过去的一个月里，我们团队的工作主要集中在 General Checks API 和 GitHub Checks API 的实现上。
General Checks API 尽管 General Checks API 是基于 GitHub Checks API 的语义实现的，我们仍然希望能提供这样的泛化接口为其他平台的相关概念做好准备，例如：GitLab 上的 Commit Status API。 在今后，我们欢迎所有人贡献针对这些平台的相关实现。</description>
</item>
<item>
<title>在 Kubernetes 上使用 Argo 实现 CI/CD</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/08/2020-08-05-ci-cd-with-argo-on-kubernetes/</link>
<pubDate>Wed, 05 Aug 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/08/2020-08-05-ci-cd-with-argo-on-kubernetes/</guid>
<description>持续集成和持续交付是一些人为之努力的目标。它让一切事物变得更简单。当然，市面上有许多 CI/CD 工具，但是随着 Kubernetes 的日渐盛行，所有这些工具都需要做相应的调整。比如说，Jenkins，这款非常成熟的 CI/CD 工具在全球范围内被广泛使用，但是这款工具缺乏创新并且感觉有点笨重。同样的话也适用于 Spinnaker。一款出色的企业解决方案拥有让工作深入开展下去的资源，但是让 CI/CD 工具以一种快速、整洁的方式升级不是一个理想的选择。还有其他的一些工具可以为更简单的工作流提供更多的支持。其中一个就是我们本文中将要介绍的 Argo。
Argo 与众不同的地方在于它管理实际 CI/CD 的方式。它是专门为了 Kubernetes 开发的并且通过 CRD（Custom Resource Definitions）集成到 Kubernetes 中。它定义了一个新的名为‘工作流’的 CRD 。在这个工作流中你可以通过一个 yaml 格式的文件定义你需要执行的操作。每一步均运行在位于 Kubernetes 集群内它自己的 Docker 容器里面。
argoproj/argo
Argo/Argo CD/Argo CI Argo 项目有几个正在开发的项目仓库。Argo 是主项目，聚焦于 Kubernetes 工作流以一种更通用的方式来被使用。Argo CD 是一种处理部署的 GitOps 方法，也就意味着 Kubernetes 集群从版本仓库镜像到任意位置时 git 仓库是事实上的唯一来源。Argo CI 看起来已经不再维护了，但是它曾经是作为 CI 工具用来基于 git 变更触发工作流的。为了安装 CI/CD 工具，你需要 Argo 以及它的工作流，同样也一个需要触发它们的 CI 工具。因为 Argo CI 已经没有开发活动了，我自己写了一个 Argo CI，可以通过 Bitbucket webhooks 触发 Argo 工作流。使用自己开发的 CI 工具，我开始试着使用 Argo 构建了一个功能全面的 CI/CD 工具。</description>
</item>
<item>
<title>Jenkins 长期支持版更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/08/2020-08-03-jenkins-release/</link>
<pubDate>Mon, 03 Aug 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/08/2020-08-03-jenkins-release/</guid>
<description>2.235.2 (2020-07-15) 重要的安全修复。 (安全公告) 修复 &ndash;httpKeepAliveTimeout 选项无效的问题(由 2.235.1 引入的缺陷回顾)。 (issue 61823, pull 4812, Winstone 5.9.1 变更日志) 修复模式关闭后按钮等待时间太久的问题(由 2.233 和 2.235.1 引入的缺陷回归)。 (issue 62560) 2.235.1 (2020-06-17) 自 2.235 以来的变更： 使插件管理可以再次支持 Internet Explorer 11 (由 2.231 引入的缺陷回归)。 (issue 62163) 防止以 Java 11 运行时缺少 javax.annotation 类的导致的遥测告警(由 2.231 引入的缺陷回归)。 (issue 61920) 修复代理启动期间涉及自定义记录器的死锁(由 2.231 引入的缺陷回归)。 (issue 62181) 在类字段解组问题的情况下，防止 Old Data Monitor 插件加载失败。 (issue 62231) 自 2.222.4 以来的重大变更: 插件管理的各种改进，包括： 默认情况下，它不再显示所有可用的插件；使用搜索字段查找插件。 现在，默认情况下按人气对它们进行排序。 此外，类别不再用于对插件进行分组，而是将其显示为标签。 (issue 61166, pull 4580, pull 4513, pull 4588, pull 4534, pull 4591, pull 4535, pull 4589, pull 4584) 将管理 Jenkins 页面上的条目进行分类，并以网格化显示。 (pull 4546) 删除“自动刷新”功能，包括现在已过时的自动刷新遥测功能。 (pull 4503) 具有扩展读取权限的用户现在将获得外观更具只读性的 UI。 (issue 61202, pull 4479, Read-only Jenkins Configuration blog post) 允许具有“全局/系统读取”权限的用户查看关于 Jenkins 、插件管理、全局安全配置和系统日志。 (issue 61205, issue 61201, issue 61203, issue 61207, issue 61455, issue 61208, issue 61208) 在具有全局/系统读取或项目/扩展读取权限的用户的只读配置表单上，区分已定义（*****）和未定义（N/A）密码。 (issue 61812) 允许具有“全局/管理”权限的用户访问系统信息、准备关机和关于 Jenkins 的管理链接。 现在，具有该权限的用户也可以配置全局配置中的使用情况统计信息。 (issue 61456, issue 61453, issue 61457, issue 61455) 尽可能使用浏览器提供的当前系统字体。 更改正文和标题的字体大小，以提高一致性和可读性。 (issue 60921) 重新设置了按钮样式。 增加了对于大按钮、超链接样式按钮和图标样式按钮的支持。 (issue 61840) 重新设置帮助图标的样式。 (pull 4663) 改进告警横幅的样式，使其更具视觉吸引力并更好地匹配现有的用户界面组件。 现在，警报在显示时完全覆盖了导航栏，而不是仅覆盖导航栏的一部分。 (issue 61478) 禁止将非管理员用户的错误堆栈跟踪作为核心功能。 (issue 60410) 2.</description>
</item>
<item>
<title>Jenkins 每周版更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-31-weekly-release/</link>
<pubDate>Fri, 31 Jul 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-31-weekly-release/</guid>
<description>2.249 (2020-07-24) 为某些构建步骤构建环境时，不再抛出异常（由 2.248 引入的缺陷的回归）。 特别是，对 Powershell 插件中的 Powershell 步骤有影响。 (issue 63168) 对齐插件管理器表标题。 (pull 4858) 修复了某些元素的标题（例如授权矩阵）的样式错误的问题。 (pull 4861) 2.248 (2020-07-21) 由于发布基础设施的问题导致的意外，Windows MSI 软件包尚未发布。 解决方法是，手动下载并替换 JENKINS_HOME 中的 jenkins.war。
停止支持 .NET Framework 2.0 将 Jenkins 服务和代理作为 Windows 服务启动。 现在需要 .NET Framework 4.0 或更高版本。 (公告, 升级指南, issue 60005, issue 61862, Windows 支持策略) 将 Windows Service Wrapper（WinSW）从基于 .NET Framework 2.0 的 2.3.0 可执行文件更新为基于 .NET Framework 4.0 的 2.9.0。 包括多项改进和问题修复。 最值得注意的是，如果需要，服务安装程序现在将要求权限提升。 (变更摘要, WinSW 完整的变更日志, Windows Agent Installer 2.</description>
</item>
<item>
<title>Jenkins CLI 命令行 v0.0.30</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-24-jcli-v0.0.30/</link>
<pubDate>Fri, 24 Jul 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-24-jcli-v0.0.30/</guid>
<description> 截止到编辑本文时，GitHub 上统计到的下载量为：7,101(+453)次。GitHub 上的 Star 数为187(+7)，码云上的 Star 数为172(+21)。
如果要把 Jenkins 和现有的系统进行对接的话，很多人可能会遇到一个问题，当调用 API 触发流水线构建后，如何能拿到构建的 ID 呢？
要回答这个问题的话，我们首先需要对 Jenkins 的相关机制有一些了解。每当触发一个任务时，Jenkins 会先把这个请求放到一个队列中，当有了可以运行该任务的计算节点（agent）之后，Jenkins 的 master 会把任务调度到对应的节点上去，此时就开始真正地运行了。
换句话说，任务的调度是异步进行的。因此，触发构建后，是无法拿到一个构建 ID 的，因为此时还没有开始构建。
我在这里给出的方案是：在 Jenkins 上安装插件 Pipeline restFul API v0.9 的后，可以通过 Jenkins CLI v0.0.30 来解决这个问题，具体使用方法如下：
jcli job build job/devops/ -b --wait --columns Number --no-headers
输出结果为：36
下面是本次版本发布中所包含的内容：
🚀 功能 增加自我升级的功能，支持升级到任意版本 (#431) @LinuxSuRen 支持更新流水线后立即执行 (#429) @LinuxSuRen 通过 homebrew 安装的话集成 man 帮助手册 (#391) @LinuxSuRen 支持触发流水线并获取构建 ID (#434) @LinuxSuRen 为插件上传命令增加超时时间 (#428) @LinuxSuRen 为插件检查更新命令增加超时时间 (#422) @LinuxSuRen 🐛 缺陷修复 修复无法在需要有 HTTP 代理的情况下连接 JNLP 节点 (#420) @LinuxSuRen 📝 文档完善 将 jcli 的文档部署到了 gitbook (#426) @LinuxSuRen 👻 维护 多个依赖的版本更新 @dependabot-preview </description>
</item>
<item>
<title>Jenkins 基础设施：统计、更新、AWS 赞助</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-15-jenkins-infrastructure-stats-updates-and-aws-sponsorship/</link>
<pubDate>Wed, 15 Jul 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-15-jenkins-infrastructure-stats-updates-and-aws-sponsorship/</guid>
<description>Jenkins 项目在很大程度上依赖于其基础架构。我们使用诸如 www.jenkins.io 和 plugins.jenkins.io 之类的网站，诸如 issue.jenkins.io 之类的议题系统，诸如 ci.jenkins.io 之类的 CI/CD 基础设施以及许多其他服务。为了提供有关 Jenkins 基础设施规模的一些信息，以下是 2020 年 4 月的一些数据：
超过 60 万人访问了 www.jenkins.io 超过 25 万个 Jenkins 服务器定期检查 Jenkins 软件包服务器和 Jenkins 更新服务器 ci.jenkins.io 上有超过 43000 个持续集成工作 超过 950 个插件在 ci.jenkins.io 上运行了他们的持续集成流水线 jenkins.io 的国家（地区）访客
Jenkins 项目是一个开源项目，由其出色的社区构建和维护。像在任何组织中一样，有特定的人员来确保那些服务始终处于运行状态。欢迎大家加入。基础设施也不例外，我们一直在寻找基础设施的新贡献者！
尽管我们无法公开共享诸如机密和证书之类的所有内容，但我们仍会尽量保持透明，以使每个人都可以理解和改进我们的基础结构而无需特权访问。有什么比使用 Git 管理基础架构工作更好的方法？
谁说的 GitOps？ 自 2008 年 3 月在 GitHub 上创建 Jenkins-infra 组织以来，已有 650 多人参与了 80 多个 git 存储库。这些贡献使 Jenkins 社区变成了现在的样子。如果您在该处找不到任何东西，则可能意味着需要一些帮助。
最近，在 Gavin Mogan、Tim Jacomb、Alex Earl 的帮助下，在许多方面都取得了重大成就，例如自动化 Jenkins 版本，刷新 plugins.</description>
</item>
<item>
<title>关于 Jenkins 术语更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-10-on-jenkins-terminology-updates/</link>
<pubDate>Fri, 10 Jul 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-10-on-jenkins-terminology-updates/</guid>
<description>2016 年，Jenkins 社区决定开始在该项目中删除令人反感的术语。在 Jenkins 2.0 中，“slave”一词已被弃用，并由“agent”一词代替。在清理被认为是最有问题的“slave”一词之后，还将预定其他术语进行审查。2017 年，该项目开始跟踪需要纠正的区域。重命名 SSH 构建代理插件以及逐步删除服务和存储库中的攻击性命名的工作已经完成。今年，一群核心贡献者继续致力于这项关键工作。
Advocacy &amp; Outreach SIG 开会讨论并确定了继续工作的优先次序。governance board 也召开了会议，将会有更多关于删除冒犯性术语的信息。上周，我们通过更新以前的博客文章并删除了旧博客中的冒犯性术语，清理了 Jenkins 内置文档和本地化中的一些引用，在项目中删除了冒犯性术语又迈出了一步。此处提供会议纪要，还可以在这里记录会议记录，还有更多工作要做。核心团队正在努力解决诸如“Master”，“whitelist”和“blacklist”之类的术语以及 git 分支术语。
我们需要您的帮助，我们将继续开展这项急需的工作，并谨此提醒大家，Jenkins 项目受《行为准则》约束。
真诚的 Marky Jackson。</description>
</item>
<item>
<title>社区推送博客-机器学习插件项目</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-06-machine-learning-plugin-project-community-bonding-blog-post/</link>
<pubDate>Mon, 06 Jul 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-06-machine-learning-plugin-project-community-bonding-blog-post/</guid>
<description>大家好！
这是 GSoC 2020 中的 Jenkins 项目之一。我们正在为此 GSoC 2020 使用此新的机器学习插件。这是我在社区关于 GSoC 2020 的故事。我很高兴与您分享我的旅程。
自我介绍和神奇的 4 位导师 我是 Moratuwa 大学的 Loghi Perinpanayagam。我被选为 Jenkins 的 GSoC 2020 机器学习插件的负责人。我很高兴向我的导师介绍这个项目。我分配了四位导师，他们非常热心地帮助我在今年夏天开发代码。
学生
Loghi Perinpanayagam 导师
Bruno P. Kinoshita Ioannis Moutsatsos Marky Jackson Shivay Lamba 去年我的准备情况如何？ 我在第二年就了解了 GSoC 开源项目。但是我至少在去年尝试了另一个组织的项目，该项目与《数据科学的数据可视化建议》有关。但是问题是我的贡献不如今年那么大，在申请过程中为时已晚。像往常一样，与其他项目相比，与机器学习相关的项目有很多竞争。我准备学习机器学习中的数据可视化以及推荐系统的现有模型。最后，我当时用 SeqToSeq 模型编写了一个提案，当时对神经网络知识不多。而且我没有通过专用的闲暇渠道进行太多交流。这可能是失败的原因之一。但是主要原因是我对 GSoC 2019 的了解不多。
我如何跨过 GSoC 2020？ 自从我意识到开源的必要性和对社区的帮助以来，我一直热衷于为开源项目做出贡献。实际上，我于 2019 年在印度班加罗尔完成了实习，我立即专注于参与 GSoC。这是我作为计算机科学理学学士学位课程的学生的最后一年（2020年），我希望今年能被选为学生。
我们部门举办了一次指导研讨会，我知道 Jenkins 已经打开了他们的项目构想。这是我的 GSoC 2020 旅程的一个非常令人印象深刻的开始。我在 jenkins.io 页面上浏览了所有草案并接受了项目。因为我已经对机器学习感兴趣，并且对 Java 很熟悉，所以我选择了最令人印象深刻的想法，因为它没有初始回购协议。这意味着我想利用我的知识对该项目进行很多思考和研究。但是我必须做出贡献，并且想了解 Jenkins 代码库的基础结构。因为这样可以使选择面板易于接洽该项目的学生。然后，我反复搜索为 Jenkins 做贡献。我发现从 git 插件和 git 客户端插件可以轻松解决的问题。我开始在 git 插件和 git 客户端插件上贡献一些测试问题。在清楚了解插件在 Jenkins 中的工作原理后，我开始使用项目构想页面中提供的提示来进行 POC 的工作。实际上，编写代码很有趣。</description>
</item>
<item>
<title>Jenkins CLI 命令行 v0.0.29</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-02-jcli-v0.0.29/</link>
<pubDate>Thu, 02 Jul 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-02-jcli-v0.0.29/</guid>
<description> 截止到编辑本文时，GitHub 上统计到的下载量为：6,648次。GitHub 上的 Star 数为180，码云上的 Star 数为151。
Jenkins CLI 加入了码云最有价值开源项目计划（GVP），并且迎来了两位社区贡献者的首次贡献。非常感谢码云对该项目的认可，以及开源贡献者的努力。到目前为止，在 GitHub 上记录的有11位社区开发者参与过项目贡献，我们非常地欢迎更多的人加入！
🚀 功能 支持把 HTTP 请求以 curl 命令的形式输出 (#409) @LinuxSuRen 支持关闭 Jenkins (#346) @LinuxSuRen 支持保存 token 到 keyring (#399) @LinuxSuRen 触发 Jenkins 参数化任务时，支持传递文件 @WangXiangUSTC 添加函数 default 到子命令 cwp 到配置文件解析 (#415) @LinuxSuRen 支持直接运行 jenkinsfile (#379) @sladyn98 🐛 缺陷修复 修复读取 keyring 中的 token 时可能发生的错误 (#419) @LinuxSuRen 📝 文档完善 添加相似的项目 jenni (#401) @LinuxSuRen 👻 维护 多个依赖的版本更新 @dependabot-preview 增加徽章 hits 用于显示项目页面访问次数 (#418) @LinuxSuRen 改进 docker 构建 (#396) @LinuxSuRen </description>
</item>
<item>
<title>使用 Kibana 和 Rsyslog 监控 Linux 日志</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-01-monitoring-linux-logs-with-kibana-and-rsyslog/</link>
<pubDate>Wed, 01 Jul 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-01-monitoring-linux-logs-with-kibana-and-rsyslog/</guid>
<description>如果你是一名系统管理员，或者是一名好奇的软件开发工程师，那么你很有可能在平常挖掘日志信息的时候找到一些很有价值的信息。
有时你或许想监控虚拟机的 SSH 指令。
有时你或许想查看下你的应用程序服务器在某一天某一个特定的时间出现了什么样的错误信息。
或者你为了想一探究竟到底是谁停了你的一个虚拟机的 systemd 服务。
如果你想从这几个地方了解的话，或许你来对地方了。
在这篇文章当中，我们将会构建一个完整的日志监控流水线，使用 ELK 堆栈（ElasticSearch、Logstash、和 Kibana）和 Rsyslog 作为一个强力的系统日志服务器。
在开始动手之前，让我们先快速的考虑下技术因素，让我们讨论下为什么我们使用 Kibana 监控 Linux 日志。
Ⅰ-为什么你需要监控 Linux 日志？ 监控 Linux 日志是非常关键的，而且每一名 DevOps 工程师都需要知道怎样做。理由如下:
你可以通过日志得到实时可视化的反馈: 这或许是众多日志监控理由中最关键的一个，你可以构建一些有意义的可视化视图（例如表格，饼状图，图表或者柱状图）来为你的日志赋予一些意义。
你可以汇总这些信息来构建高级以及复杂的仪表盘: 有时一个原始数据是不够的，你或许想加上一些其他的日志或者将它们与其他日志比较从而了解一个整体的变化趋势。一个具有表达式处理功能的可视化平台可以让你这样操作这些信息。
你可以快速过滤一个特定的术语或者是一个给定的时间段: 如果你只对 SSH 日志感兴趣，你可以为其构建一个指定的仪表盘。
以一种快捷和优雅的方式，日志是可导航的: 我知道从日志文件中无止尽的日志信息中抓取信息的痛苦。我宁愿有一个平台来专门做这件事。
Ⅱ- 你将会学习到什么 这篇入门文章你将会学习到下面的一些知识:
日志在 Linux 系统是如何处理的（Ubuntu 或 Debian）以及什么是 rsyslog。
怎样安装 ELK 堆栈（*ElasticSearch 7.2，LogStash 和 Kibana*）以及这些工具是用来做什么的。
怎样配置 rsyslog 从而将日志转发到 Logstash。
怎样配置 Logstash 从而获取日志以及 ElasticSearch 存储。</description>
</item>
<item>
<title>KubeSphere DevOps 初体验，内置 Jenkins 引擎</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-30-kubesphere-devops-using-jenkins/</link>
<pubDate>Tue, 30 Jun 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-30-kubesphere-devops-using-jenkins/</guid>
<description>初识 KubeSphere KubeSphere 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。KubeSphere 支持部署在任何基础设施环境，提供在线与离线安装，支持一键升级与扩容集群，并且各功能组件支持模块化和可插拔的安装。
解读 KubeSphere DevOps KubeSphere DevOps 作为 KubeSphere 容器平台的一个可插拔功能组件，内置了 Jenkins 作为在 Kubernetes 之上的 CI/CD 引擎。借助 Jenkins 丰富的插件体系和易于进行扩展开发的特性，帮助 DevOps 团队在一个统一的平台中，打通开发、测试、构建、部署、监控、日志与通知等流程。KubeSphere 为 DevOps 团队打造了以容器为载体的端到端的应用交付平台，实现从应用开发、持续集成、单元测试、制品构建到应用的生产交付，所有的流程都是一个完整的闭环。
KubeSphere DevOps 充分利用和释放 Kubernetes 动态扩展的能力。例如，KubeSphere 在内置的 DevOps 系统使用了 Jenkins Kubernetes 的动态 Agent，这样的方案相较于传统虚拟机上的 Jenkins 要更加灵活敏捷。同时，在 KubeSphere DevOps 中内置了常用的 Agent 类型，例如 Maven、Node.js、Go 等，并且还支持自定义与扩展的 Agent 类型。
除了基于 Jenkins 引擎打造的 CI/CD 流水线，KubeSphere 还为业务开发者提供了自动化打包部署的工具集。业务开发者即使还没有深入了解 Docker 与 Kubernetes 的机制，也可以借助 KubeSphere 内置的自动化 CD 工具，如 Binary to Image 和 Source to Image。用户只需要提交一个仓库地址，或上传 JAR/WAR/Binary 等二进制文件，即可快速将制品打包成 Docker 镜像并发布到镜像仓库，最终将服务自动发布至 Kubernetes 中，无需编写一行 Dockerfile。</description>
</item>
<item>
<title>使用 Python 制作酷炫多彩的 Jenkins 插件词云图</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-29-generate-jenkins-plugins-word-cloud/</link>
<pubDate>Mon, 29 Jun 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-29-generate-jenkins-plugins-word-cloud/</guid>
<description>作为最流行的 CI/CD 工具，Jenkins 的优势之一是其生态强大，而这与其插件体系分不开的。 目前 Jenkins 插件 1500+ （截止2020年06月17日，插件数量为1749）。
近日发现词云比较好玩，于是想着以 Jenkins 插件名称为数据源，形成的词云会是什么样的呢，什么关键字会比较突出呢？ 想到就去做，带着问题，带着好奇心，开始了实践之旅～
插件基本字段说明 以 Jenkins 中文本地化插件为例，在 Jenkins 官网插件详情页面可以看出： 其 ID 为 localization-zh-cn，Name 为 Localization: Chinese (Simplified)。
获取所有 Jenkins 插件的名称 如何获取所有 Jenkins 插件的名称呢？这里我想到3种方式，或许还有更多方式：
插件官网爬虫抓取
插件权限文件获取
插件更新中心配置文件获取
对比上面的三种方式，插件权限文件中并没有 Name 字段，插件更新中心配置文件相对从插件官网抓取比较简单。 所以计划从 update-center.json 进行解析，其中插件名称在 json 中对应字段为 title。
生成 Jenkins 插件名称文件 读取 update-center.json 中 plugin 的 title 字段，按行写入到 jenkins-plugins.txt 文件，代码如下：
# -*- coding: UTF-8 -*- import json if __name__ == &quot;__main__&quot;: json_obj = json.</description>
</item>
<item>
<title>Jenkins Hackfest 用户体验文档报告</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-24-jenkins-user-experience-hackfest-documentation-results/</link>
<pubDate>Wed, 24 Jun 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-24-jenkins-user-experience-hackfest-documentation-results/</guid>
<description>Jenkins 技术文档是我们项目的重要组成部分，因为它是正确使用 Jenkins 的关键。好的文档可以指导用户，并鼓励选择好的实现方式。这是用户体验的关键部分。
在最近的 Jenkins UI/UX hackfest 中，文档是改善 Jenkins 用户体验的特定途径。我们从经验丰富的 Jenkins 贡献者和新人那里获得了许多进步。来自世界各地的贡献者提交了有关安装，管理和操作 Jenkins 文档的 PR。
从 Wiki 迁移文档 Jenkins Wiki 页面为 Jenkins 用户收集了 15 年的经验和智慧。但是，这种经验和智慧与不准确，不完整和过时的信息混杂在一起。
Jenkins Wiki 迁移项目确定了 Jenkins Wiki 上访问量最大的 50 个页面，并创建了 GitHub 问题来跟踪这些页面到 www.jenkins.io 的迁移。这是我们第一次使用 GitHub 问题作为文档的大规模实验。结果是压倒性的正面。Hackfest 贡献者在许多文档章节中添加了新的章节，包括：
Jenkins 使用 流水线 Jenkins 管理 系统管理 Hackfest 解决了 Wiki 迁移问题中的 19 个问题。有关其他 25 个 Wiki 迁移问题的工作正在进行中。我们已经取得了长足的进步，并期待将来取得更好的成绩。新的贡献者非常有效地使用了“good first issues”标签。我们以未分配的 25 个“good first issues”中的大多数未分配开始了 Hackfest，并以 14 个已关闭的项目和另外 10 个正在进行的项目完成了 Hackfest。 当我们使用 Jenkins Wiki 迁移来欢迎新的文档撰稿人时，我们将提供更多的“good first issues”。</description>
</item>
<item>
<title>GitHub App 身份验证支持已发布</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-17-github-app-authentication-support-released/</link>
<pubDate>Wed, 17 Jun 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-17-github-app-authentication-support-released/</guid>
<description>我很高兴的宣布在 Jenkins 中作为 GitHub 应用进行身份验证现已支持。这是许多用户期待已久的功能。它已在 GitHub Branch Source 2.7.1 中发布，现在可以在 Jenkins 更新中心使用。
身份验证为 GitHub 应用带来了很多好处：
更高的请求频率限制 - GitHub 应用程序的速率限制随您的组织规模而定，而基于用户的令牌的限制为 5000，无论您拥有多少存储库。 与用户无关的身份验证 - 每个 GitHub 应用都有自己的用户独立身份验证。不再需要“机器人”用户或确定谁应该是 2FA 或 OAuth 令牌的所有者。 改进的安全性和更严格的权限 - 与服务用户及其个人访问令牌相比，GitHub Apps 提供了更精细的权限。这使 Jenkins GitHub 应用程序需要更少的权限集即可正常运行。 访问 GitHub Checks API - GitHub Apps 可以访问 GitHub Checks API 以从 Jenkins 作业创建检查运行和检查套件，并提供有关提交和代码注释的详细反馈。 开始使用 安装 GitHub Branch Source 插件，确保版本为 2.7.1 或更高。
配置 GitHub Organization 文件夹 遵循 GitHub App Authentication setup guide。这些说明也可在 GitHub 上的插件 README 文件中看到。</description>
</item>
<item>
<title></title>
<link>https://jenkins-zh.cn/meeting/2020-06-10/</link>
<pubDate>Wed, 10 Jun 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/meeting/2020-06-10/</guid>
<description> UCloud 服务器管理 Nexus 上线了 https 有问题 企业合作 中信 技术活动没有确定 句子互动 作为赞助商 提供了一年的套餐 https://github.com/jenkins-zh/jenkins-zh/pull/271 kubesphere https://github.com/kubesphere/kubesphere/issues/2182 著作权 * 翻译文章不能算是原创（个例，来自 jenkins.io 可以在公众号里申明为原创） * 在社区提供的翻译稿，在我们的公众号上首次发布 * 应该说明作者、翻译者等的具体版权说明 </description>
</item>
<item>
<title>使用 Prometheus 和 Grafana 监控 Linux 进程</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-03-monitoring-linux-processes-using-prometheus-and-grafana/</link>
<pubDate>Wed, 03 Jun 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-03-monitoring-linux-processes-using-prometheus-and-grafana/</guid>
<description>无论你是否是一名 Linux 系统管理员或是一名 DevOps 工程师，你都会在监控服务器性能指标的时候花费很长时间。
有时候实例运行非常慢但是哪里出的问题却没有任何线索。
有一些不响应的实例会阻止你在这些实例上执行类似 top 或者 htop 的远程命令。
服务器有一个瓶颈存在，但是你并不能简单快速的找到问题所在。
如果我们有一个完整的仪表盘可以帮助我们跟踪整体性能以及独立的进程该怎么操作？
可以在该链接中实时查看: http://grafana.devconnected.com/d/nZMDMoiZk/grafana-top?orgId=1&amp;refresh=5s
这篇入门文章旨在如何为 Linux 系统管理员创建一个完整的监控仪表盘
该仪表盘会展示完全可定制并且可扩展到分布式架构的多个实例的不同面板。
你将会学到什么 在即将踏入技术旅途之前，让我们快速看下通过阅读这篇文章你将学到哪些东西:
了解在 Unix 系统性能监控方面的最新技术；
怎样安装最新版本的 Prometheus v2.9.2、Pushgateway v0.8.0 以及 Grafana v6.2；
构建一个简单的 bash 脚本用来导出指标项到 Pushgateway；
构建一个完整的 Grafana 仪表盘包括最新的面板例如 ‘Gauge’ 和 ‘Bar Gauge’。
额外内容: 集成 ad-hoc 过滤器跟踪单个进程或实例。
现在我们大体浏览了一下我们将要学习哪些东西，并且没有进一步的要求，让我们介绍一些当前 Unix 系统中目前已有的内容。
Unix 进程监控基础 当提到 Unix 系统进程监控的时候，在你脑海中出现的有好几个选项。
最流行的或许就是 ‘top’ 了。
这个命令在系统管理员中间被广泛使用当系统出现性能瓶颈或许是第一条执行的命令（如果你可以访问它当然就是第一条！）
top 命令可读性已经是非常好了，但是仍有一条命令比 top 命令可读性更好：htop。</description>
</item>
<item>
<title>你的 DevOps 大脑：思考方式和工作方式</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/</link>
<pubDate>Mon, 01 Jun 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/</guid>
<description>我经常不得不说的 DevOps 神话之一就是 DevOps 完全是关于自动化和工具的。尽管二者是达到 DevOps 目标的基本要素（ DevOps 的目标是为了更快更安全地交付更有价值成果而优化从创意到价值实现的过程），但在 DevOps 的发展初期，Damon Edwards 和 John Willis 提出了 CALMS 这一缩写词来帮助解释有关 DevOps 的问题，其中字母 C 表示的文化也是一个重要元素。该想法得到了 Gartner 一篇文章的支持。该文章提到研究表明有 50％的受访者表示人的问题（与流程、技术和信息的问题相对）是目前采用 DevOps 原理和实践的最大障碍。我对自己客户的观察也支持这一想法，我的客户说文化是他们当下面临的最困难的挑战。
客户从一开始就这么说。大约七年前，当我们启动 Ranger4 的 DevOps 业务时，我们以为正在构建的是一个围绕软件和工具的业务。我们之前做么做过，并且这样做也是作为技术人员的合理选择。我们惊讶于客户一遍又一遍地问我们该如何改变文化。我们习惯于谈论技术；情感和感觉这些“软性”的东西是在饮水机旁闲谈的内容，或者用英式术语，说是酒吧里的话题。但是，当我们立即开始帮助客户后就迅速弄清了，文化可以被量化并文化生成的东西可以被确定。显而易见，文化本质上是行为，这很关键，因为我们意识到，可以使用一种在想到改变文化时常常令人感到莫名其妙的方式来影响行为，而文化这种模糊、多面的东西是很难理解的。
帮助组织采用 DevOps 原则意味着我们必须支持组织变革的推动者和领导者，帮助训练大量人力的大脑来理解和实践新的工作方式，从以项目为中心过渡到以产品、自治、价值流或链式思考以及跨职能、渐进式方法的重要转变。
工作做的越多，就越能意识到改变行为是核心，而其关键在于了解驱动行为的因素：我们的大脑。在过去的几年中，我发现神经科学在帮助组织变革上提供了大量指导。由于这是一门科学，是由数据驱动的，所以我们可以信任它。
关于我们都拥有的大脑的一些事实包括：
重 3 磅（体重的 2％） 使用人体内 20％的血液和氧气 干重的 60％是脂肪（那是相当多的） 100,000 英里的血管 2％的脱水时会影响认知能力 每分钟有一公升的血液流过大脑 人类的大脑与体重的比例是最大的 包含 860 亿个神经元 重要提示：如果您想了解更多有关大脑不同部位的信息，可以使用 Wellcome Trust 的交互式 3D 模型 AMAZE 。
关于神经元的一些事实：
它们使用电信号和化学信号相互沟通 神经元通过轴突链接产生神经回路 不同的回路执行不同的任务 一个神经元每秒可以传输 1,000 次神经冲动 大脑中有 10,000 种特定类型的神经元 脑信息以每小时 268 英里的速度传播 学习和不学习( unlearning ) 无一例外，我们客户都将努力从瀑布式过渡到敏捷作为业务和技术挑战核心。他们认识到自己正受到数字化的干扰。如果想要生存，能够蓬勃发展那更好，那么他们就需要在吞吐量和稳定性方面都能做得更好。但是，如果组织中的所有人（无论是 200 人还是 20,000 人）都接受过以项目为导向的工作方式的培训，资金也是以项目为导向，系统随着自身的发展而变成紧密耦合的整体，组织结构被孤立，组织中有负责变革咨询和发布管理团队，组织的工作被外包，技术发展滞后，那么组织中的人将很难改变自己的行为。实际上他们必须忘记（ unlearn ）多年甚至几十年已经学习到并坚信的东西。</description>
</item>
<item>
<title>Windows Docker Agent 镜像可以常规使用了</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-28-docker-windows-agents/</link>
<pubDate>Thu, 28 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-28-docker-windows-agents/</guid>
<description>我们想宣布可以使用官方 Windows agent Docker 镜像，这些镜像允许在 Docker 和 Kubernetes 上使用 Windows 操作系统配置 Jenkins agent。
新镜像 现在，所有 agent 的正式 Docker 镜像都提供 nanoserver-1809 和 windowsservercore-1809 标签，其中包括 Windows 镜像以及当前的 Java 8（类似于 latest 标签）。 我们还提供了明确的 Java 选择，例如 jdk8-windowsservercore-1809 或 jdk11-nanoserver-1809。 版本标记也可用，例如 jenkins/agent:4.3-4-jdk8-nanoserver-1809。
jenkins/agent 是一个基础的 agent，它捆绑 agent.jar 来进行 agent&lt;= =&gt; master之间的通讯，最有用的是可以作为其他镜像的基础镜像。Windows 镜像从版本 4.3-4 开始可用。
jenkins/inbound-agent 是一个基于上面 jenkins/agent 镜像的 agent，它提供了用 PowerShell 编写的包装类脚本，以帮助指定 agent.jar 的参数。Windows 镜像从版本 4.3-4 开始可用。
jenkins/ssh-agent 是一个安装了 OpenSSH 的镜像， 应该与 SSH Build Agents Plugin 一起使用。Windows 镜像从版本 2.</description>
</item>
<item>
<title>Jenkins 每周版更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-25-weekly-release/</link>
<pubDate>Mon, 25 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-25-weekly-release/</guid>
<description>2.237 (2020-05-18) 防止以 Java 11 运行时缺少 javax.annotation 类的导致的遥测告警(由 2.231 引入的缺陷回归)。 (issue 61920) 在类字段解组问题的情况下，防止 Old Data Monitor 插件加载失败。 (issue 62231) 确保在 UserLanguages 遥测初始化程序总是在扩展后运行。 (issue 60118) 确保 job/folder 创建事务正确检查请求的名称中是否包含无效字符。 (issue 61956) 开发者: 将 Apache Ant 从 1.10.7 更新到 1.10.8。 (pull 4725) 开发者: 将 JSTL API 库从 1.2.1 更新到 1.2.7。 (pull 4656, 变更日志更新到 1.2.5, 1.2.3 到 1.2.7 的差异, 1.2.1 到 1.2.3 的差异) 开发者: 在 Java API 中弃用 jenkins.model.Configuration。 (pull 4715) 2.</description>
</item>
<item>
<title>使用 Docker、Kubernetes 和 Azure DevOps 实现 DevOps</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-20-devops-with-docker-kubernetes-and-azure-devops/</link>
<pubDate>Wed, 20 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-20-devops-with-docker-kubernetes-and-azure-devops/</guid>
<description>这篇文章，我们将会分解关于你想了解的 DevOps 的所有知识，因而你可以着手构建自己的 CI/CD 流水线。
这篇文章，我们将注意力集中于 DevOps 上。
什么是 DevOps？它跟 Agile 有什么不同？有哪些受欢迎的 DevOps 工具？在 DevOps 中，Docker、Kubernetes 和 Azure DevOps 又是充当了什么样的角色。让我们从一个简单的使用场景开始这次的内容。
你将会学习 什么是 DevOps？
为什么我们需要 DevOps？
DevOps 和 Agile 有什么区别？
有哪些重要的 DevOps 工具？
Docker 怎样能够帮助到 DevOps？
Kubernetes 怎样能够帮助到 DevOps？
Azure DevOps 怎样能够帮助到 DevOps？
什么是持续集成，持续交付？
什么是基础设施即代码？
Terraform 和 Ansible 怎样能够帮助 DevOps？
免费课程 - 10 步速成 10 步学习 Docker</description>
</item>
<item>
<title>Jenkins 中文社区携手 KubeSphere，共建 DevOps 技术生态</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-19-jenkins-kubesphere-partner/</link>
<pubDate>Tue, 19 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-19-jenkins-kubesphere-partner/</guid>
<description>今天，Jenkins 中文社区 与 KubeSphere 开源社区 联合官宣，两大开源社区从今天开始正式合作，携手共建 DevOps 技术生态！
4 月 14 日，Jenkins 中文社区负责人 Rick 与 KubeSphere 社区多名成员，在技术层面、内容层面、开源社区建设等三个方向进行深入地探讨，最终对两个社区的合作不约而同地达成了一致。
在此次交流会上，KubeSphere 社区 Maintainer @runze xia 先向 Jenkins 中文社区介绍了 KubeSphere DevOps 的技术实现方案，以及为什么采用 Jenkins 作为 KubeSphere DevOps 的引擎。同时，Rick 也向 KubeSphere 社区介绍了 Jenkins-formulas 项目，该项目将来可用来替换 KubeSphere 当前的 Nginx 作为下载插件的 Update Center 方案。
并且，两个社区还将在开源协作与技术内容输出方向共同努力，为社区的开发者和用户带来 DevOps 相关的优质技术文章与实践案例。当然，有一些开发者和社区用户表示，两个社区都开始紧密合作了，两个社区的小伙伴们是不是要约时间面基了？这些要求我们都可以统统安排上！两大社区后续计划联合举办线上的技术直播分享活动、在线研讨会，以及线下 Meetup，欢迎社区小伙伴持续关注我们的动态。
交流会后，Rick 表示自己非常希望加入 KubeSphere 社区，参与 KubeSphere 社区贡献。KubeSphere 社区非常欢迎 Jenkins 中文社区的所有对 KubeSphere 与云原生技术兴趣的同学参与社区开发和文档贡献，KubeSphere 所有的代码、文档、沟通均在 GitHub、Slack 和论坛可见，对于 Jenkins 爱好者我们还在社区设立了 SIG-DevOps 供开发者交流，欢迎大家加入 Slack Channel。</description>
</item>
<item>
<title>Jenkins agent Docker 镜像重新命名了，你知道吗？</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-18-docker-agent-image-renaming/</link>
<pubDate>Mon, 18 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-18-docker-agent-image-renaming/</guid>
<description>我们正式宣布对 Jenkins agent 官方 Docker 镜像重新命名。 它不会对 Jenkins 用户产生任何直接影响，但是希望他们逐渐升级其实例。 本文提供了新的镜像名称、升级过程以及旧镜像支持策略等相关信息。 我们还将讨论在 Jenkins 中 Docker 包的下一步计划。
新镜像名称 jenkins/agent 是旧的 jenkins/slave 镜像从 4.3-2 开始的新名称 jenkins/inbound-agent 是旧的 jenkins/jnlp-slave 镜像从 4.3-2 开始的新名称 jenkins/ssh-agent 是旧的 jenkins/ssh-slave 镜像从 2.0.0 开始的新名称 请参阅下面的升级指南。
为什么要重新命名？ &ldquo;slave&rdquo; 一词在开源社区中被广泛认为是不合适的。它已于2016年在 Jenkins 2.0中正式弃用，但在某些 Jenkins 组件中仍有遗留用法。 这个 Epic —— JENKINS-42816：Slave 到 Agent 的重命名遗留问题 用于跟踪此类问题的清理。 官方 Docker agent 镜像是一个显而易见的案例，要修改在 DockerHub 上的旧版本镜像并非易事。很高兴这次更新终于解决了镜像命名问题。
另一个值得注意的变化是使用 inbound agent 代替 JNLP agent 术语。 历史上，&rdquo;JNLP&rdquo; 已被用作远程协议的名称。 JNLP 代表 Java Network Launch Protocol，它是 Java Web Start 的一部分。 在 Java 1.</description>
</item>
<item>
<title>致广大Jenkins 中文社区关注者的感谢信</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-16-a-thank-you-letter-for-jenkins-fans/</link>
<pubDate>Sat, 16 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-16-a-thank-you-letter-for-jenkins-fans/</guid>
<description>故事要从 2020/5/12 社区公众号发布的文章 手把手教会你 Jenkins 备份与恢复 说起。
1-先从故事本身说起 5月12日，公众号发布了一篇有关 Jenkins 备份与恢复的文章，其中分享了以下一段备份 Shell 脚本：
#!/bin/bash # Jenkins Configuraitons Directory cd $JENKINS_HOME # Add general configurations, job configurations, and user content git add -- *.xml jobs/*/*.xml userContent/* ansible/* # only add user configurations if they exist if [ -d users ]; then user_configs=`ls users/*/config.xml` if [ -n &quot;$user_configs&quot; ]; then git add $user_configs fi fi # mark as deleted anything that's been, well, deleted to_remove=`git status | grep &quot;deleted&quot; | awk '{print $3}'` if [ -n &quot;$toremove&quot; ]; then git rm --ignore-unmatch $toremove fi git commit -m &quot;Automated Jenkins commit&quot; git push -q -u origin master 文章格式核对完成后，便在公众号上发布了。</description>
</item>
<item>
<title>征集用户故事- Jenkins is the Way</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-15-call-for-user-stories-jenkins-is-the-way/</link>
<pubDate>Fri, 15 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-15-call-for-user-stories-jenkins-is-the-way/</guid>
<description>Jenkins Is The Way 参加开发者大会最让我们喜欢的一件事就是与 Jenkins 用户（无论是新手还是老用户）见面。用户们高兴地谈论自己的项目，分享如何使用 Jenkins 推进项目的技巧。自从冠状病毒大流行以来，我们正更多地依靠新的方式聚集起来，比如通过 Jenkins 在线聚会，GitHub 合作以及 Twitter threads。
这是一个重大的改变。但不变的是，分享用户构建的故事、解决方案，以及在实施 Jenkins 中获得的出色成果的这一需求。我们好奇，为什么没有人收集这些用户故事并与 Jenkins 社区分享。
引入 Jenkins Is The Way 因此，我们迈出了第一步，把社区中每个人用 Jenkins 创造的所有很棒的东西进行记录和存档。这样，Jenkins 的新老用户都可以使用这个存档搜索 Jenkins 解决方案以获取灵感。我们预见将会建成一个庞大的来自世界各地的解决方案的库，解决可以想象到的各个行业中的各种困难与挑战。我们决定将该档案称为“Jenkins Is The Way”，并将托管在 https://JenkinsIsTheWay.io 上。
为了汇总这些故事，我们创建了一个简单的在线问卷，以便 Jenkins 用户可以使用这个领先的开源自动化服务器提交自己的经验故事。拥有如此多的插件来支持构建、部署和自动化大家的项目，我们期待收集大量的故事。
我们已经收到了一些，包括一些说明了为什么 Jenkins Is The Way 的故事：
可以编写自己的发布流水线
可以创造持续交付
可以理解并简化软件生命周期
可以简化云端自动化
可以促进日常工作
添加您的故事，展示使用 Jenkins 的骄傲成果，获得 T 恤衫 通过分享您的 Jenkins 故事，成为可以激发 Jenkins 社区的灵感。只需访问此链接并填写表格即可。我们将会询问您的项目目标，使用 Jenkins 克服的技术挑战以及所创建的解决方案。只需20-30分钟就可以完成填表。
我们将故事整理并将其发布在 https://JenkinsIsTheWay.</description>
</item>
<item>
<title></title>
<link>https://jenkins-zh.cn/meeting/2020-05-13/</link>
<pubDate>Wed, 13 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/meeting/2020-05-13/</guid>
<description> UCloud 服务器管理 Nexus 上线了 http://repo.jenkins-zh.cn/ https 有问题 企业合作 KubeSphere 5月19日 官宣 https://github.com/jenkins-zh/jenkins-zh/pull/252 中信 招聘信息的发布（论坛） 技术活动没有确定 句子互动 作为赞助商 提供了一年的套餐 https://github.com/jenkins-zh/jenkins-zh/pull/271 禅道 技术分享 5月20日 有礼品赞助 文章的贡献（原创、翻译） 杰蛙 5月23日下午（周六），沙龙 F5 Nginx 中文社区成立的官宣 著作权 * 翻译文章不能算是原创（个例，来自 jenkins.io 可以在公众号里申明为原创） * 在社区提供的翻译稿，在我们的公众号上首次发布 * 应该说明作者、翻译者等的具体版权说明 社区激励 推文 https://github.com/jenkins-zh/jenkins-zh/issues/237 社区媒体账号运营情况 简书 @yJunS 开源中国 微博 公众号 </description>
</item>
<item>
<title>使用 Nexus OSS 为 Docker 镜像提供代理/缓存功能</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-13-using-nexus-oss-as-a-proxy-cache-for-docker-images/</link>
<pubDate>Wed, 13 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-13-using-nexus-oss-as-a-proxy-cache-for-docker-images/</guid>
<description>在企业环境中工作，无论是商业组织还是非商业组织，你会发现在互联网上获取信息存在着种种限制。
通常，服务器会运行在一个控制非常严格的环境中并且不能从互联网中获取资源以确保获取的所有资源都是安全的。
当你要使用一些公开的可获取的 Docker 容器时这会变得更麻烦，你会用到“古法”偷偷摸摸的把 Docker 镜像放到你的主机上。
对我而言，事情甚至更加困难。我需要一个通过第三方访问的（受限的）私有仓库。所以现在我该怎么办呢？
幸运的是，目前市面上有好几个可以作为代理或者‘拉入式缓存’的 Docker Registries，这正是我们所需要的。用来作为代理或者缓存的主机需要互联网的权限，而且只有这一台机器需要。其他所有需要获取 Docker 镜像的主机通过这台机器访问互联网，该机器同样很方便的缓存了数据这样只需要检索一次就可以更快的分发到内部局域网的主机上。
诸如 Sonatype Nexus、JFrog Artifactory、甚至 Docker Registry 都提供这些确切的功能，以及一些功能。这里我将会使用 Sonatype Nexus 完成所有的设置，主要的功能在 OSS 版本中可以使用（Artifactory 功能则是 Pro 版本的一部分功能）。
这篇文章将会向你展示怎样配置 Nexus OSS 来实现类似 Docker Hub ，私有仓库或者两者的结合那样的拉入式缓存功能。同样会向你展示怎样配置 Docker 客户端从而在检索镜像的时候能够使用到你的缓存。
需要的软件 Sonatype Nexus OSS 3.15.0（或更高版本）
Docker 17.09（或更高版本）
我设置了两个基于 Ubuntu LTS 版本的虚拟机，一个运行了 Sonatype Nexus 3.14.0 的 Docker 容器（这个机器称作 docker-host），另一个只运行 Docker（称作 docker-client）。
请注意一些网络配置或许跟你的配置不一样（例如 IP）但是方法是相同的。同样，请注意那台运行 Nexus OSS 的机器（docker-host）需要有访问互联网的权限。
[更新，2018年10月] 请使用 Nexus 3.</description>
</item>
<item>
<title>手把手教会你 Jenkins 备份与恢复</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-12-how-to-backup-and-restore-jenkins/</link>
<pubDate>Tue, 12 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-12-how-to-backup-and-restore-jenkins/</guid>
<description>前言 Jenkins 是一个 Java 语言编写的开源工具，结合持续集成与持续交付相关技术的运用可提升软件开发过程的自动化水平。
Jenkins 从最开始安装到权限设置，插件安装，任务维护等是一个费力的工程，因此定期备份数据的重要性不言而喻。
在本文中，我们将手把手演示如何备份并恢复 Jenkins。
备份操作指引 Step1：创建一个新的任务 这里推荐自由风格任务类型，即 Freestyle project
Step2：源码管理选择 None Step3：设置任务执行时间 选择 “Build Periodically”，然后可以根据需要设置备份时间和频率
例如，25 12 * * * 会在每天白天 12:25 运行任务
Step4：Build 模块添加 “Execute Shell” 在 Build 模块选择 Execute Shell，添加以下脚本内容
为方便读者直接使用，脚本内容如下：
#!/bin/bash # Jenkins Configuraitons Directory cd $JENKINS_HOME # Add general configurations, job configurations, and user content git add -- *.xml jobs/*/*.xml userContent/* ansible/* # only add user configurations if they exist if [ -d users ]; then user_configs=`ls users/*/config.</description>
</item>
<item>
<title>如何使用 Jenkins 声明式流水线</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-08-how-to-use-the-jenkins-declarative-pipeline/</link>
<pubDate>Fri, 08 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-08-how-to-use-the-jenkins-declarative-pipeline/</guid>
<description>Jenkins 为您提供了两种开发流水线代码的方式：脚本式和声明式。
脚本式流水线（也称为“传统”流水线）基于 Groovy 作为其特定于域的语言。 而声明式流水线提供了简化且更友好的语法，并带有用于定义它们的特定语句，而无需学习 Groovy。
Jenkins 的流水线插件版本2.5引入了对声明式流水线的支持。
在本文中，我们将介绍开发声明式流水线脚本的所有可用指令，这将清楚地说明其功能。
声明式流水线语法 必须使用 pipeline 语句定义有效的声明式流水线，并包括以下必需的部分：
agent stages stage steps 另外，还有这些可用的指令：
environment (在流水线或阶段级别定义) input (阶段级别定义) options (在流水线或阶段级别定义) parallel parameters post script tools triggers when 现在，我们将从所需的指令/部分开始，对列出的每个指令/部分进行描述。
agent Jenkins 通过将分布式构建委托给“代理/agent”节点来提供执行分布式构建的能力。 这样做可以使您仅使用 Jenkins 服务器的一个实例来执行多个项目，而工作负载却被分配给了它的代理。 有关如何配置主/代理模式的详细信息超出了本博客的范围。请参阅 Jenkins 分布式构建以获取更多信息。
代理应标记上标签，以便彼此轻松识别。 例如，节点可以通过其平台（Linux，Windows 等），其版本或位置等来标记。 “agent”部分配置流水线可以在哪些节点上运行。 指定 agent any 意味着 Jenkins 将在任何可用节点上运行任务。
其用法的一个示例可以是：
pipeline { agent any ... } stages 本部分允许在流水线上生成不同的阶段，这些阶段将在运行任务时显示为不同的段。
一个包含阶段语句的示例流水线：
pipeline { agent any stages { .</description>
</item>
<item>
<title>Jenkins CLI 命令行 v0.0.28</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-07-jcli-v0.0.28/</link>
<pubDate>Thu, 07 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-07-jcli-v0.0.28/</guid>
<description>截止到编辑本文时，GitHub 上统计到的下载量为：5,498次。GitHub 上的 Star 数为157，码云上的 Star 数为89。
Jenkins CLI 增加对了对插件机制的支持，用户可以通过编写插件的方式增强 jcli 的功能。第一个插件可以以 git 仓库的形式，在团队内部分享你的配置文件。
为了保证交付质量，我们增加了 e2e 测试。后续，也会逐渐增加 e2e 的测试用例。
🚀 功能 支持清理无效的配置项 (#383) @LinuxSuRen 在版本打印的命令中增加了日期 (#388) @LinuxSuRen 增加插件机制 (#385) @LinuxSuRen 支持打开外部链接 (#384) @LinuxSuRen 给命令 jcli center start 增加命令行补全 (#380) @LinuxSuRen 增加 man 文档的支持 (#382) @LinuxSuRen 给命令 jcli plugin upload 增加命令行补全 (#378) @LinuxSuRen 支持用指定的浏览器打开 (#377) @LinuxSuRen 🐛 缺陷修复 修复命令 job log 的错误帮助信息 (#375) @LinuxSuRen 命令 jcli doc 不需要读取配置文件 (#376) @yJunS 📝 文档完善 命令文档的完善 (#392) @LinuxSuRen 👻 维护 修复 readme 文件中失效的链接 (#393) @LinuxSuRen 升级 github.</description>
</item>
<item>
<title>为你的 GitLab 项目使用 k3s Kubernetes 集群</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-06-using-a-k3s-kubernetes-cluster-for-your-gitlab-project/</link>
<pubDate>Wed, 06 May 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-06-using-a-k3s-kubernetes-cluster-for-your-gitlab-project/</guid>
<description>TL;DR k3s 是一个轻量级的 Kubernetes 发行版（小于 40 MB），它非常容易安装，仅需要 512 MB 的 RAM。对 IoT 设备、边缘计算以及运行 CI 任务来说均是一个完美的选择。这篇文章中，我将创建一个 k3s 集群然后向你们展示怎样将它集成到一个 GitLab 项目中。
关于 k3s k3s 是一款由 Rancher Labs 开发的轻量级的 Kubernetes 发行版。
它作为 Kubernetes 认证的发行版使用最低的系统要求:
Linux 3.10+ 每个服务器 521 MB ram 每个节点 75 MB ram 200 MB 磁盘空间 x86_64，ARMv7，ARM64 这使得 k3s 非常适合 IoT 相关的事物。
在 GitLab 创建一个项目 在安装 k3s 之前，我们先在 GitLab 上创建一个名为 api 的新项目。
创建完成后，我们进入到 Operation &gt; Kubernetes 菜单。
这里我们有两种选择:
我们可以在 GKE（Google Kubernetes Engine）上创建一个 Kubernetes 集群。 我们可以导入一个已存在的 Kubernetes 集群的配置（不管在哪里创建的）。 注意: 最新版本的 GitLab，新集群只能在 GKE 中创建。GitLab，有没有允许在其他 Kubernetes 提供商（AKS、EKS、DOKS&hellip;）创建集群的计划呢？:)</description>
</item>
<item>
<title>使用 kind 和 Docker 启动本地的 Kubernetes</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-29-starting-local-kubernetes-using-kind-and-docker/</link>
<pubDate>Wed, 29 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-29-starting-local-kubernetes-using-kind-and-docker/</guid>
<description>介绍 你曾经花过一整天时间尝试入门 Kubernetes 吗？多亏最近新出现的一些工具，你可以不用再为此大费周章了。
这篇文章中，我将向你展示使用 kind 在单个 Docker 容器中启动一个集群的步骤。
什么是 kind？ kind 是一款使用 Docker 容器 “nodes” 运行 Kubernetes 集群的工具。 https://kind.sigs.k8s.io/
介绍看起来没有描述信息，但是很明显能知道是源于 “Kubernetes IN Docker”。该工具具备了跨平台友好的优势即便你使用的是 Windows 版本的 Docker。当然了，缺点就是它的可追溯性比较差。
安装 kind 因为 kind 是 go 语言实现的，请确保安装了最新版本的 golang。根据开发者文档，推荐使用 go1.11.5 及以上版本。为了安装 kind，请运行这些命令（可能需要运行一段时间）
go get -u sigs.k8s.io/kind kind create cluster 然后确认 “kind” 集群是可用的。
kind get clusters 设置 kubectl 同样的，使用 Homebrew 或者 Chocolatey 安装最新版本的 kubernetes-cli。最新版本的 Docker 包含了 Kubernetes 的功能，但使用的是老版本的 kubectl。
运行该命令检查它的版本号。</description>
</item>
<item>
<title>Jenkins 长期支持版更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-24-jenkins-release/</link>
<pubDate>Wed, 22 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-24-jenkins-release/</guid>
<description>2.222.1 (2020-03-25) Jenkins 启动时将不从磁盘加载全局构建丢弃程序的配置(JENKINS-61688)。 配置已保存，但在重新启动时将不加载。 Jenkins 2.222.1 将始终以 Job Build Discarder 的默认配置启动。 重新启动时将忽略自定义全局构建丢弃配置。 每次 Jenkins 重新启动时，都会配置默认的全局构建丢弃。
自 2.222 以来的变更： 重要安全修复。 (安全公告) 修复了任务配置表单中之前保存步骤中存在的拖放操作问题 (由 2.217 引入的缺陷回归)。 (issue 61429) Winstone 5.9: 修复最大表单内容大小和表单内容密钥的传递(由 Jetty 9.4.20 和 Jenkins 2.205 引入的缺陷回归)。 (pull 4542, issue 60409, Winstone 5.9 变更日志, Jetty 9.4.27 变更日志) Winstone 5.9: 修复由于 X-Forwarded-Host 和 X-Forwarded-Port 订阅问题而导致的将不正确的反向代理重定向到 Host 的问题(由 Jetty 9.4.20 和 Jenkins 2.205 引入的缺陷回归)。 (pull 4542, issue 60199, Winstone 5.</description>
</item>
<item>
<title>Kubernetes 构造可自由扩展的 Jenkins</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-22-scale-your-jenkins-agents-using-kubernetes/</link>
<pubDate>Wed, 22 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-22-scale-your-jenkins-agents-using-kubernetes/</guid>
<description>如果你是一名在职软件工程师，那你大概率已经使用过 Jenkins，至少听说过。
Jenkins 是目前最受欢迎的开源持续集成与持续交付（CI/CD）工具。为何它会受到如此多用户的追捧？诸如 CloudBees 这样的组织及相关优秀社区提供了坚实的帮助与支持，此外，一大批开发人员贡献了数以千计的插件，加上 Jenkins 良好的易用性，都让 Jenkins 从开源工具中脱颖而出。
基于以上特点，Jenkins 可以轻松实现以下事情：
结合主流版本管理工具，如 Git，Subversion 和 Mercurial； 集成代码质量管理工具，如 Sonarqube，Fortify； 使用 Maven 或 Gradle 构建 ； 使用 Junit 进行单元测试； 虽然 Jenkins 如此强大，但其入门使用却非常简单，你只需要准备一个 Web 应用服务器如 Tomcat 和一份可执行的安装文件 jenkins.war 即可。Jenkins 的运行方式有很多种，这里将介绍几种非常典型的方式。
独立的 Jenkins 服务器 在这种模式下，只有一个 Jenkins 服务器负责所有的构建任务并使用 TCP 连接部署到远程服务器上。这也是最简单的一种方式，你完全不需要担心其他可变因素。
主从策略 采用单机模式运行 Jenkins 有一些弊端。
尽管单机模式你无需考虑多服务器和节点，但当大量的构建任务在同一时间运行时，服务器可能会负荷过重。你可能会考虑增加节点可并发执行的构建任务数量，但是很快就会遇到性能瓶颈。
为了解决这个问题，你可以将部分任务分发到其他的机器上去，即 Jenkins 从节点。Jenkins 从节点会运行一段程序与主节点进行通信，判断是够有可执行的构建任务。一旦 Jenkins 主节点调度安排好构建任务，就将其分发至相应的从节点。那我们的问题解决了吗？接着往下看。
可扩展的 Jenkins 我们进一步来探索 Jenkins 的运行方式。当你的团队中还未建立 CI 时，你可能无需多台静态服务器来执行 Jenkins 任务。
当你无需 7*24 运行时，你的服务器可能会空闲，这时就产生资源浪费了。</description>
</item>
<item>
<title>Jenkins 每周版更新</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-20-weekly-release/</link>
<pubDate>Mon, 20 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-20-weekly-release/</guid>
<description>2.230 (2020-04-06) 改进告警横幅的样式，使其更具视觉吸引力并更好地匹配现有的用户界面组件。 现在，警报在显示时完全覆盖了导航栏，而不是仅覆盖导航栏的一部分。 (issue 61478) 检查任何一个权限时，权限错误中将不再显示已禁用的权限。 (issue 61467) 显示与标签相关而非单个节点的阻塞原因时，允许使用超链接。 (pull 4616) 添加选项以支持配置归档制品时的符号链接。 (issue 5597) 除了通常的全局/Administer权限之外，具有全局/管理权限的用户现在也可以访问准备关机管理链接。 (issue 61453) 更新页脚样式。 (issue 61496) 允许 configuration-as-code plugin 禁用管理员监控。 (issue 56937) 更新 Groovy Init hooks，使其在任务配置修改后运行。 (issue 61694) 修复指纹清除线程中的类强制转换异常。 (issue 61479) 2.229 (2020-03-29) 重新启动时使用保存的全局构建丢弃配置。 Jenkins 2.221 到 2.228 在重新启动时会忽略保存的全局构建丢弃配置。 (issue 61688) 修复设置密码后代理表单验证的问题(由 2.205 引入的缺陷回归)。 (issue 61692) 更新 .NET 版本检查，使其更适合自带的 .NET 版本。 (pull 4554) 具有全局/管理或全局/系统读取（以及通常的全局/Administer）权限的用户可以访问关于 Jenkins 的管理链接。 (issue 61455) 稳定性: 将 null 转换为 Secret 时不再抛出 NullPointerException。 (pull 4608) 升级到 Remoting 4.</description>
</item>
<item>
<title></title>
<link>https://jenkins-zh.cn/meeting/2020-04-15/</link>
<pubDate>Wed, 15 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/meeting/2020-04-15/</guid>
<description> UCloud 服务器管理 开始部署 Jenkins 运行的位置保持不变（阿里云） 与 KubeSphaere 社区合（青云）作 技术方向 https://github.com/jenkins-zh/jenkins-formulas 内容 互相推送一些文章、投稿等等 社区激励 记录第三次社区激励的记录 @yJunS
社区媒体账号运营情况 简书 @yJunS changelog 有定时更新 @zhaoying818 讲师征集 @linan607 </description>
</item>
<item>
<title>使用 Vault 与 Kubernetes 为密码提供强有力的保障</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2019-04-15-effective-secret-with-vault-and-kubernetes/</link>
<pubDate>Wed, 15 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2019-04-15-effective-secret-with-vault-and-kubernetes/</guid>
<description>介绍 Kubernetes 已经成为了容器编排方案的工业标准，而来自 HashiCorp 的 Vault 则是密码管理的工业标准。那问题来了: 怎样将这两项技术结合使用从而可以让你在 Kubernetes 的应用程序中使用来自于 Vault 中心实例的密码呢？
一种解决方法是使用 AppRole 认证。Boostport 为 AppRoles 在 Kubernetes 上的使用提供了完美的集成。另一个可行的方法是使用 Kubernetes 认证。这种认证机制为 Vault 和 Kubernetes 集群创建一个可信的联系因而你可以使用一个服务账号到 Vault 进行认证。后期你可以使用 Kubernetes 的 Vault 节点获取和更新认证令牌。
这篇实践的文章中，我会向你展示如何使用一些 Go 助手工具实现诸如认证更新令牌这些相同的工作，并且还会进一步实现-从 Vault 到 Kubernetes 同步预定义的密码子集。
等级: 高级
准备工作 简单起见我有一些选项:
用多种不同的方法启动一个 Kubernetes 集群。通常来说，minikube 用来测试或者开发。我会使用 kubeadm 因为它非常简单的就可以启动一个*真正的*集群。
在 Kubernetes 中，会使用 default 命名空间。
Vault 会在*开发*模式下运行。不要像在生产环境下那样使用它！ 确保在环境变量中设置了 VAULT_ADDR。
代码示例中会使用 Ubuntu。这些已经在 GCE 上配置为 2 vCPU 和 7.</description>
</item>
<item>
<title>Jenkins CLI 命令行 v0.0.27</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-10-jcli-v0.0.27/</link>
<pubDate>Fri, 10 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-10-jcli-v0.0.27/</guid>
<description>在本次更新中，利用 GitHub Actions 和 GoReleaser 实现了自动化版本发布。为了满足更多用户的使用场景，给出了包括：.deb、.rpm 以及 arm 架构等20种不同的包格式。
截止到编辑本文时，GitHub 上统计到的下载量为：4,985次。GitHub 上的 Star 数为146，码云上的 Star 数为87。
另外，为了让更多的 Jenkins 用户尽快地熟悉 Jenkins CLI 的功能，并上手改进日常的工作。大家可以访问下面的交互式教程：
https://www.katacoda.com/jenkins-zh
🚀 功能 支持构建插件工程 (#355) @LinuxSuRen 增加用于清空 Jenkinsfile 中的空白字符的参数 (#363) @LinuxSuRen 支持传递给自定义 Jenkins 配方的参数 (#364) @LinuxSuRen 增加对构建自定义 Jenkins 的支持 (#340) @LinuxSuRen 支持启用、禁用 Jenkins 任务 (#352) @LinuxSuRen 增加可以直接重启 Jenkins 的参数 (#345) @LinuxSuRen 支持编辑空的流水线时，提供一份样本 (#361) @LinuxSuRen 增加 goreleaser 配置文件 (#347) @LinuxSuRen 📝 文档完善 为 jcli 增加一个交互式教程 (#362) @LinuxSuRen 增加如何通过 yum 安装 jcli 的说明 (#348) @LinuxSuRen 👻 维护 不再推送开发中的 Docker 镜像 (#371) @LinuxSuRen 利用 GitHub Actions 来发布版本 (#370) @LinuxSuRen 增加对 arm 架构的支持 (#351) @LinuxSuRen github.</description>
</item>
<item>
<title>自定义 Jenkins 发行版就是这么简单</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-09-custom-jenkins-war/</link>
<pubDate>Thu, 09 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-09-custom-jenkins-war/</guid>
<description>Jenkins 是一个由开源社区驱动的项目，拥有非常丰富的插件生态，任何人都可以根据社区给出的指南为之作出贡献，甚至是将自己开发的插件托管到 Jenkins 社区。从插件市场上能看到，到目前为止有超过1500个插件可供 Jenkins 的用户挑选。当我们走进 Jenkins 这个巨型超市时，有多少人曾经有过这样的感觉——看着琳瑯满目的商品，却完全无从下手？自由风格，流水线即代码，申明式流水线，多分支流水线，配置即代码，又有多少人被应接不暇的社区新概念搞得没了头绪？
让我们暂且不去关心其他语言的用户体验如何，单看 Jenkins 简体中文插件3万左右的下载量，就足以证明 Jenkins 中文本地化工作对很多用户是有意义的。在之前的一篇博文中，我们从改善用户下载、更新插件的角度出发，发布了 Jenkins 插件中心国内源。在此，需再次对清华大学开源镜像站等组织对开源项目的支持，让更多的人得以站在巨人的肩膀上前行。在过去的四个月的时间里，插件国内源的用户在逐步上升；用户检查更新插件的峰值为931次/天。
从上面的两个数据中，不难看出，还是有相当一部分用户还没有享受到插件国内源的益处。这可能有多个原因导致：文档不清晰、配置步骤繁杂、服务器不稳定等等。对于文档、配置等问题而言，一个杀手级的一个解决方案就是——不需要文档和配置。本文要介绍给大家的就是这么一种开箱即用的方案，就像乐高积木一样，而用户只需要提交一个订单（YAML 文件）就能拿到他所需要的 Jenkins 发行版。是的，作为用户，不仅不再需要配置国内源，甚至都不需要下载和配置插件。
Jenkins 自定义发行版项目，默认提供了几个常用的配方，并支持用户以 YAML 的格式提交配方。这里的配方，包括了发行版中 Jenkins Core 的版本、插件列表、插件配置、初始化脚本等等。一旦提交的配方 Pull Request 合并到 master 分支后，就可以自动地构建出来对应的 docker 镜像以及 jenkins.war 文件。如果 Jenkins 有了新版本的话，是否还需要重新提交配方请求呢？我们已经考虑到了这一点，一旦有新版本发布的话，会自动构建出来对应的发行版（也许会有一天的延迟）。大家如果喜欢这个方案的话，可以关注托管在码云或者 GitHub 上的项目。目前，Docker 镜像的下载量已经有3000+，心动不如行动，赶快试试吧！
现有的配方包括：
配方 镜像 配置即代码 + 简体中文 jenkinszh/jenkins-zh:2.204.5 配置即代码 + 流水线 jenkinszh/jenkins-pipeline:2.204.5 配置即代码 + 流水线 + K8s jenkinszh/jenkins-k8s:2.204.5 多分支流水线 + BlueOcean jenkinszh/blueocean-zh:2.</description>
</item>
<item>
<title>以代码的形式构建 Jenkins</title>
<link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-08-build-jenkins-as-a-code/</link>
<pubDate>Wed, 08 Apr 2020 00:00:00 +0000</pubDate>
<guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-08-build-jenkins-as-a-code/</guid>
<description>在我们公司，我们尝试使用‘一切事物即代码’的模式，该模式涉及到可复制的基础架构，监控，任务等方面。但是，在这篇文章当中，我将向你展示怎样将这种模式运用到 Jenkins 上。是的，我的意思是对于 Jenkins 完全可复制的配置，以及基础架构、插件、凭据、任务以及代码中的其他东西。另外，这篇文章你将解惑下面的疑问:
我们的 Jenkins 已经变得更加稳定了吗？