[{"data":1,"prerenderedAt":1204},["ShallowReactive",2],{"/en-us/blog/tags/partners/":3,"navigation-en-us":19,"banner-en-us":435,"footer-en-us":447,"partners-tag-page-en-us":658},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/partners","tags",false,"",{"tag":9,"tagSlug":9},"partners",{"template":11},"BlogTag","content:en-us:blog:tags:partners.yml","yaml","Partners","content","en-us/blog/tags/partners.yml","en-us/blog/tags/partners","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":431,"_type":13,"title":432,"_source":15,"_file":433,"_stem":434,"_extension":18},"/shared/en-us/main-navigation","en-us",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":372,"minimal":403,"duo":422},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/","gitlab logo","header",{"text":29,"config":30},"Get free trial",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"Talk to sales",{"href":36,"dataGaName":37,"dataGaLocation":27},"/sales/","sales",{"text":39,"config":40},"Sign in",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,184,189,293,353],{"text":45,"config":46,"cards":48,"footer":71},"Platform",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"The most comprehensive AI-powered DevSecOps Platform",{"text":52,"config":53},"Explore our Platform",{"href":54,"dataGaName":47,"dataGaLocation":27},"/platform/",{"title":56,"description":57,"link":58},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":59,"config":60},"Meet GitLab Duo",{"href":61,"dataGaName":62,"dataGaLocation":27},"/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":67,"config":68},"Learn more",{"href":69,"dataGaName":70,"dataGaLocation":27},"/why-gitlab/","why gitlab",{"title":72,"items":73},"Get started with",[74,79,84],{"text":75,"config":76},"Platform Engineering",{"href":77,"dataGaName":78,"dataGaLocation":27},"/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"Developer Experience",{"href":82,"dataGaName":83,"dataGaLocation":27},"/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":166},"Product",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":27},"/solutions/",[98,123,145],{"title":99,"description":100,"link":101,"items":106},"Automation","CI/CD and automation to accelerate deployment",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,111,115,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/solutions/continuous-integration/",{"text":112,"config":113},"AI-Assisted Development",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":27,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":104,"dataGaLocation":27,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":27,"icon":130},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[132,135,140],{"text":133,"config":134},"Security & Compliance",{"href":128,"dataGaLocation":27,"dataGaName":133},{"text":136,"config":137},"Software Supply Chain Security",{"href":138,"dataGaLocation":27,"dataGaName":139},"/solutions/supply-chain/","Software supply chain security",{"text":141,"config":142},"Compliance & Governance",{"href":143,"dataGaLocation":27,"dataGaName":144},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":146,"link":147,"items":152},"Measurement",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":27},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[153,157,161],{"text":154,"config":155},"Visibility & Measurement",{"href":150,"dataGaLocation":27,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"Value Stream Management",{"href":160,"dataGaLocation":27,"dataGaName":158},"/solutions/value-stream-management/",{"text":162,"config":163},"Analytics & Insights",{"href":164,"dataGaLocation":27,"dataGaName":165},"/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab for",[169,174,179],{"text":170,"config":171},"Enterprise",{"href":172,"dataGaLocation":27,"dataGaName":173},"/enterprise/","enterprise",{"text":175,"config":176},"Small Business",{"href":177,"dataGaLocation":27,"dataGaName":178},"/small-business/","small business",{"text":180,"config":181},"Public Sector",{"href":182,"dataGaLocation":27,"dataGaName":183},"/solutions/public-sector/","public sector",{"text":185,"config":186},"Pricing",{"href":187,"dataGaName":188,"dataGaLocation":27,"dataNavLevelOne":188},"/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":280},"Resources",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"View all resources",{"href":196,"dataGaName":192,"dataGaLocation":27},"/resources/",[198,231,254],{"title":199,"items":200},"Getting started",[201,206,211,216,221,226],{"text":202,"config":203},"Install",{"href":204,"dataGaName":205,"dataGaLocation":27},"/install/","install",{"text":207,"config":208},"Quick start guides",{"href":209,"dataGaName":210,"dataGaLocation":27},"/get-started/","quick setup checklists",{"text":212,"config":213},"Learn",{"href":214,"dataGaLocation":27,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Product documentation",{"href":219,"dataGaName":220,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Best practice videos",{"href":224,"dataGaName":225,"dataGaLocation":27},"/getting-started-videos/","best practice videos",{"text":227,"config":228},"Integrations",{"href":229,"dataGaName":230,"dataGaLocation":27},"/integrations/","integrations",{"title":232,"items":233},"Discover",[234,239,244,249],{"text":235,"config":236},"Customer success stories",{"href":237,"dataGaName":238,"dataGaLocation":27},"/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":27},"/blog/","blog",{"text":245,"config":246},"Remote",{"href":247,"dataGaName":248,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":250,"config":251},"TeamOps",{"href":252,"dataGaName":253,"dataGaLocation":27},"/teamops/","teamops",{"title":255,"items":256},"Connect",[257,262,267,272,277],{"text":258,"config":259},"GitLab Services",{"href":260,"dataGaName":261,"dataGaLocation":27},"/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":27},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Events",{"href":275,"dataGaName":276,"dataGaLocation":27},"/events/","events",{"text":14,"config":278},{"href":279,"dataGaName":9,"dataGaLocation":27},"/partners/",{"backgroundColor":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","Insights for the future of software development",{"altText":285,"config":286},"the source promo card",{"src":287},"/images/navigation/the-source-promo-card.svg",{"text":289,"config":290},"Read the latest",{"href":291,"dataGaName":292,"dataGaLocation":27},"/the-source/","the source",{"text":294,"config":295,"lists":297},"Company",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"About",{"href":303,"dataGaName":304,"dataGaLocation":27},"/company/","about",{"text":306,"config":307,"footerGa":310},"Jobs",{"href":308,"dataGaName":309,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":309},{"text":273,"config":312},{"href":275,"dataGaName":276,"dataGaLocation":27},{"text":314,"config":315},"Leadership",{"href":316,"dataGaName":317,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":319,"config":320},"Team",{"href":321,"dataGaName":322,"dataGaLocation":27},"/company/team/","team",{"text":324,"config":325},"Handbook",{"href":326,"dataGaName":327,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"Investor relations",{"href":331,"dataGaName":332,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"Trust Center",{"href":336,"dataGaName":337,"dataGaLocation":27},"/security/","trust center",{"text":339,"config":340},"AI Transparency Center",{"href":341,"dataGaName":342,"dataGaLocation":27},"/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"Newsletter",{"href":346,"dataGaName":347,"dataGaLocation":27},"/company/contact/","newsletter",{"text":349,"config":350},"Press",{"href":351,"dataGaName":352,"dataGaLocation":27},"/press/","press",{"text":354,"config":355,"lists":356},"Contact us",{"dataNavLevelOne":296},[357],{"items":358},[359,362,367],{"text":34,"config":360},{"href":36,"dataGaName":361,"dataGaLocation":27},"talk to sales",{"text":363,"config":364},"Get help",{"href":365,"dataGaName":366,"dataGaLocation":27},"/support/","get help",{"text":368,"config":369},"Customer portal",{"href":370,"dataGaName":371,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":373,"login":374,"suggestions":381},"Close",{"text":375,"link":376},"To search repositories and projects, login to",{"text":377,"config":378},"gitlab.com",{"href":41,"dataGaName":379,"dataGaLocation":380},"search login","search",{"text":382,"default":383},"Suggestions",[384,386,390,392,396,400],{"text":56,"config":385},{"href":61,"dataGaName":56,"dataGaLocation":380},{"text":387,"config":388},"Code Suggestions (AI)",{"href":389,"dataGaName":387,"dataGaLocation":380},"/solutions/code-suggestions/",{"text":108,"config":391},{"href":110,"dataGaName":108,"dataGaLocation":380},{"text":393,"config":394},"GitLab on AWS",{"href":395,"dataGaName":393,"dataGaLocation":380},"/partners/technology-partners/aws/",{"text":397,"config":398},"GitLab on Google Cloud",{"href":399,"dataGaName":397,"dataGaLocation":380},"/partners/technology-partners/google-cloud-platform/",{"text":401,"config":402},"Why GitLab?",{"href":69,"dataGaName":401,"dataGaLocation":380},{"freeTrial":404,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":405,"config":406},"Start free trial",{"href":407,"dataGaName":32,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"Gitlab Icon",{"src":412,"dataGaName":413,"dataGaLocation":408},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"/images/brand/gitlab-logo-type.svg",{"text":418,"config":419},"Get Started",{"href":420,"dataGaName":421,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":423,"mobileIcon":427,"desktopIcon":429},{"text":424,"config":425},"Learn more about GitLab Duo",{"href":61,"dataGaName":426,"dataGaLocation":408},"gitlab duo",{"altText":410,"config":428},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":430},{"src":416,"dataGaName":413,"dataGaLocation":408},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":436,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":437,"button":438,"config":442,"_id":444,"_type":13,"_source":15,"_file":445,"_stem":446,"_extension":18},"/shared/en-us/banner","GitLab Duo Agent Platform is now in public beta!",{"text":67,"config":439},{"href":440,"dataGaName":441,"dataGaLocation":27},"/gitlab-duo/agent-platform/","duo banner",{"layout":443},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":448,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":449,"_id":654,"_type":13,"title":655,"_source":15,"_file":656,"_stem":657,"_extension":18},"/shared/en-us/main-footer",{"text":450,"source":451,"edit":457,"contribute":462,"config":467,"items":472,"minimal":646},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":452,"config":453},"View page source",{"href":454,"dataGaName":455,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":458,"config":459},"Edit this page",{"href":460,"dataGaName":461,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":463,"config":464},"Please contribute",{"href":465,"dataGaName":466,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":468,"facebook":469,"youtube":470,"linkedin":471},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[473,496,553,582,616],{"title":45,"links":474,"subMenu":479},[475],{"text":476,"config":477},"DevSecOps platform",{"href":54,"dataGaName":478,"dataGaLocation":456},"devsecops platform",[480],{"title":185,"links":481},[482,486,491],{"text":483,"config":484},"View plans",{"href":187,"dataGaName":485,"dataGaLocation":456},"view plans",{"text":487,"config":488},"Why Premium?",{"href":489,"dataGaName":490,"dataGaLocation":456},"/pricing/premium/","why premium",{"text":492,"config":493},"Why Ultimate?",{"href":494,"dataGaName":495,"dataGaLocation":456},"/pricing/ultimate/","why ultimate",{"title":497,"links":498},"Solutions",[499,504,507,509,514,519,523,526,530,535,537,540,543,548],{"text":500,"config":501},"Digital transformation",{"href":502,"dataGaName":503,"dataGaLocation":456},"/topics/digital-transformation/","digital transformation",{"text":133,"config":505},{"href":128,"dataGaName":506,"dataGaLocation":456},"security & compliance",{"text":122,"config":508},{"href":104,"dataGaName":105,"dataGaLocation":456},{"text":510,"config":511},"Agile development",{"href":512,"dataGaName":513,"dataGaLocation":456},"/solutions/agile-delivery/","agile delivery",{"text":515,"config":516},"Cloud transformation",{"href":517,"dataGaName":518,"dataGaLocation":456},"/topics/cloud-native/","cloud transformation",{"text":520,"config":521},"SCM",{"href":118,"dataGaName":522,"dataGaLocation":456},"source code management",{"text":108,"config":524},{"href":110,"dataGaName":525,"dataGaLocation":456},"continuous integration & delivery",{"text":527,"config":528},"Value stream management",{"href":160,"dataGaName":529,"dataGaLocation":456},"value stream management",{"text":531,"config":532},"GitOps",{"href":533,"dataGaName":534,"dataGaLocation":456},"/solutions/gitops/","gitops",{"text":170,"config":536},{"href":172,"dataGaName":173,"dataGaLocation":456},{"text":538,"config":539},"Small business",{"href":177,"dataGaName":178,"dataGaLocation":456},{"text":541,"config":542},"Public sector",{"href":182,"dataGaName":183,"dataGaLocation":456},{"text":544,"config":545},"Education",{"href":546,"dataGaName":547,"dataGaLocation":456},"/solutions/education/","education",{"text":549,"config":550},"Financial services",{"href":551,"dataGaName":552,"dataGaLocation":456},"/solutions/finance/","financial services",{"title":190,"links":554},[555,557,559,561,564,566,568,570,572,574,576,578,580],{"text":202,"config":556},{"href":204,"dataGaName":205,"dataGaLocation":456},{"text":207,"config":558},{"href":209,"dataGaName":210,"dataGaLocation":456},{"text":212,"config":560},{"href":214,"dataGaName":215,"dataGaLocation":456},{"text":217,"config":562},{"href":219,"dataGaName":563,"dataGaLocation":456},"docs",{"text":240,"config":565},{"href":242,"dataGaName":243,"dataGaLocation":456},{"text":235,"config":567},{"href":237,"dataGaName":238,"dataGaLocation":456},{"text":245,"config":569},{"href":247,"dataGaName":248,"dataGaLocation":456},{"text":258,"config":571},{"href":260,"dataGaName":261,"dataGaLocation":456},{"text":250,"config":573},{"href":252,"dataGaName":253,"dataGaLocation":456},{"text":263,"config":575},{"href":265,"dataGaName":266,"dataGaLocation":456},{"text":268,"config":577},{"href":270,"dataGaName":271,"dataGaLocation":456},{"text":273,"config":579},{"href":275,"dataGaName":276,"dataGaLocation":456},{"text":14,"config":581},{"href":279,"dataGaName":9,"dataGaLocation":456},{"title":294,"links":583},[584,586,588,590,592,594,596,600,605,607,609,611],{"text":301,"config":585},{"href":303,"dataGaName":296,"dataGaLocation":456},{"text":306,"config":587},{"href":308,"dataGaName":309,"dataGaLocation":456},{"text":314,"config":589},{"href":316,"dataGaName":317,"dataGaLocation":456},{"text":319,"config":591},{"href":321,"dataGaName":322,"dataGaLocation":456},{"text":324,"config":593},{"href":326,"dataGaName":327,"dataGaLocation":456},{"text":329,"config":595},{"href":331,"dataGaName":332,"dataGaLocation":456},{"text":597,"config":598},"Sustainability",{"href":599,"dataGaName":597,"dataGaLocation":456},"/sustainability/",{"text":601,"config":602},"Diversity, inclusion and belonging (DIB)",{"href":603,"dataGaName":604,"dataGaLocation":456},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":606},{"href":336,"dataGaName":337,"dataGaLocation":456},{"text":344,"config":608},{"href":346,"dataGaName":347,"dataGaLocation":456},{"text":349,"config":610},{"href":351,"dataGaName":352,"dataGaLocation":456},{"text":612,"config":613},"Modern Slavery Transparency Statement",{"href":614,"dataGaName":615,"dataGaLocation":456},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":617,"links":618},"Contact Us",[619,622,624,626,631,636,641],{"text":620,"config":621},"Contact an expert",{"href":36,"dataGaName":37,"dataGaLocation":456},{"text":363,"config":623},{"href":365,"dataGaName":366,"dataGaLocation":456},{"text":368,"config":625},{"href":370,"dataGaName":371,"dataGaLocation":456},{"text":627,"config":628},"Status",{"href":629,"dataGaName":630,"dataGaLocation":456},"https://status.gitlab.com/","status",{"text":632,"config":633},"Terms of use",{"href":634,"dataGaName":635,"dataGaLocation":456},"/terms/","terms of use",{"text":637,"config":638},"Privacy statement",{"href":639,"dataGaName":640,"dataGaLocation":456},"/privacy/","privacy statement",{"text":642,"config":643},"Cookie preferences",{"dataGaName":644,"dataGaLocation":456,"id":645,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":456},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":456},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":456,"id":645,"isOneTrustButton":90},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":659,"featuredPost":1181,"totalPagesCount":1202,"initialPosts":1203},[660,690,712,732,753,776,796,816,840,859,881,901,920,941,962,982,1001,1021,1041,1060,1080,1099,1119,1139,1161],{"_path":661,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":662,"content":670,"config":683,"_id":686,"_type":13,"title":687,"_source":15,"_file":688,"_stem":689,"_extension":18},"/en-us/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"title":663,"description":664,"ogTitle":663,"ogDescription":664,"noIndex":6,"ogImage":665,"ogUrl":666,"ogSiteName":667,"ogType":668,"canonicalUrls":666,"schema":669},"Accelerate code reviews with GitLab Duo and Amazon Q","Use AI-powered agents to optimize code reviews by automatically analyzing merge requests and providing comprehensive feedback on bugs, readability, and coding standards.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750096976/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750096975734.png","https://about.gitlab.com/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Accelerate code reviews with GitLab Duo and Amazon Q\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-06-02\",\n      }",{"title":663,"description":664,"authors":671,"heroImage":665,"date":673,"body":674,"category":675,"tags":676},[672],"Cesar Saavedra","2025-06-02","Code reviews are critical for catching bugs, improving code readability, and maintaining coding standards, but they can also be a major bottleneck in your workflow. When you're trying to ship features quickly, waiting for multiple team members to review your code can be frustrating. The back-and-forth discussions, the scheduling conflicts, and the time it takes to get everyone aligned can stretch what should be a simple review into days or even weeks.\n\nHere's where [GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), our new offering that delivers agentic AI throughout the software development lifecycle for AWS customers, comes in to transform your review process. This intelligent, AI-powered solution can perform comprehensive code reviews for you in a fraction of the time it would take your human colleagues. By leveraging advanced agentic AI capabilities, GitLab Duo with Amazon Q streamlines your entire review workflow without sacrificing the quality and thoroughness you need. Think of it as having an always-available, highly skilled reviewer who can instantly analyze your code and provide actionable feedback.\n\n## How it works: Launching a code review\n\nSo how does GitLab Duo with Amazon Q actually work? Let's say you've just finished working on a feature and created a merge request with multiple code updates. Instead of pinging your teammates and waiting for their availability, you simply enter a quick command in the comment section: \"/q review\". That's it – just those two words trigger the AI to spring into action.\n\n![Triggering a code review using GitLab Duo with Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097002/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097002096.png)\n\nOnce you've entered the command, Amazon Q Service immediately begins analyzing your code changes. You'll see a confirmation that the review is underway, and within moments, the AI is examining every line of your updates, checking for potential issues across multiple dimensions.\nWhen the review completes, you receive comprehensive feedback that covers all the bases: bug detection, readability improvements, syntax errors, and adherence to your team's coding standards. The AI doesn't just point out problems, it provides context and suggestions for fixing them, making it easy for you to understand what needs attention and why.\n\nThe beauty of this agentic AI approach is that it handles the heavy lifting of code review while you focus on what matters most: building great software. You get the benefits of thorough code reviews — better bug detection, consistent coding standards, and improved code quality — without the time sink. Your deployment times shrink dramatically because you're no longer waiting in review queues, and your entire team becomes more productive.\n\n## Why use GitLab Duo with Amazon Q?\n\nGitLab Duo with Amazon Q transforms your development workflow in the following ways:\n- Lightning-fast code reviews that don't compromise on quality\n- Consistent application of coding standards across your entire codebase\n- Immediate feedback that helps you fix issues before they reach production\n- Reduced deployment times that let you ship features faster\n- More time for your team to focus on creative problem-solving instead of repetitive reviews\n\nReady to see this game-changing feature in action? Watch how GitLab Duo with Amazon Q can revolutionize your code review process:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> To learn more about GitLab Duo with Amazon Q visit us at an upcoming [AWS Summit in a city near you](https://about.gitlab.com/events/aws-summits/) or [reach out to your GitLab representative](https://about.gitlab.com/partners/technology-partners/aws/#form).\n> \n> And make sure to join the GitLab 18 virtual launch event to learn about our agentic AI plans and more. [Register today!](https://about.gitlab.com/eighteen/)","ai-ml",[677,476,678,679,680,9,681,682],"AI/ML","code review","product","features","AWS","tutorial",{"slug":684,"featured":90,"template":685},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q","BlogPost","content:en-us:blog:accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","Accelerate Code Reviews With Gitlab Duo And Amazon Q","en-us/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","en-us/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"_path":691,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":692,"content":698,"config":706,"_id":708,"_type":13,"title":709,"_source":15,"_file":710,"_stem":711,"_extension":18},"/en-us/blog/amazon-linux-2-service-ready-partner",{"title":693,"description":694,"ogTitle":693,"ogDescription":694,"noIndex":6,"ogImage":695,"ogUrl":696,"ogSiteName":667,"ogType":668,"canonicalUrls":696,"schema":697},"GitLab is now an Amazon Linux 2 Service Ready Partner","Being an Amazon Linux 2 Service Ready partner shows GitLab's strong commitment to AWS linux distributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682451/Blog/Hero%20Images/isis-franca-hsPFuudRg5I-unsplash.jpg","https://about.gitlab.com/blog/amazon-linux-2-service-ready-partner","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab is now an Amazon Linux 2 Service Ready Partner\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2022-09-21\",\n      }",{"title":693,"description":694,"authors":699,"heroImage":695,"date":701,"body":702,"category":703,"tags":704},[700],"Darwin Sanoy","2022-09-21","\n\nSeveral months ago, we shared that GitLab started officially supporting Amazon Linux 2 as well as providing packages for GitLab and GitLab Runner for x86 and Graviton ARM architectures.\n\nGitLab’s hard working Enablement Engineering team has taken this commitment to the next level by acquiring Amazon’s Service Ready Partner designation for Amazon Linux 2.\n\nThe AWS Service Ready program requires that GitLab provide specific evidence in regard to support, compatibility testing and security testing in order to deploy GitLab on Amazon Linux 2 with confidence.\n\nHere is GitLab’s [Amazon Linux 2 Service Ready Partner listing](https://aws.amazon.com/amazon-linux-2/partners/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&partner-solutions-cards.q=GitLab&partner-solutions-cards.q_operator=AND).\n\n## Amazon Linux 2 support in GitLab 15.0\n\nAmazon Linux 2 is supported in GitLab 15.0 and later. An [earlier blog](/blog/amazon-linux-2-support-and-distro-specific-packages/) discusses a variety of important points and provides some code in order to plan a smooth transition.\n\nThe Service Ready Designation has been received for version 15.3, but there were no changes made to the process from 15.0 to support the designation.\n\nGitLab Runner has had ARM64 binaries since 12.6.0 and now has Amazon Linux 2 RPM packages for those wanting package-based installs.\n\n## Inside the distribution team process for distribution support\n\nIt would be easy to think that adding support for additional Linux distros is a simple and easy process - but there is actually a lot of effort that goes into it. GitLab’s Distribution Team uses GitLab itself to apply full DevOps disciplines to the continuous building, testing and distribution of packaging for Amazon Linux. Here are just some of the steps in preparing a GitLab release for packaging:\n\n- Create an elastic scaling distro-specific CI build environment.\n- Create a distro-specific CI test environment.\n- 2380 compatibility tests are performed on the GitLab code base.\n- SAST and dependency security scanning are completed and a specific escalation procedure is applied for any vulnerabilities that are found.\n- Primary distributions such as distro specific .deb and .rpm packages are prepared specifically for each distribution.\n- Secondary distributions are done as well - this is when the official GitLab AMI is created.\n- CI builds and testing generally happen multiple times a week for Amazon Linux.\n\n![Amazon Linux 2 Test Results](https://about.gitlab.com/images/blogimages/2022-09-amazonlinux/al2testsubgroups.png)\n\n![Amazon Linux 2 Test Results](https://about.gitlab.com/images/blogimages/2022-09-amazonlinux/al2tests.png)\n\n## Need-to-know takeaways\n\n- GitLab is now an official Amazon Linux 2 Service Ready Partner.\n- Amazon Linux 2 RPM packages are available for GitLab from version 15.0 and for GitLab Runner.\n\n> **Note**\n> This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.\n\n![AWS Partner Logo](https://about.gitlab.com/images/blogimages/2022-09-amazonlinux/amazonlinuxandgravitonready.png){: .right}\n","engineering",[681,9,705],"DevOps",{"slug":707,"featured":6,"template":685},"amazon-linux-2-service-ready-partner","content:en-us:blog:amazon-linux-2-service-ready-partner.yml","Amazon Linux 2 Service Ready Partner","en-us/blog/amazon-linux-2-service-ready-partner.yml","en-us/blog/amazon-linux-2-service-ready-partner",{"_path":713,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":720,"config":726,"_id":728,"_type":13,"title":729,"_source":15,"_file":730,"_stem":731,"_extension":18},"/en-us/blog/aws-devsecops-competency-partner",{"title":715,"description":716,"ogTitle":715,"ogDescription":716,"noIndex":6,"ogImage":717,"ogUrl":718,"ogSiteName":667,"ogType":668,"canonicalUrls":718,"schema":719},"GitLab achieves the AWS DevSecOps Partner Competency Specialty","The AWS DevSecOps Partner Competency Specialty demonstrates that GitLab is instrumental in helping customers implement better security while continuing to innovate.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668799/Blog/Hero%20Images/securitylifecycle.png","https://about.gitlab.com/blog/aws-devsecops-competency-partner","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab achieves the AWS DevSecOps Partner Competency Specialty\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2023-09-25\",\n      }",{"title":715,"description":716,"authors":721,"heroImage":717,"date":722,"body":723,"category":724,"tags":725},[700],"2023-09-25","\nGitLab recently achieved AWS's DevSecOps Partner Competency desigation, a sub-specialty for the [AWS DevOps ISV Partner Competency](https://partners.amazonaws.com/partners/001E0000018YWFfIAO/GitLab,%20Inc) category. GitLab also holds the AWS DevOps ISV Partner Competency designation. AWS's partner qualification program signifies to customers that AWS has vetted GitLab's capabilities and use cases.\n\n> Attending [AWS re:Invent 2023](https://reinvent.awsevents.com/)? Find us at Booth 1152.\n\nAccording to AWS, solutions in the [DevSecOps category](https://aws.amazon.com/devops/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc) \"make it easy for customers to integrate security across every stage of the development and delivery cycles, providing rapid and contextual feedback to development, security, and ops teams.\" The designation comprises a [validation checklist](https://apn-checklists.s3.amazonaws.com/competency/devops/technology/CenAm4qx8.html#competencyCategories) and attestation that GitLab's DevSecOps Platform meets AWS’s expectations.\n\n## GitLab's strength in DevSecOps\nGitLab's [AI-powered DevSecOps platform](https://about.gitlab.com/gitlab-duo/) helps organizations shift left on vulnerability remediation. At GitLab, shifting left means ensuring developers have a frictionless security defect remediation experience that enables them to immediately handle vulnerabilities in their code.\n\nGitLab's DevSecOps Platform:\n- surfaces security findings shortly after they are introduced and while the code is still being worked on\n- associates findings directly with those who changed the code\n- offers remediation guidance (including on-demand training and automated fixes)\n- supports rich, in-context collaboration for vulnerability management\n\n![GitLab + AWS Workflow](https://about.gitlab.com/images/blogimages/aws/devsecops-post/gitlabawsworkflow.png)\n\n\n![AWS Partner Logo](https://about.gitlab.com/images/blogimages/aws/devopsisvpartner.png){: .right}\n","devsecops",[681,9,705],{"slug":727,"featured":6,"template":685},"aws-devsecops-competency-partner","content:en-us:blog:aws-devsecops-competency-partner.yml","Aws Devsecops Competency Partner","en-us/blog/aws-devsecops-competency-partner.yml","en-us/blog/aws-devsecops-competency-partner",{"_path":733,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":734,"content":740,"config":747,"_id":749,"_type":13,"title":750,"_source":15,"_file":751,"_stem":752,"_extension":18},"/en-us/blog/build-an-ml-app-pipeline-with-gitlab-model-registry-using-mlflow",{"title":735,"description":736,"ogTitle":735,"ogDescription":736,"noIndex":6,"ogImage":737,"ogUrl":738,"ogSiteName":667,"ogType":668,"canonicalUrls":738,"schema":739},"Build an ML app pipeline with GitLab Model Registry using MLflow","Learn how to manage your ML apps entirely through GitLab with this tutorial. Also discover the role machine learning operations, or MLOps, plays in automating the DevSecOps lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","https://about.gitlab.com/blog/build-an-ml-app-pipeline-with-gitlab-model-registry-using-mlflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Build an ML app pipeline with GitLab Model Registry using MLflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gufran Yeşilyurt, OBSS\"},{\"@type\":\"Person\",\"name\":\"Péter Bozsó\"}],\n        \"datePublished\": \"2024-09-17\",\n      }",{"title":735,"description":736,"authors":741,"heroImage":737,"date":744,"body":745,"category":675,"tags":746},[742,743],"Gufran Yeşilyurt, OBSS","Péter Bozsó","2024-09-17","__*Editor's note: From time to time, we invite members of our partner community to contribute to the GitLab Blog. Thanks to Gufran Yeşilyurt, a DevOps consultant at OBSS Technology, for co-creating with us.*__\n\nThis tutorial will walk you through setting up an MLOps pipeline with GitLab Model Registry, utilizing MLflow. This will be a great starting point to manage your ML apps entirely through GitLab. But first, it is crucial to understand why we need MLOps and what GitLab offers.\n\n[MLOps](https://about.gitlab.com/direction/modelops/mlops/#overview), or machine learning operations, is a critical practice for managing and automating the lifecycle of machine learning models, from development to deployment and maintenance. Its importance lies in addressing the complexity and dynamism of machine learning workflows, which involve not just software development but also data management, model training, testing, deployment, and continuous monitoring.\n\nMLOps ensures that models are reproducible, scalable, and maintainable, facilitating collaboration between data scientists, machine learning engineers, and operations teams. By incorporating MLOps, organizations can streamline the deployment process, reduce time to market, and improve the reliability and performance of their machine learning applications.\n\nThe necessity of MLOps arises from the unique challenges posed by machine learning projects. Unlike traditional software development, machine learning involves handling large datasets, experimenting with various models, and continuously updating models based on new data and feedback.\n\nWithout proper operations, managing these aspects becomes cumbersome, leading to potential issues like model drift, where the model's performance degrades over time due to changes in the underlying data. MLOps provides a structured approach to monitor and manage these changes, ensuring that models remain accurate and effective. Moreover, it introduces automation in various stages, such as data preprocessing, model training, and deployment, thereby reducing manual errors and enhancing efficiency.\n\nGitLab's features play a pivotal role in implementing MLOps effectively. GitLab provides an integrated platform that combines source code management, [CI/CD pipelines](https://about.gitlab.com/topics/ci-cd/), tracking and collaboration tools, making it ideal for managing machine learning projects.\n\nWith GitLab, teams can leverage version control to track changes in both code and data, ensuring reproducibility and transparency. The CI/CD pipelines in GitLab automate the testing and deployment of machine learning models, allowing for continuous integration and continuous delivery. This automation not only speeds up the deployment process but also ensures consistency and reliability in the models being deployed. \n\nAdditionally, GitLab's collaboration features, such as merge requests and code reviews, facilitate better communication and coordination among team members, ensuring that everyone is aligned and any issues are promptly addressed.\n\nPrerequisites:\n- basic knowledge of GitLab pipelines\n- basic knowledge of MLflow\n- a Kubernetes cluster\n- Dockerfile\n\nThis tutorial includes instructions to:\n- [Set up environment variables of MLflow](#set-up-environment-variables-of-mlflow)\n- [Train and log candidates at merge request](#train-and-log-candidates-at-merge-request)\n- [Register the most successful candidate](#register-the-most-successful-candidate)\n- [Dockerize and deploy an ML app with the registered model](#dockerize-and-deploy-an-ml-app-with-the-registered-model)\n\nIn this example, to decide whether to provide the user a loan, we make use of Random Forest Classifier, Decision Tree, and Logistic Regression. At the end of this showcase, we will have a web application that utilizes machine learning to respond to the user.\n\nTo reproduce this example in your own GitLab environment, you can read the rest of this article or follow the video below. You can find the source code of this example in [these OBSS repositories](https://gitlab.com/gitlab-partners-public/obss).\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/grNJAp1xAi0?si=Bf9CAP9lB1uWErOZ\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Set up environment variables of MLflow\n\nOn the host where the code is executed, set the environment variables for tracking URI and token. This might be a remote host, CI pipeline, or your local environment. When they are set, you can call `mlflow.set_experiment(\"\u003Cexperiment_name>\")`. As a reference:\n\n```\nexport MLFLOW_TRACKING_URI=\"\u003Cyour gitlab endpoint>/api/v4/projects/\u003Cyour project id>/ml/mlflow\"\nexport MLFLOW_TRACKING_TOKEN=\"\u003Cyour_access_token>\"\n```\n\n**Note:** If the training code contains the call to `mlflow.set_tracking_uri()`, remove it.\n\n## Train and log candidates at merge request\n\nIn your model train code, you can use MLflow methods to log metrics, artifacts, and parameters. You can also divide the train steps into pipeline stages if you are comfortable with that part. In this example, one Python file will be used for both training and report generation.\n\n```\nmlflow.log_params(params)\nmlflow.log_metrics(metrics_data)\nmlflow.log_artifact(artifacts)\n```\n\nYou can then create the necessary pipeline to train the experiment. By adding the relevant rules, you can trigger this pipeline manually in merge requests and observe the report generated as MR Note.\n\nWhen the pipeline is finished, you can see the details about the candidate in **Analyze > Model Experiments**.\n\n![details about the candidate in the finished pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676127/Blog/Content%20Images/Screenshot_1.png)\n\n## Register the most successful candidate\n\nAccording to the measurements you have made, we can register the most successful candidate (may be the one with the highest accuracy value) with the Run ID of the candidate.\n\nBut first, we need to create a model and its version in Registry. I created these steps in separate stages and components (because I may need these steps in other projects). You should be careful to use semantic versioning when versioning.\n\n### Register source model parameters and metrics\n\n```\nsource_candidate = client.get_run(source_candidate_id)\nparams = { k: v for k, v in source_candidate.data.params.items() }\nmetric = { k: v for k, v in source_candidate.data.metrics.items() }\n\nmodel_version = client.get_model_version(model_name, version)\nrun_id = model_version.run_id\nmodel_class = \"\"\nfor name, value in params.items():\n    client.log_param(run_id, name, value)\n    if name == \"Class\":\n        model_class = value\n\nfor name, value in metric.items():\n    client.log_metric(run_id, name, value)\n\n```\n\nAfter logging the parameters and metrics, you can [register the artifacts](https://gitlab.com/gitlab-partners-public/obss/mlops-loan-prediction/-/blob/main/register_candidate.py) as you did in the train step.\n\nYou may want to manually enter the inputs of the relevant steps as [a variable in the pipeline](https://gitlab.com/gitlab-partners-public/obss/components/-/blob/main/templates/register-candidate.yml).\n\n## CI/CD components\n\nI have used [CI/CD components](https://docs.gitlab.com/ee/ci/components/) because they provide a structured environment for managing machine learning workflows. These components enable reusability by allowing teams to store and share standardized scripts, models, and datasets, ensuring that previous work can be easily accessed, modified, and redeployed in future projects, thus accelerating development and reducing redundancy.\n\n> [Learn more about CI/CD components and the CI/CD Catalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/).\n\n## Dockerize and deploy an ML app with the registered model\n\nIn this project, while registering the model, I also register the pkl file as an artifact and then create the docker image with that artifact and send it to [GitLab Container Registry](https://about.gitlab.com/blog/next-generation-gitlab-container-registry-goes-ga/).\n\nYou can now access your Docker image from the Container Registry and deploy it to your environment with the method you want.\n\n## Resources\n- [Model experiments](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/)\n- [MLflow client compatibility](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/mlflow_client.html)\n- [CI/CD components](https://docs.gitlab.com/ee/ci/components/)\n- [Building GitLab with GitLab: Why there is no MLOps without DevSecOps](https://about.gitlab.com/blog/there-is-no-mlops-without-devsecops/)\n\n***Credits:**\nThis tutorial and the corresponding sample projects were created and generously shared with the community by [OBSS](https://obss.tech/en/). OBSS is an EMEA-based channel partner of GitLab. They have deep expertise across the whole DevSecOps lifecycle and amongst many other things, they are more than happy to support customers with migrating their MLOps workloads to GitLab.*\n",[677,682,108,9],{"slug":748,"featured":90,"template":685},"build-an-ml-app-pipeline-with-gitlab-model-registry-using-mlflow","content:en-us:blog:build-an-ml-app-pipeline-with-gitlab-model-registry-using-mlflow.yml","Build An Ml App Pipeline With Gitlab Model Registry Using Mlflow","en-us/blog/build-an-ml-app-pipeline-with-gitlab-model-registry-using-mlflow.yml","en-us/blog/build-an-ml-app-pipeline-with-gitlab-model-registry-using-mlflow",{"_path":754,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":755,"content":761,"config":770,"_id":772,"_type":13,"title":773,"_source":15,"_file":774,"_stem":775,"_extension":18},"/en-us/blog/enhance-application-security-with-gitlab-hackerone",{"title":756,"description":757,"ogTitle":756,"ogDescription":757,"noIndex":6,"ogImage":758,"ogUrl":759,"ogSiteName":667,"ogType":668,"canonicalUrls":759,"schema":760},"Enhance application security with GitLab + HackerOne","Learn about the GitLab + HackerOne partnership and how to easily implement an integration that improves your organization’s application security posture.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","https://about.gitlab.com/blog/enhance-application-security-with-gitlab-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Enhance application security with GitLab + HackerOne\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-03\",\n      }",{"title":756,"description":757,"authors":762,"heroImage":758,"date":764,"body":765,"category":766,"tags":767},[763],"Fernando Diaz","2025-04-03","Security can no longer be an afterthought in the development process. Organizations need robust solutions that integrate security throughout the entire software development lifecycle. This is where the partnership between HackerOne and GitLab creates a compelling combination for modern application development teams.\n\nGitLab, the comprehensive, AI-powered DevSecOps platform, and HackerOne, the leading crowd-sourced security platform, have established a partnership that brings together the best of both worlds: GitLab's streamlined DevSecOps workflow and HackerOne's powerful vulnerability management capabilities.\n\nIn this tutorial, you'll learn how to enhance developer productivity and your security posture by implementing HackerOne's GitLab integration.\n\n## An integration that empowers developers\n\nHackerOne's GitLab integration is remarkably straightforward, yet powerful. When security researchers discover vulnerabilities through HackerOne's platform, these findings are automatically converted into GitLab issues. This creates a seamless workflow where:\n\n* Security researchers identify vulnerabilities via HackerOne's platform  \n* Validated vulnerabilities are automatically converted into GitLab issues  \n* Development teams can address these issues directly within their existing workflow  \n* Resolution status is synchronized between both platforms\n\nYou can start leveraging the benefits of GitLab and HackerOne by using the [integration](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) to track GitLab issues as references on HackerOne. This integration provides bi-directional and seamless data syncing between your HackerOne report and GitLab issues, improving alignment between development and security teams while streamlining security vulnerability processing.\n\nTo configure the GitLab integration to sync information between your HackerOne report and your Gitlab issue, follow the instructions provided in [HackerOne's GitLab integration documentation](https://docs.hackerone.com/en/articles/10394699-gitlab-setup), which includes:\n\n1. [Setting up an OAuth 2.0 application](https://docs.gitlab.com/ee/integration/oauth_provider.html) for your GitLab instance with the provided HackerOne settings  \n2. Connecting HackerOne to the newly created OAuth 2.0 on GitLab  \n3. Authorizing HackerOne to access the GitLab API  \n4. Configuring which GitLab project you would like to escalate HackerOne reports to  \n5. Selecting the HackerOne fields to map to corresponding GitLab fields  \n6. GitLab-to-HackerOne and HackerOne-to-GitLab event configuration\n\nOnce the integration is in place, you’ll be able to seamlessly sync data bi-directionally between both GitLab and HackerOne. This helps simplify context-switching and allows vulnerabilities to be tracked with ease throughout both systems. The integration allows for the following features:\n\n* **Creating a GitLab Issue from HackerOne:** You can create new GitLab issues for reports you receive on HackerOne.  \n* **Linking HackerOne reports to existing GitLab tasks.**   \n* **Syncing updates from HackerOne to GitLab:** The following updates on a report are synced as a comment to GitLab.  \n  * Report comments  \n  * State changes  \n  * Rewards  \n  * Assignee changes  \n  * Public disclosure  \n  * Close GitLab Issue  \n* **Syncing Updates from GitLab to HackerOne:** The following updates on GitLab will be reflected in HackerOne as an internal comment on the associated report:  \n  * Comments  \n  * State changes  \n* **HackerOne severity to GitLab label mapping**: Allows you to set a custom priority when escalating a report to GitLab.  \n* **Due date mapping:** Allows you to automatically set a custom due date based on the severity of a report.\n\n![GitLab + HackerOne adding comments or change the state of the report in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\nThese features improve alignment between development and security teams and streamlining security vulnerability processing. To learn more on how the integration works, see the [integration documentation](https://docs.hackerone.com/en/articles/8571227-gitlab-integration).\n\n## A look into HackerOne bug bounty programs\n\nHackerOne provides bug bounty programs or cybersecurity initiatives where rewards are offered for discovering and reporting vulnerabilities in customers’ software systems, websites, or applications. Bug bounty programs help enhance the security of an application by:\n\n* Identifying security flaws before malicious actors can exploit them  \n* Leveraging diverse expertise from a global community of security researchers  \n* Providing a cost-effective way to improve cybersecurity  \n* Complementing internal security efforts and traditional penetration testing\n\nGitLab utilizes HackerOne’s bug bounty program, allowing security researchers to report vulnerabilities in GitLab applications or infrastructure. This crowdsourced approach helps GitLab identify and address potential security issues more effectively.\n\n![HackerOne GitLab Bug Bounty page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\nBy leveraging HackerOne's platform and the global hacker community, organizations can significantly enhance their security posture, identify vulnerabilities faster, and stay ahead of potential threats.\n\n## Secure applications and improve efficiency with GitLab \n\nGitLab provides a complete DevSecOps platform, which enables functionality for the complete software development lifecycle, including security and compliance tools. GitLab supports the following security scanner types:\n- Static Application Security Testing (SAST)\n- Dynamic Application Security Testing (DAST)\n- Container Scanning\n- Dependency Scanning\n- Infrastructure as Code Scanning\n- Coverage-guided Fuzzing\n- Web API Fuzzing\n\nWith GitLab, you can add security scanning by simply applying a template to your CI/CD pipeline definition file. For example, enabling SAST just takes a few lines of code in the `.gitlab-ci.yml`:\n\n```yaml\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nThis will run SAST on the test stage, and [auto-detect the languages used](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) in your application. Then, whenever you create a merge request, SAST will detect the vulnerabilities in the diff between the feature branch and the target branch and provide relevant data on each vulnerability to assist with remediation.\n\n![NoSQL injection vulnerability seen in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\nThe results of the SAST scanner can block code from being merged if security policies are applied. Native GitLab users can be set as approvers, allowing required reviews before merging insecure code. This assures that all vulnerabilities have oversight from the appropriate parties.\n\n![Merge request approval policy](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\nHackerOne has integrated GitLab into its operations and development processes in several significant ways, which have led to development process improvements and enhanced scalability and collaboration. These improvements include faster deployments and cross-team planning.\n\n## Key benefits of HackerOne's GitLab integration\n\nThe key benefits of using HackerOne and GitLab together include:\n\n* **Enhanced security visibility:** Development teams gain immediate visibility into security vulnerabilities without leaving their primary workflow environment. This real-time awareness helps teams prioritize security issues alongside feature development.  \n* **Streamlined remediation process:** By converting HackerOne reports directly into GitLab issues, the remediation process becomes part of the standard development cycle. This eliminates context switching between platforms and ensures security fixes are tracked alongside other development work.  \n* **Accelerated time to fix:** The integration significantly reduces the time between vulnerability discovery and resolution. With HackerOne submissions immediately available in GitLab, development teams can begin working on fixes without delay, improving overall security posture.  \n* **Improved collaboration:** Security researchers, security teams, and developers can communicate more effectively through this integration. Comments and updates flow between both platforms, creating a collaborative environment focused on improving security.  \n* **Real-world impact:** Organizations implementing the HackerOne and GitLab integration have reported:  \n  * Up to 70% reduction in time from vulnerability discovery to fix  \n  * Improved developer satisfaction by keeping them in their preferred workflow  \n  * Enhanced security visibility across the organization  \n  * More effective allocation of security resources\n\n> To get started today, visit [the integration setup page](https://docs.hackerone.com/en/articles/10394699-gitlab-setup) today.\n\n## Learn more\n\nTo learn more about GitLab and HackerOne, and how we can help enhance your security posture, check out the following resources:\n* [HackerOne's GitLab Integration Usage](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)  \n* [HackerOne GitLab Bug Bounty Program](https://hackerone.com/gitlab?type=team)\n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [HackerOne achieves 5x faster deployments with GitLab’s integrated security](https://about.gitlab.com/customers/hackerone/)  \n* [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)\n","security",[766,682,230,9,476,768,769],"DevSecOps","bug bounty",{"slug":771,"featured":6,"template":685},"enhance-application-security-with-gitlab-hackerone","content:en-us:blog:enhance-application-security-with-gitlab-hackerone.yml","Enhance Application Security With Gitlab Hackerone","en-us/blog/enhance-application-security-with-gitlab-hackerone.yml","en-us/blog/enhance-application-security-with-gitlab-hackerone",{"_path":777,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":778,"content":784,"config":790,"_id":792,"_type":13,"title":793,"_source":15,"_file":794,"_stem":795,"_extension":18},"/en-us/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion",{"title":779,"description":780,"ogTitle":779,"ogDescription":780,"noIndex":6,"ogImage":781,"ogUrl":782,"ogSiteName":667,"ogType":668,"canonicalUrls":782,"schema":783},"Meet the demand for SBOMs with GitLab and Rezilion","Learn the role of SBOMs in helping to secure your software supply chain and how to generate them with the GitLab + Rezilion integration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672849/Blog/Hero%20Images/jessica-lewis-fJXv46LT7Xk-unsplash.jpg","https://about.gitlab.com/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet the demand for SBOMs and supply chain security with GitLab and Rezilion\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-10-17\",\n      }",{"title":785,"description":780,"authors":786,"heroImage":781,"date":787,"body":788,"category":766,"tags":789},"Meet the demand for SBOMs and supply chain security with GitLab and Rezilion",[763],"2022-10-17","\nModern software development often takes advantage of code reuse. Instead of reinventing the wheel, developers can use a library that focuses on a particular\nfunction for use in an application. However, there is one caveat: These\ndependencies may be susceptible to security vulnerabilities, which may render\nyour whole application – and possibly your software supply chain – as vulnerable.\n\nThat is why DevOps teams must be able to generate a software bill of materials, or [SBOM](https://docs.gitlab.com/ee/user/application_security/dependency_list/). GitLab has partnered with [Rezilion](/partners/technology-partners/#rezilion) to make this task easier.\n\n## The need for SBOMs\n\nIn 2020, the [Solar Winds software supply chain attack happened](https://www.businessinsider.com/solarwinds-hack-explained-government-agencies-cyber-security-2020-12). Hackers used an easy-to-guess password to inject malicious\ncode into a software update and many users of the affected Solar Winds product\nOrion, including government agencies, had their data compromised.\n\nThis breach, along with other high-profile attacks, led Pres. Biden's administration to [require software vendors to deliver a software bill of materials (SBOM)](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) with any software offer they make to federal agencies.\n\n## Secure your software and manage vulnerabilities\n\nTo get started with software supply chain security, you need to not only implement security scanning, but\nalso have a process in place to manage and effectively triage these vulnerabilities.\n\nBelow, you can see the typical software development lifecycle. It shows that security scans are run on a feature branch. A developer can view the presented vulnerabilities and continue to commit to the feature branch which re-runs the scans.\n\nOnce the vulnerabilities have been remediated the feature branch can be merged. If vulnerabilities are still present, [approval](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) by the security team can be required, and you can continue to keep track of the vulnerability with a [confidential issue](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html).\n\n![](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/sdlc.png)\n\nLet's go over how to do the following:\n\n* Implement security scanners in GitLab with built-in templates\n* Manage vulnerabilities with the GitLab vulnerability report\n* Manage dependencies and generate an SBoM\n* Efficiently triage exploitable vulnerabilities with Rezilion\n\n## Implement security scanners\n\nThe first step in securing your software supply chain is to implement [security scanners](https://docs.gitlab.com/ee/user/application_security/configuration/#security-testing) into your CI/CD pipeline.\nThese scanners should be set up in a way, where they run on each code commit. When a vulnerability is detected, approval by a security team member should be required.\n\nGitLab offers many different security scanners to get you started:\n\n* [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [Infrastructure as Code (IaC) Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n* [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n* [Coverage-Guided Fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)\n* [Web-API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)\n* [Secret Detection](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n\nWith the scanners running in a pipeline, static application source code is scanned, as well as dependencies and the\nrunning application itself.\n\nThese scanners can be implemented by simply adding templates to your [GitLab CI YAML](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-manually). You can also use the [Configuration UI](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-in-the-ui-with-customizations)\nto set up and configure these security scanners. You can check out the set up instructions for each scanner in the [GitLab appsec configuration documentation](https://docs.gitlab.com/ee/user/application_security/configuration/#security-testing).\n\n## Manage vulnerabilities\n\nNext up, see how to use GitLab to manage vulnerabilities. GitLab provides a single source of truth that allows developers and\nappsec engineers to collaborate and address issues together. After the security scanners have been implemented, there are a\nfew ways to manage vulnerabilities.\n\nDevelopers will use the MR view to see all the vulnerabilities present in the **diff** between the **feature branch** and the **branch you are merging with**.\n\nYou can see below, that each vulnerability is presented in an easy-to-read view: \n\n![Life cycle illustration](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/mr-view.png)\n\nWhen you click on a vulnerability, you can see details such as:\n\n* Status\n* Description\n* Evidence\n* Severity\n* Identifiers\n* Linked Issues\n* Solution\n* Security Training\n\nThe vulnerabilities are also actionable which means they can be dismissed or a confidential issue can be created to triage later.\n\n![Screenshot of vulnerabilities](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/mr-view-2.png)\n\nThen there is the [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) which displays all the vulnerabilities detected within the **main** branch and allows for the\nsecurity team to triage and address vulnerabilities from a common interface, enabling collaboration.\n\n![Detailed view of vulnerability](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/vr-1.png)\n\nOnce you click on a vulnerability, you are provided with [advanced details](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) on the vulnerability as well as how to remediate it.\n\n![Vulnerability report](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/vr-2.png)\n![Remediation suggestions](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/vr-3.png)\n\nAn appsec engineer can change the status, add additional information, and create confidential issues from this view.\n\n## Manage dependencies\n\nNow that you have seen how to run security scans on your application, as well as manage vulnerabilities, let's explore managing our \napplication's dependencies and understanding what is running on your system.\n\nThere are a few ways of managing dependencies and generating an SBoM. I'll go over\nthe GitLab Dependency List (SBoM) as well as the dynamic Rezilion SBoM.\n\n### GitLab Dependency List (SBoM)\n\nGitLab provides a [Dependency List](https://docs.gitlab.com/ee/user/application_security/dependency_list/) also known as an SBoM.\nThe dependency list contains your project’s dependencies and critical details about those dependencies, including their known vulnerabilities.  GitLab displays dependencies with the following information:\n\n| Field\t| Description |\n| ----- | ----------- |\n| Component\t| The dependency’s name and version. |\n| Packager |\tThe packager used to install the dependency. |\n| Location |\tFor system dependencies, this lists the image that was scanned. For application dependencies, this shows a link to the packager-specific lock file in your project that declared the dependency. It also shows the dependency path to a top-level dependency, if any, and if supported. |\n| License\t| Links to the dependencies' software licenses. |\n\nYou can download your project’s full list of dependencies and their details in [CycloneDX](https://cyclonedx.org/) JSON format. CycloneDX is a lightweight SBoM standard designed for use in application security contexts and supply chain component analysis. See it in action below:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/5a-_l1bqWhQ\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n### Rezilion SBoM\n\nRezilion provides a dynamic SBoM directly within the GitLab UI. It displays all the software components your application uses, and determines their loaded/unloaded status for a quick risk assessment.\n\n![Screenshot of SBoM](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/rezilion-sbom.png)\n\n## Easily triage exploitable vulnerabilities\n\nNow that you have seen how to secure your application as well as its dependencies, you \ncan make sure addressing security issues does not slow down development. What matters most in your\nenvironment is to help save developers time and deliver secure products in a swift manner.\n\nHere is where GitLab + Rezilion comes into play: The integration reduces developers' patching efforts by enabling them to only display vulnerabilities that are exploitable. Rezilion will mark unexploitable vulnerabilities as false positives, which can then be sorted out. This can be done within the GitLab vulnerability report:\n\n![Display of exploitable vulnerabilities](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/rezilion-exploitable.png)\n\nCheck out the demo showing how GitLab and Rezilion work together:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/FgNp7FQFniE\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nWith these tools in hand, not only will you be able to secure your application's code before it makes its way to production, but you'll be able to do it in a fast and efficient manner.\n\nTo learn more about the GitLab + Rezilion integration check out this [whitepaper](https://www.rezilion.com/wp-content/uploads/2022/03/Rezilion-GitLab-Solution-Overview.pdf). You can also sign up for a free trial of [GitLab Ultimate](/free-trial) and [Rezilion](https://rezilion.com/get-started).\n\nPhoto by \u003Ca href=\"https://unsplash.com/es/@jessicalewiscreative?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Jessica Lewis\u003C/a> on \u003Ca href=\"https://unsplash.com/s/photos/checklist?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>\n",[766,9,230],{"slug":791,"featured":6,"template":685},"fast-and-efficient-sbom-with-gitlab-and-rezilion","content:en-us:blog:fast-and-efficient-sbom-with-gitlab-and-rezilion.yml","Fast And Efficient Sbom With Gitlab And Rezilion","en-us/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion.yml","en-us/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion",{"_path":797,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":798,"content":804,"config":810,"_id":812,"_type":13,"title":813,"_source":15,"_file":814,"_stem":815,"_extension":18},"/en-us/blog/four-approaches-to-gitlab-integrations",{"title":799,"description":800,"ogTitle":799,"ogDescription":800,"noIndex":6,"ogImage":801,"ogUrl":802,"ogSiteName":667,"ogType":668,"canonicalUrls":802,"schema":803},"4 approaches to GitLab integrations","Learn about use cases that help extract even more value from a DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667946/Blog/Hero%20Images/4-facets-of-gitlab-integration.png","https://about.gitlab.com/blog/four-approaches-to-gitlab-integrations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 approaches to GitLab integrations\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kurt Dusek\"}],\n        \"datePublished\": \"2023-01-26\",\n      }",{"title":799,"description":800,"authors":805,"heroImage":801,"date":807,"body":808,"category":724,"tags":809},[806],"Kurt Dusek","2023-01-26","\n\nThe benefit of a DevSecOps platform is to create a foundation upon which an organization can build its entire development process. Rather than having to log onto several different systems to manage, observe, and advance through the software development lifecycle, DevSecOps teams have one application to serve as their system of record. To augment the platform and create even more business value, organizations can create integrations with third-party software and systems, while still maintaining a unified experience for stakeholders, developers, and operators.\n\nLet's look at what integrations are possible and the use cases that drive them.\n\n## What can be integrated with GitLab\n\nAs a senior solutions architect for Alliances here at GitLab, I often get asked, \"How can I integrate GitLab with X?\" My response: That depends on what's being integrated. X could be a cloud provider, point tool, legacy application or web service that might be used in the development cycle. \n\n## How to integrate with GitLab\n\nThere are four approaches to GitLab integrations:\n\n1. Use GitLab to deploy client applications to X / Host GitLab runners on X\n2. Host GitLab Server on X\n3. Integrate with the development cycle\n4. Deep GitLab application integration\n\nLet's dig deeper into each one.\n\n### 1. Use GitLab to deploy client applications to `X` or Host GitLab runners on `X`\nA very common use case and typically the easiest to achieve. For instance, platform providers, who want to make it easy for their users to run apps built with GitLab on their infrastructure or application server, are often asked for this option. The path is to have GitLab Server be able to authenticate to the hosting platform, and deploy the (ideally containerized) application to the platform.\n\nA close cousin of this is the need to deploy [GitLab runners](https://docs.gitlab.com/runner/) to the infrastructure and register them with a GitLab instance, be it GitLab.com or a self-managed instance. Runners are easy to setup and register, and can be [configured and scaled in many different ways](https://docs.gitlab.com/runner/fleet_scaling/). \n\n### 2. Host GitLab Server on `X`\nPlatform providers are also asked to host GitLab Server on their infrastructure. What makes this easy is GitLab runs almost anywhere; if you've got Linux, you can run GitLab Server (even on a Raspberry Pi). The work has already been done for the major cloud providers, including [GCP](https://docs.gitlab.com/ee/install/google_cloud_platform/), [AWS](https://docs.gitlab.com/ee/install/aws/), [Azure](https://docs.gitlab.com/ee/install/azure/), and [Oracle Cloud](https://docs.oracle.com/en/solutions/deploy-gitlab-ci-cd-oci/index.html). If you want to run on your own infrastructure, the [Omnibus](https://docs.gitlab.com/omnibus/) installer does most of the heavy lifting for you; it's the easiest way to self-host GitLab.  \n\n### 3. Integrate with the development cycle\nHere's where it starts to get a bit more involved. The good news is that GitLab has extensive [APIs](https://docs.gitlab.com/ee/api/) and [webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) that allow for listening for events and pushing and pulling data.\n\nIf the goal is to integrate with the [CI/CD pipeline](https://docs.gitlab.com/ee/ci/index.html), this can be done by creating a container image that encapsulates the application or scripts necessary and defining a job within the pipeline that uses this image to run the integration. It's likely the integrated app produces some output that **someone** needs to review. Displaying this output directly within the Merge Request elevates third-party data rather than something that has to be searched for in another system.  Depending on the nature of the tool being integrated, it's possible to show results and a [security report](https://docs.gitlab.com/ee/development/integrations/secure.html#report), [metrics report](https://docs.gitlab.com/ee/ci/testing/metrics_reports.html), or [artifact](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#expose-job-artifacts-in-the-merge-request-ui) that can contain almost any type of data.\n\n### 4. Deep GitLab application integration\nThis is the most complex since it requires an understanding of the [architecture of the GitLab application](https://docs.gitlab.com/ee/development/architecture.html#simplified-component-overview), and how an outside service will interact with and support this architecture. An example of this would be a managed PostgresSQL or Redis service. There's a potential risk of downtime if this type of integration goes wrong, so it's important to test thoroughly in a production-like environment before considering it production-ready. Fortunately GitLab publishes several tools to do this. [GitLab Performance Tool (GPT)](/handbook/support/workflows/gpt_quick_start.html) provides an excellent way to measure and report on the performance of a GitLab instance under various usage scenarios. Its counterpart [GitLab Browser Performance Tool](https://gitlab.com/gitlab-org/quality/performance-sitespeed) tests the browser performance of various GitLab pages.  \n\nRead more on [Kurt Dusek's blog](https://blog.scientifik.org/).\n",[230,9,705],{"slug":811,"featured":6,"template":685},"four-approaches-to-gitlab-integrations","content:en-us:blog:four-approaches-to-gitlab-integrations.yml","Four Approaches To Gitlab Integrations","en-us/blog/four-approaches-to-gitlab-integrations.yml","en-us/blog/four-approaches-to-gitlab-integrations",{"_path":817,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":818,"content":824,"config":834,"_id":836,"_type":13,"title":837,"_source":15,"_file":838,"_stem":839,"_extension":18},"/en-us/blog/gitlab-and-oracle-partner-for-a-cloud-native-approach-to-modern-application-development",{"title":819,"description":820,"ogTitle":819,"ogDescription":820,"noIndex":6,"ogImage":821,"ogUrl":822,"ogSiteName":667,"ogType":668,"canonicalUrls":822,"schema":823},"Oracle and GitLab partner for cloud-native app development","Learn the benefits of deploying the DevOps platform on Oracle Cloud Infrastructure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668514/Blog/Hero%20Images/multi-cloud-future.jpg","https://about.gitlab.com/blog/gitlab-and-oracle-partner-for-a-cloud-native-approach-to-modern-application-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab and Oracle partner for a cloud native approach to modern application development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Creighton Swank\"},{\"@type\":\"Person\",\"name\":\"Vick Kelkar\"}],\n        \"datePublished\": \"2022-10-20\",\n      }",{"title":825,"description":820,"authors":826,"heroImage":821,"date":829,"body":830,"category":724,"tags":831},"GitLab and Oracle partner for a cloud native approach to modern application development",[827,828],"Creighton Swank","Vick Kelkar","2022-10-20","\nModern application development requires a cloud native platform that can operate in and across multiple cloud providers. GitLab has partnered with Oracle to enable customers to run GitLab’s DevOps platform on Oracle Cloud Infrastructure (OCI).\n\nWith OCI, organizations can accelerate migrations of existing enterprise workloads, deliver better reliability and performance for all applications, and offer the complete services customers need to build innovative cloud applications. With GitLab’s DevOps platform and OCI, businesses can create a resilient, high-performance DevOps environment. OCI also supports automatic operating system patching and zero trust architecture, which aligns with GitLab’s focus on [application security](/stages-devops-lifecycle/secure/).\n\n## The benefits of pairing GitLab and OCI\n\nPairing GitLab’s DevOps platform and OCI provides many benefits, including the following:\n\n- performance\n- platform breadth\n- security\n- value\n- hybrid and multi-cloud environments\n- GovCloud regions\n\n### Performance\n\nOCI provides a high-performance, resilient foundation for cloud services. Customers can quickly provision instances that feature the latest-generation processors via API, SDK, command line, Terraform, or the console. Workloads can scale up and/or out based on their requirements and compute-intensive workloads can leverage GPU shapes for hardware acceleration of AI/ML workloads. At the same time, GitLab runners can be configured to [leverage Nvidia GPUs](https://docs.gitlab.com/runner/configuration/gpus.html) for various executors to take advantage of GPUs and AI/ML workloads. \n\n### Platform breadth\n\nGitLab’s DevOps platform has the ability to integrate with Kubernetes service like OKE via GitLab Kubernetes agent. Leveraging GitLab’s Kubernetes agent will unlock [GitOps workflow](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html) and [CI/CD workflow](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html) for cloud native development. And the Oracle Cloud Infrastructure also offers a wide variety of platform services that allow customers to run workloads without having to manage infrastructure. Customers can run workloads on compute instances, in containers with Oracle Kubernetes Engine (OKE), or even as serverless functions. Services like object storage and events can be leveraged to build applications without managing infrastructure at all. For a complete list of these services, please click [here](https://docs.oracle.com/en-us/iaas/Content/services.htm). \n\n### Security\n\nThe second generation of OCI has been redesigned from the ground up to be a secure cloud. Oracle designed OCI architecture for security of the platform through isolated network virtualization, highly secure firmware installation, a controlled physical network, and network segmentation. GitLab’s DevOps platform is not only an ODIC provider but the platform integrates with other identity providers to support single sign-on capabilities. The platform’s [permission model](https://docs.gitlab.com/ee/user/permissions.html#instance-wide-user-permissions) follows similar approaches used by OCI around separation of concerns and role-based access to resources. \n\n### Value\n\nMission-critical and revenue-generating applications demand more than just availability from their cloud infrastructure. Mission-critical workloads also require consistent performance and the ability to manage, monitor, and modify resources running in the cloud at any time. OCI offers end-to-end SLAs covering performance, availability, and manageability of services. \n\nGitLab’s DevOps platform uses the same code base for the SaaS offering as well as self-managed instances. Having the same code base allows customers to adopt the mission-critical DevOps platform in heavily regulated industries such as financial services and healthcare.\n\n### Support for hybrid and multi-cloud environments\n\nEven though many enterprises are moving workloads to the cloud, the reality is this is a multi-cloud world, and many enterprises still maintain infrastructure locally. Oracle has entered into strategic partnerships designed to make it easier for customers to operate in a hybrid and multi-cloud environment. \n\nOracle has partnered with VMware to create the Oracle Cloud VMware solution that allows customers the ability to use their existing tools and processes to manage a VMware environment in OCI. This allows enterprises to accelerate cloud adoption without having to re-architect their applications.\n\nGitLab’s DevOps platform can be deployed on vSphere infrastructure using the GitLab [omnibus install](https://docs.gitlab.com/omnibus/) method. The platform can be installed on-premises or in the cloud. GitLab can be deployed on VMs and the GitLab runners can extend CI capabilities into other cloud environments and [cloud-native hybrid](https://docs.gitlab.com/ee/administration/reference_architectures/#cloud-native-hybrid) deployments.\n\n### GovCloud regions\n\nOCI can provide government customers with the stringent security standards necessary to protect the federal government's data. Oracle has obtained a P-ATO from the Joint Authorization Board for FedRAMP High in its U.S. Government Cloud regions. Varying levels of DISA authorizations are also available but vary by services. Find an up-to-date list [here](https://www.oracle.com/industries/government/federal/fedramp/). Meanwhile, GitLab is pursuing a FedRAMP moderate certification and working on activities related to FedRAMP-ready designation. \n\n## Get started with the GitLab DevOps platform and OCI\nOrganizations looking to run GitLab’s DevOps platform on OCI can leverage the supported [Oracle Linux](/install/) package for the platform install. Alternatively, they can leverage the helm chart or GitLab Operator to deploy to Oracle Kubernetes Engine (OKE), which will provide a [cloud-native hybrid approach](https://docs.gitlab.com/ee/administration/reference_architectures/25k_users.html#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) of the GitLab DevOps platform on OCI.\n\nGitLab’s DevOps platform, delivered as a single application, can run on multiple clouds and has the capability of supporting various official [Linux packages](/install/). Besides Linux packages, GitLab’s platform also supports deployments on Kubernetes using [helm charts](https://docs.gitlab.com/charts/) and Kubernetes [GitLab Operator](https://docs.gitlab.com/operator/). \n\nIf you would like to learn more about the GitLab DevOps platform and OCI, please access the [LiveLabs](https://apexapps.oracle.com/pls/apex/dbpm/r/livelabs/home).\n\n_[Kelkar](https://gitlab.com/vkelkar) is GitLab's Director of Alliances. Swank is Distinguished Cloud Architect and Cloud CTO at Oracle._\n",[705,832,833,9],"open source","cloud native",{"slug":835,"featured":6,"template":685},"gitlab-and-oracle-partner-for-a-cloud-native-approach-to-modern-application-development","content:en-us:blog:gitlab-and-oracle-partner-for-a-cloud-native-approach-to-modern-application-development.yml","Gitlab And Oracle Partner For A Cloud Native Approach To Modern Application Development","en-us/blog/gitlab-and-oracle-partner-for-a-cloud-native-approach-to-modern-application-development.yml","en-us/blog/gitlab-and-oracle-partner-for-a-cloud-native-approach-to-modern-application-development",{"_path":841,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":842,"content":848,"config":853,"_id":855,"_type":13,"title":856,"_source":15,"_file":857,"_stem":858,"_extension":18},"/en-us/blog/gitlab-at-aws-re-invent-2023",{"title":843,"description":844,"ogTitle":843,"ogDescription":844,"noIndex":6,"ogImage":845,"ogUrl":846,"ogSiteName":667,"ogType":668,"canonicalUrls":846,"schema":847},"GitLab at AWS re:Invent 2023","GitLab and AWS have streamlined development and security for DevSecOps teams. Learn how in lightning talks, sessions, live demos, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664472/Blog/Hero%20Images/gitlabflatlogomap.png","https://about.gitlab.com/blog/gitlab-at-aws-re-invent-2023","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab at AWS re:Invent 2023\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2023-11-22\",\n      }",{"title":843,"description":844,"authors":849,"heroImage":845,"date":850,"body":851,"category":724,"tags":852},[700],"2023-11-22","GitLab will be at AWS re:Invent 2023 in Las Vegas, November 27 to December 1, to demonstrate how the GitLab DevSecOps Platform on Amazon Web Services delivers secure, enterprise-grade AI throughout the software development lifecycle. Stop by Booth #1152 in the Security Zone for [lightning talks, live demos, customer sessions, and more](https://about.gitlab.com/events/aws-reinvent/) all week. \n\nMake sure to [check out our event page and calendar](https://about.gitlab.com/events/aws-reinvent/) to find sessions, locations, opportunities to meet with GitLab, and more (note, they do not appear in the AWS event app). Some sessions will also be available on-demand after the conference.\n\nHere are some of the lightning talks GitLab will be presenting:\n\n**Frictionless developer experience: Using human habits to accelerate DevSecOps maturity and increase joy**\n\nGitLab’s long-standing approach to building DevSecOps pipelines aligns with AWS’ new emphasis on frictionless developer experiences. Join this session to learn how the GitLab DevSecOps platform represents a true “shift left” by empowering and streamlining developers’ normal workflow.\n\n[Add to calendar - Nov. 30](https://content.gitlab.com/viewer/65412018ca9e0b9d4b50acb2?iid=654966e4f2269af78f005ba1)\n\n**New integrations and solutions for using GitLab and AWS together**\n\nIn recent months, AWS and GitLab have built new service integrations for source control, CI, and CD. You'll learn how GitLab integrates with AWS CodeStar Connections, Amazon CodeGuru, OpenID, and more, as well as development and deployment solutions for Serverless.com Framework and Terraform to AWS.\n\nAdd to calendar\n* [Nov. 28](https://content.gitlab.com/viewer/65412018ca9e0b9d4b50acb2?iid=654144eef011a50313dc7113)\n* [Nov. 29](https://content.gitlab.com/viewer/65412018ca9e0b9d4b50acb2?iid=654942dfef8fa23b213f0eca)\n* [Nov. 30](https://content.gitlab.com/viewer/65412018ca9e0b9d4b50acb2?iid=65494b66a0b8daf9ca33a386)\n\n**Secure and assured Terraform development using GitLab security scanning policies and managed DevOps environments**\n\nThis lightning talk discusses and demonstrates working example code that extends GitLab's existing support for Terraform State management with full lifecycle-managed DevOps environments for merge requests, long-lived pre-production environments, production environments, and one-off experimental environments. Whether you are developing infrastructure as code specifically or embedding it with application code for the sake of easy environment support, this lightning talk has something to offer you.\n\n[Add to calendar - Nov. 28](https://content.gitlab.com/viewer/65412018ca9e0b9d4b50acb2?iid=654961043165b6f013635639)\n\n**Secure GitLab CD pipelines to AWS with OpenID Federation, OIDC, and JWT**\n\nGitLab has three ways to authenticate and authorize your CI and CD workloads into AWS environments. Adding and refining OpenID provides the ability to use an industry standard, which is the most advanced of the three. Join us to learn how to accomplish this highly secure integration option.\n\n[Add to calendar - Nov. 29](https://content.gitlab.com/viewer/65412018ca9e0b9d4b50acb2?iid=6549580763edc0caa46ea061)\n\n**Security intelligence through full integration of Amazon CodeGuru Security into GitLab**\n\nAWS CodeGuru Security has created a full integration that enables you to view scanner results in GitLab merge requests and security dashboards so you can use them to block merges in security policy merge approval rules — just like GitLab’s integrated security scanning results. Attend this lightning talk to learn more.\n\n[Add to calendar - Nov. 28](https://content.gitlab.com/viewer/65412018ca9e0b9d4b50acb2?iid=654953f963edc0cdbf6e8c6f)\n\n## GitLab and AWS: The year in review\nThroughout 2023, GitLab and AWS announced partner designations and new service integrations that enable development, security, and operations teams to collaborate more easily, to take advantage of AI at all stages, and to flexibly scale infrastructure to create and deploy secure software faster. \n\n#### AWS recognized GitLab as a partner in several categories\n\n- **AWS DevSecOps Partner Competency Specialty:** This specialty denotes that GitLab makes it easy for customers to [integrate security across every stage](https://about.gitlab.com/blog/aws-devsecops-competency-partner/) of the development and delivery cycles, providing rapid and contextual feedback to development, security, and ops teams.\n\n-  **Amazon Linux 2023 Ready Partner:** Amazon Linux 2023-specific RPM packages are available for GitLab, starting at [Version 16.3.0](https://docs.gitlab.com/ee/administration/package_information/supported_os.html) and for GitLab Runner. Official GitLab support for Amazon Linux 2023 also means GitLab builds the RPM packages and hosts them on our packages infrastructure, Graviton (arm64) and amd64 architectures are both supported. To install GitLab on Amazon Linux 2023, [follow these instructions](https://about.gitlab.com/install/#amazonlinux-2023). \n\nLearn more about [GitLab's AWS partner designations](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_partner_designations.html).\n\n#### AWS CodeStar Connections opens up a host of AWS service integrations\n\nAWS recently completed the integration of GitLab.com SaaS into its AWS CodeStar Connections service. This service is a foundational, shared service used by many other AWS services to connect to Git repositories outside of AWS. As a result, GitLab was immediately available to AWS services once this integration was completed.\n\nGitLab is available at CodeStar Connections throughout many AWS services for connectivity to Git. In addition, using a CodeStar Connection for an AWS CodePipeline opens up other service integrations that primarily rely on CodePipeline as their key integration point.\n\nHere is a visual map of the integrations that are currently available:\n\n![CodeStar Connections integrations](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676883/Blog/Content%20Images/gitlabcodestarconnectionsintegration.png)\n\n#### AI customization with AWS CodeWhisperer\n[AWS CodeWhisperer's customization capability](https://aws.amazon.com/blogs/aws/new-customization-capability-in-amazon-codewhisperer-generates-even-better-suggestions-preview/) leverages CodeSuite Connections, allowing generative code suggestions to take into account the libraries and design patterns of your current application when suggesting new code. It does so with no ingestion of your code into the general LMM creation. AWS CodeWhisperer can be pointed to a GitLab repository. \n\n#### AWS CodeGuru and GitLab Ultimate secure scanning integration\nThe AWS CodeGuru team [built an integration with GitLab CI](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html#scm-integrations) as part of their build secure scanning capabilities. [Amazon CodeGuru Security findings](https://docs.aws.amazon.com/codeguru/latest/security-ug/get-started-gitlab.html) use GitLab’s vulnerability report formatting, enabling exports to integrate directly into GitLab Ultimate security features such as merge request views, security dashboards, and in-context remediation solutions and training. Importantly, it allows these findings to be addressed by GitLab Security Policy Merge Approval Rules. \n\n#### GitLab's new single-tenant Saas option sits atop AWS\nEarlier this year, GitLab launched [GitLab Dedicated](https://docs.gitlab.com/ee/subscriptions/gitlab_dedicated/), a single-tenancy solution for organizations in highly regulated industries that have complex regulatory, compliance, and data residency requirements. The fully isolated SaaS offering is hosted and managed by GitLab and deployed on AWS in a cloud region of the customer's choosing. [Learn more about how GitLab built GitLab Dedicated](https://about.gitlab.com/blog/building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated/).\n\n## Plan your week at AWS re:Invent\nFill your calendar with GitLab at AWS re:Invent! [Check out our calendar](https://about.gitlab.com/events/aws-reinvent/) of sponsored sessions, lightning talks, live demos, and more throughout the week at Booth #1152.\n",[681,768,476,9],{"slug":854,"featured":90,"template":685},"gitlab-at-aws-re-invent-2023","content:en-us:blog:gitlab-at-aws-re-invent-2023.yml","Gitlab At Aws Re Invent 2023","en-us/blog/gitlab-at-aws-re-invent-2023.yml","en-us/blog/gitlab-at-aws-re-invent-2023",{"_path":860,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":861,"content":867,"config":875,"_id":877,"_type":13,"title":878,"_source":15,"_file":879,"_stem":880,"_extension":18},"/en-us/blog/gitlab-at-next-25-transforming-app-modernization",{"title":862,"description":863,"ogTitle":862,"ogDescription":863,"noIndex":6,"ogImage":864,"ogUrl":865,"ogSiteName":667,"ogType":668,"canonicalUrls":865,"schema":866},"GitLab at Next '25: Transforming app modernization","GitLab participated in Google Cloud Next ‘25 and received a fifth consecutive Google Cloud Technology Partner of the Year recognition.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663121/Blog/Hero%20Images/LogoLockupPlusLight.png","https://about.gitlab.com/blog/gitlab-at-next-25-transforming-app-modernization","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab at Next '25: Transforming app modernization\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"}],\n        \"datePublished\": \"2025-04-11\",\n      }",{"title":862,"description":863,"authors":868,"heroImage":864,"date":870,"body":871,"category":872,"tags":873},[869],"Regnard Raquedan","2025-04-11","GitLab's presence at Google Cloud Next '25 highlighted our strong partnership with Google Cloud and our joint commitment to accelerating software development and delivery. We were recognized again as a Technology Partner of the Year, and included in key enterprise initiatives like Google Distributed Cloud (GDC) Build Partners and [Startup Perks from Google Cloud](https://cloud.google.com/blog/topics/startups/why-global-startups-are-gathering-at-google-cloud-next25?e=13802955). Our team members demonstrated for attendees how GitLab is positioned to be a critical DevSecOps service for Google Cloud customers.\n\n## Continuing our award-winning partnership excellence\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175937/Blog/nempa4yvfutedz3fpuxx.jpg\" alt=\"GitLab team at Google Cloud Next '25\" align=\"left\" width=\"400px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nWe're thrilled to announce that GitLab has once again been named a [Google Cloud Technology Partner of the Year award winner](https://about.gitlab.com/press/releases/2025-04-08-gitlab-wins-a-google-cloud-technology-partner-of-the-year-award-for-devops/), marking our fifth consecutive time receiving this prestigious honor. This remarkable achievement reaffirms our position as Google Cloud's primary DevOps partner, consistently delivering exceptional value year after year. The continued recognition highlights how our collaboration with Google Cloud creates tangible business outcomes for customers, enabling organizations across industries to build, secure, and deploy applications with efficiency and confidence.\n\n## Google Distributed Cloud: DevSecOps for highly regulated environments\n\nAnother significant milestone announced at Next '25 was GitLab's \"Google Cloud Ready - Distributed Cloud\" certification. This designation enables organizations to implement GitLab in air-gapped environments, addressing critical security and compliance requirements.\n\nAs an end-to-end DevSecOps solution available on Google Distributed Cloud, GitLab enables sovereign development and operations for workloads critical to national security and regulatory compliance. This integration is particularly valuable for government agencies and financial institutions that require the highest levels of data sovereignty while maintaining modern development practices.\n\n## GitLab perks for Google Startups\n\nGitLab is a Featured Partner of the new Startup Perks program from Google Cloud. This partnership ties up with our own [GitLab for Startups](https://about.gitlab.com/solutions/startups/google-cloud/) and is meant to jumpstart new tech ventures with key DevSecOps capabilities that can help with fast growth and scaling.\n\nAs one of the [Featured Perks partners](https://cloud.google.com/startup/perks), eligible startups can get free or discounted access to one year of [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) for 20 licenses. For seed or early stage startups, this benefit can help ensure collaboration, efficiency, and security without sacrificing speed and agility.\n\n## Thoughts from the dais\n\nGitLab experts shared valuable insights across multiple speaking sessions at Next '25, delivering practical knowledge on AI-powered DevSecOps, platform engineering, and cloud application delivery:\n\n* __[AI DevOps panel](https://cloud.withgoogle.com/next/25/session-library?session=BRK2-163&utm_source=copylink&utm_medium=unpaidsoc&utm_campaign=FY25-Q2-global-EXP106-physicalevent-er-next25-mc&utm_content=reg-is-live-next-homepage-social-share&utm_term=-):__ Mike Flouton, GitLab Vice President of Product Management, joined industry leaders to discuss how AI code assist tools boost productivity while enhancing application performance.\n\n* __[Software Logistics - The Missing Link in Modern Platform Engineering](https://cloud.withgoogle.com/next/25/session-library?session=CT2-16&utm_source=copylink&utm_medium=unpaidsoc&utm_campaign=FY25-Q2-global-EXP106-physicalevent-er-next25-mc&utm_content=reg-is-live-next-homepage-social-share&utm_term=-):__ GitLab Field CTO Lee Faus explored how effective software logistics create the foundation for successful platform engineering initiatives.\n\n* __[Revolutionizing Cloud Application Delivery with Intelligent Agents](https://cloud.withgoogle.com/next/25/session-library?session=CT2-17&utm_source=copylink&utm_medium=unpaidsoc&utm_campaign=FY25-Q2-global-EXP106-physicalevent-er-next25-mc&utm_content=reg-is-live-next-homepage-social-share&utm_term=-):__ Faus also demonstrated how intelligent agents are transforming cloud application delivery pipelines.\n\n## Engaging attendees across Next '25\n\nIn addition to our speaking sessions, GitLab maintained a strong presence throughout Next '25. At our booth #2170 on the expo floor, our team engaged with hundreds of attendees through demonstrations and lightning talks featuring both GitLab experts and partners like Arctiq and SADA.\n\nThe Google Cloud Makerspace's Dev Tools Pantry became a hub of innovation and collaboration. John Coghlan, Director of Developer Advocacy, observed: \"It was great to connect with many GitLab and Google Cloud customers in the Dev Tools Pantry in the Makerspace. We loved seeing the creative solutions that people came up with around developer experience and simplified deployments using GitLab and Google Cloud as their ingredients.\"\n\nThese hands-on experiences showcased how GitLab's DevSecOps solutions integrate well with Google Cloud services, with our AI-powered capabilities demonstrations drawing particular interest from attendees looking to enhance developer productivity and application security.\n\n## GitLab and Google Cloud: Transforming the future together\n\nThe energy witnessed at Next '25 exemplifies why GitLab and Google Cloud make such powerful partners. Together, we help organizations to transform how they build, secure, and deploy applications through:\n\n* AI-assisted development capabilities and collaborative workflows that can help accelerate innovation in Google Cloud environments\n\n* Shift-left security approach that integrates with Google Cloud's security-first architecture to identify vulnerabilities early in the development lifecycle\n\n* Flexible deployment options and comprehensive observability that work harmoniously with Google Cloud infrastructure to help streamline operations\n\nAs demonstrated at Next '25, the GitLab and Google Cloud partnership delivers tangible advantages for development teams facing real-world challenges – whether accelerating AI adoption, strengthening security in regulated environments, or streamlining complex deployment pipelines. The technical integration points and customer success stories shared throughout the event underscore that this collaboration continues to produce practical solutions that matter.\n\n> #### Discover how GitLab and Google Cloud can transform your application development experience at [GitLab's Google Cloud partnership page](https://about.gitlab.com/partners/technology-partners/google-cloud-platform/).","news",[874,476,276,9,872],"google",{"slug":876,"featured":6,"template":685},"gitlab-at-next-25-transforming-app-modernization","content:en-us:blog:gitlab-at-next-25-transforming-app-modernization.yml","Gitlab At Next 25 Transforming App Modernization","en-us/blog/gitlab-at-next-25-transforming-app-modernization.yml","en-us/blog/gitlab-at-next-25-transforming-app-modernization",{"_path":882,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":883,"content":889,"config":895,"_id":897,"_type":13,"title":898,"_source":15,"_file":899,"_stem":900,"_extension":18},"/en-us/blog/gitlab-is-now-an-approved-slp-vendor-in-california",{"title":884,"description":885,"ogTitle":884,"ogDescription":885,"noIndex":6,"ogImage":886,"ogUrl":887,"ogSiteName":667,"ogType":668,"canonicalUrls":887,"schema":888},"GitLab is now an approved SLP vendor in California","State and local agencies in California can now purchase GitLab licenses at an agreed-upon discount.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668402/Blog/Hero%20Images/code-gitlab-tanuki.png","https://about.gitlab.com/blog/gitlab-is-now-an-approved-slp-vendor-in-california","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab is now an approved SLP vendor in California\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-04-19\",\n      }",{"title":884,"description":885,"authors":890,"heroImage":886,"date":892,"body":893,"category":724,"tags":894},[891],"GitLab","2022-04-19","GitLab is now an approved vendor under the Software Licensing Program (SLP) with the state of California. This contract allows state and local agencies, including educational institutions in California, to purchase GitLab software licenses at an agreed-upon discount, reducing costs and streamlining the procurement process. Under the contract, agencies will have greater access to GitLab’s complete DevOps solution, which empowers organizations to deliver software faster and more efficiently.\n\nEstablished in 1994, [California’s SLP](https://www.dgs.ca.gov/PD/About/Page-Content/PD-Branch-Intro-Accordion-List/Acquisitions/Software-Licensing-Program) is managed by the Procurement Division of the Department of General Services. The program provides government agencies and institutions with discounted rates for software licenses and upgrades, reducing the need for individual departments to conduct repetitive acquisitions. \n\n“There’s an exciting opportunity for public sector agencies to benefit from automated DevOps practices,” says [Bob Stevens](/company/team/#bstevens1), GitLab’s area vice president for Public Sector Federal. “This contract makes it simpler and more cost-effective for agencies to adopt The DevOps Platform, and deliver more resilient and efficient applications while keeping security at the forefront.”  \n\nGitLab believes that this contract, which makes The DevOps Platform more accessible and cost-effective, will expedite the broader adoption of DevOps in the [public sector](/solutions/public-sector/). GitLab’s single application will enable greater collaboration within public sector agencies, allowing teams to partner on planning, building, securing, and deploying software. \n\nTo streamline the process, GitLab will work with channel partners including [Acuity Technical Solutions](https://www.acuitytechnical.com), [Launch Consulting](https://www.launchconsulting.com) and [Veteran Enhanced Technology Solutions](https://veteranets.com/). \n\n“Public sector agencies are under tremendous pressure to transform and streamline their software development processes,” said [Michelle Hodges](/company/team/#mwhodges), GitLab’s vice president of global channels. “We’re proud to extend the power of our platform to a new network of customers via trusted channel partners and to help evolve the ways in which they collaborate on and deliver software.”",[705,9,766],{"slug":896,"featured":6,"template":685},"gitlab-is-now-an-approved-slp-vendor-in-california","content:en-us:blog:gitlab-is-now-an-approved-slp-vendor-in-california.yml","Gitlab Is Now An Approved Slp Vendor In California","en-us/blog/gitlab-is-now-an-approved-slp-vendor-in-california.yml","en-us/blog/gitlab-is-now-an-approved-slp-vendor-in-california",{"_path":902,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":903,"content":909,"config":914,"_id":916,"_type":13,"title":917,"_source":15,"_file":918,"_stem":919,"_extension":18},"/en-us/blog/gitlab-is-now-available-as-an-aws-codestar-connections-provider",{"title":904,"description":905,"ogTitle":904,"ogDescription":905,"noIndex":6,"ogImage":906,"ogUrl":907,"ogSiteName":667,"ogType":668,"canonicalUrls":907,"schema":908},"GitLab is now available as an AWS CodeStar Connections provider","AWS released native CodePipeline integration for GitLab projects and repos, helping to ensure a best-in-class experience when using GitLab and AWS together.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098884/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750098884409.jpg","https://about.gitlab.com/blog/gitlab-is-now-available-as-an-aws-codestar-connections-provider","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab is now available as an AWS CodeStar Connections provider\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2024-01-11\",\n      }",{"title":904,"description":905,"authors":910,"heroImage":906,"date":911,"body":912,"category":724,"tags":913},[700],"2024-01-11","The GitLab DevSecOps Platform now integrates natively with many AWS services through AWS CodeStar Connections and AWS CodePipeline. This long-awaited integration was recently completed by the AWS CodeSuite service team for GitLab.com SaaS, GitLab Self-Managed, and GitLab Dedicated. AWS CodeStar Connections is a utility layer, which means other AWS services can enable native GitLab integration with less work.\n\nOnce created, CodeStar Connections objects can be used directly to integrate with many AWS services such as:\n- AWS CodePipeline,\n- Amazon CodeWhisperer Customization Capability,\n- AWS Service Catalog\n- AWS Glue\n\nWhen a CodeStar Connection is used to configure a GitLab CodePipeline configuration it can further support:\n- AWS CodeBuild\n- Amazon SageMaker MLOps Projects\n- AWS CodeDeploy\n\nGitLab and AWS have been working at ever deeper levels of technical and business integration to ensure that our co-customers have a best-in-class experience when using GitLab and AWS together.\n\n![AWS CodeStar integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098901/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098900704.png)\n\nCheck out the complete list of AWS Services that are now directly accessible in the [GitLab AWS Integration Index documentation](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html).\n\n![CodeStar - New Technology and Solutions for using GitLab and AWS Together ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098901/Blog/Content%20Images/Blog/Content%20Images/AWS_re_Invent_2023__New_Technology_and_Solutions_for_using_GitLab_and_AWS_Together__4__aHR0cHM6_1750098900705.png)\n\n## Resources\n\n- GitLab [AWS Integration Index documentation](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html) is a one-stop location for these new integrations as well as existing integrations\n- AWS documentation for [setting up CodeStar Connections with GitLab.com SaaS](https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-gitlab-managed.html)\n- AWS documentation for [setting up CodeStar Connections with self-managed GitLab](https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-gitlab-managed.html)\n - AWS documentation for [configuring AWS CodePipeline integration](https://docs.gitlab.com/ee/user/project/integrations/aws_codepipeline.html)\n- [AWS announcement for GitLab CodePipeline Integration for GitLab SaaS](https://aws.amazon.com/about-aws/whats-new/2023/08/aws-codepipeline-supports-gitlab/) and [AWS announcement for GitLab Self-Managed](https://aws.amazon.com/about-aws/whats-new/2023/12/codepipeline-gitlab-self-managed/)\n\n![codestar-amazonpartnerlogo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098901/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098900705.png)\n",[681,108,9,230],{"slug":915,"featured":6,"template":685},"gitlab-is-now-available-as-an-aws-codestar-connections-provider","content:en-us:blog:gitlab-is-now-available-as-an-aws-codestar-connections-provider.yml","Gitlab Is Now Available As An Aws Codestar Connections Provider","en-us/blog/gitlab-is-now-available-as-an-aws-codestar-connections-provider.yml","en-us/blog/gitlab-is-now-available-as-an-aws-codestar-connections-provider",{"_path":921,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":922,"content":928,"config":935,"_id":937,"_type":13,"title":938,"_source":15,"_file":939,"_stem":940,"_extension":18},"/en-us/blog/gitlab-operator-red-hat-certification",{"title":923,"description":924,"ogTitle":923,"ogDescription":924,"noIndex":6,"ogImage":925,"ogUrl":926,"ogSiteName":667,"ogType":668,"canonicalUrls":926,"schema":927},"GitLab Operator certified by Red Hat OpenShift","The GitLab Operator is now certified by Red Hat’s OpenShift standards, allowing users to install GitLab directly on an OpenShift cloud cluster.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682717/Blog/Hero%20Images/bi_worldwise_casestudy_image.png","https://about.gitlab.com/blog/gitlab-operator-red-hat-certification","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Operator certified by Red Hat OpenShift\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dilan Orrino\"}],\n        \"datePublished\": \"2023-05-11\",\n      }",{"title":923,"description":924,"authors":929,"heroImage":925,"date":931,"body":932,"category":933,"tags":934},[930],"Dilan Orrino","2023-05-11","\nGitLab and Red Hat have been technology partners for more than two years, collaborating on a number of projects. GitLab first started its integration with Red Hat’s OpenShift cloud-based container platform by introducing the [GitLab Runner Operator](https://catalog.redhat.com/software/container-stacks/detail/5e9877e96c5dcb34dfbb1ac9) in GitLab Version 13.3. The Runner Operator offered the capability to run pipeline tasks from an external GitLab instance to OpenShift clusters.\n\nOur next step was to more closely integrate with the OpenShift platform and alleviate the need to require the GitLab instance to run external to OpenShift-based infrastructure. [The GitLab Operator](https://docs.gitlab.com/operator/) is now certified by Red Hat, which enables the capability to install an instance of GitLab inside of an OpenShift cloud cluster.\n\n## Benefits of GitLab with Red Hat OpenShift\n\nThe [Operator framework](https://operatorframework.io/about/) offers many benefits, but the main reason we identified is that it would allow us to run a self-managed instance of GitLab inside an OpenShift cluster. The GitLab DevSecOps platform can be operated on the same trusted infrastructure as other applications and services within a customer's organization. \n\nThe Operator framework also delivers a streamlined installation and seamless version upgrades. As the GitLab Operator continues to be developed, we hope to add other elements of the Operator framework such as backup and recovery, comprehensive metrics, and auto-tuning and auto-scaling. GitLab plans to align our future cloud-native deployment model behind our Operator.\n\n![Capability model](https://about.gitlab.com/images/blogimages/gitlaboperatorcapabilitymodel.png){: .shadow}\n\n\n## Details of the Red Hat certification\n\nThe Red Hat Certification included aligning our application components with Red Hat’s Universal Base Image (UBI) when deploying through the Red Hat Marketplace. The Red Hat Certification also included meeting all of [Red Hat’s policy requirements](https://access.redhat.com/documentation/en-us/red_hat_software_certification/8.61#con-operator-requirements_openshift-sw-cert-policy-products-managed). The certification signifies GitLab being supported on OpenShift in collaboration with Red Hat. The Operator as a deployment method will be available as a recommended choice in Q3, but is available for testing now.\n\n## A technical milestone\n\nThe GitLab application is complex, so building an Operator to deploy it was a technical achievement for the GitLab and Red Hat engineering teams. Completing this operator certification is a significant milestone and gives customers the confidence and assurance that GitLab runs effectively, jointly supported by Red Hat, on OpenShift.\n\n![GitLab Operator install screen](https://about.gitlab.com/images/blogimages/gitlaboperatorinstall.png){: .shadow}\n\n\n## Try the GitLab Operator\n\n[The GitLab Operator](https://docs.gitlab.com/operator/) is available now for testing in the OpenShift console via the embedded OperatorHub, and will be production ready for GitLab instances in Q3 2023. Check out the [catalog listing](https://catalog.redhat.com/software/container-stacks/detail/5ec3fcb08b6f188e53644c0f) for links to documentation and installation instructions. For a self-managed free trial to host GitLab on your OpenShift cluster, [submit this form](/free-trial/?hosted=self-managed).\n","open-source",[9,832,833],{"slug":936,"featured":6,"template":685},"gitlab-operator-red-hat-certification","content:en-us:blog:gitlab-operator-red-hat-certification.yml","Gitlab Operator Red Hat Certification","en-us/blog/gitlab-operator-red-hat-certification.yml","en-us/blog/gitlab-operator-red-hat-certification",{"_path":942,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":943,"content":949,"config":956,"_id":958,"_type":13,"title":959,"_source":15,"_file":960,"_stem":961,"_extension":18},"/en-us/blog/gitlab-partner-of-year-emea-apac-award-winners",{"title":944,"description":945,"ogTitle":944,"ogDescription":945,"noIndex":6,"ogImage":946,"ogUrl":947,"ogSiteName":667,"ogType":668,"canonicalUrls":947,"schema":948},"Meet the 2023 GitLab Partner of the Year award winners for EMEA and APAC","We recognized our channel, technology, and cloud partners in EMEA and APAC for their collaboration and contributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679312/Blog/Hero%20Images/awardstars.jpg","https://about.gitlab.com/blog/gitlab-partner-of-year-emea-apac-award-winners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet the 2023 GitLab Partner of the Year award winners for EMEA and APAC\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patty Cheung\"}],\n        \"datePublished\": \"2023-10-02\",\n      }",{"title":944,"description":945,"authors":950,"heroImage":946,"date":952,"body":953,"category":872,"tags":954},[951],"Patty Cheung","2023-10-02","\nAt GitLab’s second annual EMEA Partner Leadership Summit, held in London last month, we invited channel, technology, and cloud partners to join us to celebrate their achievements, empower their success, and provide resources and support for the year to come. \n\nWe recognized our partners for their contributions via the Partner Leadership Awards, including EMEA and APAC Partner of the Year, EMEA Distributor of the Year, and EMEA Services Partner of the Year. \n\nGitLab strives to create collaborative and mutually beneficial relationships with our partners, and we also encourage our partners to embrace GitLab’s values of Collaboration, Results, Efficiency, Diversity, Inclusion & Belonging, Iteration, and Transparency ([CREDIT](https://handbook.gitlab.com/handbook/values/)). Each award winner demonstrated a strong partnership with GitLab and alignment with CREDIT values.\n\nOur 2023 Partner Leadership Summit Award winners for EMEA and APAC are:\n\n## EMEA Partner of the Year: SVA System Vertrieb Alexander GmbH\n_SVA is one of Germany’s leading IT services providers. With products from leading manufacturers, their project know-how and range of services, and flexibility, they develop optimal solutions for companies and public-sector clients._\n\nSVA's approach to customer engagement is a testament to their dedication to helping businesses tackle their distinctive challenges through the transformative power of DevSecOps. They have also invested in GitLab to **efficiently** manage their own workloads thus creating a strong GitLab culture and proficient technical teams. SVA works to ensure that customers not only embrace DevSecOps but also reap the full benefits, ensuring a substantial return on investment. \n\n## APAC Partner of the Year: Infograb LC\n_Infograb is a DevOps Tech company with Agile-based software development and DevOps framework technology know-how in various institutions, mainly the financial sector._\n\nInfograb was one of our first partners in Korea, and they immediately saw the value and opportunity to not only sell GitLab but provide great value for their customers through a strong services practice. Infograb has continued to grow their GitLab practice year after year, becoming a stand-out partner for us in the region. Infograb has been instrumental in helping win some of the largest enterprise customers in Korea supported by an outstanding solution engineering team who always delivers amazing **results** for their customers.\n\n## EMEA Distributor of the Year: Amazic\n_Amazic is a trusted supplier and solution advisor for partners, individuals, and many of the world’s largest organizations across different industry verticals by offering a unique platform for purchasing technology products and services and accessing training courses._\n\nAmazic earned Distributor of the Year as a result of their continued focus on developing a DevSecOps Ecosystem with GitLab throughout EMEA. They manage a dedicated open partner base, ensuring technical enablement and training around GitLab to support customer development. Their marketing department is continually **iterating** innovative campaigns highlighting business opportunities to help customers develop their own DevSecOps journey. The Amazic marketplace simplifies and consolidates customers’ product purchasing, saving time and money. \n\n## EMEA Services Partner of the Year: Adfinis\n_Adfinis is a leading service provider of Open Source solutions for over 20 years and is based in Switzerland, Germany, the Netherlands, and Australia. As a company, Adfinis contributes to sustainable and reliable IT solutions by being intensely involved in the Open Source community._\n\nAdfinis joined forces to partner with GitLab back in 2020 sharing a similar vision of working with open source solutions. Since then they have been true to their word, investing in their professional services capabilities and becoming a team of highly proficient DevSecOps engineers operating across EMEA. They always keep abreast of GitLab product releases, often being the first to prove these innovations in the field, we recognize them as a true **collaborator** to GitLab as they are to their customers. \n\nOur heartfelt congratulations to all the winners! We look forward to further collaboration in the year to come. \n\nLearn more about [GitLab’s Partner Program](https://partners.gitlab.com/English/).\n",[9,872,955],"collaboration",{"slug":957,"featured":6,"template":685},"gitlab-partner-of-year-emea-apac-award-winners","content:en-us:blog:gitlab-partner-of-year-emea-apac-award-winners.yml","Gitlab Partner Of Year Emea Apac Award Winners","en-us/blog/gitlab-partner-of-year-emea-apac-award-winners.yml","en-us/blog/gitlab-partner-of-year-emea-apac-award-winners",{"_path":963,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":964,"content":970,"config":976,"_id":978,"_type":13,"title":979,"_source":15,"_file":980,"_stem":981,"_extension":18},"/en-us/blog/gitlab-receives-ally-technology-partner-award-for-operational-excellence",{"title":965,"description":966,"ogTitle":965,"ogDescription":966,"noIndex":6,"ogImage":967,"ogUrl":968,"ogSiteName":667,"ogType":668,"canonicalUrls":968,"schema":969},"GitLab receives Ally Technology Partner Award for Operational Excellence","Financial firm recognizes GitLab for its ability to deliver lean, automated, and streamlined business models that drive simplified and resilient solutions for Ally and its customers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","https://about.gitlab.com/blog/gitlab-receives-ally-technology-partner-award-for-operational-excellence","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab receives Ally Technology Partner Award for Operational Excellence\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2024-06-18\",\n      }",{"title":965,"description":966,"authors":971,"heroImage":967,"date":973,"body":974,"category":872,"tags":975},[972],"Sandra Gittlen","2024-06-18","Earlier this month, Ally Financial, a leading digital financial services company, awarded GitLab its Ally Technology Partner Award for Operational Excellence, citing the fundamental role GitLab and the GitLab DevSecOps platform play for Ally and its customers.\n\n\"This award is meant to recognize partners who help us ensure the resiliency of our solutions and who are committed to not just providing us products but helping us to operationalize and maintain those products on a sustained basis,\" said Spencer Cremers, CIO of Enterprise Technology Operations at Ally Financial. \"GitLab is a critical toolset that is fundamental to our day-to-day operations.\" \n\nAlly began migrating to GitLab in recent years and now has a large number of applications that have fully adopted DevSecOps principles. GitLab enables Ally to carry out thousands of builds per day across all environments and deploy numerous builds into Production every week.\n\nGitLab was also lauded for helping support Ally's operational goals. \"GitLab also provides tremendous operational support when we need service or responses on a short-notice basis,\" Cremers said.\n\nHe added that GitLab is helping the company explore \"virtualized development environments for a more efficient and predictable space for developers to learn,\" as well as security tools to shift security left in the software development lifecycle.\n\nThis is the second year GitLab has won an [Ally Technology Partner Award](https://www.ally.com/tech/partnering-to-drive-transformation-2nd-annual-ally-technology-partner-awards/). In 2023, the first year these awards were given, the financial firm recognized GitLab for \"[Velocity with Quality](https://www.ally.com/tech/recognizing-delivery-in-ecosystem-ally-technology-partner-awards/)\" for excellent speed to market, responsiveness, and flexibility, allowing Ally to deliver value to customers quickly. \n\n> Learn [how Ally uses the GitLab DevSecOps Platform](https://about.gitlab.com/customers/ally/) to achieve some big wins, including a 55% increase in deployment velocity and $300k yearly cost savings.",[9,872,476],{"slug":977,"featured":6,"template":685},"gitlab-receives-ally-technology-partner-award-for-operational-excellence","content:en-us:blog:gitlab-receives-ally-technology-partner-award-for-operational-excellence.yml","Gitlab Receives Ally Technology Partner Award For Operational Excellence","en-us/blog/gitlab-receives-ally-technology-partner-award-for-operational-excellence.yml","en-us/blog/gitlab-receives-ally-technology-partner-award-for-operational-excellence",{"_path":983,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":984,"content":987,"config":995,"_id":997,"_type":13,"title":998,"_source":15,"_file":999,"_stem":1000,"_extension":18},"/en-us/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":985,"title":986},"A new offering from GitLab and IBM bridges mainframe and cloud-native development with seamless integration, CI/CD runner support, end-to-end visibility, and cost efficiency. ","GitLab Ultimate for IBM Z: Modern DevSecOps for mainframes",{"title":986,"description":985,"body":988,"category":679,"tags":989,"authors":990,"heroImage":993,"date":994},"GitLab and IBM have partnered to solve a fundamental disconnect in enterprise development: enabling mainframe developers to work with the same modern tools, workflows, and collaboration features as their distributed counterparts. GitLab Ultimate for IBM Z, a GitLab-certified, integrated DevSecOps solution tailored for the mainframe environment, does just that — allowing organizations to modernize their mainframe development workflows by facilitating a seamless migration from outdated legacy library managers. With CI/CD pipelines running natively on IBM z/OS, customers experience accelerated innovation and reduced operational costs.\n\n## Challenges of today's mainframe development\n\nEnterprise organizations that use IBM Z systems for mission-critical workloads face challenges that conventional DevSecOps tools aren’t equipped to address. Cloud-native teams benefit from modern [CI/CD](https://about.gitlab.com/topics/ci-cd/) pipelines, collaborative development, and automated testing. In contrast, mainframe teams are often left behind — stuck with outdated tools that lead to costly inefficiencies and operational silos.\n\nTeams often resort to workarounds, such as SSH connections and manual file transfers, which create security vulnerabilities and audit difficulties. When compliance requirements are stringent, these improvised solutions become unacceptable risks. Meanwhile, organizations maintain expensive parallel toolchains, with legacy mainframe development tools carrying premium licensing costs while delivering limited functionality compared to modern alternatives.\n\nThis fragmentation creates two problems: slower delivery cycles and difficulty attracting developers who expect modern development experiences.\n\n> **\"GitLab Ultimate for IBM Z represents an important step in addressing a long-standing industry challenge. IDC research shows that mainframe developers often work with legacy tooling that contributes to delivery inefficiencies and makes it harder to attract new talent. With this offering, modern DevSecOps capabilities and unified workflows are brought directly to the mainframe. This empowers developers to work more collaboratively and efficiently, while helping organizations accelerate innovation and integrate mainframe development into broader digital transformation strategies.\"** - Katie Norton, Research Manager, DevSecOps and Software Supply Chain Security at IDC\n\n## Unified development environments\n\nTrue modernization means more than just updating mainframe development. It means creating a unified platform where mainframe, cloud-native, web, and mobile development teams collaborate seamlessly.\n\nGitLab Ultimate for IBM Z enables developers to use consistent workflows whether they're deploying to z/OS, cloud, or on-premises infrastructure — knowledge transfers between teams instead of staying siloed. Organizations can modernize incrementally without business disruption, as legacy systems continue operating while teams adopt modern practices at their own pace.\n\nAs organizations pursue hybrid cloud strategies, GitLab provides the foundation for applications that span mainframe and cloud-native environments.\n\n## What is GitLab Ultimate for IBM Z?\n\nGitLab Ultimate for IBM Z delivers native z/OS Runner support, enabling seamless CI/CD pipeline execution directly on your mainframe infrastructure. This GitLab-certified solution helps eliminate the need for complex workarounds while maintaining the security and reliability your enterprise applications demand.\n\nThe combination of GitLab's comprehensive DevSecOps platform with IBM's deep mainframe expertise creates something unique in the market: a certified solution that provides a true bridge between enterprise legacy systems and cloud-native innovation.\n\n## GitLab Ultimate for IBM Z capabilities\n\nGitLab Ultimate for IBM Z provides enterprise teams with the tools they need to modernize mainframe development while preserving critical business systems.\n\n**Native z/OS Runner support** helps eliminate security risks and scalability bottlenecks associated with remote connections, while accelerating delivery through CI/CD pipelines that execute directly where your mainframe code resides.\n\n**Unified Source Code Management** modernizes your toolchain by replacing expensive legacy library managers with GitLab's searchable, version-controlled repository system, helping reduce licensing costs and maintenance overhead.\n\n**Seamless integration** with IBM Developer for z/OS Enterprise Edition (IDzEE) delivers faster software releases through dependency-based builds, automated code scanning, and comprehensive debugging tools within familiar developer environments, enhancing both quality and security.\n\n**End-to-end visibility** across mainframe and distributed environments provides comprehensive project management from planning to production, enabling automated DevOps workflows that help retain talent through modern, next-generation development tools.\n\n## Modernize your mainframe development environment today\n\nGitLab Ultimate for IBM Z is available now for organizations ready to transform their mainframe development experience. To learn more, visit the [GitLab and IBM partnership page](https://about.gitlab.com/partners/technology-partners/ibm/).",[9,679,108,768],[991,992],"Mike Flouton","Andy Bradfield","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png","2025-06-23",{"featured":90,"template":685,"slug":996},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes","content:en-us:blog:gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","Gitlab Ultimate For Ibm Z Modern Devsecops For Mainframes","en-us/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","en-us/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"_path":1002,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1003,"content":1009,"config":1015,"_id":1017,"_type":13,"title":1018,"_source":15,"_file":1019,"_stem":1020,"_extension":18},"/en-us/blog/how-secret-detection-can-proactively-revoke-leaked-credentials",{"title":1004,"description":1005,"ogTitle":1004,"ogDescription":1005,"noIndex":6,"ogImage":1006,"ogUrl":1007,"ogSiteName":667,"ogType":668,"canonicalUrls":1007,"schema":1008},"How Secret Detection can proactively revoke leaked credentials","GitLab extends Secret Detection capabilities to customers on Google Cloud.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664923/Blog/Hero%20Images/security-checklist.png","https://about.gitlab.com/blog/how-secret-detection-can-proactively-revoke-leaked-credentials","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Secret Detection can proactively revoke leaked credentials\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Connor Gilbert\"}],\n        \"datePublished\": \"2023-06-13\",\n      }",{"title":1004,"description":1005,"authors":1010,"heroImage":1006,"date":1012,"body":1013,"category":766,"tags":1014},[1011],"Connor Gilbert","2023-06-13","\n\nModern applications don’t run on their own: They rely on databases, cloud services, APIs, and other services. To connect to those systems, the applications use credentials like private keys and API tokens. These credentials have to be kept secret – if they’re leaked, adversaries can abuse them to steal data, mine cryptocurrency, or disable important systems. Today, we’re increasing the level of protection we offer GitLab Ultimate users against this serious risk via an expansion of our partnership with Google Cloud.\n\n## How GitLab addresses this risk\n[GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) addresses the risk of leaked secrets by detecting when keys, tokens, and other sensitive values are exposed in code and helping DevSecOps teams respond. It’s imperative to respond quickly when credentials are leaked, especially for keys to cloud provider accounts, since adversaries can do a lot of damage quickly. \n\nWith our expanded partnership, we’ve integrated GitLab Secret Detection with Google Cloud to better protect customers who use GitLab to develop applications on Google Cloud. Now, if an organization leaks a Google Cloud credential to a public project on GitLab.com, GitLab can automatically protect the organization by working with Google Cloud to protect the account. This protection is available in GitLab Ultimate.\n\n## GitLab’s investment in automated response\nGitLab has added support for multiple cloud platforms with [automatic response to leaked secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html), including the [automatic revocation of GitLab Personal Access Tokens (PATs)](https://about.gitlab.com/blog/pat-revocation-coming-soon/). We’re working on more integrations now, and are always looking for more cloud service vendors seeking similar protection to join [our partner program](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html#partner-program-for-leaked-credential-notifications).\n\nWe’ve also [recently expanded](https://about.gitlab.com/releases/2023/04/22/gitlab-15-11-released/#automatic-response-to-leaked-secrets-on-any-public-branch) the places automatic responses are triggered. Secret Detection users are now protected from credential leaks as soon as they appear in any public branch on GitLab.com.\n\n## Why we’re investing here\nSecurity is better when it’s integrated throughout the software development lifecycle. GitLab’s [2023 Security Without Sacrifices report](https://about.gitlab.com/press/releases/2023-04-20-gitlab-seventh-devsecops-report-security-without-sacrifices.html) found that security is one of the top benefits of a DevSecOps platform. GitLab’s DevSecOps platform enhances secure software development by helping developers and security professionals collaborate to prevent business-critical vulnerabilities. Now, in collaboration with Google Cloud, we’re adding an additional layer of protection for our mutual customers.\n\n## Better protection for GitLab/Google Cloud customers\nGoogle Cloud users on GitLab.com are now better protected. The new integration protects projects that:\n\n* are public. Private projects are unaffected by this change.\n* are hosted on GitLab.com. Projects on GitLab Dedicated or self-managed instances are unaffected.\n* use Secret Detection. If you haven't enabled Secret Detection for a project, we currently won't search it for secrets to revoke.\n\nSecret Detection searches for three types of secrets issued by Google Cloud:\n\n1. [Service account keys](https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys)\n2. [API keys](https://cloud.google.com/docs/authentication/api-keys)\n3. [OAuth client secrets](https://support.google.com/cloud/answer/6158849#rotate-client-secret)\n\nPublicly leaked secrets are sent to Google Cloud after they’re discovered. Google Cloud verifies the leaks, then works to protect customer accounts against abuse.\n\n## How the Google Cloud integration works\nOur Google Cloud integration is on by default for projects that use GitLab Secret Detection on GitLab.com. Secret Detection scanning is available in all GitLab tiers, but an automatic response to leaked secrets is currently [only available in Ultimate projects](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html#feature-availability).\n\n* To protect a project, [enable GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#enable-secret-detection).\n* To protect your entire organization, consider [enforcing scan execution](https://docs.gitlab.com/ee/user/application_security/index.html#enforce-scan-execution) to run Secret Detection in all of your projects.\n\n## What’s next\n\nWe’re excited to improve Secret Detection with this integration, but we aren’t stopping here. Check our [strategy and plans](https://about.gitlab.com/direction/secure/static-analysis/secret-detection/#strategy-and-themes) to learn more about where we’re headed.\n\n_GitLab can help secure your applications, whether they run on Google Cloud or elsewhere. Learn more about our [security and governance solutions](https://about.gitlab.com/solutions/security-compliance/)._\n",[766,833,9],{"slug":1016,"featured":6,"template":685},"how-secret-detection-can-proactively-revoke-leaked-credentials","content:en-us:blog:how-secret-detection-can-proactively-revoke-leaked-credentials.yml","How Secret Detection Can Proactively Revoke Leaked Credentials","en-us/blog/how-secret-detection-can-proactively-revoke-leaked-credentials.yml","en-us/blog/how-secret-detection-can-proactively-revoke-leaked-credentials",{"_path":1022,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1023,"content":1029,"config":1035,"_id":1037,"_type":13,"title":1038,"_source":15,"_file":1039,"_stem":1040,"_extension":18},"/en-us/blog/introducing-the-gitlab-cli",{"title":1024,"description":1025,"ogTitle":1024,"ogDescription":1025,"noIndex":6,"ogImage":1026,"ogUrl":1027,"ogSiteName":667,"ogType":668,"canonicalUrls":1027,"schema":1028},"Put `glab` at your fingertips with the GitLab CLI","We just adopted the `glab` project. Here's what's next and how to contribute!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682539/Blog/Hero%20Images/newcli.png","https://about.gitlab.com/blog/introducing-the-gitlab-cli","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Put `glab` at your fingertips with the GitLab CLI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kai Armstrong\"}],\n        \"datePublished\": \"2022-12-07\",\n      }",{"title":1024,"description":1025,"authors":1030,"heroImage":1026,"date":1032,"body":1033,"category":296,"tags":1034},[1031],"Kai Armstrong","2022-12-07","\n\nWe want to integrate GitLab with the tools our developers already use and love. This mission drove us to [adopt GitLab Workflow for VS Code](/blog/use-gitlab-with-vscode/) two years ago and we’ve been iterating on it ever since (spoiler alert: it is an integral part of our [future Web IDE](/blog/the-future-of-the-gitlab-web-ide/)). As we thought about potential next projects, we considered that the common denominator for developers, regardless of their choice of editor, is their terminal.\n\nThis led us to our next charter: to bring GitLab to the CLI to continue streamlining workflows for developers between their most used technologies.\n\nSimilar to our work with VS Code, we wanted to integrate the GitLab DevSecOps platform into all stages of the code writing process. At GitLab, we’re [dedicated to open source](/handbook/engineering/open-source/#we-believe-in-open-source) and we value building in public. It's this commitment to open source and collaboration that helped us take the first step in this project: looking to our community to see if we could partner with them on an existing open source project to bring the CLI to developers faster.\n\n## Improving GitLab’s native CLI experience\n\nI’m happy to share that we’ve adopted the open source project [`glab`](https://gitlab.com/gitlab-org/cli), which will form the foundation of GitLab’s native CLI experience. The GitLab CLI brings GitLab to your terminal, next to [where you’re already working](https://about.gitlab.com/direction/create/editor_extension/#where-we-are-headed) with Git and your code, without switching between applications and browser tabs.\n\n![glab issue list](https://about.gitlab.com/images/blogimages/glabgettingstarted.gif)\n\n### Efficiency at your fingertips\n\nThis integration means developers can now achieve the following tasks without ever leaving the terminal:\n\n- Review issues assigned to you.\n- Create branches and merge requests for those issues.\n- Check the status of pipelines.\n- Approve and merge work.\n\nToo excited? Need a tl;dr RIGHT NOW? We have [GitLab CLI installation](https://gitlab.com/gitlab-org/cli#installation) instructions waiting for you! When setting up [authentication](https://gitlab.com/gitlab-org/cli#authentication), we’ve partnered with 1Password to support their new [Shell Plugins](https://blog.1password.com/shell-plugins/) making it even easier to authenticate your session and keep your credentials secure.\n\n## How did we get here?\n\nMore than two years ago, [Clement Sam](https://gitlab.com/profclems) (a [GitLab Hero](/community/heroes/)) began work on `glab` because he wanted a tool that made his workflow easier and saved time by avoiding the need to switch between browser tabs, IDE and terminal. He initially shared the script with some of his colleagues who also found it helpful. Ultimately, Clement made the decision to open source it and since then over 80 other [contributors](https://github.com/profclems/glab/graphs/contributors) have continued to build on the tool, adding commands to interact with merge requests, issues, pipelines, and more.\n\nWe heard about  `glab` from Clement back in 2020, when the project was still early in its life cycle. We were excited about the area, but couldn’t commit at the time to giving it the long-term support it deserved. Fast forward to 2022. We felt it made sense to check in with Clement to see how the project was progressing. After a few conversations, everyone involved felt that GitLab would be a great home for long-term support and community contributors. We [adopted the project](https://github.com/profclems/glab/issues/983).\n\n## Providing a seamless transition\n\nOver the past several months, we’ve been [transitioning](https://gitlab.com/groups/gitlab-org/-/epics/7514) the project to GitLab. During the transition we’ve learned a lot about what it takes to migrate an active project to new tooling. Our efforts to adapt [GitHub Actions to GitLab CI](https://gitlab.com/groups/gitlab-org/-/epics/7784) have given us great insights into that process as users, and something we’ll be looking to share more about in a future post. We also needed to unwind some previous documentation changes by [converting them back to Markdown](https://gitlab.com/gitlab-org/cli/-/issues/1010), for compatibility with the rest of GitLab’s internal processes.\n\nFurthermore, we knew we needed to provide users with a secure experience. Prior to adoption and launch, our application security team reviewed the project and provided feedback to ensure `glab` was safe, secure, and ready for more users. \n\nWith everything ready to go, we worked across the ecosystem to [update distribution methods](https://gitlab.com/groups/gitlab-org/-/epics/8251) to point to [the new repository](https://gitlab.com/gitlab-org/cli). Our goal was to provide a seamless transition for contributors to continue working, and for users to continue receiving updates.\n\n## Strengthened by community\n\nIt’s taken a small army of people to make the adoption of `glab` complete. A special thanks to [Gary](https://gitlab.com/garyh) who stepped up to lead the engineering efforts on our side. He’s been wonderfully supported by [Kerri](https://gitlab.com/kerrizor), [Tomas](https://gitlab.com/viktomas), and many others inside of GitLab who have had a passion for this project. Our external community has also come along for the ride. We’ve had over [over 35 community contributions](https://gitlab.com/gitlab-org/cli/-/merge_requests?scope=all&state=all&label_name%5B%5D=Community%20contribution), ranging from first-time contributors to seasoned `glab` contributors. (Including Clement, who remains active in the project!).\n\n[GitLab CLI v1.24.1](https://gitlab.com/gitlab-org/cli/-/releases/v1.24.1) contains over 40 new features, bug fixes, security fixes and many more improvements since the last release. You can see the full [changelog](https://gitlab.com/gitlab-org/cli/-/releases/v1.24.1#changelog) on our releases page. Thank you to everyone who’s contributed to make all of this possible.\n\n## Want to get started now?\n\nIf you’re on macOS (and have [Homebrew](https://brew.sh/) installed) the fastest way to get started is by running:\n\n```\nbrew install glab\n```\n\nThis will install the latest version of the GitLab CLI and immediately make it available for you. Not on macOS? We have [installation instructions](https://gitlab.com/gitlab-org/cli#installation) for [Windows](https://gitlab.com/gitlab-org/cli#windows) and [Linux](https://gitlab.com/gitlab-org/cli#linux) too. \n\nAs part of getting things setup, you’ll need to set up the CLI to use a personal access token for [authentication](https://gitlab.com/gitlab-org/cli#authentication). You can do this with the `glab auth login` command and follow the prompts. Alternatively, you can use 1Password Shell Plugins to authenticate your session. With this feature, you can: \n\nSecure your personal access tokens in encrypted 1Password vaults.\nAuthenticate specific terminal sessions to access those tokens by scanning your fingerprint or using other biometrics. \n\nThis approach eliminates the need to type tokens or passwords into the terminal while removing plaintext keys from your disk. Plus, as you work across devices or environments, your key moves with you in 1Password, reducing setup time and simplifying collaboration. [Check out the 1Password documentation to get started.](https://developer.1password.com/docs/cli/shell-plugins/gitlab/).\n\n![1Password documentation](https://about.gitlab.com/images/blogimages/1passworddocumentation.png)\n\n\n## What are we doing next?\n\nNow that we’ve officially released the GitLab CLI, we’re going to spend some time taking a closer look at the issue backlog. We want to learn what the community is looking for in a CLI tool, and where opportunities exist to extend capabilities further into developer workflows. You’ll see the GitLab team more involved in discussing feature proposals and triaging bugs as we continue to ramp up on the project.\n\n## What do you want to see?\n\nThe GitLab CLI was born out of the community, and we want to continue collaborating with all of you in its future direction. If you have ideas for new features or encounter a bug, [open an issue](https://gitlab.com/gitlab-org/cli) and let us know or – in true GitLab form – [everything starts with a merge request](https://gitlab.com/gitlab-org/cli).\n",[679,832,9],{"slug":1036,"featured":6,"template":685},"introducing-the-gitlab-cli","content:en-us:blog:introducing-the-gitlab-cli.yml","Introducing The Gitlab Cli","en-us/blog/introducing-the-gitlab-cli.yml","en-us/blog/introducing-the-gitlab-cli",{"_path":1042,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1043,"content":1048,"config":1054,"_id":1056,"_type":13,"title":1057,"_source":15,"_file":1058,"_stem":1059,"_extension":18},"/en-us/blog/keyless-signing-with-cosign",{"title":1044,"description":1045,"ogTitle":1044,"ogDescription":1045,"noIndex":6,"ogImage":1006,"ogUrl":1046,"ogSiteName":667,"ogType":668,"canonicalUrls":1046,"schema":1047},"Streamline security with keyless signing and verification in GitLab","Our partnership with Sigstore means that with just a few lines in a yml file, GitLab customers can make their development environment more secure.","https://about.gitlab.com/blog/keyless-signing-with-cosign","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Streamline security with keyless signing and verification in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam White\"}],\n        \"datePublished\": \"2023-09-13\",\n      }",{"title":1044,"description":1045,"authors":1049,"heroImage":1006,"date":1051,"body":1052,"category":766,"tags":1053},[1050],"Sam White","2023-09-13","\nTraditional cryptographic keys have created security issues and management overhead for software development teams for years. To address these security issues and ease the administrative burden, GitLab is partnering with Sigstore to use their command-line utility Cosign for [keyless signing and verification](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html), which can be done by adding just a few lines in a yml file.\n\nBefore digging too far into the integration, though, let's take a closer look at some of the issues of traditional key management and some of the benefits of keyless signing.\n\n## Traditional key management\nCryptographic keys have been a mainstay of securing software and network elements for years. Traditional key management involves the generation, storage, distribution, and protection of cryptographic keys that are essential for processes like encryption, decryption, and digital signing. While these methods have worked well over the years, they pose challenges that can impact security and operational efficiency.\n\n* Complexity and risk of exposure: Generating, storing, and distributing cryptographic keys manually can be error-prone and time-consuming. This complexity increases the risk of key exposure due to mismanagement or vulnerabilities in the key storage systems.\n\n* Security risk: Risk that the key management system (KMS) might be compromised and the private key leaked. There is no way for users to verify that the public key has not been tampered with or modified.\n\n* Key rotation complexity: Regular key rotation is a security best practice, but it can be complex to manage, especially when dealing with large numbers of keys. Key rotation will often disrupt applications.\n\n* Key revocation: Revoking access to keys that are no longer needed or that have been compromised can be challenging, especially if those keys are widely used across different parts of your application.\n\n* Integration complexity: Integrating your application with a KMS can introduce complexity. If your application is distributed or consists of microservices the complexity increases.\n\n* Key distribution: There is no standard way of distributing public keys. A system for distribution must be selected and secure, and if that system is compromised the public key must be changed.\n\n![A diagram of how traditional key management works](https://about.gitlab.com/images/blogimages/traditionalkeymanagement.png){: .shadow}\n\nHow traditional key management works\n{: .note.text-center}\n\n## The move to keyless signing\nRecently, the industry has been making a push towards keyless signing. With keyless signing, a message is signed using an ephemeral key that is generated and used for signing. The key is only valid for a few minutes, greatly reducing the complexity and security issues associated with traditional key management.\n\nKeyless signing has several advantages. \n* Enhanced security: Keyless signing removes the need to store private keys on user devices, reducing the risk of exposure to malware or unauthorized access. \n\n* Simplified key management: With keyless signing, the complexities of key generation, distribution, and rotation are abstracted, leading to simplified key management processes. This streamlines operational workflows and reduces the potential for human error.\n\n* Audit trail: Keyless signing systems provide comprehensive audit trails and logging. Artifact verification is possible since public keys cannot be tampered with.\n\n* Remote signing and access: Keyless signing allows remote signing operations, enabling users to sign documents and transactions securely from anywhere. This capability enhances accessibility and collaboration without sacrificing security.\n\n* Regulatory compliance: The audit trails and accountability provided by keyless signing solutions facilitate regulatory compliance. With keyless signing, organizations can more confidently meet industry standards and demonstrate their commitment to secure practices.\n\n\n![A diagram of how keyless signing works](https://about.gitlab.com/images/blogimages/keylesssigningdiagram.png){: .shadow}\n\nHow keyless signing works\n{: .note.text-center}\n\n## Keyless signing within GitLab\nGitLab has partnered with one of the leaders in the keyless signing space, Sigstore, to help customers move away from traditional keys and easily make the transition to keyless signing.  \n\nThe Sigstore project provides a command-line utility called Cosign, which can be used for keyless signing of container images built with the GitLab CI/CD. By adding a few lines of code to the GitLab yml file, GitLab users can use Cosign to leverage the benefits of keyless signing. Sigstore’s Cosign enables software developers to sign release files, binaries, and other software artifacts.  \n\nOnce enabled within GitLab, when a user runs a pipeline, Cosign requests a short-lived key pair to use for signing, records it on a certificate transparency log (Rektor), and then discards it. The key is generated through a token obtained from the GitLab server using the [OIDC](https://docs.gitlab.com/ee/administration/auth/oidc.html) identity of the user who ran the pipeline. This token includes unique claims that certify the token was generated by a CI/CD pipeline. The private key only lasts for a short time so there is no need to store it or rotate it. With Cosign, verification data, including the public key, signature, and signing timestamp, is written to the immutable Rektor log (an append-only transparency ledger) so that signing events can be publicly audited. Users can then verify the binary and signature against the public key.\n\nThe whole process is quick and easy and greatly increases system-wide security. With this integration, there is no longer a need to set up a key management system, no longer a need to rotate keys, and no longer a need to distribute public keys. Life is simpler and more secure!\n\n## Next steps\nThis feature is now available on all tiers of GitLab SaaS.\n\nWatch a setup demo here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Ws2D77n4nAg?si=jhDRWXH7oJEwvyLS\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nFor more details, check out [Sigstore’s keyless signature documentation](https://docs.sigstore.dev/#how-sigstore-works) and then start your [free trial of GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com).\n\n\n\n\n\n",[766,872,9,230],{"slug":1055,"featured":6,"template":685},"keyless-signing-with-cosign","content:en-us:blog:keyless-signing-with-cosign.yml","Keyless Signing With Cosign","en-us/blog/keyless-signing-with-cosign.yml","en-us/blog/keyless-signing-with-cosign",{"_path":1061,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1062,"content":1068,"config":1074,"_id":1076,"_type":13,"title":1077,"_source":15,"_file":1078,"_stem":1079,"_extension":18},"/en-us/blog/managing-gitlab-resources-with-pulumi",{"title":1063,"description":1064,"ogTitle":1063,"ogDescription":1064,"noIndex":6,"ogImage":1065,"ogUrl":1066,"ogSiteName":667,"ogType":668,"canonicalUrls":1066,"schema":1067},"Managing GitLab resources with Pulumi","Learn how Pulumi's infrastructure-as-code tool helps streamline the automation of GitLab CI/CD workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683430/Blog/Hero%20Images/AdobeStock_293854129__1_.jpg","https://about.gitlab.com/blog/managing-gitlab-resources-with-pulumi","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Managing GitLab resources with Pulumi\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Josh Kodroff, Pulumi\"}],\n        \"datePublished\": \"2024-01-10\",\n      }",{"title":1063,"description":1064,"authors":1069,"heroImage":1065,"date":1071,"body":1072,"category":724,"tags":1073},[1070],"Josh Kodroff, Pulumi","2024-01-10","In the ever-evolving landscape of DevOps, platform engineers are increasingly seeking efficient and flexible tools to manage their GitLab resources, particularly for orchestrating continuous integration/continuous delivery (CI/CD) pipelines. [Pulumi](https://pulumi.com?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) offers a unique approach to infrastructure as code (IaC) by allowing engineers to use familiar programming languages such as TypeScript, Python, Go, and others. This approach streamlines the automation of GitLab CI/CD workflows. Pulumi's declarative syntax, combined with its ability to treat infrastructure as software, facilitates version control, collaboration, and reproducibility, aligning seamlessly with the GitLab philosophy.\n\nLet's explore the power of using Pulumi and GitLab.\n\n## What is Pulumi?\n\nPulumi is an IaC tool that allows you to manage resources in more than 150 supported cloud or SaaS products (including AWS and GitLab, which we will be demonstrating in this post). You can express your infrastructure with Pulumi using popular general-purpose programming languages like TypeScript, Python, and Go.\n\nPulumi is declarative (just like other popular IaC tools you may be familiar with), which means that you only need to describe the desired end state of your resources and Pulumi will figure out the order of create, read, update, and delete (CRUD) operations to get from your current state to your desired state.\n\nIt might seem strange at first to use a general-purpose programming language to express your infrastructure's desired state if you're used to tools like CloudFormation or Terraform, but there are considerable advantages to Pulumi's approach, including the following:\n- **Familiar tooling.** You don't need any special tooling to use Pulumi. Code completion will work as expected in your favorite editor or IDE without any additional plugins. You can share Pulumi code using familiar packaging tools like npm, PyPI, etc.\n- **Familiar syntax.** Unlike with DSL-based IaC tools, you don't need to learn special ways of indexing an array element, or creating loops or conditionals - you can just use the normal syntax of a language you already know.\n\nThe Pulumi product has an open source component, which includes the Pulumi command line and its ecosystem of providers, which provide the integration between Pulumi and the cloud and SaaS providers it supports. Pulumi also offers a free (for individual use) and paid (for teams and organizations) SaaS service called Pulumi Cloud, which provides state file and secrets management, among many other useful features. It’s a widely-supported open-source IaC tool.\n\n## Initializing the project\n\nTo complete this example you'll need:\n\n1. [A Pulumi Cloud account](https://app.pulumi.com?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources). Pulumi Cloud is free for individual use forever and we'll never ask for your credit card. Pulumi Cloud will manage your Pulumi state file and handle any secrets encryption/decryption. Because it's free for individual use (no credit card required), we strongly recommend that you use Pulumi Cloud as your backend when learning how to use Pulumi.\n2. A GitLab account, group, and a GitLab token set to the `GITLAB_TOKEN` environment variable.\n3. An AWS account and credentials with permissions to deploy identity and access management (IAM) resources. For details on how to configure AWS credentials on your system for use with Pulumi, see [AWS Classic: Installation and Configuration](https://www.pulumi.com/registry/packages/aws/installation-configuration/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources).\n\nThis example will use two providers from the [Pulumi Registry](https://www.pulumi.com/registry/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources):\n\n1. The [GitLab Provider](https://www.pulumi.com/registry/packages/gitlab/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) will be used to manage resources like Projects, ProjectFiles (to initialize our project repository), ProjectHooks (for the integration with Pulumi Cloud), and ProjectVariables (to hold configuration for our CI/CD pipelines).\n2. The [AWS Classic Provider](https://www.pulumi.com/registry/packages/aws/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) will be used to manage AWS resources to create OpenID Connect (OIDC) connectivity between AWS and GitLab.\n\nYou can initialize your Pulumi project by changing into a new, empty directory, running the following command, and accepting all the default values for any subsequent prompts:\n\n```bash\npulumi new typescript\n```\n\nThis will bootstrap an empty Pulumi program. Now you can import the provider SDKs for the providers you'll need:\n\n```bash\nnpm i @pulumi/aws @pulumi/gitlab\n```\n\nYour `index.ts` file is the entry point into your Pulumi program (just as you would expect in any other Node.js program) and will be the file to which you will add your resources. Add the following imports to the top of `index.ts`:\n\n```typescript\nimport * as gitlab from \"@pulumi/gitlab\";\nimport * as aws from \"@pulumi/aws\";\n```\n\nNow you are ready to add some resources!\n\n## Adding your first resources\n\nFirst, let's define a variable that will hold the audience claim in our OIDC JWT token. Add the following code to `index.ts`:\n\n```typescript\nconst audience = \"gitlab.com\";\n```\n\nThe above code assume you're using the GitLab SaaS (\u003Chttps://gitlab.com>) If you are using a private GitLab install, your value should be the domain of your GitLab install, e.g. `gitlab.example.com`.\n\nThen, you'll use a [Pulumi function](https://www.pulumi.com/docs/concepts/resources/functions/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) to grab an existing GitLab group by name and create a new public GitLab project in your GitLab group:\n\n```typescript\nconst group = gitlab.getGroup({\n  fullPath: \"my-gitlab-group\", // Replace the value with the name of your GL group\n});\n\nconst project = new gitlab.Project(\"pulumi-gitlab-demo\", {\n  visibilityLevel: \"public\",\n  defaultBranch: \"main\",\n  namespaceId: group.then(g => parseInt(g.id)),\n  archiveOnDestroy: false // Be sure to set this to `true` for any non-demo repos you manage with Pulumi!\n});\n```\n\n## Creating OIDC resources\n\nTo allow GitLab CI/CD to request and be granted temporary AWS credentials, you'll need to create an OIDC provider in AWS that contains the thumbprint of GitLab's certificate, and then create an AWS role that GitLab is allowed to assume.\n\nYou'll scope the assume role policy so that the role can be only be assumed by the GitLab project you declared earlier. The role that GitLab CI/CD assumed will have full administrator access so that Pulumi can create and manage any resource within AWS. (Note that it is possible to grant less than `FullAdministrator` access to Pulumi, but `FullAdministrator` is often practically required, e.g. where IAM resources, like roles, need to be created. Role creation requires `FullAdministrator`. This consideration also applies to IaC tools like Terraform.)\n\nAdd the following code to `index.ts`:\n\n```typescript\nconst GITLAB_OIDC_PROVIDER_THUMBPRINT = \"b3dd7606d2b5a8b4a13771dbecc9ee1cecafa38a\";\n\nconst gitlabOidcProvider = new aws.iam.OpenIdConnectProvider(\"gitlab-oidc-provider\", {\n  clientIdLists: [`https://${audience}`],\n  url: `https://${audience}`,\n  thumbprintLists: [GITLAB_OIDC_PROVIDER_THUMBPRINT],\n}, {\n  deleteBeforeReplace: true, // URLs are unique identifiers and cannot be auto-named, so we have to delete before replace.\n});\n\nconst gitlabAdminRole = new aws.iam.Role(\"gitlabAdminRole\", {\n  assumeRolePolicy: {\n    Version: \"2012-10-17\",\n    Statement: [\n      {\n        Effect: \"Allow\",\n        Principal: {\n          Federated: gitlabOidcProvider.arn,\n        },\n        Action: \"sts:AssumeRoleWithWebIdentity\",\n        Condition: {\n          StringLike: {\n            // Note: Square brackets around the key are what allow us to use a\n            // templated string. See:\n            // https://stackoverflow.com/questions/59791960/how-to-use-template-literal-as-key-inside-object-literal\n            [`${audience}:sub`]: pulumi.interpolate`project_path:${project.pathWithNamespace}:ref_type:branch:ref:*`\n          },\n        },\n      },\n    ],\n  },\n});\n\nnew aws.iam.RolePolicyAttachment(\"gitlabAdminRolePolicy\", {\n  policyArn: \"arn:aws:iam::aws:policy/AdministratorAccess\",\n  role: gitlabAdminRole.name,\n});\n```\n\nA few things to be aware of regarding the thumbprint:\n\n1. If you are self-hosting GitLab, you'll need to obtain the thumbprint from your private GitLab installation.\n2. If you're using GitLab SaaS, it's possible GitLab's OIDC certificate may have been rotated by the time you are reading this.\n\nIn either case, you can obtain the correct/latest thumbprint value by following AWS' instructions contained in [Obtaining the thumbprint for an OpenID Connect Identity Provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html) in the AWS docs.\n\nYou'll also need to add the role's ARN as a project variable so that the CI/CD process can make a request to assume the role:\n\n```typescript\nnew gitlab.ProjectVariable(\"role-arn\", {\n  project: project.id,\n  key: \"ROLE_ARN\",\n  value: gitlabAdminRole.arn,\n});\n```\n\n## Project hook (optional)\n\nPulumi features an integration with GitLab via a webhook that will post the output of the `pulumi preview` directly to a merge request as a comment. For the webhook to work, you must have a Pulumi organization set up with GitLab as its SSO source. If you don't have a Pulumi organization and would like to try the integration, you can [sign up for a free trial](https://app.pulumi.com/signup?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) organization. The trial lasts 14 days, will give you access to all of Pulumi's paid features, and does not require a credit card. For full details on the integration, see [Pulumi CI/CD & GitLab integration](https://www.pulumi.com/docs/using-pulumi/continuous-delivery/gitlab-app/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources).\n\nTo set up the webhook, add the following to your `index.ts` file:\n\n```typescript\nnew gitlab.ProjectHook(\"project-hook\", {\n  project: project.id,\n  url: \"https://api.pulumi.com/workflow/gitlab\",\n  mergeRequestsEvents: true,\n  enableSslVerification: true,\n  token: process.env[\"PULUMI_ACCESS_TOKEN\"]!,\n  pushEvents: false,\n});\n```\n\nNote that the above resource assumes that your Pulumi access token is stored as an environment variable. You may want to instead store the token in your stack configuration file. To do this, run the following command:\n\n```bash\npulumi config set --secret pulumiAccessToken ${PULUMI_ACCESS_TOKEN}\n```\n\nThis will store the encrypted value in your Pulumi stack configuration file (`Pulumi.dev.yaml`). Because the value is encrypted, you can safely commit your stack configuration file to git. You can access its value in your Pulumi program like this:\n\n```typescript\nconst config = new pulumi.Config();\nconst pulumiAccessToken = config.requireSecret(\"pulumiAccessToken\");\n```\n\nFor more details on secrets handling in Pulumi, see [Secrets](https://www.pulumi.com/docs/concepts/secrets/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) in the Pulumi docs.\n\n## Creating a repository and adding repository files\n\nYou'll need to create a git repository (a GitLab project) and add some files to it that will control the CI/CD process. First, create some files that you'll include in your GitLab repo:\n\n```bash\nmkdir -p repository-files/scripts\ntouch repository-files/.gitlab-ci.yml repository-files/scripts/{aws-auth.sh,pulumi-preview.sh,pulumi-up.sh}\nchmod +x repository-files/scripts/{aws-auth.sh,pulumi-preview.sh,pulumi-up.sh}\n```\n\nNext, you'll need a GitLab CI/CD YAML file to describe the pipeline: which container image it should be run in and what the steps of the pipeline are. Place the following code into `repository-files/.gitlab-ci.yml`:\n\n```yaml\ndefault:\n  image:\n    name: \"pulumi/pulumi:3.91.1\"\n    entrypoint: [\"\"]\n\nstages:\n  - infrastructure-update\n\npulumi-up:\n  stage: infrastructure-update\n  id_tokens:\n    GITLAB_OIDC_TOKEN:\n      aud: https://gitlab.com\n  before_script:\n    - chmod +x ./scripts/*.sh\n    - ./scripts/aws-auth.sh\n  script:\n    - ./scripts/pulumi-up.sh\n  only:\n    - main # i.e., the name of the default branch\n\npulumi-preview:\n  stage: infrastructure-update\n  id_tokens:\n    GITLAB_OIDC_TOKEN:\n      aud: https://gitlab.com\n  before_script:\n    - chmod +x ./scripts/*.sh\n    - ./scripts/aws-auth.sh\n  script:\n    - ./scripts/pulumi-preview.sh\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n```\n\nThe CI/CD process is fairly simple but illustrates the basic functionality needed for a production-ready pipeline (or these steps may be all your organization needs):\n\n1. Run the `pulumi preview` command when a merge request is opened or updated. This will help the reviewer gain important context. Because IaC is necessarily stateful (the state file is what enables Pulumi to be a declarative tool), when reviewing changes reviewers _must have both the code changes and the infrastructure changes to fully understand the impact of changes to the codebase_. This process constitutes continuous integration.\n2. Run the `pulumi up` command when code is merged to the default branch (called `main` by default). This process constitutes continuous delivery.\n\nNote that this example uses the [`pulumi/pulumi`](https://hub.docker.com/r/pulumi/pulumi) \"kitchen sink\" image that contains all the runtimes for all the languages Pulumi supports, along with some ancillary tools like the AWS CLI (which you'll need in order to use OIDC authentication). While the `pulumi/pulumi` image is convenient, it's also quite large (1.41 GB at the time of writing), which makes it relatively slow to initialize. If you're creating production pipelines using Pulumi, you may want to consider creating your own custom (slimmer) image that has exactly the tools you need installed, perhaps starting with one of Pulumi's language-specific images, e.g. [`pulumi/pulumi-nodejs`](https://hub.docker.com/r/pulumi/pulumi-nodejs).\n\nThen you'll need to write the script that authenticates GitLab with AWS via OIDC. Place the following code in `repository-files/scripts/aws-auth.sh`:\n\n```bash\n#!/bin/bash\n\nmkdir -p ~/.aws\necho \"${GITLAB_OIDC_TOKEN}\" > /tmp/web_identity_token\necho -e \"[profile oidc]\\nrole_arn=${ROLE_ARN}\\nweb_identity_token_file=/tmp/web_identity_token\" > ~/.aws/config\n\necho \"length of GITLAB_OIDC_TOKEN=${#GITLAB_OIDC_TOKEN}\"\necho \"ROLE_ARN=${ROLE_ARN}\"\n\nexport AWS_PROFILE=\"oidc\"\naws sts get-caller-identity\n```\n\nFor continuous integration, you'll need a script that will execute the `pulumi preview` command when a merge request is opened. Place the following code in `repository-files/scripts/pulumi-preview.sh`:\n\n```bash\n#!/bin/bash\nset -e -x\n\nexport PATH=$PATH:$HOME/.pulumi/bin\n\nyarn install\npulumi login\npulumi org set-default $PULUMI_ORG\npulumi stack select dev\nexport AWS_PROFILE=\"oidc\"\npulumi preview\n```\n\nFor continuous delivery, you'll need a similar script that will execute the `pulumi up` command when the Merge Request is merged to the default branch. Place the following code in `repository-files/scripts/pulumi-up.sh`:\n\n```bash\n#!/bin/bash\nset -e -x\n\n# Add the pulumi CLI to the PATH\nexport PATH=$PATH:$HOME/.pulumi/bin\n\nyarn install\npulumi login\npulumi org set-default $PULUMI_ORG\npulumi stack select dev\nexport AWS_PROFILE=\"oidc\"\npulumi up -y\n```\n\nFinally, you'll need to add these files to your GitLab Project. Add the following code block to your `index.ts` file:\n\n```typescript\n[\n  \"scripts/aws-auth.sh\",\n  \"scripts/pulumi-preview.sh\",\n  \"scripts/pulumi-up.sh\",\n  \".gitlab-ci.yml\",\n].forEach(file => {\n  const content = fs.readFileSync(`repository-files/${file}`, \"utf-8\");\n\n  new gitlab.RepositoryFile(file, {\n    project: project.id,\n    filePath: file,\n    branch: \"main\",\n    content: content,\n    commitMessage: `Add ${file},`,\n    encoding: \"text\",\n  });\n});\n```\n\nNote that we're able to take advantage of general-purpose programming language features: We are able to create an array and use `forEach()` to iterate through its members, and we are able to use the `fs.readFileSync()` method from the Node.js runtime to read the contents of our file. This is powerful stuff!\n\n## Project variables and stack outputs\n\nYou'll need a few more resources to complete the code. Your CI/CD process will need a Pulumi access token in order to authenticate against the Pulumi Cloud backend which holds your Pulumi state file and handles encryption and decryption of secrets. You will also need to supply name of your Pulumi organization. (If you are using Pulumi Cloud as an individual, this is your Pulumi username.) Add the following to `index.ts`:\n\n```typescript\nnew gitlab.ProjectVariable(\"pulumi-access-token\", {\n  project: project.id,\n  key: \"PULUMI_ACCESS_TOKEN\",\n  value: process.env[\"PULUMI_ACCESS_TOKEN\"]!,\n  masked: true,\n});\n\nnew gitlab.ProjectVariable(\"pulumi-org\", {\n  project: project.id,\n  key: \"PULUMI_ORG\",\n  value: pulumi.getOrganization(),\n});\n```\n\nFinally, you'll need to add a stack output so that we can run the `git clone` command to test out our pipeline. Stack outputs allow you to access values within your Pulumi program from the command line or from other Pulumi programs. For more information, see [Understanding Stack Outputs](https://www.pulumi.com/learn/building-with-pulumi/stack-outputs/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources). Add the following to `index.ts`:\n\n```typescript\nexport const gitCloneCommand = pulumi.interpolate`git clone ${project.sshUrlToRepo}`;\n```\n\n## Deploying your infrastructure and testing the pipeline\n\nTo deploy your resources, run the following command:\n\n```bash\npulumi up\n```\n\nPulumi will output a list of the resources it intends to create. Select `yes` to continue.\n\nOnce the command has completed, you can run the following command to get the git clone command for your GitLab repo:\n\n```bash\npulumi stack output gitCloneCommand\n```\n\nIn a new, empty directory, run the `git clone` command from your Pulumi stack output, e.g.:\n\n```bash\ngit clone git@gitlab.com:jkodroff/pulumi-gitlab-demo-9de2a3b.git\n```\n\nChange into the directory and create a new branch:\n\n```bash\ngit checkout -b my-first-branch\n```\n\nNow you are ready to create some sample infrastructure in our repository. You can use the `aws-typescript` to quickly generate a simple Pulumi program with AWS resources:\n\n```bash\npulumi new aws-typescript -y --force\n```\n\nThe template includes a very simple Pulumi program that you can use to prove out the pipeline:\n\n```bash\n$ cat index.ts\nimport * as pulumi from \"@pulumi/pulumi\";\nimport * as aws from \"@pulumi/aws\";\nimport * as awsx from \"@pulumi/awsx\";\n\n// Create an AWS resource (S3 Bucket)\nconst bucket = new aws.s3.Bucket(\"my-bucket\");\n\n// Export the name of the bucket\nexport const bucketName = bucket.id;\n```\n\nCommit your changes and push your branch:\n\n```bash\ngit add -A\ngit commit -m \"My first commit.\"\ngit push\n```\n\nIn the GitLab UI, create a merge request for your branch:\n\n![Screenshot demonstrating opening a GitLab Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683438/Blog/Content%20Images/create-merge-request.jpg)\n\nYour merge request pipeline should start running:\n\n![Screenshot demonstrating opening a GitLab Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683438/Blog/Content%20Images/merge-request-running.jpg)\n\nOnce the pipeline completes, you should see the output of the `pulumi preview` command in the pipeline's logs:\n\n![Screenshot of a GitLab pipeline log showing the output of the \"pulumi preview\" command](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683438/Blog/Content%20Images/pulumi-preview.jpg)\n\nIf you installed the optional webhook, you should see the results of `pulumi preview` posted back to the merge request as a comment:\n\n![Screenshot of the GitLab Merge Request screen showing the output of the \"pulumi preview\" command as a comment](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683438/Blog/Content%20Images/merge-request-comment.jpg)\n\nOnce the pipeline has completed running, your merge request is ready to merge:\n\n![Screenshot of the GitLab Merge Request screen showing a successfully completed pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683438/Blog/Content%20Images/merge.jpg)\n\nMerging the merge request will trigger the main branch pipeline. (Note that in this screen you will see a failed initial run of CI/CD on the main branch toward the bottom of the screen. This is normal and is caused by the initial upload of `.gitlab-ci/yml` to the main branch without a Pulumi program being present.)\n\n![Screenshot of the GitLab pipelines screen showing a running pipeline along with a passed pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683438/Blog/Content%20Images/piplines.jpg)\n\nIf you click into the main branch pipeline's execution, you can see your bucket has been created:\n\n![Screenshot of a GitLab pipeline log showing the output of the \"pulumi up\" command](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683438/Blog/Content%20Images/pulumi-up.jpg)\nTo delete the bucket, run the following command in your local clone of the repository:\n\n```bash\npulumi destroy\n```\n\nAlternatively, you could create a merge request that removes the bucket from your Pulumi program and run the pipelines again. Because Pulumi is declarative, removing the bucket from your program will delete it from AWS.\n\nFinally, run the `pulumi destroy` command again in the Pulumi program with your OIDC and GitLab resources to finish cleaning up.\n\n## Next steps\n\nUsing IaC to define pipelines and other GitLab resources can greatly improve your platform team's ability to reliably and quickly manage the resources to keep application teams delivering. With Pulumi, you also get the power and expressiveness of using popular programming languages to express those resources!\n\nIf you liked what you read here, here are some ways you can enhance your CI/CD pipelines:\n\n- Add [Pulumi Policy Packs](https://www.pulumi.com/docs/using-pulumi/crossguard/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) to your pipeline: Pulumi policy packs allow you to validate that your resources are in compliance with your organization's security and compliance policies. Pulumi's open source [Compliance Ready Policies](https://www.pulumi.com/docs/using-pulumi/crossguard/compliance-ready-policies/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) are a great place to start on your journey. Compliance Ready Policies contain policy rules for the major cloud providers for popular compliance frameworks like PCI-DSS and ISO27001, and policy packs are easy to integrate into your pipelines.\n- Check out [Pulumi ESC (Environments, Secrets, and Configuration)](https://www.pulumi.com/product/esc/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources): Pulumi ESC makes it easy to share static secrets like GitLab tokens and can even [generate dynamic secrets like AWS OIDC credentials](https://www.pulumi.com/blog/esc-env-run-aws/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources). ESC becomes especially useful when using Pulumi at scale because it reduces the duplication of configuration and secrets that are used by multiple Pulumi programs. You don't even have to use Pulumi IaC to benefit from Pulumi ESC - [Pulumi ESC's command line](https://www.pulumi.com/docs/esc-cli/commands/?utm_source=GitLab&utm_medium=Referral&utm_campaign=Managing-GitLab-Resources) can be used with any CLI tool like the AWS CLI.",[108,768,9,230],{"slug":1075,"featured":6,"template":685},"managing-gitlab-resources-with-pulumi","content:en-us:blog:managing-gitlab-resources-with-pulumi.yml","Managing Gitlab Resources With Pulumi","en-us/blog/managing-gitlab-resources-with-pulumi.yml","en-us/blog/managing-gitlab-resources-with-pulumi",{"_path":1081,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1082,"content":1087,"config":1093,"_id":1095,"_type":13,"title":1096,"_source":15,"_file":1097,"_stem":1098,"_extension":18},"/en-us/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners",{"title":1083,"description":1084,"ogTitle":1083,"ogDescription":1084,"noIndex":6,"ogImage":946,"ogUrl":1085,"ogSiteName":667,"ogType":668,"canonicalUrls":1085,"schema":1086},"Meet the 2023 GitLab Partner of the Year award winners","We recognized our channel, technology, and cloud partners for their collaboration and contributions.","https://about.gitlab.com/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet the 2023 GitLab Partner of the Year award winners\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nima Badiey\"}],\n        \"datePublished\": \"2023-07-20\",\n      }",{"title":1083,"description":1084,"authors":1088,"heroImage":946,"date":1090,"body":1091,"category":872,"tags":1092},[1089],"Nima Badiey","2023-07-20","\nAt GitLab’s second annual Partner Leadership Summit in June, we invited channel, technology, and cloud partners to join us to celebrate their achievements, empower their success, and provide resources and support for the year to come. \n\nWe recognized our partners for their contributions via the Partner Leadership Awards, including Partner of the Year, Public Sector Partner of the Year, Public Sector Distributor of the Year, and Public Sector Services Partner of the Year. \n\nWe also introduced a new award category: Emerging Partner of the Year. The Emerging Partner of the Year award recognizes a new partner who consistently demonstrates a commitment to building a solution practice based on GitLab’s leading DevSecOps platform.\n\nGitLab strives to create collaborative and mutually beneficial relationships with our partners, and we also encourage our partners to embrace GitLab’s values of Collaboration, Results, Efficiency, Diversity, Inclusion & Belonging, Iteration, and Transparency ([CREDIT](https://handbook.gitlab.com/handbook/values/)). Each award winner demonstrated a strong partnership with GitLab and alignment with CREDIT values.\n\nOur 2023 Partner Leadership Summit Award winners are:\n\n### Partner of the Year: SHI Stratascale, a SHI Company\n_Stratascale, a subsidiary of SHI International, brings a consultancy-first approach to helping customers rapidly adapt to business changes by delivering end-to-end support of the transformation process._\n\nStratascale was selected as GitLab’s Partner of the Year because it provides a strong delivery framework, which is leveraged by customers looking to migrate their application development framework and meet DevSecOps requirements using GitLab technology. As a **result**, GitLab’s partnership with both Stratascale and legacy SHI experienced significant growth in 2023.\n\n### Emerging Partner of the Year: NextLink Labs\n_NextLink Labs is a DevOps, custom software development and cybersecurity consultancy._\n\nNextLink Labs is GitLab’s first Emerging Partner of the Year. NextLink Labs scales their impact to prospects and customers by leading with partnership best practices and **collaboration**. They provide value stream assessments, work with GitLab to create market awareness for our joint support, and help customers create paths to leverage the full value of GitLab’s leading DevSecOps platform. \n\n### Public Sector Partner of the Year: Flywheel Data\n_Flywheel Data is a value added reseller whose goal is to provide clients with the right tools, products, and technologies to accelerate mission success._\n\nFor the second year in a row, Flywheel Data is GitLab’s Public Sector Partner of the Year. Flywheel Data works with GitLab to deliver a single platform for DevSecOps to the U.S. government markets. Together, Flywheel and GitLab deliver immediate value to joint clients by simplifying the way their development, security, IT and ops teams collaborate to build software and manage infrastructure. This leads to a more **efficient** workflow for joint clients.\n\n### Public Sector Distributor of the Year: Carahsoft\n_Carahsoft is a public sector IT solutions provider, supporting federal, state, and local government agencies as well as education and healthcare organizations._\n\nCarahsoft earned Public Sector Distributor of the Year as a result of their complete alignment and execution of CREDIT values. Carahsoft demonstrates **collaboration** through dedicated resources and integrated alignment with the GitLab team, which enables Carahsoft and the reseller community to invest in the partnership while accelerating the public sector's ability to achieve digital transformation initiatives and mission success.\n\n### Public Sector Services Partner of the Year: Sirius Federal – A CDW Company\n_Sirius Federal, A CDW Company, helps customers design, orchestrate and manage technologies that drive business and government agency success._\n\nSirius Federal **iterated** on their processes over the last year to introduce new resources, such as “This Sirius Federal GitLab Adoption Workshop.” Sirius Federal offers best practice solutions that help Public Sector agencies achieve optimal outcomes and meet compliance guidelines. Their new offering increased engagement, set a vision for growth, and helped customers who had been stalled in their DevSecOps Platform adoption.\n\nOur heartfelt congratulations to all the winners! We look forward to further collaboration in the year to come. \n\n*Learn more about [GitLab’s Partner Program](https://partners.gitlab.com/).*\n",[9,872,955],{"slug":1094,"featured":6,"template":685},"meet-the-2023-gitlab-partner-of-the-year-award-winners","content:en-us:blog:meet-the-2023-gitlab-partner-of-the-year-award-winners.yml","Meet The 2023 Gitlab Partner Of The Year Award Winners","en-us/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners.yml","en-us/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners",{"_path":1100,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1101,"content":1107,"config":1113,"_id":1115,"_type":13,"title":1116,"_source":15,"_file":1117,"_stem":1118,"_extension":18},"/en-us/blog/meet-the-2024-gitlab-partner-of-the-year-award-winners",{"title":1102,"description":1103,"ogTitle":1102,"ogDescription":1103,"noIndex":6,"ogImage":1104,"ogUrl":1105,"ogSiteName":667,"ogType":668,"canonicalUrls":1105,"schema":1106},"Meet the 2024 GitLab Partner of the Year award winners","Find out who was recognized across our channel, technology, and cloud partners for their collaboration and contributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099196/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_3Ap5GS9mcSfiVI0dAVDRHg_1750099195945.png","https://about.gitlab.com/blog/meet-the-2024-gitlab-partner-of-the-year-award-winners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet the 2024 GitLab Partner of the Year award winners\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Weber\"}],\n        \"datePublished\": \"2024-04-25\",\n      }",{"title":1102,"description":1103,"authors":1108,"heroImage":1104,"date":1110,"body":1111,"category":872,"tags":1112},[1109],"Chris Weber","2024-04-25","[GitLab’s Partner Program](https://partners.gitlab.com/) fosters a thriving partner ecosystem of DevSecOps expertise to enable innovation through software development and drive customer value.  \n\nEarlier this month, we gathered our channel, technology, and cloud partners from across the globe to celebrate their achievements, empower their success, and provide resources and support for the year to come.\n\nWe recognized our partners for their contributions with awards highlighting our emerging, services, distributor, and public sector partners in AMER, APJ, and EMEA. Each award winner demonstrated a strong partnership with GitLab and focused on delivering excellent outcomes to our customers.\n\nHere are our 2024 GitLab Partner of the Year award winners by region.\n\n## AMER\n\n### Emerging Partner of the Year: [SADA, an Insight company](https://sada.com/)\nSADA, an Insight company, is a global cloud consulting and professional services market leader providing solutions powered by Google Cloud.\n\n### Services Partner of the Year: [CDW](https://www.cdw.com/)\nCDW offers customized, tailored solutions across cloud solutions, cybersecurity, and managed services for industries across government, education, and healthcare. \n\n### Partner of the Year: [Stratascale/SHI](https://www.stratascale.com/)\nStratascale, a subsidiary of SHI International, brings a consultancy-first approach to helping customers rapidly adapt to business changes by delivering end-to-end support of the transformation process.\n\n## APJ\n### Emerging Partner of the Year: [Fineshift](https://fineshift.com/)\nFineshift empowers organizations in APAC to deliver secure software more efficiently by enhancing their software development processes with unified DevSecOps workflows. \n\n### Services Partner of the Year: [Adfinis](https://adfinis.com/en/)\nAdfinis delivers innovative and tailored IT solutions to customers ranging from small businesses to large enterprises, leveraging open-source technologies to achieve their goals. \n\n### Distributor of the Year: [TD Synnex](https://www.tdsynnex.com/na/us/)\nTD Synnex connects vendors and resellers with customers across APAC to deliver critical IT solutions that drive operational efficiencies. \n\n### Partner of the Year: [DevOps1](https://devops1.com.au/)\nDevOps1 assists customers in their application modernization journeys to increase agility, improve time to market, and enhance business value. \n\n## EMEA\n### Emerging Partner of the Year: [Kiratech](https://www.kiratech.it/en/)\nKiratech enables businesses to onboard new technologies, improve efficiency, and drive innovation with its expert counsel on cloud-native solutions and DevOps methodologies.  \n\n### Services Partner of the Year: Name: [cc Cloud GmbH](http://www.codecentric.cloud/)\ncc Cloud supports organizations from consulting through to managed services to support their digitalization journey and transformation.\n\n### Distributor of the Year: [Amazic](https://amazic.com/)\nAmazic enables its customers to modernize their IT infrastructure with the help of DevOps methodologies and cloud computing. \n\n### Partner of the Year: [SVA](https://www.svasoftware.com/)\nSVA provides customers with comprehensive, tailored IT solutions such as cloud computing, cybersecurity, and software development. \n\n## Public Sector\n\n### Services Partner of the Year: [Sirius Federal](https://www.cdw.com/content/cdw/en/industries/federal-it-solutions.html)\nSirius Federal, a CDW Company, helps customers design, orchestrate, and manage technologies that drive business and government agency success.\n\n### Emerging Partner of the Year: [Thundercat Technologies](https://www.thundercattech.com/)\nThunderCat Technology works closely with public sector agencies to deliver comprehensive solutions across cloud computing, cybersecurity, and modernization that meet the unique needs of government IT. \n\n### Distributor of the Year: [Carahsoft](https://www.carahsoft.com/)\nCarahsoft is a public sector IT solutions provider, supporting federal, state, and local government agencies as well as education and healthcare organizations.\n\n### Partner of the Year: [Flywheel Data](https://flywheeldata.com/)\nFlywheel Data is a value-added reseller that provides clients with the right tools, products, and technologies to accelerate mission success.\n\n> Learn more about [GitLab’s Partner Program](https://partners.gitlab.com/).\n",[872,9],{"slug":1114,"featured":6,"template":685},"meet-the-2024-gitlab-partner-of-the-year-award-winners","content:en-us:blog:meet-the-2024-gitlab-partner-of-the-year-award-winners.yml","Meet The 2024 Gitlab Partner Of The Year Award Winners","en-us/blog/meet-the-2024-gitlab-partner-of-the-year-award-winners.yml","en-us/blog/meet-the-2024-gitlab-partner-of-the-year-award-winners",{"_path":1120,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1121,"content":1127,"config":1133,"_id":1135,"_type":13,"title":1136,"_source":15,"_file":1137,"_stem":1138,"_extension":18},"/en-us/blog/r2devops-open-source-hub-cicd",{"title":1122,"description":1123,"ogTitle":1122,"ogDescription":1123,"noIndex":6,"ogImage":1124,"ogUrl":1125,"ogSiteName":667,"ogType":668,"canonicalUrls":1125,"schema":1126},"How to create a hub of GitLab CI/CD jobs with R2Devops","Here's how R2Devops and GitLab can work together to streamline CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682395/Blog/Hero%20Images/r2devops1.png","https://about.gitlab.com/blog/r2devops-open-source-hub-cicd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to create a hub of GitLab CI/CD jobs with R2Devops\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Salerno\"}],\n        \"datePublished\": \"2022-07-27\",\n      }",{"title":1122,"description":1123,"authors":1128,"heroImage":1124,"date":1130,"body":1131,"category":872,"tags":1132},[1129],"Sandra Salerno","2022-07-27","\n\nCI/CD has changed our development processes, but it hasn’t simplified them in every aspect. The amount of knowledge necessary to implement and maintain your first CI/CD pipelines is huge, and the time you need to invest in it is consequential. Partnering with GitLab, R2Devops aims to simplify CI/CD onboarding by creating a hub of CI/CD jobs. In this blog post I'll show you how to use R2DevOps with GitLab to add jobs to an open source hub.\n\n## A collaborative hub of open source jobs\n\nCollaboration is core to our development processes. On a daily basis, we use open source software and code and ask our teammates for review. Working together to achieve common goals helps us to develop better products and improve continuously. With R2Devops, you’ll find a [collaborative library of open source CI/CD jobs](https://r2devops.io/_/jobs). \n\nYou can save a lot of time by using jobs from an open source library. You won’t have to write your pipeline from scratch for every new project, and you can focus on what you like doing, which is coding.\n\nAnd, of course, working together is working smarter. R2Devops empowers collaboration by allowing developers to add their own jobs into the library directly from their GitLab account. \n\n## How to add a job in R2Devops\n\n![Adding a job](https://about.gitlab.com/images/blogimages/r2devops2.gif){: .shadow.small.left}\n\nLink your GitLab account to [R2Devops](https://r2devops.io), fill in the URL of your repository, the path of your job, and give it a name. Once you click on import, our crawler will check three files:\n\n1.) the jobname.yml/jobname.yaml \n\n2.) the changelog.md\n\n3.) the readme.md. \n\nThe crawler process is explained in detail [in our documentation](https://docs.r2devops.io/crawler/). In short, without a jobname.yml file, R2 won’t be able to import your job. The changelog.md allows R2 to check your job’s versions, and the readme.md is used to build the documentation for each version of your job.\n\nEt voilà, anyone can see your job in R2Devops and easily use it in their pipeline.\n\nOnce your job is in R2Devops, you can add information such as the license, description, and specify labels. This helps other users understand what your job can be used for. That data and the job’s code appears in the documentation. 👇\n\n![Data in the documentation](https://about.gitlab.com/images/blogimages/r2devops3.png){: .shadow.small.left}\n\n### Include any jobs in one line with GitLab Include keyword feature\n\n[In January 2019, GitLab released a feature](https://about.gitlab.com/releases/2019/01/22/gitlab-11-7-released/) that simplifies the CI/CD keyword [Include](https://docs.gitlab.com/ee/ci/yaml/index.html#include) process. Rather than copying the code of a job every time you need to create a new pipeline, you can instead indicate to your pipeline where the source is located.\n\nFor example, this:\n\n![pre-include](https://about.gitlab.com/images/blogimages/r2devops4.png){: .shadow.small.left}\n\ncan become the below:\n\n![post-include](https://about.gitlab.com/images/blogimages/r2devops5.png){: .shadow.small.left}\n\nThis feature is used in R2Devops. Every resource added in the library gets its own _Include_ link, so anyone can implement it in one line in their CI/CD. It also means that the file you are using is located in a unique place. Once you update it, you only have to update the include link by modifying the version of the job you want to use. You don’t have to update the whole code in every pipeline you own.\n\n### Customize the job you need using GitLab variables\n\nMost of R2Devops’ jobs are plug and play, meaning you can add the _Include_ link of the job in your pipeline, launch it, and it will work. We understand every project is different and has its own requirements, which is why we defined variables for each job. \n\n[GitLab CI/CD variables](https://docs.gitlab.com/ee/ci/variables/) and YAML overrides allow you to customize the jobs and make them fit your project easily. \n\n![How to customize](https://about.gitlab.com/images/blogimages/r2devops6.png){: .shadow.small.left}\n\nWe have included two jobs from the hub as examples: [python_test](https://r2devops.io/_/r2devops-bot/python_test) code and[sls-scan](https://r2devops.io/_/r2devops-bot/sls_scan). Using the variables defined in the documentation for each job, you can personalize the behavior of these jobs to fit our project requirements.\n\n## Matching GitLab's values of open source and transparency\n\nR2Devops joined the [GitLab Alliance Partner Program](/handbook/alliances/) in March. Both solutions share the same goal – to simplify developer lives by improving development processes. If you want to take part in the development of the open source CI/CD community of GitLab or give feedback on the solution, please [join the R2Devops community on Discord.](https://discord.r2devops.io?utm_medium=website&utm_source=r2devops&utm_campaign=button https://discord.r2devops.io?utm_medium=gitlab&utm_source=blog&utm_campaign=articleR2Devops)\n\nCover image by [Duy Pham](https://unsplash.com/@miinyuii) on [Unsplash](https://unsplash.com)\n{: .note}\n\n\n",[108,705,9],{"slug":1134,"featured":6,"template":685},"r2devops-open-source-hub-cicd","content:en-us:blog:r2devops-open-source-hub-cicd.yml","R2devops Open Source Hub Cicd","en-us/blog/r2devops-open-source-hub-cicd.yml","en-us/blog/r2devops-open-source-hub-cicd",{"_path":1140,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1141,"content":1147,"config":1155,"_id":1157,"_type":13,"title":1158,"_source":15,"_file":1159,"_stem":1160,"_extension":18},"/en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration",{"title":1142,"description":1143,"ogTitle":1142,"ogDescription":1143,"noIndex":6,"ogImage":1144,"ogUrl":1145,"ogSiteName":667,"ogType":668,"canonicalUrls":1145,"schema":1146},"Secure and publish Python packages: A guide to CI integration","Learn how to implement a secure CI/CD pipeline across five stages with the GitLab DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662080/Blog/Hero%20Images/AdobeStock_1097303277.jpg","https://about.gitlab.com/blog/secure-and-publish-python-packages-a-guide-to-ci-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure and publish Python packages: A guide to CI integration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-01-21\",\n      }",{"title":1142,"description":1143,"authors":1148,"heroImage":1144,"date":1150,"body":1151,"category":766,"tags":1152},[1149],"Tim Rizzi","2025-01-21","Supply chain security is a critical concern in software development. Organizations need to verify the authenticity and integrity of their software packages. This guide will show you how to implement a secure CI/CD pipeline for Python packages using GitLab CI, incorporating package signing and attestation using Sigstore's Cosign.\n\nYou'll learn:\n\n- [Why sign and attest your Python packages?](#why-sign-and-attest-your-python-packages%3F)\n- [Pipeline overview](#pipeline-overview)\n- [Complete pipeline implementation: Setting up the environment](#complete-pipeline-implementation-setting-up-the-environment)\n   * [Environment configuration](#environment-configuration)\n   * [Configuration breakdown](#configuration-breakdown)\n-  The 6 stages\n\n    1. [Building](#building-crafting-the-package)\n    2. [Signing](#signing-the-digital-notarization)\n    3. [Verification](#verification-the-security-checkpoint)\n    4. [Publishing](#publishing-the-controlled-release)\n    5. [Publishing signatures](#publishing-signatures-making-verification-possible)\n    6. [Consumer verification](#consumer-verification-testing-the-user-experience)\n\n## Why sign and attest your Python packages?\n\nHere are four reasons to sign and attest your Python packages:\n\n* **Supply chain security:** Package signing ensures that the code hasn't been tampered with between build and deployment, protecting against supply chain attacks.\n* **Compliance requirements:** Many organizations, especially in regulated industries, require cryptographic signatures and provenance information for all deployed software.\n* **Traceability:** Attestations provide a verifiable record of build conditions, including who built the package and under what circumstances.\n* **Trust verification:** Consumers of your package can cryptographically verify its authenticity before installation.\n\n## Pipeline overview\n\nEnsuring your code's integrity and authenticity is necessary. Imagine a pipeline that doesn't just compile your code but creates a cryptographically verifiable narrative of how, when, and by whom your package was created. Each stage acts as a guardian, checking and documenting the package's provenance.\n\nHere are six stages of a GitLab pipeline that ensure your package is secure and trustworthy:\n\n* Build: Creates a clean, standard package that can be easily shared and installed.\n* Signing: Adds a digital signature that proves the package hasn't been tampered with since it was created.\n* Verification: Double-checks that the signature is valid and the package meets all our security requirements.\n* Publishing: Uploads the verified package to GitLab's package registry, making it available for others to use.\n* Publishing Signatures: Makes signatures available for verification.\n* Consumer Verification: Simulates how end users can verify package authenticity.\n\n## Complete pipeline implementation: Setting up the environment\n\nBefore we build our package, we need to set up a consistent and secure build environment. This configuration ensures every package is created with the same tools, settings, and security checks.\n\n### Environment configuration\n\nOur pipeline requires specific tools and settings to work correctly.\n\nPrimary configurations:\n\n* Python 3.10 for consistent builds\n* Cosign 2.2.3 for package signing\n* GitLab package registry integration\n* Hardcoded package version for reproducibility\n\n**Note about versioning:** We've chosen to use a hardcoded version (`\"1.0.0\"`) in this example rather than deriving it from git tags or commits. This approach ensures complete reproducibility and makes the pipeline behavior more predictable. In a production environment, you might want to use semantic versioning based on git tags or another versioning strategy that fits your release process.\n\nTool requirements:\n\n* Basic utilities: `curl`, `wget`\n* Cosign for cryptographic signing\n* Python packaging tools: `build`, `twine`, `setuptools`, `wheel`\n\n### Configuration breakdown\n\n```yaml\nvariables:\n  PYTHON_VERSION: '3.10'\n  PACKAGE_NAME: ${CI_PROJECT_NAME}\n  PACKAGE_VERSION: \"1.0.0\"\n  FULCIO_URL: 'https://fulcio.sigstore.dev'\n  REKOR_URL: 'https://rekor.sigstore.dev'\n  CERTIFICATE_IDENTITY: 'https://gitlab.com/${CI_PROJECT_PATH}//.gitlab-ci.yml@refs/heads/${CI_DEFAULT_BRANCH}'\n  CERTIFICATE_OIDC_ISSUER: 'https://gitlab.com'\n  PIP_CACHE_DIR: \"$CI_PROJECT_DIR/.pip-cache\"\n  COSIGN_YES: \"true\"\n  GENERIC_PACKAGE_BASE_URL: \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${PACKAGE_NAME}/${PACKAGE_VERSION}\"\n```\n\nWe use caching to speed up subsequent builds:\n\n```yaml\ncache:\n  paths:\n    - ${PIP_CACHE_DIR}\n```\n\n## Building: Crafting the package\n\nEvery software journey begins with creation. In our pipeline, the build stage is where raw code transforms into a distributable package, ready to travel across different Python environments.\n\nThe build process creates two standardized formats:\n\n* a wheel package (.whl) for quick, efficient installation\n* a source distribution (.tar.gz) that carries the complete code\n\nHere's the build stage implementation:\n\n```yaml\nbuild:\n  extends: .python-job\n  stage: build\n  script:\n    - git init\n    - git config --global init.defaultBranch main\n    - git config --global user.email \"ci@example.com\"\n    - git config --global user.name \"CI\"\n    - git add .\n    - git commit -m \"Initial commit\"\n    - export NORMALIZED_NAME=$(echo \"${CI_PROJECT_NAME}\" | tr '-' '_')\n    - sed -i \"s/name = \\\".*\\\"/name = \\\"${NORMALIZED_NAME}\\\"/\" pyproject.toml\n    - sed -i \"s|\\\"Homepage\\\" = \\\".*\\\"|\\\"Homepage\\\" = \\\"https://gitlab.com/${CI_PROJECT_PATH}\\\"|\" pyproject.toml\n    - python -m build\n  artifacts:\n    paths:\n      - dist/\n      - pyproject.toml\n```\n\nLet's break down what this build stage does:\n\n1. Initializes a Git repository (`git init`) and configures it with basic settings\n2. Normalizes the package name by converting hyphens to underscores, which is required for Python packaging\n3. Updates the package metadata in `pyproject.toml` to match our project settings\n4. Builds both wheel and source distribution packages using `python -m build`\n5. Preserves the built packages and configuration as artifacts for subsequent stages\n\n## Signing: The digital notarization\n\nIf attestation is the package's biography, signing is its cryptographic seal of authenticity. This is where we transform our package from a mere collection of files into a verified, tamper-evident artifact.\n\nThe signing stage uses Cosign to apply a digital signature as an unbreakable seal. This isn't just a stamp — it's a complex cryptographic handshake that proves the package's integrity and origin.\n\n```yaml\nsign:\n  extends: .python+cosign-job\n  stage: sign\n  id_tokens:\n    SIGSTORE_ID_TOKEN:\n      aud: sigstore\n  script:\n    - |\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          cosign sign-blob --yes \\\n            --fulcio-url=${FULCIO_URL} \\\n            --rekor-url=${REKOR_URL} \\\n            --oidc-issuer $CI_SERVER_URL \\\n            --identity-token $SIGSTORE_ID_TOKEN \\\n            --output-signature \"dist/${filename}.sig\" \\\n            --output-certificate \"dist/${filename}.crt\" \\\n            \"$file\"\n        fi\n      done\n  artifacts:\n    paths:\n      - dist/\n```\n\nThis signing stage performs several crucial operations:\n\n1. Obtains an OIDC token from GitLab for authentication with Sigstore services\n2. Processes each built package (both wheel and source distribution)\n3. Uses Cosign to create a cryptographic signature (`.sig`) for each package\n4. Generates a certificate (`.crt`) that proves the signature's authenticity\n5. Stores both signatures and certificates alongside the packages as artifacts\n\n## Verification: The security checkpoint\n\nVerification is our final quality control gate. It's not just a check — it's a security interrogation where every aspect of the package is scrutinized.\n\n```yaml\nverify:\n  extends: .python+cosign-job\n  stage: verify\n  script:\n    - |\n      failed=0\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          if ! cosign verify-blob \\\n            --signature \"dist/${filename}.sig\" \\\n            --certificate \"dist/${filename}.crt\" \\\n            --certificate-identity \"${CERTIFICATE_IDENTITY}\" \\\n            --certificate-oidc-issuer \"${CERTIFICATE_OIDC_ISSUER}\" \\\n            \"$file\"; then\n            failed=1\n          fi\n        fi\n      done\n      if [ $failed -eq 1 ]; then\n        exit 1\n      fi\n```\n\nThe verification stage implements several security checks:\n\n1. Examines each package file in the `dist` directory\n2. Uses Cosign to verify the signature matches the package content\n3. Confirms the certificate's identity matches our expected GitLab pipeline identity\n4. Validates our trusted OIDC provider issued the certificate\n5. Fails the entire pipeline if any verification check fails, ensuring only verified packages proceed\n\n## Publishing: The controlled release\n\nPublishing is where we make our verified packages available through GitLab's package registry. It's a carefully choreographed release that ensures only verified, authenticated packages reach their destination.\n\n```yaml\npublish:\n  extends: .python-job\n  stage: publish\n  script:\n    - |\n      cat \u003C\u003C EOF > ~/.pypirc\n      [distutils]\n      index-servers = gitlab\n      [gitlab]\n      repository = ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/pypi\n      username = gitlab-ci-token\n      password = ${CI_JOB_TOKEN}\n      EOF\n      TWINE_PASSWORD=${CI_JOB_TOKEN} TWINE_USERNAME=gitlab-ci-token \\\n        twine upload --repository-url ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/pypi \\\n        dist/*.whl dist/*.tar.gz\n```\n\nThe publishing stage handles several important tasks:\n\n1. Creates a `.pypirc` configuration file with GitLab package registry credentials\n2. Uses the GitLab CI job token for secure authentication\n3. Uploads both wheel and source distribution packages to the GitLab PyPI registry\n4. Makes the packages available for installation via pip\n\n## Publishing signatures: Making verification possible\n\nAfter publishing the packages, we must make their signatures and certificates available for verification. We store these in GitLab's generic package registry, making them easily accessible to users who want to verify package authenticity.\n\n```yaml\npublish_signatures:\n  extends: .python+cosign-job\n  stage: publish_signatures\n  script:\n    - |\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          curl --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --fail \\\n               --upload-file \"dist/${filename}.sig\" \\\n               \"${GENERIC_PACKAGE_BASE_URL}/${filename}.sig\"\n\n          curl --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --fail \\\n               --upload-file \"dist/${filename}.crt\" \\\n               \"${GENERIC_PACKAGE_BASE_URL}/${filename}.crt\"\n        fi\n      done\n```\n\nThe signature publishing stage performs these key operations:\n\n1. Processes each built package to find its corresponding signature files\n2. Uses the GitLab API to upload the signature (`.sig`) file to the generic package registry\n3. Uploads the corresponding certificate (`.crt`) file\n4. Makes these verification artifacts available for downstream package consumers\n5. Uses the same version and package name to maintain the connection between packages and signatures\n\n## Consumer verification: Testing the user experience\n\nThe final stage simulates how end users will verify your package's authenticity. This stage acts as a final check and a practical example of the verification process.\n\n```yaml\nconsumer_verification:\n  extends: .python+cosign-job\n  stage: consumer_verification\n  script:\n    - |\n      git init\n      git config --global init.defaultBranch main\n      mkdir -p pkg signatures\n\n      pip download --index-url \"https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/pypi/simple\" \\\n          \"${NORMALIZED_NAME}==${PACKAGE_VERSION}\" --no-deps -d ./pkg\n\n      pip download --no-binary :all: \\\n          --index-url \"https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/pypi/simple\" \\\n          \"${NORMALIZED_NAME}==${PACKAGE_VERSION}\" --no-deps -d ./pkg\n\n      failed=0\n      for file in pkg/*.whl pkg/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          sig_url=\"${GENERIC_PACKAGE_BASE_URL}/${filename}.sig\"\n          cert_url=\"${GENERIC_PACKAGE_BASE_URL}/${filename}.crt\"\n\n          curl --fail --silent --show-error \\\n               --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --output \"signatures/${filename}.sig\" \\\n               \"$sig_url\"\n\n          curl --fail --silent --show-error \\\n               --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --output \"signatures/${filename}.crt\" \\\n               \"$cert_url\"\n\n          if ! cosign verify-blob \\\n            --signature \"signatures/${filename}.sig\" \\\n            --certificate \"signatures/${filename}.crt\" \\\n            --certificate-identity \"${CERTIFICATE_IDENTITY}\" \\\n            --certificate-oidc-issuer \"${CERTIFICATE_OIDC_ISSUER}\" \\\n            \"$file\"; then\n            failed=1\n          fi\n        fi\n      done\n\n      if [ $failed -eq 1 ]; then\n        exit 1\n      fi\n```\n\nThis consumer verification stage simulates the end-user experience by:\n\n1. Creating a clean environment to test package installation\n2. Downloading the published packages from the GitLab PyPI registry\n3. Retrieving the corresponding signatures and certificates from the generic package registry\n4. Performing the same verification steps that end users would perform\n5. Ensuring the entire process works from a consumer's perspective\n6. Failing the pipeline if any verification step fails, providing an early warning of any issues\n\n## Summary\n\nThis comprehensive pipeline provides a secure and reliable way to build, sign, and publish Python packages to GitLab's package registry. By following these practices and implementing the suggested security measures, you can ensure your packages are appropriately verified and safely distributed to your users.\n\nThe pipeline combines modern security practices with efficient automation to create a robust software supply chain. Using Sigstore's Cosign for signing and attestation, along with GitLab's built-in security features, you can provide users with trustworthy cryptographically verified packages.\n\n> #### Get started on your security journey today with a [free 60-day trial of GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com).\n\n## Learn more\n- [Documentation: Use Sigstore for keyless signing and verification](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html)\n- [Streamline security with keyless signing and verification in GitLab](https://about.gitlab.com/blog/keyless-signing-with-cosign/)\n- [Annotate container images with build provenance using Cosign in GitLab CI/CD](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd/)",[766,230,9,680,1153,108,476,682,1154],"CI","solutions architecture",{"slug":1156,"featured":90,"template":685},"secure-and-publish-python-packages-a-guide-to-ci-integration","content:en-us:blog:secure-and-publish-python-packages-a-guide-to-ci-integration.yml","Secure And Publish Python Packages A Guide To Ci Integration","en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration.yml","en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration",{"_path":1162,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1163,"content":1169,"config":1175,"_id":1177,"_type":13,"title":1178,"_source":15,"_file":1179,"_stem":1180,"_extension":18},"/en-us/blog/self-managed-support-gitlab-for-jira-app",{"title":1164,"description":1165,"ogTitle":1164,"ogDescription":1165,"noIndex":6,"ogImage":1166,"ogUrl":1167,"ogSiteName":667,"ogType":668,"canonicalUrls":1167,"schema":1168},"Self-managed support extended to GitLab for Jira App","Connect GitLab with the Jira development panel to sync merge requests, commits, and transition Jira issue statuses from GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682573/Blog/Hero%20Images/jason-goodman-Oalh2MojUuk-unsplash.jpg","https://about.gitlab.com/blog/self-managed-support-gitlab-for-jira-app","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Self-managed support extended to GitLab for Jira App\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Grant Hickman\"}],\n        \"datePublished\": \"2023-01-12\",\n      }",{"title":1164,"description":1165,"authors":1170,"heroImage":1166,"date":1172,"body":1173,"category":872,"tags":1174},[1171],"Grant Hickman","2023-01-12","\n\nDeveloping fast feedback loops is a core tenet of DevOps and is critical to the communication required between planning functions and engineering teams. GitLab provides many integrated features for Agile Planning within the DevSecOps Platform, but we understand the importance of supporting tools used within the broader DevOps ecosystem. This is why we’ve partnered with Atlassian to provide additional (and more straightforward) support between GitLab and Atlassian Jira, via the GitLab for Jira app.\n\n## GitLab for Jira app: Proxy for Self-Managed GitLab\n\nFor Jira Cloud, the GitLab for Jira app now officially supports integration with both GitLab SaaS and GitLab Self-Managed, making it easier to identify the ideal integration based on the type of installation mix you may have.\n\nWith the GitLab for Jira app, you can: \n\n- Display merge requests, commits, pipelines, deployments, feature flags, and branches directly in the Jira Development Panel, creating a quick view into progress on feature development.\n- Link commits, commit messages, and issue comments by mentioning the Jira Issue ID.\n- Transition issues from a commit, saving developers time from context switching across tools.\n- Add time tracking or custom comments to an issue with Smart Commits.\n\n## Configuring the GitLab for Jira app with GitLab Self-Managed\n\nHere are the steps to take to configure the GitLab for Jira app with GitLab Self-Managed: \n\n1. Visit the GitLab for Jira App in the Atlassian Marketplace.\n1. Click “Get it now”.\n1. Choose “GitLab (self managed)” Note: this requires a GitLab Admin role.\n1. Configure your [Instance OAuth App in GitLab](https://docs.gitlab.com/ee/integration/jira/connect-app.html#connect-the-gitlabcom-for-jira-cloud-app-for-self-managed-instances).\n1. Provide your instance URL.\n1. Sign in to your GitLab instance.\n1. Link your namespace.\n\n## Limitations and considerations\n\n1. If you have implemented the GitLab for Jira app manually via App Manifest, proceed with caution. This is our first iteration and we’ll be improving the workflow to make it easier to migrate to the official GitLab for Jira app from the App Manifest approach.\n1. Traffic will be routed through GitLab.com for the GitLab for Jira app to configure the integration. \n1. To configure the integration, you will need to be an admin of the Jira project and the GitLab instance to enable the integration.\n\n## Deprecation and removal of Jira Cloud support for DVCS integration\n\nAs the GitLab for Jira app now supports GitLab Self-Managed, this is the recommended path for integration between Jira Cloud and GitLab (for GitLab.com and GitLab Self-Managed). The GitLab DVCS connector will only support Jira Server and Jira Data Center moving forward. Jira Cloud support within the DVCS integration is [deprecated and will be removed in %16.0](https://docs.gitlab.com/ee/update/deprecations.html#jira-github-enterprise-dvcs-integration).\n\nTo simplify how to choose which integrations are a fit for you, see below:\n\n1. Are you using Jira Cloud?\n    1. Use the [GitLab for Jira app](https://marketplace.atlassian.com/apps/1221011?tab=overview&hosting=cloud).\n    2. You can also use the [GitLab Jira Integration](https://docs.gitlab.com/ee/integration/jira/configure.html) with the GitLab for Jira app.\n\n2. Are you using Jira Server or Jira Data Center?\n    1. Use the [Jira DVCS Connector](https://docs.gitlab.com/ee/integration/jira/dvcs.html)\n    2. You can also use the [GitLab Jira Integration](https://docs.gitlab.com/ee/integration/jira/configure.html) with the Jira DVCS Connector.\n\n## Options for using the GitLab for Jira app with GitLab Self-Managed\n\nWith this release, you may now configure the [GitLab for Jira app directly from the Atlassian Marketplace](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?tab=overview&hosting=cloud). This gives you a guided workflow for enabling the app and leverages GitLab.com as a proxy for your self-managed instance, for purposes of enabling the integration.\n\nAlternatively, you may also install the GitLab for Jira app by fetching a manifest file or creating your own Marketplace listing. To explore these approaches, you can [visit our documentation](https://docs.gitlab.com/ee/integration/jira/connect-app.html#install-the-gitlabcom-for-jira-cloud-app-for-self-managed-instances).\n\n### Read more\n\n- [Epic](https://gitlab.com/groups/gitlab-org/-/epics/5650) about the extension of self-managed support to GitLab from Jira app\n- [How to integrate GitLab.com with Jira Cloud](/blog/integrating-gitlab-com-with-atlassian-jira-cloud/)\n- [Documentation](https://docs.gitlab.com/ee/integration/jira/connect-app.html) on GitLab.com for Jira Cloud app\n\n_Cover image by [Jason Goodman](https://unsplash.com/@jasongoodman_youxventures?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://www.unsplash.com)._\n",[680,230,9],{"slug":1176,"featured":6,"template":685},"self-managed-support-gitlab-for-jira-app","content:en-us:blog:self-managed-support-gitlab-for-jira-app.yml","Self Managed Support Gitlab For Jira App","en-us/blog/self-managed-support-gitlab-for-jira-app.yml","en-us/blog/self-managed-support-gitlab-for-jira-app",{"_path":1182,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1183,"content":1189,"config":1196,"_id":1198,"_type":13,"title":1199,"_source":15,"_file":1200,"_stem":1201,"_extension":18},"/en-us/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud",{"title":1184,"description":1185,"ogTitle":1184,"ogDescription":1185,"noIndex":6,"ogImage":1186,"ogUrl":1187,"ogSiteName":667,"ogType":668,"canonicalUrls":1187,"schema":1188},"GitLab & Google Cloud partnership accelerates cloud adoption","Learn how Cloud Seed came about and how it will help speed app modernization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665811/Blog/Hero%20Images/daytime-clouds.jpg","https://about.gitlab.com/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Accelerate cloud adoption with GitLab's open source partnership with Google Cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sri Rangan\"}],\n        \"datePublished\": \"2022-10-11\",\n      }",{"title":1190,"description":1185,"authors":1191,"heroImage":1186,"date":1193,"body":1194,"category":933,"tags":1195},"Accelerate cloud adoption with GitLab's open source partnership with Google Cloud",[1192],"Sri Rangan","2022-10-11","\nSince December 2021, GitLab Incubation has partnered with Google Cloud to develop\nsolutions that will help customers address one of their biggest business requirements: accelerating cloud adoption.\n\nWe are thrilled to announce the release of Cloud Seed at Google Cloud Next 2022,\nand we are even more excited to follow up with our community. Cloud Seed is an open\nsource partnership between GitLab and Google Cloud to accelerate cloud adoption and\napp modernization.\n\nThe origins of Cloud Seed date back to late 2020 when I worked closely with GitLab co-founder and CEO [Sid Sijbrandij]( /company/team/#sytses) on an experiment called “5 Minute Production\". Our focus was to improve developer experience while consuming cloud services and enabling DevSecOps best practices by default.\n\nFor this, GitLab needed to collaborate with the hyper clouds, and Google Cloud emerged as our natural choice. In this post I’d like to shed light on our collaboration, the results our partnership has achieved, and the positive business outcomes our customers will realize.\n\n## Refining the use case\n\nFirst, we reached out and polled our customers to try and understand their cloud adoption use cases. \n\nWe found the enterprise market segment focused on migrating existing systems to the cloud to achieve their digital transformation targets, while the SMB and startup segment focused on embracing the cloud for greenfield initiatives.\n\n## Cloud Run and Cloud SQL\n\nWhile motivations for enterprise and SMB segments varied, the underlying use case —– deploying web applications to the cloud —– remained the same. Thus, we selected two of the more popular Google Cloud managed services that web applications make use of: [Cloud Run](https://cloud.google.com/run) and [Cloud SQL](https://cloud.google.com/sql).\n\nCloud Run makes it possible to build and deploy scalable containerized apps written in any language (including Go, Python, Java, Node.js, .NET, and Ruby) on a fully managed platform. Meanwhile, Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server with rich extension collections, configuration flags, and developer ecosystems.\n\n## Open source collaboration\n\nGitLab comes with a rich tradition of [open source](/solutions/open-source/). Our partners at Google Cloud understood and complemented that remarkably, which made for a close collaboration between our two teams. We agreed quite early in the process that all capabilities built within Cloud Seed will be open source and, therefore, available for all GitLab users regardless of their market segment, license tier, or any other consideration.\n\n## Preview environments on Cloud Run\n\nThe Cloud Seed private beta was made available to trusted testers in May 2022, and based on the successful beta program, Preview Environments with GitLab and Cloud Run emerged among the most popular use cases.\n\n**Take a look at Preview Environments on GitLab with Cloud Seed:**\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/zDMGCyAgCPY\" title=\"Preview Environments on GitLab with Cloud Seed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nMost Git-based development workflows make use of temporary feature branches. In larger teams and organizations, it is required that feature branches are made available for review and testing.\n\nWith Cloud Seed, a Cloud Run deployment pipeline can be generated in less than two minutes that deploys all feature branches to Cloud Run. Given Cloud Run’s free tier, this can be a cost-effective method to deploy and manage preview environments.\n\n## Relational databases with Cloud SQL\n\nAnother common use case, typically in the app migration scenario, is to set up and migrate relational databases in the cloud. Our beta-test users voted for Cloud SQL as their most popular data storage option among a myriad of Google Cloud services.\n\nWith Cloud Seed, traditional relational databases such as Postgres, MySQL, and SQL Server can be spun up from the GitLab web UI. Similar to the Cloud Run workflow described above, these database instances can be made branch, tag, and environment specific. Alternatively, a GitLab project can be spun up for database operations, where Cloud Seed creates a suitable Cloud SQL instance while the Git repository serves as the host for configuration and migration operations.\n\n## Looking ahead\n\nOur purpose is clear: We learn from our users and customers about their use cases and needs, and we build capabilities to support them through their cloud adoption journeys. We are thrilled to announce the release of Cloud Seed at [Google Cloud Next '22](https://cloud.withgoogle.com/next), and we are even more excited to follow up with our community. Connect with us @OpenCloudSeed on Twitter and try out Cloud Seed today at GitLab.com.\n",[9,832,833],{"slug":1197,"featured":6,"template":685},"accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud","content:en-us:blog:accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud.yml","Accelerate Cloud Adoption With Gitlabs Open Source Partnership With Google Cloud","en-us/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud.yml","en-us/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud",3,[660,690,712,732,753,776,796,816,840],1753799761052]