 Hello everyone. I'm glad to see you here. So my name is Marek Marusin and I am a participant of one of many summer coding programs. Actually, this is Google Summer of Code. So I'm part of Fedora community around, I don't know, three months. And before I start talking about one great automation tool, I would just like to thank my mentors and their team who really helped me with a lot of technical stuff. And I think without them I won't be here. So I will be talking about releasebot. Releasebot is especially useful when you are upstream developer or when you are maintainer of some projects. Because as we know, we still need to do quite a lot of manually work and hard work. And actually, that's why we are working on releasebot. Because imagine that you just created some, you are working on some great project. You create some amazing code, push it, and merge some great pull requests. And then you need to do this hard work like clicking and making releases, uploading to PyPI or packaging and et cetera. So that's why we are working on releasebot. And at current state, releasebot can create releases on PyPI GitHub and we are working on Pagur. But actually, I believe that maybe some in the future, we can also probably help like JavaScript developers or Ruby developers and create some and I'll upload their packages online. So I think you will like the concept of the releasebot. It's working in five steps. Actually, it's four. So step one, US upstream developer can open an issue in your upstream repository, which basically trigger our releasebot. Step two, releasebot is triggered and it will look on our repository, maybe work with some change log. Change log is basically file which describe differences between versions and it will create a pull request. Then in step three, US upstream developer, you just check the pull request if everything is okay and merge it. And step four, releasebot just create a release on PyPI, on GitHub or Pagur. So that's it and it just depends what you set up in your configuration files. And step five, your users are just very, very happy, but who actually benefits from the releasebot. It's you as a maintainer because you can just put your legs on the table or just doing much important stuff. Today, I actually prepared live demo, but I'm not sure how Internet, I found out that Internet is really slow here. So you'll see how it will work. Okay. So here, I have like a clean environment, Python environment, and I will be working with our README file in our releasebot repository. There is quite a lot of text, but you will see that it's pretty easy to work with this README. So there are several modes, how you can run a releasebot. You can run it on your local machine. You can run it on OpenShift and to the future, we are preparing GitHub application to make whole process much more easier. But today, I will show you just this most easier way how can you set up your releasebot on your local machine. So let's install our releasebot. And while it's installing, I will create a new repository on GitHub. Let's say it will be our project where we want to create our release. So let's call it like most amazing presentation and create the repository. Okay. And actually, I will clone this repository into my workspace. So it's here. I don't know if you can see it. And I will go inside this project. Okay. Now I'm going to read me of the releasebot. And there are two ways how you can set up your this configuration files. One way is just run releasebot in it. But actually, I want to show you some manual configuration to understand what's actually how it works. So basically, there are two configuration files. One configuration file we need to set up into our repository because make repository like compatible with releasebot. And second configuration file we need because it will contain some sensitive data. So let's create our first configuration file. We have some examples here. So I will basically copy paste it into our project. So I will create new file, copy paste and save it as releaseconv.yaml. Okay. So now I will go from the button and I will explain a little this configuration file. So basically here we have some labels because releasebot is working with issues and pull requests in your GitHub repository. So we want to sometimes label it. So let's say we want labels like bot and flock 2019. For this demo, we don't want to publish our release on PyPI. So I will choose false. And basically, there is some information for change or we don't need for now. But we need one more flag. Actually, it's triggered on issue. And this flag basically means that our releasebot will be triggered when new issue will be open in our repository. So let's save it and I will put it to the master. Okay, fine. So now when I refresh our repository, it should be there. Yes, it is. And the last thing we need to set up is our second configuration. We have also some example here. So I will copy paste it as well. But there is one important thing. We shouldn't, as I told, the second configuration file contains some sensitive data. So we shouldn't save it into our project repository. We can save it into our local machine or into some private GitHub repository. So I will go to my workspace. Create a new file. I will save it like cons.yml. And it's quite intuitive. So I will fill all the flags. But actually, if you want to know more about these configuration files, we have two tables, one for each configuration file where you can know more about all these flags and what you can set up into your configuration. So repository name is this new most amazing presentation. Repository owner, it's me. And we will need also GitHub username. It's also me. And I will set up a refresh interval for 15 seconds. Actually, when releasebot run on your local machine, it's based on pooling. So there is some infinity loop. And every now 15 seconds, it will wake up and check the repository if there is some new issues, let's say. But when you run releasebot, for example, in OpenShift, it works on webhook. So you just create some webhook URL and GitHub itself will notify the releasebot that there is some new action and I want to create a new release. And the last thing I need to set up is my very secure token from GitHub. So I will set up here. And okay, I actually think this is everything. You can see that set up configuration files for releasebot. It's quite easy. Stuff up to five minutes. So now I will do last thing and it will be, I will copy paste the command how to run our releasebot. So I will go to our workspace. So I want to run a releasebot with configuration file const yaml and debug flag, which basically means that it will just show us some prints what actually releasebot do. So now I will run it. So now it's sleeping for 15 seconds. So let's go to our most amazing presentation and I will create our first issue which will trigger like creating a new issue. But before I have to know in which format I can create such issues. So let's create a new issue and in our readme there are all the formats you can use actually. So let's create a new issue in our presentation. Let's call it version 001 release and submit this issue. As we can see, there is our first release and our bot is sleeping for 15 seconds. So let's wait for a while. Yes, so now it's doing the hard job, hard work now. And yeah, now when I refresh our repository there is one closed issue. There are our labels like bot and flock 2019. When I open it, there is some message from our releasebot. I just made a pull request for release version 001 and here is the link. So I will open our pull request. There is actually again some message from our releasebot and there is no change provided. I will fix it in the next step. So let's match this pull request. It's merged. Now when I check our repository, there are still zero releases and our bot is sleeping. So let's wait for a while. What do you mean? Okay. Yes, I can see. Okay, so actually now we have our first release made by our releasebot. So quite easy stuff how to do this. For now, I just quitted the releasebot for a while. I will go to our project and I will create a changelog. I need to pull all changes from our project and I will upload empty changelog. At changelog it push origin. Let's push it to the master. And again, I will run our releasebot. Okay, let's type it. Okay. So now I will show you the last thing. Let's create a new my release. Let's go again into our project and create new issue. New issue, new my release, submit new issue and let's wait for our releasebot. Okay. So there is pull request and here we can see the commit and what's new in our changelog. Actually, we can also edit it when we want some changes. So add changelog from releasebot and commit and let's just merge this. Okay. Now again, let's wait for our releasebot. So nice. Now we should have like two releases and the second release also contain message from the changelog. So actually, this is everything I wanted to show you today. In the future, actually, this is my task for this summer. I'm working on the GitHub application so it might be much more easier to set releasebot on your repository and yeah. If you have any questions now, you can ask me or yes. Labels, you can use labels just just if you want to use labels like you know, when you have your upstream project here, you have a lot of issues and you just want to know which is from your bot. So there is labels from the bot actually and the same is for the pull request. You know, a lot of people using labeling just to find difference between all the pull requests and issues. Actually, you mean like project name. I specified yes because we need to do this actually because there are two configuration files. And I used a project name in the second one which is actually private because there are some sensitive information like GitHub token. So this won't be saved somewhere within my project actually. Yes, this is actually true. I don't know. I'm saying you don't need the lines. No, you need them actually because okay, so the thing is that you run already both like in OpenShift or in the container and you have this config file in your private repository and that private repository is not your upstream project actually. Yeah, so you just need or this is kind of getting at the same point. It's like, so how does ReleaseBot know where the project is supposed to be releasing is? Like is that in this directory? Like where do you run ReleaseBot from? To anywhere? So in this config file can I have multiple projects? Not yet, not yet actually. Now we are working on this GitHub application and we want to figure out how to use one ReleaseBot instance for more deployments actually. And there are two ways like we can hard code it in a configuration file or your repository is what you want to use or actually if you will run a GitHub application there will be webhooks so GitHub itself will notify you which project want new release. So then these lines maybe will be just deleted. I'm not sure yet. So basically, so you don't have to have a check out of the project? What do you mean? Can you? You are assuming that I have only one project in one major repository? At the current SDS? A use case. But I have questions. If Release actually requires add action like bumping version in setup.py, am I able to do that with this one? Yes, yes. Okay actually I'm here till Sunday so if you have more questions you can just find me here. And I just would like to invite you for two more presentation. One is here from Thomas. It's also about releases and how to bring your upstream release to Fedora in one step. So against some automate it is packet. Yes and the second one is I think it's tomorrow morning. It's Fedora summer coding showcase and meetup. So thank you for listening and enjoy.