 Thank you for coming to my session. My name is Aivina Zaks. I'm open source evangelist and web developer. And in the past year, I've been working as a project manager for GitLab Acceleration Initiative. Today, we will divide into details and reasons why moving from Drupal CI to GitLab CI is good and how this change impacts module maintainers. So this session is targeted for everyone who works with Contribute Module Core is a different and separate step. GitLab Acceleration Initiative is the second phase of the major move by Drupal Association to provide Drupal developers with modern development platform. In 2020, code base was moved to GitLab. And in the current phase, we're moving issues and testing to GitLab as well. And in most cases in this presentation, when I use word GitLab, I'm referencing to self-hosted GitLab instance where Drupal code is available. First, I want to talk about what stays on Drupal.org and what will be on GitLab after initiative is complete. Drupal projects releases and endpoints with APIs and everything else stays on Drupal.org, as well as contribution credit and user documentation. These are very Drupal-specific components. Code is already on GitLab, and now we're working on replacing current bespoke Drupal CI with more standard GitLab CI. And after that, contributors can begin using GitLab issues instead of using Drupal.org issues. Existing issues for modules will be migrated to GitLab by Drupal Association. This effort is a major collaboration between Drupal community, Drupal Association, and GitLab. And clearly defined roles and responsibilities allows us to move forward efficiently. First, I would like to thank all contributors to this project and especially Drupal Spons projects for providing expertise, brainstorming, and insight. Thank you very much. The big important part of our collaboration with GitLab is that we're using standard features and we're not hacking GitLab core. And using basic principle of open source to identify missing features, we define how GitLab core can be improved and contribute back to GitLab their issues and discussions rather than building bespoke features on our end. So this is the outline of what we're doing for the last year. I'm going to be doing for the next six months. And there are two major steps. One is issues migration and the other part related is testing migrations. We're going to do a quick overview of what is going to be happening with issues, but this presentation is mostly about GitLab CI. So this is what issues look today. This is what boards look now. And this is what issues will look after they are imported in GitLab. And right now, we are in the process of testing migration tools. So this is actual web form issues migrated into test GitLab instance. After migration is completed, all standard GitLab tools for issues management will become available to developers. And there are lots of them, and they're all very helpful. However, issues migration will bring a major change. Testing will change from bespoke centralized Drupal CI and will be replaced with GitLab CI. The reason why we need to completely switch to GitLab CI because once issues are migrated, issues and Drupal.org will be completely decoupled and Drupal CI cannot be triggered. So what's the implications? Maintainers will have to set up their own GitLab CI file if they want testing for their contrib modules. They have two options. One, maintainer can include existing templates, and there's going to be one template provided by DA. And it's work in progress. And there is also advanced Drupal Spoon CI CD template that includes Composer and integration with local instances. It is available now, and you can try it anytime. And the second option is maintainers can write completely their own GitLab CI file, and some projects are already doing this. Testing phase started in spring, and using first template was provided by Drupal Spoon and several models wrote their own templates, including Project Browser. If you want to request GitLab CI to be enabled on your module, you go to this issue, submit your request, and your testing will be enabled on the Friday of the week when you're requested. Here are examples of what projects are doing with GitLab CI because it is not limited to testing. Some projects are using Drupal template, and we had some feedback, so the template itself is being improved when people test some corner cases and find bugs or do advanced testing. Open source principles in the work. People use it to build Drupal 10 readiness tests. Alex Spott is using GitLab CI to build distribution and recipes, and Brian is using GitLab pages for documentation, which is really, really great use of features provided out of the box by GitLab open source software. I want to thank earlier doctors. It always takes a little bit more effort and a little bit more time to work with a product that is not completely finished, so thank you very much for contributing your time and your work. So now I want to go through how GitLab CI will be converted to GitLab CI step by step. Let's look how it will take in practice, and hopefully in the next few weeks, prototype templates for maintainers that I'm going to be showing today will be finalized and prepared for initial release for every maintainer to use. So let's look at how we're moving UI-based Drupal CI that was provided and maintained by DA to new GitLab CI that is provided but can be modified. Why Drupal DA is putting so much effort into creating this template? We have thousands of Drupal projects, and we want to provide consistent baseline for testing even though the code for the testing will be sitting now in every module separately. We have, say, in PHP and database, options available for everyone, same coding standards, linting, so people don't have to spend time building their own things for standard things. Defaults will automatically provide what versions of core and Drupal system requirements it can be tested. And so maintainer can set and forget test configurations and work on their models rather than trying to figure out how to run Drupal CI. And for those who want to go beyond the template, they can extend Drupal CI with their images configurations or whatever they want to test. We already enabled GitLab CI for a handful of projects, and this is a screenshot of example code that is included in GitLab CI. GitLab CI is completely containerized, so those first few bootstrapping steps needs to be done within one of containers. GitLab CI itself takes care of spinning up containers for testing. And then we're defining for test execution what we're going to be doing, how we're going to doing, and where we are going to be looking at results. So the first thing we define is what code do we test? In Drupal CI, we had a screen where we could select which combination you want to test. In GitLab CI, you will be choosing branches, and I'll do a demo in a couple of slides, how you can add template to each branch, which takes a little bit more time for setup but provides much more flexibility than before. Moving forward, Drupal Association is thinking about adding default template for all new projects, but that is at least six months out. And for existing projects, you will add GitLab CI manually. Again, we'll do the demo. And when you begin testing, get feedback is very much appreciated. We are defining set of default environments where you can run the tests. And we'll explain how environments for testing can be chosen using semantic labels that are defined in variables in include files. This is where we set schedules now. GitLab CI has a very powerful system of pipelines and schedules. So you will go under Tab Schedules, and you can schedule any pipeline that you want to run. And it is very easy to maintain. And now we're going to dive into a real demo. And this is the prototype that is work in progress. And discussions are happening in GitLab channel. Send your feedback as greatly appreciated. Any questions so far? I have one question. You said early on, maybe this is too long of an answer, but you said early on that we're talking about Intrib and Drupal Core is something else that's different. Why is it different? And why are we not talking about that? Core has much more complex testing structure because core has to be tested with many more testing than contrived levels. If something is not wrong with contrived module, it's maintainer's problem at the end of the day. If something is wrong with a core, it impacts so many sites that you can't say, oh, we're going to experiment with this new testing. And something goes wrong. Well, oops. So that requires much more robust testing system and, most important, much more robust testing. So there are going to be a lot of testing of the testing before it can be released. OK, so the goal is to eventually get core into GitLab, but it's a later phase. Absolutely, yes. And this is a huge learning curve. So GitLab CI is a huge tool. It's like people who are coming from HTML coding to Drupal they're like, oh my god, what a learning curve. In the similar way, when Drupal is coming to GitLab CI, it's a huge learning curve. It's a very developed system. And there are so many things that Drupal community needs to learn to be efficient with this that it requires time. And nobody wants to put untested things on core. Did you say that the Drupal Association is running their own on-prem or their own installation of GitLab that's separate from like the hosted GitLab? Is that right? Yes, this is a very important point because there is GitLab.com where you can host your project for free at any time. The reason why Drupal Association have chosen to use one of the reasons, GitLab versus GitHub is that GitLab is open source software. So you can do self-hosted repository. And you have more flexibility there in terms of workflows, configuration, integration with user management. And there's a lot of work happening behind the scenes for integration of Drupal users with GitLab users. So there is a full authentication. And this was one of the challenges that were clearly identified by lots of developers, which is interesting. Like yesterday, very experienced developers, like 20 years experienced, like, oh, I forgot I have to go back to Drupal.org issue and click the additional button, get Git access. So all this additional work will go away when issues are on GitLab. But there has to be very good integration with login. So that's why it is unself-hosted. One of the reasons why it is unself-hosted instance. Cool, thank you. So the way GitLab CI templates are going to be offered at this point is Drupal Association will have file templates. And this is how, and we're using out-of-the-box GitLab features, which makes it much easier. And then modules are at the project level. So we're preserving existing Drupal project structure. Templates, file templates itself that are here, have, are also built with includes. So include folder has set of files that set defaults. And GitLab CI folder has set of templates. So it's built in mind that eventually you can extend beyond one basic template. Includes, include files have configurations for environments and workflows. And maybe something else, eventually. And this files can be, the way GitLab CI is set up, this default variables can be overwritten in your end template. And it propagates through the whole system. Variables include, will provide you with GitLab CI variables that automatically track development versions. So if you're using semantic labels, Drupal latest, or Drupal stable, or core minor, or whatever it is, when you move from 9 to 10 to 11, people who are using this variables in their own templates don't need to track what is the stable version of Drupal at this point, whether it's 9.4, 9.6, or 10.2. So the overall goal is that contrib maintainers don't have to update their testing configurations when new versions of Drupal are released. Drupal association will maintain this values, and then your test runs will update automatically. Workflows include, will set up when your tests run. By default, tests are run on commit and on merge request. And then you can define schedule both in code, in YAML file, or in GitLab UI. This is where I'm going to show you how you can add GitLab CI via Web ID because we're targeting people who want to use also UI tools. And we believe that developers will figure out their way for GitLab, and we don't need to provide instructions. So what GitLab allows us to do is it allows us to add template from the dropdown of the templates that we've seen before that are stored in the folder, which are, in turn, contain variables that are stored in respective includes folder. And then you add it, and then you commit it to your branch, and you can trigger, tests will be triggered even when you're committing template, or you can add additional schedules. And then anticipating a question from the audience, it is being in development right now. And we hope to release it as soon as it has been tested enough so it can be released in alpha. So I want to do a demo of how existing projects are using it right now so you can compare what was the old. So this was the old screen of how it used to be. And the GIN project is currently using this template, and this shows you where we're moving from. So here you can see that this is where people currently can add testing and see results of testing and schedule things. After we convert to Drupal CI, and this project is live, so you can go and check it if you are interested to see what's going on with the testing that already is working. So here you would see under this tab, this is where you would see results of the tests. It's not really working here. So this is where you would see results of the tests under artifacts. And one of the challenges is that people who are, as Drupal community is beginning to start GitLab CI, there's a lot of learning on where things are in GitLab CI. There's so many very cool features, but you have to learn them. So once you convert to GitLab CI, you will need to go and disable scheduled rules because you can start testing now without waiting until issues will be migrated. But then you don't want to abuse resources and do testing both on Drupal CI and GitLab CI. One time where you might want to compare this testing as if you set up your more custom GitLab CI and you want to see whether you're getting the same results as you have now with Drupal CI, this is where you might run both. But in general, you would want to disable it. And very important note that everyone needs to know. Patch testing is not available on GitLab CI. So patches should go away. There is a very heated discussion about it in the GitLab channel. And people are bringing all kind of very good points. And there are some things in development on GitLab side like how to preserve patches or how to work with patches or how to generate. I never understood why that. Why don't they want patches to exist? This is a subject for a whole entire new presentation. I will be more than happy to provide this presentation. Come visit you guys on site so we can have heated discussion. But there are some arguments on both sides that make sense. Are the existing patches that are currently on Drupal.org are they going to be preserved? Because we have them in code bases like composer patches and stuff like that. Right. I think if they are composer patches, whatever is in your code is not going to change. So whatever you have on Drupal.org in code already, that will stay there. We're talking here about patches that are attached to issues. That's what I mean. Yeah, that's what we're talking about. In the future, they're all going to be merge requests, which is fine. And you can get a patch file out of that if you want to. I'm talking about all the patches that are currently on Drupal.org in the file system with links that are there. We have those in our composer JSON file. So are they going to be preserved on Drupal.org and just not use that process anymore? But as long as the file is still preserved in the right place on Drupal.org. This is an excellent question. I will very much appreciate if you put this question in writing in GitLab channel. I can't answer it for you today. But having it in writing on GitLab channel in Slack will ensure that it will be converted. Or you can file it directly on Drupal.org, or both. Because this way. I'll search it too, because that answer, the question may have been answered all the time. I'm not sure. OK. So I think the current policy is that you're not supposed to use Drupal.org to post your patches. And so I guess it's going against policy. But I mean, I do that right now. So I guess should we change the policy then? Yes. I'm confused by that. Because how else do you do composer patches? Well, you could do it locally. Right. This is heated discussion that keep happening. Every probably three or four weeks there is discussion. Oh, we are relying on patches. And we need them. So the more discussion you contribute to Drupal.org discussion, the better policy can be developed. And the better decisions can be made, saying this is where this code that people are using will be stored once issues are migrated. Right. To be clear, I don't care about future stuff. Like everything in the future can be total GitLab everything. I'm just talking about all the patches in the past that are still that are currently on Drupal.org. If that file system just gets preserved, then I'm fine with that. As I said, it's an excellent question. And I think that by contributing this discussion, you can to answer your question about the policy. The policy is something that can be changed. Because the goal of the policy is to support Drupal community and not to, you know, one day just cut off thousands and thousands of sites that are relying on pulling these things on the regular basis. So this will be taken into consideration very seriously. The excellent question. And this is how you can help. Please join us. Request GitLab CI for your modules. Start testing them. Things are available right now. And the more early feedback, the more early adopters we have, the better templates will be provided when things are ready to move on. And for those who have custom Drupal CI, I think these people should be looking early at moving from custom Drupal CI to custom GitLab CI. This is various random links that were useful. To me, they will be in the presentation. Different people will have different things that they find useful. This is what I put together when I was learning, on my first round of learning GitLab. And here is a list of questions for you, for discussion, for looking for getting back to Drupal Association, like how Drupal Association can be most helpful in this transition. And please join us and contribute in person, online, and in any other way. Thank you very much.