GitHub Actions with Forked PRs?!

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

Jason: Hello, everyone, and welcome to another episode of Learn With Jason. Today on the show, we're bringing back the one, the only B. Dougie. Yo, Brian Douglas, how you doing, man?

Brian: I'm doing fantastic. How are you doing?

Jason: I'm doing really well. I'm having just a great day. Any day that I get to hang out with you is a good day.

Brian: That's awesome. Well, we should do it more often.

Jason: Absolutely, absolutely. So I mean, I know why I'm excited. For folks who aren't familiar with you, do you want to give us a little bit of a background?

Brian: Yeah, yeah. So B. Dougie. My given name is Brian Douglas, which is on the lower third. I'm a staff developer advocate at GitHub, focused on getting people to use features. I talk to open source maintainers, talk to a lot of people in the chat. Just doing my thing out here in Oakland, California. Enjoying -- I was enjoying sun last week. We're one of the few areas not getting the heat wave. So hopefully I'm not making everybody else feel bad sweating in the U.S. But yeah, just enjoying 66-degree weather every day.

Jason: Just out with a light jacket.

Brian: I have my cardigan on. I figured I'd dress for the occasion.

Jason: Good, I'm not jealous at all. No, it finally feels like it's cooling down again in Portland. We might go outside today, who knows. So yeah, you also run Open Sauced, your streamer. You do a bunch of cool things with the open-source community. I'm a big fan. I also have a -- wait, where is it? I've got the sub. I've got the pizza face you can see down in the chat there. We have the pizza emote, which is a brilliant idea I keep intending to steal and keep not doing. But yeah, so today we're going to focus down a little bit. So in general, you do a lot of open-source work. As we all know, a huge amount of open-source work happens on GitHub. And one of the things that gets really tricky as you start working on lots and lots of open source is that things start to kind of sprawl on you. There's a lot of little chores. There's a lot of small hoops that you got to jump through. Most of it is stuff that's really repetitive. So you work a lot with GitHub Actions, which are kind of designed to make that less painful, right? I guess that's not all they're designed for. Maybe I should let you give the overview. What are GitHub Actions for?

Brian: Yeah, I'm happy to do that. This is my second time on, so the first time we actually chatted, we did do a GitHub Action. We were very brand new into GitHub Actions. I think nine months in. There were a lot of question marks that we sort of discovered together. I was very new to Actions myself, too. I don't know if it showed. But to describe GitHub Actions, it's a way to automate portions of your workflow in and around GitHub. So GitHub itself has been around for about 14 years, and about a month after it launched, we launched an API. I mention that because GitHub Actions is built around a bunch of primitives for GitHub. So the API, authentication, web hooks, it's all built in by default in a repository. You just have to go to the Actions tab, enable it, and you're good to go. It gives you options to automate. Like, you could run your test, which is an obvious automation. Or you can automate your deployments. If you're using something besides Netlify or maybe if you're using Netlify and you're deploying other sites based on things that are actually changing, you actually trigger to Netlify deploy using CLI deploy, as well as what we're going to do maybe later, which is add comments to PRs, which is trivial. I picked a trivial example to hopefully talk about some other stuff that's not so trivial about using GitHub Actions.

Jason: Yeah, and I think one of the things that's really hard for me, at least, whenever I start looking at a new tool, especially one that's in an automation space, is a lot of times I have a hard time seeing myself using it. I try to kind of visualize like, oh, I see how this is useful if you're Google. I see how this is useful if you've got a team of 50 engineers. But how is this useful for me? So what I like about GitHub Actions is that it doesn't feel like, oh, I got to set up a huge amount of infrastructure here. I can kind of just put together a little bit and give it a try and see what it does. So the on-ramp is lower, which is always kind of friendly. It's always one of the things I love about tooling in general. It's why I work where I work. It's why I use most of the tools I use. I like it when people take a bunch of the busy work away from me and let me do the stuff I want to do. So maybe we should talk a little bit about just kind of the specifics of what we're going to do today. You said we're going to comment on some PRs. How -- kind of what is the overview of this? What are we going to be using, and what does it do? Why is it useful to me as a GitHub maintainer?

Brian: Yeah, yeah. So, zooming out a bit, we're going to basically trigger Actions around PR. That's a piece of automation that a lot of maintainers care about. They want to automate things like labeling PRs. So whether this PR is something that needs to be triaged or actually tested. I've been working on an Action that basically -- actually, I haven't been working on it. One of my contributors took this over. If you open a PR and there's no issue attached to the PR, I want to flag that as not a red flag but more of like, ah, maybe this wasn't needed, but I'm going to take my time to review this because this is unwanted. That sounds horrible. But this is code that maybe wasn't expected. This is kind of an issue during times like Hacktoberfest we get a contribution for the sake of contributions. I want to label those to either notify folks or comment on those to let people know, hey, thanks, but maybe open an issue first so we can have the discussion first. I think with open source as a maintainer, you could say yes to too much stuff and get overwhelmed and burnt out. We see this -- like, I see it all the time with maintainers. This was great, but also, I don't think -- maintaining is not cut out for me. My hope is showcasing this, we can approach things to automate and make sure everybody has a good experience, maintainers, but also contributors.

Jason: Yeah, I think, you know, not to fall into a philosophical rabbit hole here, but I think this is worth talking about a little bit. One of the big tragedies I see is when somebody who is really motivated but doesn't have, like, strong boundary setting skills gets into open source. You just see them get eaten alive. You watch them pour themselves into it, they do amazing work, but the problem is when you give work away for free, there's definitely a non-trivial percentage of the population that doesn't value free work at all. So no matter how much you give, they always want more, and they're always unhappy with it. Having that conversation with somebody who, you know -- like, hey, you work on a tool, they like your tool, but they want you to do something for them and you don't have time or you don't -- it's not high on your priority list. Then they yell at you for it. That's a really uncomfortable conversation to have. So something that I find interesting about this is what you're suggesting. Rather than forcing open-source contributors to have these uncomfortable conversations over and over and over again, they can find some of the most common energy drains around their repos and put some light automation in place. So not like roboticize the repo and make it inhuman, but the things you know will be a problem, the things you know will be challenging that take a lot of your time and energy. You can say, hey, in this repo, we do it like this. This is the process. You didn't follow the process. It's not because I don't like you. It's because I have to protect my time. But then you're not the one doing it. It's not your emotional labor to be the one saying that. I like that. I mean, I know this is something you think about a lot. Like, it's the subject of your show with Open Sauce. Kind of thinking about that. Yeah, I mean, do you think -- do you feel like what I just ran through, do you feel like that's a viable way to help protect maintainers and kind of prevent some burn out?

Brian: Yeah, yeah. I think it very much is. But there's a give and take. So automating too many things is definitely a thing that I've seen, where as soon as you try to make a commit, you get hit with, what do you call it, the husky. You're like, ah, man, what is this? I'm going to spend a week trying to fix these things I didn't touch. Then you get the PR open and it's like, oh, can you rebase? Let me learn how to rebase. This is actually all stuff I've hit with contributor projects. Then I figure out how to rebase. Oh, sign the CLI. Then I sign the CLA. It's like, oh, by the way, you didn't read the contributing. Well, I didn't because I was doing all this other stuff.

