1 00:00:06,320 --> 00:00:11,499 [Music] 2 00:00:15,599 --> 00:00:18,560 good afternoon welcome back 3 00:00:17,760 --> 00:00:21,520 um 4 00:00:18,560 --> 00:00:23,840 russell curry is a linux and open source 5 00:00:21,520 --> 00:00:27,279 hacker and microsoft powerpoint 2003 6 00:00:23,840 --> 00:00:28,880 aficionado um who works at ibm oz labs 7 00:00:27,279 --> 00:00:31,199 uh on the 8 00:00:28,880 --> 00:00:33,840 power platform focusing on linux kernel 9 00:00:31,199 --> 00:00:36,079 hardening and continuous integration uh 10 00:00:33,840 --> 00:00:38,640 he'll be presenting to us today on 11 00:00:36,079 --> 00:00:40,399 using or abusing github actions for 12 00:00:38,640 --> 00:00:42,559 building and testing kernels thank you 13 00:00:40,399 --> 00:00:44,719 russell 14 00:00:42,559 --> 00:00:45,760 thanks a lot andrew uh it's good to be 15 00:00:44,719 --> 00:00:49,280 back 16 00:00:45,760 --> 00:00:50,800 at the colonel miniconf um 17 00:00:49,280 --> 00:00:53,680 i apologize 18 00:00:50,800 --> 00:00:55,520 slightly for the eye searing madness you 19 00:00:53,680 --> 00:00:59,120 are currently witnessing on your screens 20 00:00:55,520 --> 00:01:00,640 and i'm not just referring to my face 21 00:00:59,120 --> 00:01:02,399 in this talk i'm going to talk about 22 00:01:00,640 --> 00:01:04,799 github actions for for kernel 23 00:01:02,399 --> 00:01:06,880 development and what's why that might be 24 00:01:04,799 --> 00:01:09,119 relevant to you um you might be 25 00:01:06,880 --> 00:01:10,840 wondering why should i care about a 26 00:01:09,119 --> 00:01:12,400 proprietary 27 00:01:10,840 --> 00:01:14,880 centralized uh 28 00:01:12,400 --> 00:01:16,080 vendor lock-in-ish platform 29 00:01:14,880 --> 00:01:17,600 that 30 00:01:16,080 --> 00:01:19,600 we don't even use 31 00:01:17,600 --> 00:01:21,600 for kernel development you might also be 32 00:01:19,600 --> 00:01:22,720 wondering uh why you're looking at word 33 00:01:21,600 --> 00:01:24,640 art 34 00:01:22,720 --> 00:01:27,600 i hope to answer one of these questions 35 00:01:24,640 --> 00:01:30,240 appropriately by the end of the talk so 36 00:01:27,600 --> 00:01:32,240 so let's get into it let's go over 37 00:01:30,240 --> 00:01:36,079 what github actions is and then we can 38 00:01:32,240 --> 00:01:38,159 look at why it might be a value to us 39 00:01:36,079 --> 00:01:39,280 github actions is a continuous 40 00:01:38,159 --> 00:01:41,040 integration 41 00:01:39,280 --> 00:01:42,560 service provided by 42 00:01:41,040 --> 00:01:44,000 by github 43 00:01:42,560 --> 00:01:47,040 if you think about how a typical 44 00:01:44,000 --> 00:01:49,119 software project works on github if it 45 00:01:47,040 --> 00:01:51,439 uses github for development you know 46 00:01:49,119 --> 00:01:53,360 people send pull requests and when they 47 00:01:51,439 --> 00:01:55,200 send the pull request that code will get 48 00:01:53,360 --> 00:01:57,040 built and tested and 49 00:01:55,200 --> 00:01:58,880 if there's something wrong with it it'll 50 00:01:57,040 --> 00:02:01,119 flag that on the pull request there'll 51 00:01:58,880 --> 00:02:02,880 be like an inline if it can narrow down 52 00:02:01,119 --> 00:02:05,680 the problem to a specific line of code 53 00:02:02,880 --> 00:02:07,119 it'll like be there visually in the 54 00:02:05,680 --> 00:02:08,879 code review 55 00:02:07,119 --> 00:02:10,800 stuff 56 00:02:08,879 --> 00:02:13,599 for release management and builds and 57 00:02:10,800 --> 00:02:16,319 publishing you can use github actions if 58 00:02:13,599 --> 00:02:18,640 you maintain software packages to build 59 00:02:16,319 --> 00:02:20,640 for a variety of different platforms and 60 00:02:18,640 --> 00:02:23,920 and publish that to 61 00:02:20,640 --> 00:02:25,840 docker hub or whatever um we don't care 62 00:02:23,920 --> 00:02:29,040 about any of that uh 63 00:02:25,840 --> 00:02:31,200 that's not what we're here for um 64 00:02:29,040 --> 00:02:33,440 there's one main reason why i think 65 00:02:31,200 --> 00:02:35,440 github actions is quite valuable to us 66 00:02:33,440 --> 00:02:37,920 in the kernel development world and it 67 00:02:35,440 --> 00:02:40,959 can be summarized in in three magic 68 00:02:37,920 --> 00:02:44,800 words and those three magic words are 69 00:02:40,959 --> 00:02:47,440 unlimited free compute now 70 00:02:44,800 --> 00:02:50,160 i'm not sure about you but when i see 71 00:02:47,440 --> 00:02:51,920 these three words uh my brain produces 72 00:02:50,160 --> 00:02:54,160 the the happy chemicals my brain gets 73 00:02:51,920 --> 00:02:56,560 excited when i see this i start thinking 74 00:02:54,160 --> 00:02:59,680 of the many possibilities i could take 75 00:02:56,560 --> 00:03:02,080 advantage of with with this resource 76 00:02:59,680 --> 00:03:03,599 and so it doesn't really matter well it 77 00:03:02,080 --> 00:03:05,920 doesn't matter but it's not a deal 78 00:03:03,599 --> 00:03:08,720 breaker that the platform is is 79 00:03:05,920 --> 00:03:10,480 proprietary and centralized when we can 80 00:03:08,720 --> 00:03:12,400 use it for 81 00:03:10,480 --> 00:03:14,480 unlimited free compute to make our 82 00:03:12,400 --> 00:03:16,400 kernel development better so that's what 83 00:03:14,480 --> 00:03:19,519 i'm going to get into today 84 00:03:16,400 --> 00:03:20,640 uh so to explain a little bit more about 85 00:03:19,519 --> 00:03:22,720 why that is 86 00:03:20,640 --> 00:03:26,080 github makes the service available for 87 00:03:22,720 --> 00:03:28,000 free to public repositories 88 00:03:26,080 --> 00:03:30,560 not strictly open source because you can 89 00:03:28,000 --> 00:03:33,120 have a public repository with a 90 00:03:30,560 --> 00:03:35,440 proprietary license and that would still 91 00:03:33,120 --> 00:03:36,959 have this but you know the idea from 92 00:03:35,440 --> 00:03:38,480 github is that this is a give back to 93 00:03:36,959 --> 00:03:39,200 the open source community and then you 94 00:03:38,480 --> 00:03:40,640 know 95 00:03:39,200 --> 00:03:41,920 you might use this for your personal 96 00:03:40,640 --> 00:03:43,760 project think it's good and then 97 00:03:41,920 --> 00:03:45,360 convince your employer to pay for it and 98 00:03:43,760 --> 00:03:48,400 so i guess that's the 99 00:03:45,360 --> 00:03:50,000 the business model um so let's get into 100 00:03:48,400 --> 00:03:52,080 what it can do 101 00:03:50,000 --> 00:03:53,920 and and what it can do for us so if you 102 00:03:52,080 --> 00:03:55,120 think about what it can do 103 00:03:53,920 --> 00:03:57,280 and how that might be relevant to the 104 00:03:55,120 --> 00:03:59,439 kernel well the answer is you can do it 105 00:03:57,280 --> 00:04:01,920 kind of do anything it's just a server 106 00:03:59,439 --> 00:04:03,360 you get given a server on which you can 107 00:04:01,920 --> 00:04:06,239 execute 108 00:04:03,360 --> 00:04:08,799 whatever you want um 109 00:04:06,239 --> 00:04:11,040 except they don't have nested kvm so 110 00:04:08,799 --> 00:04:12,720 that's somewhat of a limiter but aside 111 00:04:11,040 --> 00:04:15,360 from that anything you can do within a 112 00:04:12,720 --> 00:04:17,519 virtual machine running linux you can do 113 00:04:15,360 --> 00:04:19,919 the the the limitation is that you're 114 00:04:17,519 --> 00:04:21,600 running inside a relatively crummy vm 115 00:04:19,919 --> 00:04:23,840 that you know you're not going to be 116 00:04:21,600 --> 00:04:26,240 able to make that j200 and have it 117 00:04:23,840 --> 00:04:28,000 complete in a minute 118 00:04:26,240 --> 00:04:29,440 you're going to be constrained by that 119 00:04:28,000 --> 00:04:31,440 but there's still a lot you can get done 120 00:04:29,440 --> 00:04:33,520 within those constraints 121 00:04:31,440 --> 00:04:35,360 and that can definitely be a value so 122 00:04:33,520 --> 00:04:36,880 let's let's get a bit more into it let's 123 00:04:35,360 --> 00:04:39,120 build a kernel 124 00:04:36,880 --> 00:04:40,560 the bare minimum requisite to get some 125 00:04:39,120 --> 00:04:42,720 value out of the service is to have it 126 00:04:40,560 --> 00:04:45,040 build kernels for us so let's figure out 127 00:04:42,720 --> 00:04:45,759 what we need to be able to do that 128 00:04:45,040 --> 00:04:47,360 so 129 00:04:45,759 --> 00:04:49,840 you need a github repository so you need 130 00:04:47,360 --> 00:04:51,280 a github account you need a reaper you 131 00:04:49,840 --> 00:04:53,360 may need to go into the settings of that 132 00:04:51,280 --> 00:04:55,360 repo and manually enable actions if you 133 00:04:53,360 --> 00:04:56,560 haven't done so before you need the 134 00:04:55,360 --> 00:04:58,479 source tree 135 00:04:56,560 --> 00:05:00,479 you could 136 00:04:58,479 --> 00:05:01,680 within your action get the source tree 137 00:05:00,479 --> 00:05:03,039 from a different repo but for 138 00:05:01,680 --> 00:05:04,320 simplicity's sake we'll say it's in the 139 00:05:03,039 --> 00:05:06,160 same one 140 00:05:04,320 --> 00:05:08,080 and you need a workflow file this is the 141 00:05:06,160 --> 00:05:11,199 the special source that actually tells 142 00:05:08,080 --> 00:05:14,080 github what to do this is a file checked 143 00:05:11,199 --> 00:05:16,479 into the repository it's in dot github 144 00:05:14,080 --> 00:05:18,160 workflows so it needs to be committed to 145 00:05:16,479 --> 00:05:20,320 the repository none of this is 146 00:05:18,160 --> 00:05:22,400 configured externally to the repository 147 00:05:20,320 --> 00:05:23,520 all lives in in the repo so you could 148 00:05:22,400 --> 00:05:24,639 check this in 149 00:05:23,520 --> 00:05:26,960 into git 150 00:05:24,639 --> 00:05:30,080 uh good luck up streaming that but you 151 00:05:26,960 --> 00:05:31,759 know depending on your workflow 152 00:05:30,080 --> 00:05:33,680 so what's a workflow file how do we how 153 00:05:31,759 --> 00:05:36,800 do we get one how do we how do we get 154 00:05:33,680 --> 00:05:37,759 this going uh the workflow 155 00:05:36,800 --> 00:05:40,080 is 156 00:05:37,759 --> 00:05:42,320 described in yaml which is a 157 00:05:40,080 --> 00:05:44,160 another markup language 158 00:05:42,320 --> 00:05:46,320 they're all the same they all have 159 00:05:44,160 --> 00:05:48,320 different syntax they're all 160 00:05:46,320 --> 00:05:51,039 kind of annoying 161 00:05:48,320 --> 00:05:53,120 you need to define within that file what 162 00:05:51,039 --> 00:05:55,360 triggers the workflow so 163 00:05:53,120 --> 00:05:58,400 what are the conditions for it to run 164 00:05:55,360 --> 00:06:00,880 you need to describe what the workflow 165 00:05:58,400 --> 00:06:02,560 will run on so 166 00:06:00,880 --> 00:06:05,280 what hardware essentially what you are 167 00:06:02,560 --> 00:06:07,039 asking github for and then you know the 168 00:06:05,280 --> 00:06:09,199 meat and potatoes of what does the 169 00:06:07,039 --> 00:06:10,880 action actually do 170 00:06:09,199 --> 00:06:12,800 so quickly looking at triggers this 171 00:06:10,880 --> 00:06:14,639 isn't particularly interesting to us 172 00:06:12,800 --> 00:06:17,120 we're pretty much just going to be using 173 00:06:14,639 --> 00:06:19,520 push triggers for the workflows i have 174 00:06:17,120 --> 00:06:21,039 in mind but um there's a lot of stuff 175 00:06:19,520 --> 00:06:22,720 here and if you go to the documentation 176 00:06:21,039 --> 00:06:24,560 there's a whole bunch of stuff that's 177 00:06:22,720 --> 00:06:26,400 probably largely irrelevant if you don't 178 00:06:24,560 --> 00:06:28,880 have a very github-centric 179 00:06:26,400 --> 00:06:30,720 you know workflow already 180 00:06:28,880 --> 00:06:32,479 you can have stuff trigger whenever you 181 00:06:30,720 --> 00:06:35,280 push to any branch whenever you push to 182 00:06:32,479 --> 00:06:36,960 specific branches on pull requests which 183 00:06:35,280 --> 00:06:38,479 we probably won't use 184 00:06:36,960 --> 00:06:40,400 manual triggers so that's either you 185 00:06:38,479 --> 00:06:44,880 know going in and clicking a button in 186 00:06:40,400 --> 00:06:44,880 the ui or making an api request 187 00:06:45,520 --> 00:06:48,800 and there's also a bunch of filtering 188 00:06:46,880 --> 00:06:51,520 you can do based on the actual contents 189 00:06:48,800 --> 00:06:53,759 of the commit or the the body of work 190 00:06:51,520 --> 00:06:55,440 a common example is that you have 191 00:06:53,759 --> 00:06:58,080 actions that are going to run tests and 192 00:06:55,440 --> 00:06:59,759 those tests are only going to run if 193 00:06:58,080 --> 00:07:01,440 the subsystem that they're testing has 194 00:06:59,759 --> 00:07:03,360 actually changed so if there's no code 195 00:07:01,440 --> 00:07:04,880 changes in the subsystem you probably 196 00:07:03,360 --> 00:07:06,800 don't need to waste time testing it on 197 00:07:04,880 --> 00:07:08,240 this given commit so 198 00:07:06,800 --> 00:07:10,400 there's a bunch of fanciness you can do 199 00:07:08,240 --> 00:07:11,840 there 200 00:07:10,400 --> 00:07:13,680 now let's talk about 201 00:07:11,840 --> 00:07:15,440 where it's actually going to run 202 00:07:13,680 --> 00:07:18,639 we're going to be talking about github's 203 00:07:15,440 --> 00:07:20,479 freely provided hosted runners now you 204 00:07:18,639 --> 00:07:22,000 can provide your own you can you can 205 00:07:20,479 --> 00:07:25,280 bring your own 206 00:07:22,000 --> 00:07:26,800 and give github an ssh key and then run 207 00:07:25,280 --> 00:07:30,479 their software on your machine do i 208 00:07:26,800 --> 00:07:32,160 think it's only x86 and maybe arm you 209 00:07:30,479 --> 00:07:34,160 know but then you're buying into a 210 00:07:32,160 --> 00:07:36,479 proprietary ecosystem 211 00:07:34,160 --> 00:07:37,759 uh without using their computers for 212 00:07:36,479 --> 00:07:39,520 free so that's a bit less fun so i'm not 213 00:07:37,759 --> 00:07:40,720 going to talk about that 214 00:07:39,520 --> 00:07:42,639 instead we're going to talk about you 215 00:07:40,720 --> 00:07:46,720 know the two viable options for us which 216 00:07:42,639 --> 00:07:48,240 is ubuntu and older ubuntu 217 00:07:46,720 --> 00:07:50,080 there's also other operating systems 218 00:07:48,240 --> 00:07:52,000 that you might want for other projects 219 00:07:50,080 --> 00:07:53,520 but we're looking at two ubuntu's if 220 00:07:52,000 --> 00:07:54,800 you're not a fan of ubuntu you can you 221 00:07:53,520 --> 00:07:56,319 know there's 222 00:07:54,800 --> 00:07:58,960 container runtimes you can do whatever 223 00:07:56,319 --> 00:08:02,960 you want to get into a build environment 224 00:07:58,960 --> 00:08:02,960 you prefer but you start with ubuntu 225 00:08:03,199 --> 00:08:08,000 these are hosted on microsoft azure 226 00:08:05,039 --> 00:08:10,800 github is owned by microsoft 227 00:08:08,000 --> 00:08:13,039 github actions is derivative from azure 228 00:08:10,800 --> 00:08:15,599 pipelines i believe if you've done azure 229 00:08:13,039 --> 00:08:16,639 stuff you might recognize this class of 230 00:08:15,599 --> 00:08:18,720 instances 231 00:08:16,639 --> 00:08:20,960 uh but they're not too hot right you get 232 00:08:18,720 --> 00:08:23,360 a two core cpu from a xeon from 233 00:08:20,960 --> 00:08:24,240 somewhere in the last several years um 234 00:08:23,360 --> 00:08:26,720 from 235 00:08:24,240 --> 00:08:29,280 you know lower end zeons from 2021 back 236 00:08:26,720 --> 00:08:31,599 to haswell which is like 24 nanometer i 237 00:08:29,280 --> 00:08:34,479 think um 238 00:08:31,599 --> 00:08:36,320 there's seven gigs of ram and 14 gigs of 239 00:08:34,479 --> 00:08:37,519 disk space per 240 00:08:36,320 --> 00:08:40,800 instance 241 00:08:37,519 --> 00:08:42,959 so that is not what you get total across 242 00:08:40,800 --> 00:08:46,160 your repository that is what you get for 243 00:08:42,959 --> 00:08:47,440 one configuration of one job at once so 244 00:08:46,160 --> 00:08:48,880 you can have a lot of these running at 245 00:08:47,440 --> 00:08:50,399 the same time 246 00:08:48,880 --> 00:08:52,839 it's not like your entire workload must 247 00:08:50,399 --> 00:08:57,519 be constrained to this single 248 00:08:52,839 --> 00:09:00,240 vm and finally we have the you know 249 00:08:57,519 --> 00:09:01,680 the workflow file we have 250 00:09:00,240 --> 00:09:04,080 putting it all together to build a 251 00:09:01,680 --> 00:09:05,360 kernel this is everything you need to 252 00:09:04,080 --> 00:09:07,040 build a kernel well there's another 253 00:09:05,360 --> 00:09:08,480 slide these two slides are everything 254 00:09:07,040 --> 00:09:10,480 you need to be able to be able to build 255 00:09:08,480 --> 00:09:11,279 a kernel through the system 256 00:09:10,480 --> 00:09:12,640 so 257 00:09:11,279 --> 00:09:14,320 let's go over it you know we've got a 258 00:09:12,640 --> 00:09:16,000 cosmetic name there we're calling this 259 00:09:14,320 --> 00:09:17,839 this workflow kernel build we're 260 00:09:16,000 --> 00:09:21,839 triggering it on push so this will run 261 00:09:17,839 --> 00:09:23,279 whenever any push is made to any branch 262 00:09:21,839 --> 00:09:25,440 are 263 00:09:23,279 --> 00:09:27,040 defining a job called kernel and saying 264 00:09:25,440 --> 00:09:31,440 that it runs on 265 00:09:27,040 --> 00:09:33,680 ubuntu latest which is ubuntu latest lts 266 00:09:31,440 --> 00:09:35,760 so that will you know go out to their 267 00:09:33,680 --> 00:09:38,000 gigantic farm of vms and find them on 268 00:09:35,760 --> 00:09:40,080 the title and make it run your stuff the 269 00:09:38,000 --> 00:09:42,880 stuff that's going to run gets defined 270 00:09:40,080 --> 00:09:44,720 in the steps of that job so 271 00:09:42,880 --> 00:09:45,920 first up we've got a users which 272 00:09:44,720 --> 00:09:47,760 essentially 273 00:09:45,920 --> 00:09:51,040 instead of defining our own commands to 274 00:09:47,760 --> 00:09:53,839 run we are going to use a predefined 275 00:09:51,040 --> 00:09:56,480 action in this case it comes from github 276 00:09:53,839 --> 00:09:59,040 but you can get actions from 277 00:09:56,480 --> 00:10:00,720 anywhere essentially it like there's a 278 00:09:59,040 --> 00:10:02,399 marketplace thing 279 00:10:00,720 --> 00:10:05,040 you know people in the community sharing 280 00:10:02,399 --> 00:10:06,560 their own their own pre-made actions to 281 00:10:05,040 --> 00:10:09,200 save you from doing some stuff yourself 282 00:10:06,560 --> 00:10:10,720 so you can look through and find stuff 283 00:10:09,200 --> 00:10:12,640 probably of limited relevance to the 284 00:10:10,720 --> 00:10:13,680 kernel but there's certainly stuff out 285 00:10:12,640 --> 00:10:15,200 there 286 00:10:13,680 --> 00:10:16,480 that could be useful 287 00:10:15,200 --> 00:10:18,560 um so in this case it's just going to 288 00:10:16,480 --> 00:10:21,360 check out our repo on disk so uh 3 is 289 00:10:18,560 --> 00:10:24,320 going to be it slash home slash runner 290 00:10:21,360 --> 00:10:24,320 linux or something 291 00:10:24,640 --> 00:10:29,440 next we have a a run step that we are 292 00:10:27,360 --> 00:10:31,760 describing as install dependencies where 293 00:10:29,440 --> 00:10:33,440 we install the dependencies there is a 294 00:10:31,760 --> 00:10:35,120 decent amount of stuff pre-installed i 295 00:10:33,440 --> 00:10:36,399 believe to build the kernel i just had 296 00:10:35,120 --> 00:10:39,519 to install 297 00:10:36,399 --> 00:10:41,200 lib ssl dev and lib elf dev like it had 298 00:10:39,519 --> 00:10:42,720 making stuff so 299 00:10:41,200 --> 00:10:44,560 i should probably manually specify 300 00:10:42,720 --> 00:10:47,519 everything just in case and then we 301 00:10:44,560 --> 00:10:50,079 build the kernel and we're done that's 302 00:10:47,519 --> 00:10:52,880 all you need put that in a github repo 303 00:10:50,079 --> 00:10:54,720 and magic will eventually occur 304 00:10:52,880 --> 00:10:56,880 so it it works that's that's all you 305 00:10:54,720 --> 00:10:59,600 need someone else's computer has run 306 00:10:56,880 --> 00:11:02,079 make for us which is 307 00:10:59,600 --> 00:11:04,720 pretty good it took 14 minutes and 27 308 00:11:02,079 --> 00:11:06,640 seconds in this case 309 00:11:04,720 --> 00:11:08,720 not super fast i could have done that in 310 00:11:06,640 --> 00:11:12,000 two minutes on my computer 311 00:11:08,720 --> 00:11:14,480 on my power bill so still neat right you 312 00:11:12,000 --> 00:11:15,920 can have this triggering all the time 313 00:11:14,480 --> 00:11:17,839 it's not your computer you don't have to 314 00:11:15,920 --> 00:11:19,680 maintain it this is all this is all 315 00:11:17,839 --> 00:11:21,440 pretty good um but it's not really 316 00:11:19,680 --> 00:11:23,440 getting us anywhere interesting so let's 317 00:11:21,440 --> 00:11:25,440 look at scaling this up and having a 318 00:11:23,440 --> 00:11:29,120 look at what else we can do to get some 319 00:11:25,440 --> 00:11:31,839 more get some more value here well 320 00:11:29,120 --> 00:11:33,600 this is where we get some value 321 00:11:31,839 --> 00:11:34,959 the kernel 322 00:11:33,600 --> 00:11:37,279 has 323 00:11:34,959 --> 00:11:38,160 probably infinite scaling configurations 324 00:11:37,279 --> 00:11:41,120 of 325 00:11:38,160 --> 00:11:45,040 architectures endian's uh 326 00:11:41,120 --> 00:11:47,440 32-bit 64-bit def configs um just 327 00:11:45,040 --> 00:11:49,920 configs in general platforms within 328 00:11:47,440 --> 00:11:51,519 those architectures you know ways of 329 00:11:49,920 --> 00:11:53,680 running bare metal 330 00:11:51,519 --> 00:11:55,519 kvm whatever 331 00:11:53,680 --> 00:11:56,480 matrix is really really big 332 00:11:55,519 --> 00:11:58,560 and 333 00:11:56,480 --> 00:12:00,959 you can scale that up using github 334 00:11:58,560 --> 00:12:03,360 actions whatever your matrix is that you 335 00:12:00,959 --> 00:12:05,680 don't have time to to manually test or 336 00:12:03,360 --> 00:12:06,800 to maintain the infrastructure for 337 00:12:05,680 --> 00:12:09,680 you can just 338 00:12:06,800 --> 00:12:11,600 get github to do it for you 339 00:12:09,680 --> 00:12:14,079 as much as you can within a virtual 340 00:12:11,600 --> 00:12:16,079 machine so you can 341 00:12:14,079 --> 00:12:17,519 run queue on different architectures you 342 00:12:16,079 --> 00:12:20,160 can use different compilers you can you 343 00:12:17,519 --> 00:12:21,839 know cross-compile stuff you can use gcc 344 00:12:20,160 --> 00:12:25,440 clang different versions of those you 345 00:12:21,839 --> 00:12:26,880 can scale this up usually and 346 00:12:25,440 --> 00:12:28,240 some of them will run at the same time 347 00:12:26,880 --> 00:12:29,920 you probably won't get an entire data 348 00:12:28,240 --> 00:12:31,279 center to yourself but some of them will 349 00:12:29,920 --> 00:12:32,639 run at the same time based on what 350 00:12:31,279 --> 00:12:33,839 github feels like chucking you at the 351 00:12:32,639 --> 00:12:35,600 time 352 00:12:33,839 --> 00:12:37,040 so you can scale this up pretty nicely 353 00:12:35,600 --> 00:12:38,800 and define that through your matrix 354 00:12:37,040 --> 00:12:40,959 there's some quite complicated stuff you 355 00:12:38,800 --> 00:12:42,399 can do in there to make sure that you're 356 00:12:40,959 --> 00:12:45,040 getting exactly the stuff you want 357 00:12:42,399 --> 00:12:48,000 tested in the way you want it um 358 00:12:45,040 --> 00:12:51,040 if a you know n by m size matrix of 359 00:12:48,000 --> 00:12:53,040 stuff doesn't actually help you 360 00:12:51,040 --> 00:12:54,480 in this case we've just defined one 361 00:12:53,040 --> 00:12:56,320 variable that we're going to be 362 00:12:54,480 --> 00:12:58,720 switching through which is just the def 363 00:12:56,320 --> 00:12:59,839 config we're still just dealing with x86 364 00:12:58,720 --> 00:13:02,320 here we're just going to change the def 365 00:12:59,839 --> 00:13:05,040 config so we've got four instead of one 366 00:13:02,320 --> 00:13:06,560 and when we we run our make instead of 367 00:13:05,040 --> 00:13:08,079 explicitly referring to the def config 368 00:13:06,560 --> 00:13:10,639 we're going to refer to the variable 369 00:13:08,079 --> 00:13:11,920 with some funky variable reference 370 00:13:10,639 --> 00:13:12,720 syntax 371 00:13:11,920 --> 00:13:14,560 so 372 00:13:12,720 --> 00:13:16,560 instead of building one thing slowly 373 00:13:14,560 --> 00:13:19,120 we've built four things slowly but then 374 00:13:16,560 --> 00:13:21,839 not too much more time so this is where 375 00:13:19,120 --> 00:13:23,279 you start creeping in with the the value 376 00:13:21,839 --> 00:13:25,440 you can get out of github actions it's 377 00:13:23,279 --> 00:13:27,519 infrastructure you don't manage you 378 00:13:25,440 --> 00:13:30,240 don't pay for that can do a lot of stuff 379 00:13:27,519 --> 00:13:31,920 for you without you telling it to um 380 00:13:30,240 --> 00:13:34,240 i'll get into it later but i run some 381 00:13:31,920 --> 00:13:35,839 continuous integration using github 382 00:13:34,240 --> 00:13:37,680 actions and 383 00:13:35,839 --> 00:13:39,360 i'm routinely surprised that it's just 384 00:13:37,680 --> 00:13:41,199 been running posting results not 385 00:13:39,360 --> 00:13:42,959 exploding for months without me checking 386 00:13:41,199 --> 00:13:45,680 it so 387 00:13:42,959 --> 00:13:48,959 that's some good time investment i think 388 00:13:45,680 --> 00:13:51,040 so here you can see that i i pushed the 389 00:13:48,959 --> 00:13:52,880 commit it took 17 minutes that's to 390 00:13:51,040 --> 00:13:54,800 complete all possible all the 391 00:13:52,880 --> 00:13:55,839 configurations to find all four of the 392 00:13:54,800 --> 00:13:58,560 jobs 393 00:13:55,839 --> 00:14:00,480 and you can see from the yellow icon 394 00:13:58,560 --> 00:14:02,079 thing those were spinning so they were 395 00:14:00,480 --> 00:14:03,600 all running at the same time we weren't 396 00:14:02,079 --> 00:14:05,600 resource constrained waiting for more 397 00:14:03,600 --> 00:14:08,880 instances all four of them got given one 398 00:14:05,600 --> 00:14:11,839 of those vms at the same time um so 399 00:14:08,880 --> 00:14:11,839 that's scaling 400 00:14:11,920 --> 00:14:16,079 just briefly mentioning before we get 401 00:14:13,440 --> 00:14:17,680 into some of the fancier stuff you can 402 00:14:16,079 --> 00:14:20,000 do with this 403 00:14:17,680 --> 00:14:21,839 um there's first class docker support so 404 00:14:20,000 --> 00:14:24,079 if you have a docker 405 00:14:21,839 --> 00:14:26,560 container that you build stuff in with 406 00:14:24,079 --> 00:14:28,320 all the nice things that you like um 407 00:14:26,560 --> 00:14:29,760 you can give that to github actions and 408 00:14:28,320 --> 00:14:33,519 then it won't need to recreate it every 409 00:14:29,760 --> 00:14:36,800 time um it knows how to do documentation 410 00:14:33,519 --> 00:14:38,240 stuff so um there isn't that same kind 411 00:14:36,800 --> 00:14:40,240 of first class support for some other 412 00:14:38,240 --> 00:14:41,440 container runtimes but there is 413 00:14:40,240 --> 00:14:45,839 people in the community who have done it 414 00:14:41,440 --> 00:14:45,839 before so there is prior art there 415 00:14:45,920 --> 00:14:50,320 um 416 00:14:46,880 --> 00:14:53,040 caching so cash um 417 00:14:50,320 --> 00:14:55,360 exists and is cool and is complicated 418 00:14:53,040 --> 00:14:56,959 and hard to get a good hit rate on 419 00:14:55,360 --> 00:14:58,480 sometimes 420 00:14:56,959 --> 00:14:59,920 and i'm not an expert in getting the 421 00:14:58,480 --> 00:15:01,440 perfect special source to make it work 422 00:14:59,920 --> 00:15:03,440 in github actions but my builds do run 423 00:15:01,440 --> 00:15:05,120 faster most of the time from having it 424 00:15:03,440 --> 00:15:07,120 so i'm going to call that a win uh 425 00:15:05,120 --> 00:15:10,240 github actions has a cache feature your 426 00:15:07,120 --> 00:15:12,639 repository has five gigs of storage for 427 00:15:10,240 --> 00:15:15,360 you to chuck your cache in there 428 00:15:12,639 --> 00:15:16,480 the way it works is that you give it 429 00:15:15,360 --> 00:15:18,240 what you want to chuck in there so in 430 00:15:16,480 --> 00:15:20,959 this case the c cache directory and you 431 00:15:18,240 --> 00:15:23,920 give it a key to refer to it later so if 432 00:15:20,959 --> 00:15:26,079 you want you know your cache to be hot 433 00:15:23,920 --> 00:15:28,240 you can you know make it so that the key 434 00:15:26,079 --> 00:15:30,399 is this specific config and then you'll 435 00:15:28,240 --> 00:15:32,240 use that specific c cache when you you 436 00:15:30,399 --> 00:15:33,680 build that specific config again later 437 00:15:32,240 --> 00:15:36,560 saving you some time 438 00:15:33,680 --> 00:15:38,320 so um you can go up to five gigs if 439 00:15:36,560 --> 00:15:40,639 something in the cache isn't hit in a 440 00:15:38,320 --> 00:15:42,240 week it gets evicted or if you are 441 00:15:40,639 --> 00:15:44,720 running up to that five gigs it will 442 00:15:42,240 --> 00:15:47,199 evict the oldest thing to make room so 443 00:15:44,720 --> 00:15:49,360 that's how it works it's not perfect but 444 00:15:47,199 --> 00:15:51,839 it's it's pretty good and not too hard 445 00:15:49,360 --> 00:15:53,199 to get going if you can um 446 00:15:51,839 --> 00:15:55,040 you know if you're using docker maybe 447 00:15:53,199 --> 00:15:57,360 it's hard to get the c cache in and out 448 00:15:55,040 --> 00:15:57,360 you know 449 00:15:57,759 --> 00:16:01,040 um 450 00:15:59,199 --> 00:16:03,920 problem matches so this is essentially a 451 00:16:01,040 --> 00:16:06,560 way to teach github actions what your 452 00:16:03,920 --> 00:16:08,639 output means uh you know you're running 453 00:16:06,560 --> 00:16:10,880 gcc or clang it's spitting out a bunch 454 00:16:08,639 --> 00:16:12,560 of stuff some of it's exploding lots of 455 00:16:10,880 --> 00:16:15,199 it is unimportant some of it is 456 00:16:12,560 --> 00:16:17,600 important how do you get github to know 457 00:16:15,199 --> 00:16:18,880 what those things mean um 458 00:16:17,600 --> 00:16:20,560 if you're just using this to run stuff 459 00:16:18,880 --> 00:16:21,680 for you you kind of don't really care 460 00:16:20,560 --> 00:16:23,279 but if you're trying to build something 461 00:16:21,680 --> 00:16:25,680 on top of it whether that's you're using 462 00:16:23,279 --> 00:16:27,279 the api or you want that kind of 463 00:16:25,680 --> 00:16:29,199 interactive feedback that you would get 464 00:16:27,279 --> 00:16:31,279 from submitting a pull request where you 465 00:16:29,199 --> 00:16:33,279 know you introduce a warning on a 466 00:16:31,279 --> 00:16:35,120 specific line it puts that warning on 467 00:16:33,279 --> 00:16:37,680 the line in the code review thing then 468 00:16:35,120 --> 00:16:38,880 you can use this so um truncated a lot 469 00:16:37,680 --> 00:16:41,279 here but essentially you chuck in the 470 00:16:38,880 --> 00:16:44,320 regex and tell it what the groups refer 471 00:16:41,279 --> 00:16:46,399 to and then it will put that into into 472 00:16:44,320 --> 00:16:50,560 the github api and present it 473 00:16:46,399 --> 00:16:52,560 so something you can do 474 00:16:50,560 --> 00:16:56,639 uh this is an example of that so we've 475 00:16:52,560 --> 00:16:58,480 got a spas warning here um 476 00:16:56,639 --> 00:17:00,560 that's what the text looks like when 477 00:16:58,480 --> 00:17:03,199 it's just vomited out onto the 478 00:17:00,560 --> 00:17:06,000 um onto the console output and with our 479 00:17:03,199 --> 00:17:08,000 regex that knows how to pause it um 480 00:17:06,000 --> 00:17:11,520 github turns that into a into an 481 00:17:08,000 --> 00:17:14,720 annotation so it has the job that was 482 00:17:11,520 --> 00:17:17,439 run it has the uh matrix configuration 483 00:17:14,720 --> 00:17:18,799 so that's going to be rpc64 484 00:17:17,439 --> 00:17:21,839 little endian 485 00:17:18,799 --> 00:17:23,439 uh with pvc64 l8 def config running in 486 00:17:21,839 --> 00:17:27,439 an environment that was 487 00:17:23,439 --> 00:17:28,880 ubuntu 2204 or built on ubuntu 104. 488 00:17:27,439 --> 00:17:30,480 um and when you click on that it takes 489 00:17:28,880 --> 00:17:32,480 you to like you know it knows the line 490 00:17:30,480 --> 00:17:33,760 of code that generated the sparse 491 00:17:32,480 --> 00:17:37,600 warning 492 00:17:33,760 --> 00:17:39,200 so you can build stuff on this 493 00:17:37,600 --> 00:17:40,400 uh 494 00:17:39,200 --> 00:17:43,120 quickly going to talk about getting 495 00:17:40,400 --> 00:17:45,039 stuff in and out of jobs so 496 00:17:43,120 --> 00:17:46,960 much like something like jenkins you can 497 00:17:45,039 --> 00:17:48,480 archive artifacts and artifacts are 498 00:17:46,960 --> 00:17:50,720 essentially the part of your build that 499 00:17:48,480 --> 00:17:52,640 is preserved so you know you might want 500 00:17:50,720 --> 00:17:54,080 to build your tree for a bunch of 501 00:17:52,640 --> 00:17:55,280 different architectures well you can you 502 00:17:54,080 --> 00:17:57,679 know 503 00:17:55,280 --> 00:17:59,280 archive the vm linux and then people can 504 00:17:57,679 --> 00:18:01,919 run your kernel 505 00:17:59,280 --> 00:18:03,679 in this example we're just taking uh a 506 00:18:01,919 --> 00:18:05,440 build log we're saying that okay when we 507 00:18:03,679 --> 00:18:07,679 build our kernel it's gonna leave its 508 00:18:05,440 --> 00:18:10,320 login build.log and then we're gonna 509 00:18:07,679 --> 00:18:13,039 archive it but with a reference to the 510 00:18:10,320 --> 00:18:14,880 the def config we used so at the end of 511 00:18:13,039 --> 00:18:17,280 our thing when we've run all these jobs 512 00:18:14,880 --> 00:18:21,120 we'll have you know separate archived 513 00:18:17,280 --> 00:18:24,799 artifacts referencing each configuration 514 00:18:21,120 --> 00:18:27,120 then we can refer to them later so 515 00:18:24,799 --> 00:18:29,600 in this case we are accessing the the 516 00:18:27,120 --> 00:18:32,720 artifacts from a previous run and the 517 00:18:29,600 --> 00:18:34,799 specific case i use this for is that um 518 00:18:32,720 --> 00:18:36,799 i will have the maintainers tree i'll 519 00:18:34,799 --> 00:18:38,480 have like the base that i apply patches 520 00:18:36,799 --> 00:18:40,880 on top of 521 00:18:38,480 --> 00:18:44,640 running these actions as well and so 522 00:18:40,880 --> 00:18:46,799 when i i run jobs on incoming patches i 523 00:18:44,640 --> 00:18:49,120 have a base to compare it to so i can 524 00:18:46,799 --> 00:18:52,000 tell is the spurs warning an introduced 525 00:18:49,120 --> 00:18:54,000 regression or is it was it already there 526 00:18:52,000 --> 00:18:56,320 upstream and we shouldn't 527 00:18:54,000 --> 00:18:57,679 mark that against this incoming patch 528 00:18:56,320 --> 00:19:00,720 series 529 00:18:57,679 --> 00:19:03,760 so uh this one is a it's using a 530 00:19:00,720 --> 00:19:05,520 community action not from github um 531 00:19:03,760 --> 00:19:07,200 to download another fact we say this is 532 00:19:05,520 --> 00:19:08,640 the workflow we care about we only want 533 00:19:07,200 --> 00:19:10,400 to look at successes so if the build 534 00:19:08,640 --> 00:19:12,400 failed we don't want to use the log from 535 00:19:10,400 --> 00:19:16,480 that we specify the branch and we 536 00:19:12,400 --> 00:19:17,840 specify the uh the name to put it at 537 00:19:16,480 --> 00:19:20,559 and 538 00:19:17,840 --> 00:19:22,240 this lets us do direct comparisons with 539 00:19:20,559 --> 00:19:23,760 whatever we previously want to compare 540 00:19:22,240 --> 00:19:25,200 to which is quite important if you're 541 00:19:23,760 --> 00:19:27,840 trying to 542 00:19:25,200 --> 00:19:29,440 find newly introduced things you do need 543 00:19:27,840 --> 00:19:31,280 to have some other logic that you know 544 00:19:29,440 --> 00:19:33,360 knows how to diff 545 00:19:31,280 --> 00:19:35,120 at your output 546 00:19:33,360 --> 00:19:36,880 but this is a way to do inline 547 00:19:35,120 --> 00:19:39,679 comparison so you're only flagging stuff 548 00:19:36,880 --> 00:19:40,640 that's newly introduced 549 00:19:39,679 --> 00:19:42,559 um 550 00:19:40,640 --> 00:19:45,520 after you've built your kernel you can 551 00:19:42,559 --> 00:19:47,200 boot it and test it um i'm not going to 552 00:19:45,520 --> 00:19:48,720 cover that too much but it's just the 553 00:19:47,200 --> 00:19:50,400 same as doing it in a shell script right 554 00:19:48,720 --> 00:19:51,840 if you already have a shell script just 555 00:19:50,400 --> 00:19:53,120 tell github actions to run your shell 556 00:19:51,840 --> 00:19:53,919 script 557 00:19:53,120 --> 00:19:55,360 you 558 00:19:53,919 --> 00:19:57,679 just 559 00:19:55,360 --> 00:20:00,240 run it you take your thing you boot the 560 00:19:57,679 --> 00:20:02,080 thing you probably write a script using 561 00:20:00,240 --> 00:20:03,360 expect you 562 00:20:02,080 --> 00:20:05,760 you know 563 00:20:03,360 --> 00:20:08,320 check if it worked or not you 564 00:20:05,760 --> 00:20:10,240 reconsider your career options 565 00:20:08,320 --> 00:20:11,840 and you carry on so 566 00:20:10,240 --> 00:20:13,360 anything like that is possible you know 567 00:20:11,840 --> 00:20:15,520 you can because you can build you can 568 00:20:13,360 --> 00:20:17,679 take cross compilers you can build other 569 00:20:15,520 --> 00:20:19,120 architectures you can run stuff inside 570 00:20:17,679 --> 00:20:22,320 that you know you can 571 00:20:19,120 --> 00:20:24,559 run yourself tests inside queue 572 00:20:22,320 --> 00:20:26,720 for the thing you just built so 573 00:20:24,559 --> 00:20:29,679 again lots of possibilities within a 574 00:20:26,720 --> 00:20:29,679 restricted environment 575 00:20:31,520 --> 00:20:34,480 now i'm going to give an example of 576 00:20:32,880 --> 00:20:36,080 putting it all together into into 577 00:20:34,480 --> 00:20:37,679 something quite unquote real this is 578 00:20:36,080 --> 00:20:38,640 what i worked on a couple months of last 579 00:20:37,679 --> 00:20:40,159 year 580 00:20:38,640 --> 00:20:41,919 doing 581 00:20:40,159 --> 00:20:43,440 so 582 00:20:41,919 --> 00:20:45,280 i'm using github actions right now to 583 00:20:43,440 --> 00:20:48,640 run some some continuous integration for 584 00:20:45,280 --> 00:20:50,400 arch power pc based on um the actions 585 00:20:48,640 --> 00:20:51,440 that the powerpc maintainer michael 586 00:20:50,400 --> 00:20:52,559 hellman 587 00:20:51,440 --> 00:20:53,760 had written 588 00:20:52,559 --> 00:20:54,880 um 589 00:20:53,760 --> 00:20:57,679 because 590 00:20:54,880 --> 00:20:59,520 we were running rci using jenkins and 591 00:20:57,679 --> 00:21:01,520 jenkins 592 00:20:59,520 --> 00:21:03,760 is jenkins so 593 00:21:01,520 --> 00:21:05,600 we have the standard stuff for a 594 00:21:03,760 --> 00:21:08,480 kernel 595 00:21:05,600 --> 00:21:10,000 development list we've got our list 596 00:21:08,480 --> 00:21:11,600 that all development happens on we don't 597 00:21:10,000 --> 00:21:13,120 use github or anything 598 00:21:11,600 --> 00:21:16,559 i've got my github repository with 599 00:21:13,120 --> 00:21:18,640 actions in it based on based on mpus 600 00:21:16,559 --> 00:21:20,159 um we've got a patchwork server so i'll 601 00:21:18,640 --> 00:21:21,200 show patchwork in a sec but essentially 602 00:21:20,159 --> 00:21:24,000 we use it 603 00:21:21,200 --> 00:21:25,840 for an api to get the patch series from 604 00:21:24,000 --> 00:21:28,240 and then there's an api to push the the 605 00:21:25,840 --> 00:21:30,240 final results too so that no one really 606 00:21:28,240 --> 00:21:32,320 has to care that this is running on on 607 00:21:30,240 --> 00:21:33,600 github that can be kind of transparent 608 00:21:32,320 --> 00:21:36,400 and then there's snow patch which is a 609 00:21:33,600 --> 00:21:38,559 tool i wrote um that does a little 610 00:21:36,400 --> 00:21:40,799 middle manning it's you know taking 611 00:21:38,559 --> 00:21:42,640 stuff pushing stuff putting gluing all 612 00:21:40,799 --> 00:21:44,159 the pieces together is what snow patch 613 00:21:42,640 --> 00:21:45,039 does 614 00:21:44,159 --> 00:21:47,120 so 615 00:21:45,039 --> 00:21:48,720 this is patchwork if you haven't seen it 616 00:21:47,120 --> 00:21:52,159 it essentially just gives you a the 617 00:21:48,720 --> 00:21:53,120 state of a mailing list right now 618 00:21:52,159 --> 00:21:54,320 only 619 00:21:53,120 --> 00:21:55,919 useful for that purpose if the 620 00:21:54,320 --> 00:21:58,000 maintainer actually uses it but if they 621 00:21:55,919 --> 00:21:59,120 do use it then you know we can see here 622 00:21:58,000 --> 00:22:01,200 that 623 00:21:59,120 --> 00:22:03,120 it's only showing us patches that 624 00:22:01,200 --> 00:22:04,159 you know are currently for consideration 625 00:22:03,120 --> 00:22:06,559 it's not showing stuff that's been 626 00:22:04,159 --> 00:22:08,159 accepted already or superseded 627 00:22:06,559 --> 00:22:09,440 on the right side here we can see some 628 00:22:08,159 --> 00:22:11,280 green 629 00:22:09,440 --> 00:22:14,240 is successes warnings and failures and 630 00:22:11,280 --> 00:22:17,120 this is the result of the tests running 631 00:22:14,240 --> 00:22:19,280 on on github so the github actions are 632 00:22:17,120 --> 00:22:20,559 being plumbed through here to produce 633 00:22:19,280 --> 00:22:21,760 test results 634 00:22:20,559 --> 00:22:23,360 so 635 00:22:21,760 --> 00:22:24,720 um 636 00:22:23,360 --> 00:22:26,400 the process of doing that goes through 637 00:22:24,720 --> 00:22:28,720 snowpatch 638 00:22:26,400 --> 00:22:30,960 it's just it's a daemon that 639 00:22:28,720 --> 00:22:32,960 watches patchwork for new stuff applies 640 00:22:30,960 --> 00:22:34,320 that stuff to a tree pushes the tree to 641 00:22:32,960 --> 00:22:35,840 github 642 00:22:34,320 --> 00:22:37,280 waits for the actions that get triggered 643 00:22:35,840 --> 00:22:39,760 from that push to complete and then 644 00:22:37,280 --> 00:22:41,679 sends the results back to patchwork 645 00:22:39,760 --> 00:22:44,400 and it does that a lot 646 00:22:41,679 --> 00:22:44,400 concurrently 647 00:22:44,799 --> 00:22:47,200 so 648 00:22:45,600 --> 00:22:49,120 the actual workflows themselves are 649 00:22:47,200 --> 00:22:51,440 doing quite a bit i didn't write 650 00:22:49,120 --> 00:22:53,200 these sprinkled some stuff in that's of 651 00:22:51,440 --> 00:22:54,400 lower quality um 652 00:22:53,200 --> 00:22:56,559 so 653 00:22:54,400 --> 00:22:59,520 power pc if you know anything about it 654 00:22:56,559 --> 00:23:01,440 has quite a wide matrix itself 32-bit 655 00:22:59,520 --> 00:23:03,200 64-bit um 656 00:23:01,440 --> 00:23:04,799 big endian little endian lots of 657 00:23:03,200 --> 00:23:07,600 different platforms 658 00:23:04,799 --> 00:23:10,240 we have 64-bit and better than 64-bit 659 00:23:07,600 --> 00:23:11,919 server lots of different depth configs 660 00:23:10,240 --> 00:23:13,520 still support for the wii and gamecube 661 00:23:11,919 --> 00:23:15,440 you know it's it's a bit it's a big 662 00:23:13,520 --> 00:23:16,880 matrix so there's a lot of value here in 663 00:23:15,440 --> 00:23:19,440 spreading some of that out you know 664 00:23:16,880 --> 00:23:22,159 building and testing these lesser uh 665 00:23:19,440 --> 00:23:25,200 lower priority or you know just less 666 00:23:22,159 --> 00:23:28,080 lower user base platforms i guess um 667 00:23:25,200 --> 00:23:30,000 it builds stuff it boots stuff in kwemu 668 00:23:28,080 --> 00:23:33,280 uses gcn clang 669 00:23:30,000 --> 00:23:34,000 um we use a tool called smart spars diff 670 00:23:33,280 --> 00:23:37,520 to 671 00:23:34,000 --> 00:23:40,320 you know intelligently split new stuff 672 00:23:37,520 --> 00:23:42,640 in a spa static analysis output from 673 00:23:40,320 --> 00:23:45,520 what upstream was showing and then 674 00:23:42,640 --> 00:23:47,679 register a problem manager on that diff 675 00:23:45,520 --> 00:23:49,600 to add annotations just for newly 676 00:23:47,679 --> 00:23:52,400 introduced sparse diff so we can use 677 00:23:49,600 --> 00:23:54,240 that to report test results 678 00:23:52,400 --> 00:23:56,240 and yeah those actions were primarily 679 00:23:54,240 --> 00:23:58,000 written by michael allman i just made 680 00:23:56,240 --> 00:23:59,440 them worse 681 00:23:58,000 --> 00:24:01,039 and this is the end result so if you go 682 00:23:59,440 --> 00:24:02,559 to patchwork and click on the series 683 00:24:01,039 --> 00:24:03,520 this is the kind of thing you see right 684 00:24:02,559 --> 00:24:06,480 you see 685 00:24:03,520 --> 00:24:07,679 is the the workflows that got run 686 00:24:06,480 --> 00:24:09,200 a bunch of these are running a bunch of 687 00:24:07,679 --> 00:24:12,080 different configurations so you know you 688 00:24:09,200 --> 00:24:14,159 can see eight jobs 24 jobs from the the 689 00:24:12,080 --> 00:24:16,320 matrix that ran on this specific series 690 00:24:14,159 --> 00:24:18,400 and in this case 691 00:24:16,320 --> 00:24:19,520 that warning is coming from an 692 00:24:18,400 --> 00:24:20,400 annotation 693 00:24:19,520 --> 00:24:22,480 on 694 00:24:20,400 --> 00:24:23,760 on github actions from that problem 695 00:24:22,480 --> 00:24:25,520 matcher so that's how it kind of all 696 00:24:23,760 --> 00:24:28,080 goes full circle and you can see that it 697 00:24:25,520 --> 00:24:30,400 knows the specific config that produced 698 00:24:28,080 --> 00:24:32,000 the um the warning and that comes from 699 00:24:30,400 --> 00:24:33,840 that strategy matrix so that's how it 700 00:24:32,000 --> 00:24:38,080 kind of all comes full circle after a 701 00:24:33,840 --> 00:24:38,080 lot of github api wrestling 702 00:24:38,320 --> 00:24:42,400 so some other potential use cases for 703 00:24:40,080 --> 00:24:44,400 this aside from this specific one i 704 00:24:42,400 --> 00:24:46,080 think you know can certainly be of use 705 00:24:44,400 --> 00:24:48,080 to subsystem maintainers because you 706 00:24:46,080 --> 00:24:49,679 have a matrix of stuff that you're not 707 00:24:48,080 --> 00:24:51,440 constantly testing you don't always have 708 00:24:49,679 --> 00:24:52,880 the hardware to test it you can you know 709 00:24:51,440 --> 00:24:54,640 keep some of that more 710 00:24:52,880 --> 00:24:56,559 more niche stuff 711 00:24:54,640 --> 00:24:58,799 rolling um 712 00:24:56,559 --> 00:25:00,480 developer pre-submits is another one a 713 00:24:58,799 --> 00:25:02,720 lot of discussion about that in the last 714 00:25:00,480 --> 00:25:04,640 few years in general but um one of the 715 00:25:02,720 --> 00:25:06,559 hardest things for especially new 716 00:25:04,640 --> 00:25:08,559 developers is getting your build 717 00:25:06,559 --> 00:25:10,080 environment going and then you know then 718 00:25:08,559 --> 00:25:12,080 being asked to consider all these other 719 00:25:10,080 --> 00:25:14,799 platforms that you don't have to develop 720 00:25:12,080 --> 00:25:16,880 on yourself it's quite daunting um so 721 00:25:14,799 --> 00:25:19,200 you know if you pre-construct something 722 00:25:16,880 --> 00:25:21,360 and can just say to a new developer hey 723 00:25:19,200 --> 00:25:23,279 clone this repo or you know open a pull 724 00:25:21,360 --> 00:25:24,799 request against it and it'll test all 725 00:25:23,279 --> 00:25:28,159 this stuff before someone on the mailing 726 00:25:24,799 --> 00:25:30,000 list tells you you broke 32-bit again um 727 00:25:28,159 --> 00:25:33,200 then that can be that could be quite 728 00:25:30,000 --> 00:25:34,960 useful so it could be a very easy 729 00:25:33,200 --> 00:25:37,120 jumping off point to cover a lot of 730 00:25:34,960 --> 00:25:38,559 stuff that people probably won't test 731 00:25:37,120 --> 00:25:40,159 manually especially if they're not aware 732 00:25:38,559 --> 00:25:42,000 of it 733 00:25:40,159 --> 00:25:43,760 similarly with other architectures 734 00:25:42,000 --> 00:25:45,600 because you can build 735 00:25:43,760 --> 00:25:47,279 all the architectures and at least you 736 00:25:45,600 --> 00:25:48,720 know emulate all the architectures in 737 00:25:47,279 --> 00:25:49,840 claim you always for a smoke test that 738 00:25:48,720 --> 00:25:51,760 doesn't boot 739 00:25:49,840 --> 00:25:54,480 also quite useful when you don't have 740 00:25:51,760 --> 00:25:56,320 access to specific hardware and you know 741 00:25:54,480 --> 00:25:58,080 if one person does it once everyone can 742 00:25:56,320 --> 00:26:00,080 copy it and everyone doesn't have to 743 00:25:58,080 --> 00:26:02,159 individually figure out the magic when 744 00:26:00,080 --> 00:26:04,480 you incantations to to boot some 745 00:26:02,159 --> 00:26:06,960 architecture you're not familiar with um 746 00:26:04,480 --> 00:26:09,840 and yeah anything with a big matrix that 747 00:26:06,960 --> 00:26:12,720 can scale out um you can set github 748 00:26:09,840 --> 00:26:14,559 actions to work doing um so it's it's 749 00:26:12,720 --> 00:26:15,600 worth considering for that again it's 750 00:26:14,559 --> 00:26:17,840 it's not great investing in a 751 00:26:15,600 --> 00:26:20,320 proprietary platform you know vendor 752 00:26:17,840 --> 00:26:22,960 lock-in etc but um 753 00:26:20,320 --> 00:26:25,520 it really is just kind of run it and go 754 00:26:22,960 --> 00:26:27,600 um and someone else's energy bill goes 755 00:26:25,520 --> 00:26:30,080 up as a result so i'm a big fan of that 756 00:26:27,600 --> 00:26:30,080 personally 757 00:26:31,039 --> 00:26:36,080 quickly covering limitations uh 758 00:26:33,760 --> 00:26:36,080 you know 759 00:26:37,679 --> 00:26:42,000 if you are using this on a moderate 760 00:26:40,240 --> 00:26:43,919 volume mailing list to test every single 761 00:26:42,000 --> 00:26:46,159 patch it can keep up just fine and run 762 00:26:43,919 --> 00:26:47,600 things in a reasonable amount of time if 763 00:26:46,159 --> 00:26:49,360 you 764 00:26:47,600 --> 00:26:52,400 ingest 765 00:26:49,360 --> 00:26:55,120 a couple months of that mailing list all 766 00:26:52,400 --> 00:26:57,039 creating new workflow triggers at the 767 00:26:55,120 --> 00:26:58,640 same time 768 00:26:57,039 --> 00:27:00,960 github will kind of just silently 769 00:26:58,640 --> 00:27:02,880 realize that you're a jerk and give you 770 00:27:00,960 --> 00:27:04,799 very little so if you're flooding it 771 00:27:02,880 --> 00:27:06,400 with a ton of stuff you can get rate 772 00:27:04,799 --> 00:27:08,320 limited um 773 00:27:06,400 --> 00:27:10,720 if you have like a matrix of 24 things 774 00:27:08,320 --> 00:27:13,120 on one job it's unlikely you'll get 24 775 00:27:10,720 --> 00:27:14,480 vms at the same time so 776 00:27:13,120 --> 00:27:16,480 it's never going to be super time 777 00:27:14,480 --> 00:27:18,320 sensitive typically like you know we'll 778 00:27:16,480 --> 00:27:20,640 do all these tests and they'll come back 779 00:27:18,320 --> 00:27:22,720 in like half an hour to an hour so it's 780 00:27:20,640 --> 00:27:24,080 not glacial but it's not instant as is 781 00:27:22,720 --> 00:27:26,320 the nature of 782 00:27:24,080 --> 00:27:27,039 infrastructure you don't own or pay for 783 00:27:26,320 --> 00:27:28,880 um 784 00:27:27,039 --> 00:27:30,080 no guarantee you'll get you know you 785 00:27:28,880 --> 00:27:31,520 might be like i need this to finish 786 00:27:30,080 --> 00:27:33,679 right now right now give me a give me a 787 00:27:31,520 --> 00:27:34,720 machine you have no ability to influence 788 00:27:33,679 --> 00:27:36,640 that 789 00:27:34,720 --> 00:27:38,320 sometimes it'll just die your job will 790 00:27:36,640 --> 00:27:39,919 just fail and action will fail it'll 791 00:27:38,320 --> 00:27:42,399 just error 792 00:27:39,919 --> 00:27:44,159 happens infrequently but it does happen 793 00:27:42,399 --> 00:27:46,480 and finally 794 00:27:44,159 --> 00:27:48,480 if for example you had 795 00:27:46,480 --> 00:27:51,279 a github repository 796 00:27:48,480 --> 00:27:53,760 with thousands of branches 797 00:27:51,279 --> 00:27:56,000 that you were using to like track every 798 00:27:53,760 --> 00:27:58,480 single series on the mailing list for 799 00:27:56,000 --> 00:28:01,279 a couple years and then 800 00:27:58,480 --> 00:28:03,520 you merged into that someone's branch 801 00:28:01,279 --> 00:28:06,640 that had actions in it and you hadn't 802 00:28:03,520 --> 00:28:09,840 disabled the email that triggers when 803 00:28:06,640 --> 00:28:11,039 i got ddos basically from from github to 804 00:28:09,840 --> 00:28:12,720 the point where i couldn't receive more 805 00:28:11,039 --> 00:28:14,880 mail for the day because my mail gateway 806 00:28:12,720 --> 00:28:17,200 had just given up it had hit its limit 807 00:28:14,880 --> 00:28:19,600 and it took half an hour to delete 250 808 00:28:17,200 --> 00:28:21,200 000 emails from the the fast mail web ui 809 00:28:19,600 --> 00:28:23,200 so uh 810 00:28:21,200 --> 00:28:24,960 unlikely anyone will ever hit this but i 811 00:28:23,200 --> 00:28:27,120 felt like i had to talk about it because 812 00:28:24,960 --> 00:28:28,399 it was just baffling 813 00:28:27,120 --> 00:28:30,480 um 814 00:28:28,399 --> 00:28:32,480 and yeah that's all that's all i had so 815 00:28:30,480 --> 00:28:35,120 happy to take any questions if we we 816 00:28:32,480 --> 00:28:36,720 still have any time and um 817 00:28:35,120 --> 00:28:38,799 thanks a lot for having me especially 818 00:28:36,720 --> 00:28:40,240 big thanks to to andrew for organizing 819 00:28:38,799 --> 00:28:45,399 the colonel mini comp yet again he does 820 00:28:40,240 --> 00:28:45,399 a fantastic job so thanks everyone 821 00:28:48,240 --> 00:28:53,200 okay thank you very much russell 822 00:28:50,399 --> 00:28:56,559 um unfortunately we have uh reached the 823 00:28:53,200 --> 00:28:58,880 uh end of the time slot so we don't 824 00:28:56,559 --> 00:29:00,399 really have time for questions but uh 825 00:28:58,880 --> 00:29:02,559 you can see russell will be around the 826 00:29:00,399 --> 00:29:05,039 conference and he's got his twitter 827 00:29:02,559 --> 00:29:06,480 email there um and i'm sure he'll be 828 00:29:05,039 --> 00:29:08,799 happy to 829 00:29:06,480 --> 00:29:11,799 take further questions 830 00:29:08,799 --> 00:29:11,799 um 831 00:29:12,000 --> 00:29:15,480 thanks a lot angie