Jason: I opened up the contributing MD, and it opened up another automation that said I needed to sign an SLA.

Brian: Yeah, yeah, yeah. Or it takes you to a whole other website. It's all unfortunate stuff, and it's stuff that maintainers do to protect themselves, but also not realizing that, you know, there's a gate when it comes to open source. Sometimes there's this thing I've been talking about, unintentional gatekeeping, where you don't realize you're putting gates around your project saying only folks who know how to use rebase or only folks who have used Git since 2007 can contribute to this project. If you came to my project and you have no idea what rebase is, why are you here? Get out of here.

Jason: Yeah, how dare you.

Brian: And it's like no one -- most people are not intentionally doing that. But some people, because as a maintainer they've hit trauma or hit an anxiety level that's like I'm never going to do that again, and then now they're basically passing out their pain to everybody else by saying, no, thanks, close, and passive-aggressive -- yeah, anyway. What I'm getting at is there's a way to not over-automate. What I do is automate whenever a new contributor contributes to my project. There's a little comment that automates itself. It's not trying to get anybody to do anything except join our Discord. I do that intentionally because in Discord, it's so much easier to have awkward conversations of like, you know, I don't know GraphQL. Open Sauce uses GraphQL. So join the discord, ask questions, or I can give you links and stuff. I can be like, oh, wow, there should be a doc on this. Then I can go open issue, prep for creating docs and stuff like that, which has happened a lot in my project because the project I've been working on I've been working on since I worked at Netlify previously. I started it while I was doing advocacy there. I just happened to be building it on my own, so there's a lot of knowledge I didn't document because I didn't think I would be still working on this thing four years later. But here we are. That's kind of how open source works. One project takes off and you're like, I guess I'm maintaining this thing.

Jason: Yeah, exactly. I think that's -- well, and that's the part that's always heartbreaking, when you see somebody hit their wall and they're like, okay, I'm done. I'm just walking away. We've seen this with a few projects, even recently, where the maintainers are posting public apologies because they burned out. It's like, you shouldn't feel guilty about -- like putting your mental health first, that's not a bad thing. Don't feel guilty about that.

Brian: Honestly -- yeah, sorry to cut you off, but you can get sucked in sometimes. You're like, I've been writing code for eight years on GitHub, and magically one project takes off. Now I'm excited and I'm getting all the dopamine or endorphins that are saying, wow, people like my code. I must be doing something right. So let me cater to this. Let me invite you to the party, give you contributor access. Then you realize, oh, this is the only thing I'm working on right now. I'm in the interested in this code anymore. What's the handoff path? What can I do to no longer be like either the face or do I just disappear. A lot of times that's what happens. People just stop responding to things, and they move on. I've contributed to projects, and back in the day there was a project around the GraphQL space early on. I really liked it. The maintainer responded to a couple of my contributions early on. You know, like, oh, cool. I started doing talks about this stuff. Then it sort of just fell off. I didn't know what happened. I still today don't know what happened to the maintainer. I was like, hey, if you want, I can take over this, I can maintain it. I really want to keep using this library. It just never -- I never got a response. I ended up forking it and using it. Eventually, I moved on because there were better tools at that point. Apollo had a better tool. I was like, I'm just going to use this thing now.

Jason: Absolutely, yeah. Well, cool. So all of that kind of philosophical underpinning in place, today we're going to write a GitHub Action that will listen for a PR. I'm just repeating what you said to make sure I understand it. So we're going to write a GitHub Action that listens for a new PR, and when it sees a new PR, it's going to check for some condition. If that condition is true, it will -- it's going to check that we didn't mention an issue, right?

Brian: We can go that deep. Yeah, so basically -- actually, I do have an issue open on this in Open Sauce if you want to take a look at that. So first, issue number 1072.

Jason: Let me switch over to pair programming here. Before we dive in, let me do a couple shout outs here. I'm going to shout out, first and foremost, we have this episode, like every episode being live captioned. We have Rachel with us today. Thank you very much, Rachel. That is on the home page of the site, learnwithjason.dev. You can see the live captions right here, as well as watching along with the show. That's made possible by our sponsors, Netlify, Fauna, Auth0, and Hasura, all of whom are kicking in to make the show more accessible to more people, which I really appreciate. While you're clicking on things, check out Brian Douglas' Twitter. Get on there. It's a lot of fun. It's a good pizza-filled feed. All things that I enjoy. There's also a lot of Beyonce, which is another very -- I don't know. I'm never sad to see Beyonce on the feed. Then we're going to be talking about GitHub Actions today. Is this the right page I should link people to for GitHub Actions? Or should I use a different one?

Brian: No, that works. That will get you started. There's links to docs there and everything. It's a good place. It's a thing we started with GitHub Actions, having these landing pages for features. We grew up as a company. Now I can point people to GitHub.com/feature/whatever the feature name is.

Jason: And you said you created an issue, 1072 here. Open Sauce repo, for you all to go check out.

Brian: So we can get to the point where we actually check for issues and see if there's -- or check for PRs and check if there's linked issues. We can do that in like, I think, step two, actually. But basically, this is like the path I figure we can walk down. There's going to be a couple things. I already have a bunch of actions enabled on my project. Just by you opening a PR, we can talk through what happened. Because you've never -- I believe you've never contributed to Open Sauce. If you have, this is not going to work. If you haven't contributed to Open Sauce, I'll show you what happens when you're a first-time contributor. The actions don't run automatically. This is kind of the overarcing conversation I wanted to have about PRs and actions because this comes up all the time. GitHub, we have a lot of users. 65 million users worldwide. Everybody uses GitHub differently. It's a power tool, which is totally okay and fine. But when it comes to open source, a lot of these projects operate like companies. But with contributors from everywhere. So it's like a different model than what our paid -- or I guess our enterprise customers are using. So for that reason, and because of Bitcoin mining, we don't let you have first-time contributors open PRs and trigger any actions.

Jason: So to repeat the threat model there, if I am a first-time contributor and I'm a dirt bag, I could write a GitHub action that would do cryptomining, open a pull request on your repo, and it would do cryptomining against your account, right?

Brian: Yep. And it would -- so let's say if you ran a job t will run indefinitely until I woke up one day and said, oh, wow, it looks like my action minutes are gone. You get 2,000 action minutes for free, which is pretty generous, which is why it's so advantageous to set up miners inside of NPM modules, which are actual examples of what's happened. Also, I'll point out the GitHub Security Lab has articles on all these examples and threat models, specifically for Actions. I highly recommend checking them out if you're interested and concerned in any way.

Jason: Nice, okay. Cool. So if I want to start here, like I want to make a change, I assume I need to clone the repo, right?

Brian: Yep, yep. You can clone or fork. Forking is a good start.

Jason: All right. Let's fork it.

Brian: You'll have to fork eventually.

Jason: Yeah, so let's do that. Wait, how do I do this? From the GitHub -- so if I want to go to -- if I use the GitHub CLI, I can just fork from right here.

Brian: Yeah, so actually, if you use the GitHub CLI -- go to the GitHub repo, and there's a green button. It will give you the actual command you can copy and paste.

Jason: What? Oh, look at that. That's cool. Okay. Then if I wanted to fork it, can I just say, like, fork?

Brian: Honestly, I don't know if there's a fork command. I actually haven't -- I've never done that. I usually just fork from there.

Jason: I can. Oh, yeah. I'm going to do that. I'm just going to fork it straight up. Let's see if it works. Here we go, everybody. Welt, it forked to the wrong place, but we'll make it work.

Brian: I guess you would have wanted it in Learn With Jason instead.

Jason: As long as I can link to it. So I have a fork. Let's go into Open Sauced. Good, good. All right. So I have all the things. If I open this in VS Code, which opened in the wrong tab. It jumped back to the wrong window. Come on now. So here we've got the different folders. Here's our source. And when we're looking at this repo, this is opensauced.pizza, right?

Brian: Yep. Yeah, and I guess we didn't explain this, too, as well. Opensauced.pizza is a project I mentioned earlier that I made. It's the path to your next open source contribution, which is a very broad way to say that I just want people to contribute to open source. So we don't have this feature yet. But if you log in, what you get are some recommendations for repos to start tracking and start contributing to. I have a whole algorithm idea that I've been talking with the contributors about, where there can be suggestions from other Open Sauced users. The way we do this is look at your stars. If you star a repo, it gets thrown into a pool of possible projects to contribute to. Then I'm going to basically check from other users if you star the same repos, then that would be a good signal of, hey, this is a project everybody should probably pay attention to because ten people are interested in this. Then I'm going to go a step further. This is all pie in the sky. Have not made this happen. Eventually, they will have some recommendations on what issues to work on.

Jason: Nice. Very cool, yeah. So what we've done here is just cloned the repo for this whole project. I now have a copy of it locally. It's my fork. So if I look at, I believe, if I do like a git remote -- nope, that's not it.

Brian: Dash V?

Jason: There we go. So it gives up the upstream of the Open Sauced library. The origin is my fork.

Brian: Yep. This concept right here, this is like what confused me about contributing. GitHub CLI gives that to you for free.

Jason: I got to tell you, the GitHub CLI is such a game changer. Like, before the GitHub CLI, I was using Hub. It was an amazing tool. It still is an amazing tool, does a lot of cool things. But the GitHub CLI has been just incredible. Let me throw a link in. If y'all aren't using it -- I use it all the time. It's so dang good. And you should absolutely go give this thing a try. It's very, very good. I see the chat is -- first of all, Chris Biscardi hit his two-year sub mark today right before we started. Thank you very much, Chris, for all the support. Also, I can't believe I've been doing this for two years. Then they just called out that I did, in fact, install -- I did install the FortNite theme. So let me turn it on. This is the new Fortnite mode from Sarah. Let me enable legendary mode.

Brian: That's amazing. I saw the tweet. I didn't look at this, but my co-worker installed it and was playing around with it last night.

Jason: Look at this llama. It's just such a ridiculous thing. Yeah, here's the chicken. I don't get it. Sarah is the funniest person I know. What a ridiculous human. But no, I love this. So yeah, let's roll Fortnite theme today. We'll do that. So, okay. I have the GitHub CLI, it's incredible. We're using that. Now that I have the GitHub CLI, I've been able to fork and clone the Open Sauced repo all in one command, which I have locally. I'm ready to do stuff.

Brian: Yeah. So I think the first thing we could probably do is to create some trivial change. The trivial change will help move the conversation along. So if you can go to the docs folder, create a file called learnwithjason.md. Probably link to this conversation. I can fill this out later and summarize this. Put some copy, Learn With Jason. Excellent. I think that's perfect. I think now you can open a PR. Actually commit this then open the PR, whichever way you open PRs.

Jason: So here's a question that I always have with forked PRs. I think this is a matter of preference more than it is a matter of necessity. When you open a PR from a forked repo, are you creating a branch, or are you just committing to main and then opening a PR against your main?

Brian: So this is actually covered in my contributing MD.

Jason: Which I can read.

Brian: Yeah, the preference is actually creating a branch, mainly because having some description in your branch is always going to be helpful for the maintainer. I also do recommend adding the issue number in the branch name. It's not required. But yeah, there's my -- and these are all steps I've stolen from other open source projects. Stolen, MIT licensed. No attribution needed. But what I'm getting at is -- yeah, so there's my example of adds new thing.

Jason: So what I will do is check out a new branch. So dash B is for a new branch. I will call this, what was it, 1072 is the issue number.

Brian: Yep.

Jason: Yeah, 1072. And then we'll say add LWJ doc. Okay. So now we're in this doc. By the way, Star Ship is amazing and gives you all this context so we can see where we are. I'm in this branch. Now if I look, I have one unchecked file. That's what this question mark means. I'm going to git add everything. Then we have the -- it's now added. So I can git commit. And my message is going to be doc, add a learn with Jason doc. Okay. So now there's nothing in my change here, but I can git push origin 1072.

Brian: Yeah, and there's -- this was mentioned in the chat, a question about forking and a branch on fork. I prefer this, too, as well because if you have a fork, there's a new feature on GitHub that shipped a couple months ago where there's a button to fetch from upstream. So you can do this locally. Or if you have a fork, you could also fetch from upstream from the main branch. So if you're not pushing to your main branch, you're not corrupting the history. So you don't have to delete the repo -- or delete the fork every time you want to contribute to the project if you don't touch main.

Jason: That's a great point. Okay. Yeah, that's an excellent reason to not use the main branch then. Okay. So now I have created this, and it looks like it gives me a shortcut where I could just click this button. But I'm in my CLI and I love the CLI.

Brian: Yeah, you can do the CLI command.

Jason: Gh pr create. Watch the magic, y'all. I'm going to send it so Open sauced and use my branch. It auto suggested a title. It says doc, add a Learn With Jason doc. Do you have a different format you prefer?

Brian: I think doc should work. We do semantic versioning for the PR titles. I squash all my commits. It's a whole other question and soapbox I can get on. But yeah, I think just keep doc in there. I think that should work. If it doesn't, we can fix it.

Jason: Okay. So I'm going to do -- instead of using nano, I'm going to do something I really like here. Instead of submitting this, I'm going to continue in the browser. So watch what happens.

Brian: Yeah, I was going to recommend doing that.

Jason: Look at this. Now I have my PR set up. It's like mostly set to go. You're using -- you do these through templates, right?

Brian: Yeah, so I have a PR template that gives you all this context.

Jason: And if I'm trying to learn how to add one of these, is that living in the repo?

Brian: Actually, it's not. That would be a great doc.

Jason: Oh, interesting. Yeah.

Brian: No, it's one of those -- it's funny because PR templates are something I didn't know until I was on a team and someone did it. I was like, what is this? How is it working? It happened to be a former GitHub employee. Actually, former CTO of Netlify. He's the one that taught me how this works.

Jason: Nice, nice, nice.

Brian: Yeah, I had no idea this was a thing. I think a lot of people come to my repository like, what's happening here? But what I want to say is, like, it's very important to not delete the context of this because this is necessary for me for creating, generating release notes and change logs. So I prefer everybody just to, you know, create a pull request, read it, and edit to update the context there. But here, we've got a -- you can check the box of documentation update, write a little description.

Jason: Do not leave this blank. So this is -- doesn't really fix it. It just kind of addresses 1072. So now we've set -- I bounced. So here's 1072, related tickets and documents. So I guess I can just keep this and say re 1072. What did I just type? I said the right letters.

Brian: That works. 072, I'm not sure if that would have pulled up issue number 72 or not.

Jason: Okay. So desk top. There is no visual change, really. Add a test? No, because they're not needed.

Brian: I just want to point out these questions are nice because this sparks people to say, oh, I didn't add any tests. They'll ask me, should I write tests? How can I approach this? I can even mentor them and coach them on how to writing tests in React. So again, this is like all stuff to help shepherd people to contribute to a project, even for the first time or second time or whatnot.

Jason: Mm-hmm. Okay. Come on now. 1072. Okay. So we know this is going to be part of a series of PRs instead of just being the one. We need to find a good animated GIF. How does this make me feel? I'm feeling very pizza centric today. That's the one.

Brian: Oh, I've never seen this one before. I feel like I've seen all pizza GIFs. This is something I also learned at my time at Netlify. Actually, Netlify kind of made me the human I am today. But I add this little link because it gets me a signal that people read the PR template. If there's no GIF, you don't get your stuff closed, but it does give me a better reaction. Like, it helps me to jump in to help review the stuff.

Jason: Okay, I think -- why do these all have audio? When did GIPHY become a video channel? This is now how it makes me feel. Geez. All right. Here's a small. Let's do a small.

Brian: Oh, I didn't know you could do different sizes. Today I learned. That's helpful.

Jason: Adam Levine excited about pizza.

Brian: Oh, shout out to accessibility.

Jason: Got to add those alt tags. Okay. So PRs with deleted sections will be marked invalid. Now I'm going to create my pull request.

Brian: That's the equivalent of when you go to someone's house and it says this house is protected by this security system. I haven't set up automation for that yet, but it's on my plans.

Jason: Okay. So I have now set up this pull request. Here's our doc. We've got all the pieces. And it'll link through here, where it shows that we did some stuff. This, no joke, is one of my favorite features of GitHub, this breadcrumb trail. You can say I'm working on this issue, and you put a number, and then it shows up in the sequence. You just get this nice timeline of this is what's happening.

Brian: Yeah. A couple things I want to point out. We can actually check out the checks tab. If you scroll down to where the statuses are -- or click there -- we'll see one failure, which I should probably add docs to the semantic release acceptable. I just added docs the last couple months.

Jason: Oh, docs, not doc.

Brian: Okay, that's what it was. We'll need to update the title to have an S. That's what it is. Okay.

Jason: Okay.

Brian: Cool, so that's going to trigger the actions to rerun. Then you're also going to see, if you go to the conversation tab and scroll all the way down to where the end of the PR is, you're going to see a couple different things. You can actually see some skipped actions. Also, you see big yellow font, two workflows are awaiting approval. This is what I talked about with the Bitcoin miner. You've never contributed to my project. This project doesn't know who you are. I think Netlify does the same thing with deploy previews. If this project does not know who you are, first-time contributor, it's not going to auto deploy stuff. It's for protection of the maintainer. So two things we could do. If you go to issue 1072 and you write in the comment .take, this will trigger an action to assign you to the issue. So you've literally never did anything in my project at all. So you commenting on my project, now you're a known -- you're an outside contributor. You exist. So if I look for a list of people who have contributed to the project, you now show up. This is all back-end stuff, more insider knowledge.

Jason: Oh, look at that.

Brian: Now you've been assigned the issue. This is something that's been a limitation for a lot of open-source projects. If I want to -- so specifically the project -- again, I stole this project. Again, MIT license. But I was chatting with them, and their issue is they have a bunch of issues. They want people to just jump in and take them. They don't want to be the sort of forcing factor to be like, okay, you have this issue and then go back and say, hey, you were assigned this issue, are you still working on this? So I've created automation. This is all in the contributing MD. Anybody on the project can just jump in and grab an issue. Don't ask me for permission. Just go ahead and assign it. Then if you want to follow up and ask questions, that's definitely possible. I think after assigning, I should add a comment and say, okay, thanks for taking the issue, here are next steps.

Jason: Sure, sure.

Brian: It is something I probably should add as I'm thinking out loud. If you go to my -- this is a great time to take a break and look at my workflows folder. If you go into the code tab -- actually, here you go. Inside of VS Code. Assign yourself. This is what the action is doing. Here I've got the assign. I'm watching for any created or edited issue comments. Then I'm running an action I created myself. Well, I took the idea. It was inspired. I ended up writing the code a little bit differently than what they did. But it's going to that repository. It's going to be using this GitHub token and assigning yourself.

Jason: Nice.

Brian: So that's the gist of it. So that works.

Jason: I'm not going to lie, I'm continually impressed by how much you can do with very little code once you've kind of got the core of it set up somewhere. This is just a repo. So if we go to this GitHub repo, which I guess we can do.

Brian: Yeah, definitely check out the GitHub repo. This is also very important. You should probably -- if you're going to use a GitHub Action, go look at the code. Make sure it looks legit. I did something very clever here where I'm using component steps inside of action yaml. This is a way to write scripts inside of one file. Because this was a handful of bash, I threw it into action.yaml. I'm running it as if it looks like an action workflow. And this gets run in my project. I can basically make this reusable because I use the same model in multiple projects.

Jason: Nice. Yeah, that's great. Well, cool. So now we have our ability to take an action, which I've done. Now I'm assigned.

Brian: Yeah, and in the PR -- I still have to approve your PR. So I click the button while we were waiting. Now it's going to start running all the other actions. I've got CodeQL, which is analyzing any sort of security vulnerabilities, as well as performance issues inside of my project. So if you add anything that is not performant in my markdown, it will let me know. Obviously this is going to check code files and not markdown.

Jason: Sure.

Brian: Then it's going to run my CI. The one thing I did want to point out is the difference between pull request web hooks and pull request target, which we'll get into in the next thing we're about to do. Pull request is what it sounds like. It's a web hook that runs on pull request. So you open the PR, it runs. If there are any tokens that is in the pull request, it's going to run on your tokens. So you, as the -- they call it a GitHub actor, the actor of generating the PR. It's going to run on your tokens. That works totally fine. I'm not leveraging any sort of tokens or personal access tokens. The semantic pull request, as well as the -- actually, I'm not using tokens there. The welcome message, though, that does use a token. This is what we're going to re-create.

Jason: Okay.

Brian: That uses a token because it needs to write to PR comments. So it looks like -- did it complete? Oh, it got skipped. So might have to get regenerated. I wonder if I can -- it got skipped because we didn't know who you were.

Jason: Ah, okay.

Brian: But now we know who you are. I'm just going to rerun that on my end. Just so we can see the comment get generated. This is one of those cases where I planned all this out, but also I've contributed to this all the time in all my other accounts. It was hard to sandbox that experience. But we're doing it live. So now it's going to rerun. Then you'll see a comment show up and say, hey, thanks so much.

Jason: Okay. So we're watching. Things are happening. CI/CD is almost done. We'll just give Adam Levine some screen time.

Brian: Yeah, honestly, I think this is -- I didn't think this through. It looks like it was still skipped. Why is the welcome message not saying hello? Somebody say hello to Jason.

Jason: Someone greet me.

Brian: If not, I can run this one more time. I think I can run it manually. If not, we can move on, and we'll see -- we'll rebuild that message. Essentially, what's going to happen -- actually, you know what, I'll just -- rather than belaboring this, I can just look at another PR, which I did get a first-time PR recently.

Jason: Okay.

Brian: We can just look at that message. Looking for the other Jason that just recently contributed. Oh, here we go. PR number 1059.

Jason: Just going to click in and edit. 1059.

Brian: Yeah, so this would have been the message if we didn't go the round about way. That would have been the message that showed up. Hey, thanks so much, join the discord. That's, again, intentional because I want people to be comfortable to ask questions. I personally don't like asking open-ended questions inside of my issues or PR comments because, you know, it exposes my lack of knowledge. Imposter syndrome. We all deal with it. So I want to make sure people have a place that they can finds me and ask those questions. I want to say the majority of folks do, but a handful of people do follow through and do that.

Jason: Cool. Cool, cool. Yeah, and I love this. The fact that this is just right here and it gives you a clear next step. Also, it lets you know, like -- I've opened PRs and I've also been the maintainer who sees a PR get opened and nothing happens for weeks. It's not because the maintainer, at least when I was the maintainer, it's not because I wanted to ignore somebody. It's because I just, like -- sometimes I just can't. I look at my GitHub notifications and I'm just like, not today. I can't do it today. Then I just close the tab. So I love this idea of at least acknowledging it. Like, there is a place for you to go. There's a next step. It wasn't just like thrown into the void. It's not a review. It's not like actual progress, but it's better than the void of silence when you just kind of open up a PR and nothing happens.

Brian: Yeah, and full disclosure, I didn't have this originally. This was just a link. I'd point people to the read me or contributing MD. I realized people were not getting to the Discord. It was too many steps to get there. So I replaced all those links and other contexts to just go to the Discord if you have any questions. We'll be back. Honestly, I've had a very busy week. I've been doing a lot of interviews for my team, as well as we shipped two features in the last week.

Jason: So you're really slacking off there.

Brian: Yeah, slacking off. I feel like I've taken time to work longer hours on other projects. Basically, I do go dark from time to time for reasons. I'm about to go on a week off of work, next week. I won't be dark. Actually, I'm probably going to work on the features I was mentioning before. But I intentionally make myself available on Discord but don't always make myself available in -- I'm laughing because there's somebody who said hello on your PR. Or on your issue. The chat is on top of everything.

Jason: I appreciate it. Thank you, chat, for making me feel welcome.

Brian: Sorry, the note I was going to make is at GitHub, we use GitHub to build GitHub. So my notifications are unreal. There are repos and projects and other folks on different organizations internally at GitHub who are hitting me up in notifications. We don't do email. We just do GitHub issues.

Jason: Whoa.

Brian: For that reason, it makes it hard to find Open Sauced issues and stuff like that.

Jason: You just gave me anxiety by telling me you only use GitHub notifications. Oh, my god. How do you -- okay. You know what, I'm not going to talk about this right now. I have so many questions.

Brian: Anybody, prospective GitHub employees, it's not that bad. You can unsubscribe to stuff. I just track mentions, to be honest.

Jason: Oh, okay, okay.

Brian: But because my mentions are like -- I don't know. I'm kind of a big deal at GitHub. Just saying. So people mention me on things. I do get mentioned and asked questions inside of issues a lot.

Jason: People mention me. I like that. That needs to be like a T-shirt. Or an animated GIF. People @ mention me on things. (Laughter) Okay. So we have, let's see, about 40 minutes remaining. I'm ready to do some --

Brian: Yeah, let's tackle -- let me go ahead and merge your PR. We're going to make that work. I do realize we could have triggered a new change and it would have rerun all the actions. When I was trying to rerun it, it runs it in a sandbox environment. If you make any other changes anywhere else, it's running in that sandbox. So it is actually pushing another commit.

Jason: Got it, got it.

Brian: Or you can do manual triggers, which I didn't have set up for this. We won't belabor that. We'll create our own actions.

Jason: Yeah, let's do it. And look, I can delete my branch now. Cleaning it right on up.

Brian: Thanks for keeping it tidy.

Jason: Then I can -- let's git checkout main. Then I'm going to git pull upstream.

Brian: Actually, before you do that, if you go into your repo -- actually, it's the same thing. If you go to your repo on your fork, I just want to show that quick.

Jason: Let's totally do that. That's absolutely what we should do. I'm going to go to my fork, which is here. Oh, we deleted it.

Brian: Yeah, your branch is gone.

Jason: Let me get rid of my branch. Okay.

Brian: And below the code button, there's a fetch upstream.

Jason: Oh, glory. Glory!

Brian: It's a little trivial because the only change you have is one commit.

Jason: It's so good, though.

Brian: I squash all the commits, so it's going to be one commit. Now you can pull from your origin main or git pull, which is going to default to origin as well.

Jason: Oh, beauty. It's so good. I love it so much.

Brian: There's so much dancing that you have to do to rebase, main, pull, remote, that now it's just one button.

Jason: And you saw I was about to like go into all this stuff. I was going to run the commands that I've memorized. I was going to do my little -- but it's all muscle memory. If you distracted me in the middle of that process, I'd have to start all over again.

Brian: Yeah, and I think I actually opened an issue for the CLI to make it easier on the CLI. So rather than click the button in the UI, it could have been like gh repo fetch upstream or whatever the command is. I'm saying it out loud because if everybody else wants to jump on the issue and say, hey, plus one, don't do that. But it would be a great signal so we can get that in the CLI as well.

Jason: We'll add a lot of heart emojis.

Brian: Yes, reactions are great.

Jason: So now I have our updated -- if I look in my code here, looking in the docs, here it is. Now we're on the main branch. Here, we can see we're on the main branch. So we're merged. We're up to date with upstream. I'm ready to do more stuff, which it sounds like we're going to be getting into actions here. So do I go back to this workflows folder?

Brian: Yep, you can create a new workflow. In this workflow -- actually, I don't know what a great name is. We can eventually get to the point where we check for linked issues. So at a PR, you can -- actually, if you go back to your PR, in the side bar, you could just show -- there's a section or I guess any PR, to be honest. There's a section called linked issues. This will give you -- yeah, right there. So for this PR, there's no linked issues. So we can write a quick script to check for linked issues. Then write a comment and say, hey, there's no linked issues. Pretty trivial, but it's super useful to run through this because other people who are on the same horse that I'm on, which is every PR should have a linked issue and then talk about this. Even if it's sort of a hand wavy, I opened the PR, but by the way I'm going to have the conversation over here, it's a good signal. It's okay that your code doesn't get merged because there was no discussion. The discussion helps get your PR merged.

Jason: Got it, okay. So let's do it.

Brian: We'll create a workflows file.

Jason: And it's going to be called, like, check linked issue.yml.

Brian: That works.

Jason: That's as much as I know about yml.

Brian: Excellent. You're right there with me. To be honest, the whole DevOps yml thing, something I was familiar with thanks to serverless.com, because they were the first tool that forced me to use YAML.

YAML, YAML, YAML.

Jason: Oh, no. We're in a loop. Oh, someone just called it again. I was like, I don't even know what to do if that's broken.

Brian: I haven't seen that before. That's amazing.

Jason: We don't do a lot of YAML on the show. There aren't a lot of occasions on it.

Brian: You got to get more YAML dev advocates or whatever. Senior YAML developers.

Jason: I mean, you know. Netlify is a TOML shop.

Brian: Yes, TOML for the win. We used HCL, the original language that was leveraged for GitHub Actions. In the later version of Actions, we ended up using YAML.

Jason: Who is Tom? Tom Warner. I don't know if you were trolling or if you knew the answer. Yeah, Tom Preston Werner. It was obvious to him.

Brian: My space guy. Fun fact, the office is in the same space.

Jason: Wait, is Tom, Myspace Tom --

Brian: No.

Jason: He didn't just put on a wig and say I'm not Myspace guy anymore?

Brian: I don't know. Get Tom on the phone, everybody.

Jason: We need an investigative journalist, stat.

Brian: We need to know this now. Hold the phone.

Jason: Has anyone ever seen Myspace Tom and Tom Preston Warner in the same place at the same time?

Brian: Honestly, no.

Jason: Yeah, probably not, right?

Brian: Not something I've seen.

Jason: I am severely digressing here. I don't want to run us out of time.

Brian: Yeah, let's start by naming this action workflow. So name: And check for linked issues, I guess. And on pull request.

Jason: Like so, right?

Brian: Yep. Then we'll need to -- so this is -- the first thing we did was name it. Then we're setting up what we're going to be watching for. We're going to be watching for any pull request that gets opened. We're going to check for linked issues. Going below, we'll have to start the jobs. So with GitHub Actions, you get 20 asynchronous jobs. Then you can name these jobs with an ID. This could be check pull requests or check-pull requests:. It's up to you.

Jason: You know what I just realized? It's been so long since I've written YAML, I didn't realize you could put hyphens in identifiers.

Brian: Yeah, welcome to the club. So a new line. So with the 20 asynchronous jobs, this will be our one job. I don't know how to explain YAML. Sorry. We'll need to do runs-on. There are some VS Code shortcuts that help with the completion. We don't have to look into it now. We'll just use ubuntu-latest because that's what I use for everything. Also, to be quite honest, it's the best thing to use. MacOS is literally trash can Max inside of a server. Not the best use of using servers. If anybody from Apple is here and they work in the infrastructure side, please ship some blades, some actual server structure. That would be awesome for everybody. Then this is going to be interesting. This is where we're going to name the steps of our job. Steps, colon.

Jason: Is it like this?

Brian: Yeah.

Jason: Do you have to indent?

Brian: You will need to indent, yes.

Jason: Okay.

Brian: Then for the sake of just getting something up and running because this won't run, mainly because you're an outsider in this project, do runs and echo hello world. Then commit this as a work in progress branch. I want to show this because we're going to switch line two to something different.

Jason: Is this correct? Do I have to quote this or anything?

Brian: No, that works.

Jason: Okay. So then I will get back into my CLI. Let's git checkout a new branch. We'll call this 1072 add GitHub Action. Then we'll git add everything. Check status. There it is. So we'll commit and say -- would this be a feature or a chore? What do you think?

Brian: Um, this will be a feature. It's going to be adding an actual action.

Jason: Okay. So then I'm going to git push origin 1072 add GitHub Action. We'll GitHub pr create. Okay. We're going to push it to my branch. Title will be feature. Add GitHub Action to -- what do I want to do? GitHub Action to check for linked issues. And we're going to skip and continue in the browser. Wrong tab.

Brian: You can also make this a draft PR as well, just a signal for everybody else. Hit the dropdown, do draft.

Jason: Okay. I'm going to skip all these -- well, I guess I can do that. Whatever. We'll check some boxes.

Brian: We can check boxes later. I tend to be in the practice of PR'ing early. Mainly as a signal of progress and stuff is happening. It's also a great way to get comments on your code. The one thing I wanted to point out is the fact that this action is not going to run. So if we look for -- what was the name of the action?

Jason: Like check linked issue or something. It's not in here.

Brian: Yes, and it's not in there because this is another sort of threat mechanism. You cannot open a PR to action and also have it run in the PR that you have it open on. If that makes sense.

Jason: Seems reasonable.

Brian: Yeah, it seems reasonable, but when we changed this, a lot of people were like question marks. This really comes down to we had to make a decision -- we as in GitHub. In open source, is it really important to have someone open a PR with an issue? This comes up around testing actions. You're able to fork and test this locally on your fork. But you should not be testing new actions live in quote/unquote production. What happens with this action, it's actually going to be running on actual code that's in the PR itself. So I wanted to point out this is not going to show up in the list. We're going to be running this mostly from your fork going forward. That way we can see it being triggered. So with that being said, we might have to test this in your fork PR.

Jason: Thank you, CJ, for making this into a real thing. Hilarious. Okay. Good job, well done. So now that I have this PR and I have an action, the action is not running, we do need to test it before we merge it, right? We don't want chaos to ensue. What is our step?

Brian: Unfortunately, we'll have to do another PR inside of your branch. Sorry, inside of your fork, to actually test this out. That way we can get this to -- we can test some of the logic we're going to build in a second. If you want to make another branch and make a PR to --

Jason: To my own, yeah. Okay. All right. So then what we can do is just open up an empty PR? Just change whatever? I don't remember how to do an empty commit.

Brian: On the same branch, you could do GH repo PR create and then point it to -- in the dropdown, point it to your PR. Right now it's pointing to upstream. If you point it to your PR, it should be able to create another PR. Does that make sense?

Jason: Wait, gh, pr create. Then where should we push the branch? I want you to push the branch.

Brian: Yeah.

Jason: No, I want it to be --

Brian: It doesn't give you a choice to --

Jason: Yeah, I think I need to change it. So let's do this. Let's do pr create help, and it should show me what the upstreams are. It probably does. I'm probably post owner repo.

Brian: Okay. Select another repository.

Jason: I think that's what I want. So I'm going to do R and jlengstorf open sauced. I think that'll do the same thing. We're going to push that.

Brian: Yes.

Jason: Yes, okay. So that's what we want. I'm pushing. This time I am just going to commit it because I don't care. So we've created our PR. I can click and open it. Now I'm in my branch, and it should be running our checks, which it isn't.

Brian: No, it is not. I think this might be a limitation in general. Sorry.

Jason: No, it's doing a thing.

Brian: I think we have an error.

Jason: What's my error? What did I do? Cannot be shown. Step must define a uses or run key. So I typoed.

Brian: Okay.

Jason: This is why we test. So is it run?

Brian: No S.

Jason: Oh, no. Okay. All right.

Brian: We were doomed from the start. But we found it. That was fast.

Jason: That should rekick this thing off. Now it is running an action. Good. Check for linked issue. It's doing stuff. So it did its thing and it passed. So let's go click and see. Run echo hello world. It did, in fact, echo hello world.

Brian: Looks good to me.

Jason: We've done the thing.

Brian: Yeah, now we can write some legit logic.

Jason: Let's do it.

Brian: In the issue, I made a link to GitHub Script, which I don't think we talked about last time I was on because I don't think it existed. It gives us an ability to write JavaScript instead of YAML, which sounds scary. But it's going to be okay. I'll walk you through it.

Jason: Okay. So I'm going to go to issues, here, and we're going to go to GitHub Script. Here we are.

Brian: Yeah, so the read me will give you the gist -- (Laughter). Sorry, just reading the chat. People are reacting to my dad joke. Basically, if you scroll down to the read me, there will be an example. You can use GitHub Script as an action. Just a little further down. There we go. Actually, just below here, this is an example of using external scripts. Where's any JavaScript? Okay, keep going down. This is about JSON encoding.

Jason: Oh, look at that.

Brian: Yeah, we can just copy that whole block.

Jason: Wow. Look at this.

Brian: This is actually the code we want to write. I forgot this was -- I mean, if you want to do some copy pasta coding.

Jason: Let's do some copy pasta because we are running short on time and I want to make sure we finish. We're pulling in actions GitHub repo script. We're saying with a script, and our script is going to do GitHub issues create comment. We know the issue number. We know the repo owner. We know the repo, all from context. Context comes in from the action.

Brian: Yeah, and this GitHub object, that's actually Octokit. It's pretty powerful. Gregor was just on one of the previous episodes. He's the maintainer of that stuff under the hood.

Jason: It is incredible. You should check that episode out. There's so much cool stuff we can do with it. But we're not talking about that. We're talking about this. So let's get in here. Oh, he's in the chat today. What's up, Gregor? Good to see you.

Brian: We can probably just change the comment and call it good and see the comment get written inside your PR. We'll just confirm that works. Then we can do the same thing upstream.

Jason: Use the old Discord comment. Let's go git commit GitHub. Then we'll do a message of feature, add comment. So now we've got our conversation here. What we should see is this kick off again. They're running again, just went yellow. I might need to refresh this.

Brian: One thing I should add about GitHub Script is it's a great way to prototype actions quickly, like what we're doing. Eventually, take that script and put it into a JavaScript file so I can test it properly and get syntax highlighting and all that stuff because YAML and JavaScript don't play well. Again, probably not a permanent solution despite the fact that some of my GitHub Scripts have been around for years. Also, you can take that same script that works and make your own action that can be used in other projects as well. If you want to quickly do an example live on Learn With Jason, it's definitely my go to.

Jason: Very cool. Yeah, and it worked. We have successfully added a thing. This is actually really nice because then it's not impersonating a person. And we were able to do this without having to go create a bot. Bot users are fine to set up, but it is kind of a pain, and there's steps and hoops. So being able to do this quickly is really, really nice.

Brian: There's a security risk as well when you create bot users. Then you have to maintain two-factor authentication on the bot users across teams. If that person leaves who owns the bot users, then you have this whole handoff thing, which is why we recommend things like GitHub Apps or GitHub Actions to do this instead.

Jason: Yeah, absolutely. So, okay. Now we've got this. I think the last piece that we need to do is let's update this to say what we're eventually going to say. Hey, you didn't link an issue from this PR. Could you please do that? That's a bad message. That's not what I would actually say, but we're short on time, so we're going to ship it. Now I need to add the check. How do we actually get it to check for this?

Brian: Check for looking for issues?

Jason: Yeah, for a linked issue.

Brian: Yeah, so I don't know if it's easier for me to give you a link to code that works and does this or if I talk you through it.

Jason: Let's see. What's left on our list here? We wanted to talk about workflow permissions. That's what we've been talking about.

Brian: Yeah, we haven't got that far yet. We did an audible. We're implementing a different action. But that would have been also writing a comment. Basically, that's because with my storybook, I have a Netlify deploy that's separate from Open Sauce. I want to have a storybook link for that specifically. I can address that later off air. But we can actually, in the GitHub Script, we can check to see the current PR and see if there's any link issues, if that make sense.

Jason: Okay. Can I just write like straight -- am I just writing JavaScript in here? I can do whatever I want?

Brian: You're definitely writing JavaScript.

Jason: Oh, my god. What a -- how many people are screaming in the chat right now? Give me an F in the chat if you're excited about JavaScript in YAML. (Laughter)

Brian: I guess the easiest way is capture a response from our issue number.

Jason: Okay.

Brian: Basically, let's just do const above there. We want to get the context of the issue. Not only just the issue. Basically just type PR -- I don't know. Why am I blanking? PR details sounds great. Then here we'll do some async stuff because we can. Just type await.

Jason: Okay.

Brian: Then GitHub.issues.listeventsfortimeline. This will get all the events on the timeline. This is going to take a couple different parameters. If you do a curly brace, like an object, then the first thing will be issue number. That could be context.issuenumber.

Jason: Is it this set? Can I just copy/paste this?

Brian: Yeah, it's everything there.

Jason: Okay, great.

Brian: That way we can get all the events. From those PR details, we'll need to filter those and look for anything that's called crossed reference, so in quotes. So filter details, maybe, or RFS sounds great.

Jason: Then I'm going to get one detail. Then I can say we want to see if -- is it like detail.name?

Brian: .event.

Brian: And we want to see if it equals -- you said it and I forgot it immediately.

Brian: Crossed-referenced.

Jason: Like that?

Brian: Yep. It's prdetails.data. The JSON object will always be sort of squashed inside the data.

Jason: That's right.

Brian: For the most part, we could probably run this in console.log because at this point, I'm kind of flying blind. Just to see what the cross-referenced data looks like. I think that would be -- yeah, that would be good.

Jason: Yeah, okay. Let's do it. Here we go. Actually, what we're going to get here is this should be an array, right? If the detail.event, if it's empty, we know we're done.

Brian: Yeah, I was coming to that conclusion. So if it's empty --

Jason: If refs.length is greater than zero, then we can just return. We're done. Get out. Then if it is zero, then we write this comment.

Brian: Yep. Cool. Pair programming for the win.

Jason: But I have to spell it right. So theoretically speaking, this should work.

Brian: Theoretically. I have low confidence in my memory to write code. But here we go. There are some other ways to debug this. A GitHub user called Crazy Max has a lot of cool actions. I use one called dump context. Literally, that's what it does. It dumps the context of the PR that you opened. Then you can sort of inspect that inside their action runner. So basically, I do that a ton.

Jason: Nice. So I'm pulling up Sarah's VS Code theme because somebody else just mentioned this as well. This is the Fortnite theme from Sarah Drasner. We'll make sure that shows up in the show notes for folks. Okay. So theoretically speaking, we have added a comment. I did not add a link from this PR. Good. So that means that it worked. Now let's see if I link an issue, which I would do by -- let's edit. Then I can just say --

Brian: 1072 is the one we've been working on. So you can't link -- you have to put the full URL. The shorthand of pound is going to be on that repo.

Jason: So we're going to drop in the whole thing. Then GitHub does this cool thing I like, where it gets shortened. I love it.

Brian: It gets shortened, but it names the repo I'm coming from.

Jason: Do we have a linked issue now?

Brian: It might take a refresh. I don't know if linked issues work when you have issues turned off in your fork.

Jason: Do I have issued turned off in my fork? Oh, I do, don't I?

Brian: Yeah, because it is a fork. Theoretically, this would work. It's just that we're operating in a sort of -- what's the term? We're not firing on all cylinders because we don't have issues turned on.

Jason: Okay. I just turned issues on.

Brian: Go ahead and create a different issue. I think it needs to be referenced within the same project.

Jason: That's usually how I open issues. Okay.

Brian: That's an automatic closure. I should set up an automation. If anybody opens an automation with that, no thanks.

Jason: So we're going to change this. It'll fix two. So I'm going to update. Now we have linked issues. One is set. It says it has a linked issue.

Brian: There we go, yep. Technically, we're not checking for previous comments. You might need to delete all those other comments. We could do logic to check to see if the comment exists already and remove that comment.

Jason: We probably should. But I'm going to just make a new -- I'm going to make a new PR here that'll just change this. Git commit. And this will update our PR. There it goes. Running our checks again. And if we did this right, we will not see -- we'll see the action complete, but we won't get a comment.

Brian: Yes.

Jason: So here's our action. It's queued.

Brian: The anticipation.

Jason: No! I screwed it up! So something in here -- and this is absolutely, like, now we have -- let's see. What do we even do here? Let's console log refs. That should contain --

Brian: Oh, we're specifically looking -- no, that should -- yeah, console log refs. My assumption is maybe there's something else being cross referenced. Sorry. There's no cross referenced. It's coming back empty. I wonder if that actual --

Jason: Oh, so maybe I should log the data too. So we'll do log of PR details and see what comes in there. Okay. I need to set this to upstream so I can do a fast origin test GitHub Action. Then we're going to get a new push. This one is going to give us a bunch of logs. So here we've got check pull request. We can look. Let's see what logs out. We're now in a race against time.

Brian: There's definitely a better way to set this up locally to test and debug this. It's not too bad to push to another commit.

Jason: Commiter, message. Event committed. Event committed. Event reviewed.

Brian: We actually are not getting any cross-reference events. Maybe this is a limitation. I don't think there were any changes, though.

Jason: So let's just look at event and pop through these and see what we've found. So we have 11 events. Committed, committed, reviewed, committed, commented, committed, comment deleted, committed, commented, committed, committed. Okay. So we're not getting a cross reference. So what that shows us is that the action itself works. We were just looking for the wrong thing. And that's okay because I threw Brian a curveball as soon as we started. Hey, what if we changed your whole plan and did something different? So this is not anything on GitHub Actions. This is 100% me doing what I do best, which is sowing chaos.

Brian: And me running with it. For context, we're pretty close. It's just trying to figure out what -- how to track linked issues inside the API. So we might actually have to hit a different end point. I know Gregor is a whiz. He's in the chat. If he wants to comment on the PR and tell us exactly what the end point is, maybe we can fix it after, later. I feel like we're so close, and this is something I've been so ready to have in my project and also recommend other people have in their project. When this does get actually implemented, I'll probably throw out a blog post and explain this and point people to this.

Jason: Okay. So here's what we'll do. We know -- here's what we were able to do today. We got -- we managed to kind of set up and fork. We played with the CLI. We got an action set up. And we got that action running, where we're able to kind of execute using Octokit, arbitrary stuff. So let me link to Octokit as well. Octokit is super powerful. We're using the JS version. So you can do just about anything in the API, if not everything in the API, through Octokit.js. That's what we're using under the hood here. So anything that we've got GitHub-dot, that's Octokit. We just have to figure out what the right API end point is, which is what we didn't get. So what works about this action is everything. It does exactly what it's intended to do. What we're wrong on is we are not pulling in the right details to figure out what the linked issue is. So yeah, Gregor, if you want to help us figure out what the right end point is, we can update this PR and link that from the show notes so everybody can see the working example when they reference this. Then yeah, Brian, I'm stoked to see your blog post on this because it is very, very cool. With that being said, where should people go if they want to keep up with you or take next steps here?

Brian: Yeah, yeah. So I'm bdougieYo on Twitter. That's the centralized hub of all the stuff I do. Also, no pressure, Gregor. I know you have a busy life as well. Open source for the win. Also, I have a Poly Work. Oh, you just did it as a thingy.

Brian: Yeah, a custom URL. If you just want to keep up with my blog posts, YouTube videos. It's the best place to keep up with that. So follow me there. You know, that's a cool place the kids are hanging out today.

Jason: Oh, look. Wait, do I have one of these? I do, I do have one. Now I can follow. Look at me go. Yeah, so now I'm following Brian Douglas on Poly Work.

Brian: If you scroll down a little bit, you'll see I have a YouTube channel. Every now and then when I have a YouTube video I think you should watch, I throw it up on there as well.

Jason: I very much enjoy all of your YouTube content. It's very fun. We'll just throw one of these in.

Brian: Got to love the ads.

Jason: Stop, everybody, please.

Brian: There I am.

Jason: Yeah, look at this guy. Also, I love that our lighting kind of matches. Like, the purple on mine just kind of fades into the purple on yours. It's excellent.

Brian: I should have updated it. I don't know. Can I get green going on this one? No. Close enough.

Jason: While you're doing that -- nailed it. So as usual, this show has been live captioned. We've had Rachel with us all day. Thank you so much, Rachel, for being here. She's from White Coat Captioning. That is made possible through the support of our sponsors, Netlify, Fauna, Auth0, and Hasura, all kicking in to make the show more accessible to more people. Go to the home page. Click on their logos. Check out their websites. They're cool folks. We have episodes on all of these. Go dig around in the archives, see some things. I think that's it, right? Any where else you want people to check before we call this one done?

Brian: No, those are the two main places. Also, YouTube.com/GitHub. I've been throwing videos up there a while now. It does get lost in the sauce a bit because we have a lot of content that goes there. Like and subscribe. If you see my face, double like if you can.

Jason: Smash that like button, ring the bell. Yeah, do the thumbs up. All those things.

Brian: Yeah.

Jason: Yes, absolutely. 100%. I always want to go so far with these jokes.

Brian: I had no response because that was my joke.

Jason: (Laughter) But yeah, definitely get in there. Go make all of that happen. I guess I can -- here, I'll do it. And we're going to ring that ball.

Brian: Excellent. We got one.

Jason: (Laughter) Don't tell anybody. I'm totally going to unring that bell afterwards because I have too many notifications.

Brian: I feel you.

Jason: Y'all, thank you so much for hanging out today. Brian, I really appreciate it. Make sure you go and check out this schedule because we have an absolutely incredible schedule coming up. This is only a portion of what's coming because I've been too lazy to update my website. We have like 25 episodes in the schedule coming up. So make sure you add on Google Calendar. That'll put this on your calendar. It doesn't send you notifications or block your calendar. It just lets you know when things are happening so you can always catch episodes when they come up. And remember, you can go find us on YouTube. I should probably add the Learn With Jason YouTube on here. I don't think there's any way to find it anywhere.

Brian: Yeah, I love catching up on the ones that I miss. My trick is I watch them 2X.

Jason: That is a hack. All right, y'all. I think that's all the time we have for today. Chat, stay tuned. We're going to find somebody to raid. Ben -- Brian. What did I just do? I read Ben out of the chat and turned to you. Brian, thank you so much for hanging out today. This was an absolute pleasure. Can't wait to see what y'all keep doing with GitHub Actions. All right, y'all. See you next time.