[{"data":1,"prerenderedAt":2297},["ShallowReactive",2],{"/en-us/blog/categories/product/":3,"navigation-en-us":21,"banner-en-us":433,"footer-en-us":446,"product-category-page-en-us":658},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":9,"_source":17,"_file":18,"_stem":19,"_extension":20},"/en-us/blog/categories/product","categories",false,"",{"title":9,"description":10},"Product","Browse articles related to Product on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","product","content:en-us:blog:categories:product.yml","yaml","content","en-us/blog/categories/product.yml","en-us/blog/categories/product","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":429,"_type":16,"title":430,"_source":17,"_file":431,"_stem":432,"_extension":20},"/shared/en-us/main-navigation","en-us",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":375,"minimal":406,"duo":420},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/","gitlab logo","header",{"text":31,"config":32},"Get free trial",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"Talk to sales",{"href":38,"dataGaName":39,"dataGaLocation":29},"/sales/","sales",{"text":41,"config":42},"Sign in",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,185,190,296,356],{"text":47,"config":48,"cards":50,"footer":73},"Platform",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"The most comprehensive AI-powered DevSecOps Platform",{"text":54,"config":55},"Explore our Platform",{"href":56,"dataGaName":49,"dataGaLocation":29},"/platform/",{"title":58,"description":59,"link":60},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":61,"config":62},"Meet GitLab Duo",{"href":63,"dataGaName":64,"dataGaLocation":29},"/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":69,"config":70},"Learn more",{"href":71,"dataGaName":72,"dataGaLocation":29},"/why-gitlab/","why gitlab",{"title":74,"items":75},"Get started with",[76,81,86],{"text":77,"config":78},"Platform Engineering",{"href":79,"dataGaName":80,"dataGaLocation":29},"/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"Developer Experience",{"href":84,"dataGaName":85,"dataGaLocation":29},"/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/topics/devops/the-role-of-ai-in-devops/",{"text":9,"left":91,"config":92,"link":94,"lists":98,"footer":167},true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":29},"/solutions/",[99,124,146],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":29},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":29,"dataGaName":109},"/solutions/continuous-integration/",{"text":113,"config":114},"AI-Assisted Development",{"href":63,"dataGaLocation":29,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Source Code Management",{"href":119,"dataGaLocation":29,"dataGaName":117},"/solutions/source-code-management/",{"text":121,"config":122},"Automated Software Delivery",{"href":105,"dataGaLocation":29,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Security","Deliver code faster without compromising security",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":29,"icon":131},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,136,141],{"text":134,"config":135},"Security & Compliance",{"href":129,"dataGaLocation":29,"dataGaName":134},{"text":137,"config":138},"Software Supply Chain Security",{"href":139,"dataGaLocation":29,"dataGaName":140},"/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Compliance & Governance",{"href":144,"dataGaLocation":29,"dataGaName":145},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":147,"link":148,"items":153},"Measurement",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":29},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[154,158,162],{"text":155,"config":156},"Visibility & Measurement",{"href":151,"dataGaLocation":29,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Value Stream Management",{"href":161,"dataGaLocation":29,"dataGaName":159},"/solutions/value-stream-management/",{"text":163,"config":164},"Analytics & Insights",{"href":165,"dataGaLocation":29,"dataGaName":166},"/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab for",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":29,"dataGaName":174},"/enterprise/","enterprise",{"text":176,"config":177},"Small Business",{"href":178,"dataGaLocation":29,"dataGaName":179},"/small-business/","small business",{"text":181,"config":182},"Public Sector",{"href":183,"dataGaLocation":29,"dataGaName":184},"/solutions/public-sector/","public sector",{"text":186,"config":187},"Pricing",{"href":188,"dataGaName":189,"dataGaLocation":29,"dataNavLevelOne":189},"/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":283},"Resources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"View all resources",{"href":197,"dataGaName":193,"dataGaLocation":29},"/resources/",[199,232,255],{"title":200,"items":201},"Getting started",[202,207,212,217,222,227],{"text":203,"config":204},"Install",{"href":205,"dataGaName":206,"dataGaLocation":29},"/install/","install",{"text":208,"config":209},"Quick start guides",{"href":210,"dataGaName":211,"dataGaLocation":29},"/get-started/","quick setup checklists",{"text":213,"config":214},"Learn",{"href":215,"dataGaLocation":29,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Product documentation",{"href":220,"dataGaName":221,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best practice videos",{"href":225,"dataGaName":226,"dataGaLocation":29},"/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrations",{"href":230,"dataGaName":231,"dataGaLocation":29},"/integrations/","integrations",{"title":233,"items":234},"Discover",[235,240,245,250],{"text":236,"config":237},"Customer success stories",{"href":238,"dataGaName":239,"dataGaLocation":29},"/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":29},"/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":251,"config":252},"TeamOps",{"href":253,"dataGaName":254,"dataGaLocation":29},"/teamops/","teamops",{"title":256,"items":257},"Connect",[258,263,268,273,278],{"text":259,"config":260},"GitLab Services",{"href":261,"dataGaName":262,"dataGaLocation":29},"/services/","services",{"text":264,"config":265},"Community",{"href":266,"dataGaName":267,"dataGaLocation":29},"/community/","community",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Events",{"href":276,"dataGaName":277,"dataGaLocation":29},"/events/","events",{"text":279,"config":280},"Partners",{"href":281,"dataGaName":282,"dataGaLocation":29},"/partners/","partners",{"backgroundColor":284,"textColor":285,"text":286,"image":287,"link":291},"#2f2a6b","#fff","Insights for the future of software development",{"altText":288,"config":289},"the source promo card",{"src":290},"/images/navigation/the-source-promo-card.svg",{"text":292,"config":293},"Read the latest",{"href":294,"dataGaName":295,"dataGaLocation":29},"/the-source/","the source",{"text":297,"config":298,"lists":300},"Company",{"dataNavLevelOne":299},"company",[301],{"items":302},[303,308,314,316,321,326,331,336,341,346,351],{"text":304,"config":305},"About",{"href":306,"dataGaName":307,"dataGaLocation":29},"/company/","about",{"text":309,"config":310,"footerGa":313},"Jobs",{"href":311,"dataGaName":312,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":312},{"text":274,"config":315},{"href":276,"dataGaName":277,"dataGaLocation":29},{"text":317,"config":318},"Leadership",{"href":319,"dataGaName":320,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":322,"config":323},"Team",{"href":324,"dataGaName":325,"dataGaLocation":29},"/company/team/","team",{"text":327,"config":328},"Handbook",{"href":329,"dataGaName":330,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":332,"config":333},"Investor relations",{"href":334,"dataGaName":335,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":337,"config":338},"Trust Center",{"href":339,"dataGaName":340,"dataGaLocation":29},"/security/","trust center",{"text":342,"config":343},"AI Transparency Center",{"href":344,"dataGaName":345,"dataGaLocation":29},"/ai-transparency-center/","ai transparency center",{"text":347,"config":348},"Newsletter",{"href":349,"dataGaName":350,"dataGaLocation":29},"/company/contact/","newsletter",{"text":352,"config":353},"Press",{"href":354,"dataGaName":355,"dataGaLocation":29},"/press/","press",{"text":357,"config":358,"lists":359},"Contact us",{"dataNavLevelOne":299},[360],{"items":361},[362,365,370],{"text":36,"config":363},{"href":38,"dataGaName":364,"dataGaLocation":29},"talk to sales",{"text":366,"config":367},"Get help",{"href":368,"dataGaName":369,"dataGaLocation":29},"/support/","get help",{"text":371,"config":372},"Customer portal",{"href":373,"dataGaName":374,"dataGaLocation":29},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":376,"login":377,"suggestions":384},"Close",{"text":378,"link":379},"To search repositories and projects, login to",{"text":380,"config":381},"gitlab.com",{"href":43,"dataGaName":382,"dataGaLocation":383},"search login","search",{"text":385,"default":386},"Suggestions",[387,389,393,395,399,403],{"text":58,"config":388},{"href":63,"dataGaName":58,"dataGaLocation":383},{"text":390,"config":391},"Code Suggestions (AI)",{"href":392,"dataGaName":390,"dataGaLocation":383},"/solutions/code-suggestions/",{"text":109,"config":394},{"href":111,"dataGaName":109,"dataGaLocation":383},{"text":396,"config":397},"GitLab on AWS",{"href":398,"dataGaName":396,"dataGaLocation":383},"/partners/technology-partners/aws/",{"text":400,"config":401},"GitLab on Google Cloud",{"href":402,"dataGaName":400,"dataGaLocation":383},"/partners/technology-partners/google-cloud-platform/",{"text":404,"config":405},"Why GitLab?",{"href":71,"dataGaName":404,"dataGaLocation":383},{"freeTrial":407,"mobileIcon":412,"desktopIcon":417},{"text":408,"config":409},"Start free trial",{"href":410,"dataGaName":34,"dataGaLocation":411},"https://gitlab.com/-/trials/new/","nav",{"altText":413,"config":414},"Gitlab Icon",{"src":415,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":413,"config":418},{"src":419,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-type.svg",{"freeTrial":421,"mobileIcon":425,"desktopIcon":427},{"text":422,"config":423},"Learn more about GitLab Duo",{"href":63,"dataGaName":424,"dataGaLocation":411},"gitlab duo",{"altText":413,"config":426},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":428},{"src":419,"dataGaName":416,"dataGaLocation":411},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":434,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"title":435,"titleMobile":435,"button":436,"config":441,"_id":443,"_type":16,"_source":17,"_file":444,"_stem":445,"_extension":20},"/shared/en-us/banner","GitLab 18 & the next step in intelligent DevSecOps.",{"text":437,"config":438},"Watch now",{"href":439,"dataGaName":440,"dataGaLocation":29},"/eighteen/","gitlab 18 banner",{"layout":442},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":447,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":448,"_id":654,"_type":16,"title":655,"_source":17,"_file":656,"_stem":657,"_extension":20},"/shared/en-us/main-footer",{"text":449,"source":450,"edit":456,"contribute":461,"config":466,"items":471,"minimal":646},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":451,"config":452},"View page source",{"href":453,"dataGaName":454,"dataGaLocation":455},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":457,"config":458},"Edit this page",{"href":459,"dataGaName":460,"dataGaLocation":455},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":462,"config":463},"Please contribute",{"href":464,"dataGaName":465,"dataGaLocation":455},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":467,"facebook":468,"youtube":469,"linkedin":470},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[472,495,552,581,616],{"title":47,"links":473,"subMenu":478},[474],{"text":475,"config":476},"DevSecOps platform",{"href":56,"dataGaName":477,"dataGaLocation":455},"devsecops platform",[479],{"title":186,"links":480},[481,485,490],{"text":482,"config":483},"View plans",{"href":188,"dataGaName":484,"dataGaLocation":455},"view plans",{"text":486,"config":487},"Why Premium?",{"href":488,"dataGaName":489,"dataGaLocation":455},"/pricing/premium/","why premium",{"text":491,"config":492},"Why Ultimate?",{"href":493,"dataGaName":494,"dataGaLocation":455},"/pricing/ultimate/","why ultimate",{"title":496,"links":497},"Solutions",[498,503,506,508,513,518,522,525,529,534,536,539,542,547],{"text":499,"config":500},"Digital transformation",{"href":501,"dataGaName":502,"dataGaLocation":455},"/solutions/digital-transformation/","digital transformation",{"text":134,"config":504},{"href":129,"dataGaName":505,"dataGaLocation":455},"security & compliance",{"text":123,"config":507},{"href":105,"dataGaName":106,"dataGaLocation":455},{"text":509,"config":510},"Agile development",{"href":511,"dataGaName":512,"dataGaLocation":455},"/solutions/agile-delivery/","agile delivery",{"text":514,"config":515},"Cloud transformation",{"href":516,"dataGaName":517,"dataGaLocation":455},"/solutions/cloud-native/","cloud transformation",{"text":519,"config":520},"SCM",{"href":119,"dataGaName":521,"dataGaLocation":455},"source code management",{"text":109,"config":523},{"href":111,"dataGaName":524,"dataGaLocation":455},"continuous integration & delivery",{"text":526,"config":527},"Value stream management",{"href":161,"dataGaName":528,"dataGaLocation":455},"value stream management",{"text":530,"config":531},"GitOps",{"href":532,"dataGaName":533,"dataGaLocation":455},"/solutions/gitops/","gitops",{"text":171,"config":535},{"href":173,"dataGaName":174,"dataGaLocation":455},{"text":537,"config":538},"Small business",{"href":178,"dataGaName":179,"dataGaLocation":455},{"text":540,"config":541},"Public sector",{"href":183,"dataGaName":184,"dataGaLocation":455},{"text":543,"config":544},"Education",{"href":545,"dataGaName":546,"dataGaLocation":455},"/solutions/education/","education",{"text":548,"config":549},"Financial services",{"href":550,"dataGaName":551,"dataGaLocation":455},"/solutions/finance/","financial services",{"title":191,"links":553},[554,556,558,560,563,565,567,569,571,573,575,577,579],{"text":203,"config":555},{"href":205,"dataGaName":206,"dataGaLocation":455},{"text":208,"config":557},{"href":210,"dataGaName":211,"dataGaLocation":455},{"text":213,"config":559},{"href":215,"dataGaName":216,"dataGaLocation":455},{"text":218,"config":561},{"href":220,"dataGaName":562,"dataGaLocation":455},"docs",{"text":241,"config":564},{"href":243,"dataGaName":244,"dataGaLocation":455},{"text":236,"config":566},{"href":238,"dataGaName":239,"dataGaLocation":455},{"text":246,"config":568},{"href":248,"dataGaName":249,"dataGaLocation":455},{"text":259,"config":570},{"href":261,"dataGaName":262,"dataGaLocation":455},{"text":251,"config":572},{"href":253,"dataGaName":254,"dataGaLocation":455},{"text":264,"config":574},{"href":266,"dataGaName":267,"dataGaLocation":455},{"text":269,"config":576},{"href":271,"dataGaName":272,"dataGaLocation":455},{"text":274,"config":578},{"href":276,"dataGaName":277,"dataGaLocation":455},{"text":279,"config":580},{"href":281,"dataGaName":282,"dataGaLocation":455},{"title":297,"links":582},[583,585,587,589,591,593,595,600,605,607,609,611],{"text":304,"config":584},{"href":306,"dataGaName":299,"dataGaLocation":455},{"text":309,"config":586},{"href":311,"dataGaName":312,"dataGaLocation":455},{"text":317,"config":588},{"href":319,"dataGaName":320,"dataGaLocation":455},{"text":322,"config":590},{"href":324,"dataGaName":325,"dataGaLocation":455},{"text":327,"config":592},{"href":329,"dataGaName":330,"dataGaLocation":455},{"text":332,"config":594},{"href":334,"dataGaName":335,"dataGaLocation":455},{"text":596,"config":597},"Environmental, social and governance (ESG)",{"href":598,"dataGaName":599,"dataGaLocation":455},"/environmental-social-governance/","environmental, social and governance",{"text":601,"config":602},"Diversity, inclusion and belonging (DIB)",{"href":603,"dataGaName":604,"dataGaLocation":455},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":606},{"href":339,"dataGaName":340,"dataGaLocation":455},{"text":347,"config":608},{"href":349,"dataGaName":350,"dataGaLocation":455},{"text":352,"config":610},{"href":354,"dataGaName":355,"dataGaLocation":455},{"text":612,"config":613},"Modern Slavery Transparency Statement",{"href":614,"dataGaName":615,"dataGaLocation":455},"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":38,"dataGaName":39,"dataGaLocation":455},{"text":366,"config":623},{"href":368,"dataGaName":369,"dataGaLocation":455},{"text":371,"config":625},{"href":373,"dataGaName":374,"dataGaLocation":455},{"text":627,"config":628},"Status",{"href":629,"dataGaName":630,"dataGaLocation":455},"https://status.gitlab.com/","status",{"text":632,"config":633},"Terms of use",{"href":634,"dataGaName":635,"dataGaLocation":455},"/terms/","terms of use",{"text":637,"config":638},"Privacy statement",{"href":639,"dataGaName":640,"dataGaLocation":455},"/privacy/","privacy statement",{"text":642,"config":643},"Cookie preferences",{"dataGaName":644,"dataGaLocation":455,"id":645,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":455},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":455},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":455,"id":645,"isOneTrustButton":91},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"featuredPost":659,"allPosts":680,"totalPages":2295,"initialPosts":2296},{"_path":660,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":661,"content":664,"config":673,"_id":676,"_type":16,"title":677,"_source":17,"_file":678,"_stem":679,"_extension":20},"/en-us/blog/exact-code-search-find-code-faster-across-repositories",{"noIndex":6,"title":662,"description":663},"Exact Code Search: Find code faster across repositories","Discover how this new GitLab feature can find exact matches, use regex patterns, and see contextual results across terabytes of codebases.",{"title":662,"description":663,"authors":665,"heroImage":667,"date":668,"body":669,"category":14,"tags":670},[666],"Dmitry Gruzd","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-06-25","**TL;DR:** What if you could find any line of code across 48 TB of repositories in milliseconds? GitLab's new [Exact Code Search](https://docs.gitlab.com/ee/user/search/exact_code_search.html) makes this possible, delivering pinpoint precision, powerful regex support, and contextual multi-line results that transform how teams work with large codebases.\n## Why traditional code search is challenging\n\nAnyone who works with code knows the frustration of searching across repositories. Whether you're a developer debugging an issue, a DevOps engineer examining configurations, a security analyst searching for vulnerabilities, a technical writer updating documentation, or a manager reviewing implementation, you know exactly what you need, but traditional search tools often fail you.\n\nThese conventional tools return dozens of false positives, lack the context needed to understand results, and slow to a crawl as codebases grow. The result? Valuable time spent hunting for needles in haystacks instead of building, securing, or improving your software.\n\nGitLab's code search functionality has historically been backed by Elasticsearch or OpenSearch. While these are excellent for searching issues, merge requests, comments, and other data containing natural language, they weren't specifically designed for code. After [evaluating numerous options](https://gitlab.com/groups/gitlab-org/-/epics/7404), we developed a better solution.\n\n## Introducing Exact Code Search: Three game-changing capabilities\n\nEnter GitLab's **[Exact Code Search](https://docs.gitlab.com/ee/user/search/exact_code_search.html)**, currently in beta testing and powered by [Zoekt](https://github.com/sourcegraph/zoekt) (pronounced \"zookt\", Dutch for \"search\"). Zoekt is an open-source code search engine originally created by Google and now maintained by Sourcegraph, specifically designed for fast, accurate code search at scale. We've enhanced it with GitLab-specific integrations, enterprise-scale improvements, and seamless permission system integration.\n\nThis feature revolutionizes how you find and understand code with three key capabilities:\n\n**1. Exact Match mode: Zero false positives**\n\nWhen toggled to **Exact Match mode**, the search engine returns only results that match your query exactly as entered, eliminating false positives. This precision is invaluable when:\n\n* Searching for specific error messages\n* Looking for particular function signatures\n* Finding instances of specific variable names\n\n**2. Regular Expression mode: Powerful pattern matching**\n\nFor complex search needs, Regular Expression mode allows you to craft sophisticated search patterns:\n\n* Find functions following specific naming patterns\n* Locate variables matching certain constraints\n* Identify potential security vulnerabilities using pattern matching\n\n**3. Multiple-line matches: See code in context**\n\n![Exact Code Search](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\n\nInstead of seeing just a single line with your matching term, you get the surrounding context that's crucial for understanding the code. This eliminates the need to click through to files for basic comprehension, significantly accelerating your workflow.\n\n## From features to workflows: Real-world use cases and impact\n\nLet's see how these capabilities translate to real productivity gains in everyday development scenarios:\n\n### Debugging: From error message to root cause in seconds\n\nBefore Exact Code Search:\nCopy an error message, search, wade through dozens of partial matches in comments and documentation, click through multiple files, and eventually find the actual code.\n\nWith Exact Code Search:\n\n1. Copy the exact error message\n2. Paste it into Exact Code Search with Exact Match mode\n3. Instantly find the precise location where the error is thrown, with surrounding context\n\n**Impact:** Reduce debugging time from minutes to seconds, eliminating the frustration of false positives.\n\n### Code exploration: Master unfamiliar codebases quickly\n\nBefore Exact Code Search:\nBrowse through directories, make educated guesses about file locations, open dozens of files, and slowly build a mental map of the codebase.\n\nWith Exact Code Search:\n\n* Search for key methods or classes with Exact Match mode\n* Review multiple line matches to understand implementation details\n* Use Regular Expression mode to find similar patterns across the codebase\n\n**Impact:** Build a mental map of code structure in minutes rather than hours, dramatically accelerating onboarding and cross-team collaboration.\n\n### Refactoring with confidence\n\nBefore Exact Code Search:\nAttempt to find all instances of a method, miss some occurrences, and introduce bugs through incomplete refactoring.\n\nWith Exact Code Search:\n\n* Use Exact Match mode to find all occurrences of methods or variables\n* Review context to understand usage patterns\n* Plan your refactoring with complete information about impact\n\n**Impact:** Eliminate the \"missed instance\" bugs that often plague refactoring efforts, improving code quality and reducing rework.\n\n### Security auditing: Finding vulnerable patterns\n\nSecurity teams can:\n\n* Create regex patterns matching known vulnerable code\n* Search across all repositories in a namespace\n* Quickly identify potential security issues with context that helps assess risk\n\n**Impact:** Transform security audits from manual, error-prone processes to systematic, comprehensive reviews.\n\n### Cross-repository insights\n\nSearch across your entire namespace or instance to:\n\n* Identify similar implementations across different projects\n* Discover opportunities for shared libraries or standardization\n\n**Impact:** Break down silos between projects and identify opportunities for code reuse and standardization.\n\n## The technical foundation: How Zoekt delivers speed and precision\n\nBefore diving into our scale achievements, let's explore what makes Zoekt fundamentally different from traditional search engines — and why it can find exact matches so incredibly fast.\n\n### Positional trigrams: The secret to lightning-fast exact matches\n\nZoekt's speed comes from its use of **positional trigrams** — a technique that indexes every sequence of three characters along with their exact positions in files. This approach solves one of the biggest pain points developers have had with Elasticsearch-based code search: false positives.\n\nHere's how it works:\n\n**Traditional full-text search engines** like Elasticsearch tokenize code into words and lose positional information. When you search for `getUserId()`, they might return results containing **user**, **get**, and **Id** scattered throughout a file — leading to those frustrating false positives for GitLab users.\n\n**Zoekt's positional trigrams** maintain exact character sequences and their positions. When you search for `getUserId()`, Zoekt looks for the exact trigrams like **get**, **etU**, **tUs**, **Use**, **ser**, **erI**, **rId**, **Id(\", \"d()**, all in the correct sequence and position. This ensures that only exact matches are returned.\n\nThe result? Search queries that previously returned hundreds of irrelevant results now return only the precise matches you're looking for. This was [one of our most requested features](https://gitlab.com/gitlab-org/gitlab/-/issues/325234) for good reason - developers were losing significant time sifting through false positives.\n\n### Regular expression performance at scale\n\nZoekt excels at exact matches and is optimized for regular expression searches. The engine uses sophisticated algorithms to convert regex patterns into efficient trigram queries when possible, maintaining speed even for complex patterns across terabytes of code.\n\n## Built for enterprise scale\n\nExact Code Search is powerful and built to handle massive scale with impressive performance. This is not just a new UI feature — it's powered by a completely reimagined backend architecture.\n\n### Handling terabytes of code with ease\n\nOn GitLab.com alone, our Exact Code Search infrastructure indexes and searches over **48 TB** of code data while maintaining lightning-fast response times. This scale represents millions of repositories across thousands of namespaces, all searchable within milliseconds. To put this in perspective: This scale represents more code than the entire Linux kernel, Android, and Chromium projects combined. Yet Exact Code Search can find a specific line across this massive codebase in milliseconds.\n\n### Self-registering node architecture\n\nOur innovative implementation features:\n\n* **Automatic node registration:** Zoekt nodes register themselves with GitLab\n* **Dynamic shard assignment:** The system automatically assigns namespaces to nodes\n* **Health monitoring:** Nodes that don't check in are automatically marked offline\n\nThis self-configuring architecture dramatically simplifies scaling. When more capacity is needed, administrators can simply add more nodes without complex reconfiguration.\n\n### Distributed system with intelligent load balancing\n\nBehind the scenes, Exact Code Search operates as a distributed system with these key components:\n\n* **Specialized search nodes:** Purpose-built servers that handle indexing and searching\n* **Smart sharding:** Code is distributed across nodes based on namespaces\n* **Automatic load balancing:** The system intelligently distributes work based on capacity\n* **High availability:** Multiple replicas ensure continuous operation even if nodes fail\n\n*Note: High availability is built into the architecture but not yet fully enabled. See [Issue 514736](https://gitlab.com/gitlab-org/gitlab/-/issues/514736) for updates.*\n\n### Seamless security integration\n\nExact Code Search automatically integrates with GitLab's permission system:\n\n* Search results are filtered based on the user's access rights\n* Only code from projects the user has access to is displayed\n* Security is built into the core architecture, not added as an afterthought\n\n### Optimized performance\n\n* **Efficient indexing:** Large repositories are indexed in tens of seconds\n* **Fast query execution:** Most searches return results with sub-second response times\n* **Streaming results:** The new gRPC-based federated search streams results as they're found\n* **Early termination:** Once enough results are collected, the system pauses searching\n\n## From library to distributed system: Engineering challenges we solved\n\nWhile Zoekt provided the core search technology, it was originally designed as a minimal library for managing `.zoekt` index files - not a distributed database or enterprise-scale service. Here are the key engineering challenges we overcame to make it work at GitLab's scale\"\n\n### Challenge 1: Building a orchestration layer\n\n**The problem:** Zoekt was designed to work with local index files, not distributed across multiple nodes serving many concurrent users.\n\n**Our solution:** We built a comprehensive orchestration layer that:\n\n* Creates and manages database models to track nodes, indices, repositories, and tasks\n* Implements a self-registering node architecture (inspired by GitLab Runner)\n* Handles automatic shard assignment and load balancing across nodes\n* Provides bidirectional API communication between GitLab Rails and Zoekt nodes\n\n### Challenge 2: Scaling storage and indexing\n\n**The problem:** How do you efficiently manage terabytes of index data across multiple nodes while ensuring fast updates?\n\n**Our solution:** We implemented:\n\n* Intelligent sharding: Namespaces are distributed across nodes based on capacity and load\n* Independent replication: Each node independently indexes from [Gitaly](https://gitlab.com/gitlab-org/gitaly) (our Git storage service), eliminating complex synchronization\n* Watermark management: Sophisticated storage allocation that prevents nodes from running out of space\n* Unified binary architecture: A single `gitlab-zoekt` binary that can operate in both indexer and webserver modes\n\n### Challenge 3: Permission Integration\n\n**The problem:** Zoekt had no concept of GitLab's complex permission system - users should only see results from projects they can access.\n\n**Our solution:** We built native permission filtering directly into the search flow:\n\n* Search requests include user permission context\n* Results are filtered to include only those the user can access in case permissions change before indexing completes\n\n### Challenge 4: Operational simplicity\n\n**The problem:** Managing a distributed search system shouldn't require a dedicated team.\n\n**Our solution:**\n\n* Auto-scaling: Adding capacity is as simple as deploying more nodes - they automatically register and start handling work\n* Self-healing: Nodes that don't check in are automatically marked offline and their work redistributed\n* Zero-configuration sharding: The system automatically determines optimal shard assignments\n\n## Gradual rollout: Minimizing risk at scale\n\nRolling out a completely new search backend to millions of users required careful planning. Here's how we minimized customer impact while ensuring reliability:\n\n### Phase 1: Controlled testing (gitlab-org group)\n\nWe started by enabling Exact Code Search only for the `gitlab-org` group - our own internal repositories. This allowed us to:\n\n* Test the system with real production workloads\n* Identify and fix performance bottlenecks\n* Streamline the deployment process\n* Learn from real users' workflows and feedback\n\n### Phase 2: Performance validation and optimization\n\nBefore expanding, we focused on ensuring the system could handle GitLab.com's scale:\n\n* Implemented comprehensive monitoring and alerting\n* Validated storage management with real production data growth\n\n### Phase 3: Incremental customer expansion\n\nWe gradually expanded to customers interested in testing Exact Code Search:\n\n* Gathered feedback on performance and user experience\n* Refined the search UI based on real user workflows\n* Optimized indexing performance (large repositories like `gitlab-org/gitlab` now index in ~10 seconds)\n* Refined the architecture based on operational learnings\n* Massively increased indexing throughput and improved state transition livecycle\n\n### Phase 4: Broad rollout\n\nToday, over 99% of Premium and Ultimate licensed groups on GitLab.com have access to Exact Code Search. Users can:\n\n* Toggle between regex and exact search modes\n* Experience the benefits without any configuration changes\n* Fall back to the previous search if needed (though few choose to)\n\nRolling this out gradually meant users didn't experience service disruptions, performance degradation, or feature gaps during the transition. We've already received positive feedback from users as they notice their results becoming more relevant and faster.\n\n> **For technical deep dive:** Interested in the detailed architecture and implementation? Check out our comprehensive [design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) for in-depth technical details about how we built this distributed search system.\n\n## Getting started with Exact Code Search\n\nGetting started with Exact Code Search is simple because it's already enabled by default for Premium and Ultimate groups on GitLab.com (over 99% of eligible groups currently have access).\n\n### Quickstart guide\n\n1. Navigate to the Advanced Search in your GitLab project or group\n2. Enter your search term in the code tab\n3. Toggle between Exact Match and Regular Expression modes\n4. Use filters to refine your search\n\n### Basic search syntax\n\nWhether using Exact Match or Regular Expression mode, you can refine your search with modifiers:\n\n| Query Example | What It Does                                             |\n| ------------- | -------------------------------------------------------- |\n| `file:js`     | Searches only in files containing \"js\" in their name     |\n| `foo -bar`    | Finds \"foo\" but excludes results with \"bar\"              |\n| `lang:ruby`   | Searches only in Ruby files                              |\n| `sym:process` | Finds \"process\" in symbols (methods, classes, variables) |\n\n> **Pro Tip:** For the most efficient searches, start specific and then broaden if needed. Using `file:` and `lang:` filters dramatically increases relevance.\n\n### Advanced search techniques\n\nStack multiple filters for precision:\n\n```\nis_expected file:rb -file:spec\n```\n\nThis finds \"is_expected\" in Ruby files that don't have \"spec\" in their name.\n\nUse regular expressions for powerful patterns:\n\n```\ntoken.*=.*[\\\"']\n```\n\n[Watch this search performed against the GitLab Zoekt repository.](https://gitlab.com/search?search=token.*%3D.*%5B%5C%22'%5D&nav_source=navbar&project_id=46649240&group_id=9970&search_code=true&repository_ref=main&regex=true)\n\nThe search helps find hardcoded passwords, which, if not found, can be a security issue.\n\nFor more detailed syntax information, check the [Exact Code Search documentation](https://docs.gitlab.com/user/search/exact_code_search/#syntax).\n\n## Availability and deployment\n\n### Current availability\n\nExact Code Search is currently in Beta for GitLab.com users with Premium and Ultimate licenses:\n\n* Available for over 99% of licensed groups\n* Search in the UI automatically uses Zoekt when available, Exact Code Search in Search API is behind a feature flag\n\n### Self-managed deployment options\n\nFor self-managed instances, we offer several deployment methods:\n\n* Kubernetes/Helm: Our most well-supported method, using our [`gitlab-zoekt` Helm chart](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt)\n* Other deployment options: We're working on streamlining deployment for Omnibus and other installation methods\n\nSystem requirements depend on your codebase size, but the architecture is designed to scale horizontally and/or vertically as your needs grow.\n\n## What's coming next\n\nWhile Exact Code Search is already powerful, we're continuously improving it:\n\n* **Scale optimizations** to support instances with hundreds of thousands of repositories\n* **Improved self-managed deployment** options, including streamlined Omnibus support\n* **Full high availability support** with automatic failover and load balancing\n\nStay tuned for updates as we move from Beta to General Availability.\n\n## Transform how you work with code\n\nGitLab's Exact Code Search represents a fundamental rethinking of code discovery. By delivering exact matches, powerful regex support, and contextual results, it solves the most frustrating aspects of code search:\n\n* No more wasting time with irrelevant results\n* No more missing important matches\n* No more clicking through files just to understand basic context\n* No more performance issues as codebases grow\n\nThe impact extends beyond individual productivity:\n\n* **Teams collaborate better** with easy code referencing\n* **Knowledge sharing accelerates** when patterns are discoverable\n* **Onboarding becomes faster** with quick codebase comprehension\n* **Security improves** with effective pattern auditing\n* **Technical debt reduction** becomes more feasible\n\nExact Code Search isn't just a feature, it's a better way to understand and work with code. Stop searching and start finding.\n\n**We'd love to hear from you!** Share your experiences, questions, or feedback about Exact Code Search in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/420920). Your input helps us prioritize improvements and new features.\n\n> #### Ready to experience smarter code search? Learn more in our [documentation](https://docs.gitlab.com/ee/user/search/exact_code_search.html) or try it now by performing a search in your Premium or Ultimate licensed namespaces or projects. Not a GitLab user yet? Try [a free, 60-day trial of GitLab Ultimate with Duo](https://about.gitlab.com/free-trial/)!",[14,671,672],"tutorial","open source",{"featured":6,"template":674,"slug":675},"BlogPost","exact-code-search-find-code-faster-across-repositories","content:en-us:blog:exact-code-search-find-code-faster-across-repositories.yml","Exact Code Search Find Code Faster Across Repositories","en-us/blog/exact-code-search-find-code-faster-across-repositories.yml","en-us/blog/exact-code-search-find-code-faster-across-repositories",[681,700,720,739,760,777,801,823,845,867,887,907,928,948,967,986,1005,1027,1048,1066,1087,1108,1126,1146,1166,1185,1205,1228,1248,1267,1288,1307,1328,1348,1369,1387,1406,1427,1447,1466,1485,1505,1524,1545,1564,1586,1605,1626,1646,1666,1686,1706,1726,1746,1767,1788,1810,1830,1851,1872,1892,1913,1934,1953,1974,1995,2014,2034,2055,2076,2096,2117,2135,2154,2173,2193,2213,2234,2253,2274],{"_path":682,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":683,"content":686,"config":693,"_id":696,"_type":16,"title":697,"_source":17,"_file":698,"_stem":699,"_extension":20},"/en-us/blog/gitlab-patch-release-18-1-1-18-0-3-17-11-5",{"noIndex":91,"title":684,"description":685},"GitLab Patch Release: 18.1.1, 18.0.3, 17.11.5","Learn more about this patch release for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"title":684,"description":685,"authors":687,"heroImage":689,"date":668,"body":690,"category":14,"tags":691},[688]," Rohit Shambhuni","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","Learn more about [this patch release](https://about.gitlab.com/releases/2025/06/25/patch-release-gitlab-18-1-1-released/) for GitLab Community Edition (CE) and Enterprise Edition (EE).",[692],"patch releases",{"featured":6,"template":674,"externalUrl":694,"slug":695},"https://about.gitlab.com/releases/2025/06/25/patch-release-gitlab-18-1-1-released/","gitlab-patch-release-18-1-1-18-0-3-17-11-5","content:en-us:blog:gitlab-patch-release-18-1-1-18-0-3-17-11-5.yml","Gitlab Patch Release 18 1 1 18 0 3 17 11 5","en-us/blog/gitlab-patch-release-18-1-1-18-0-3-17-11-5.yml","en-us/blog/gitlab-patch-release-18-1-1-18-0-3-17-11-5",{"_path":701,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":702,"content":705,"config":714,"_id":716,"_type":16,"title":717,"_source":17,"_file":718,"_stem":719,"_extension":20},"/en-us/blog/reduce-the-load-on-gitlab-gitaly-with-bundle-uri",{"noIndex":6,"title":703,"description":704},"Reduce the load on GitLab Gitaly with bundle URI","Discover what the bundle URI Git feature is, how it is integrated into Gitaly, configuration best practices, and how GitLab users can benefit from it.",{"title":703,"description":704,"heroImage":706,"date":707,"body":708,"category":14,"tags":709,"authors":712},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099013/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2814%29_6VTUA8mUhOZNDaRVNPeKwl_1750099012960.png","2025-06-24","Gitaly plays a vital role in the GitLab ecosystem — it is the server\ncomponent that handles all Git operations. Every push and pull made to/from\na repository is handled by Gitaly, which has direct access to the disk where\nthe actual repositories are stored. As a result, when Gitaly is under heavy\nload, some operations like CI/CD pipelines and browsing a repository in the\nGitLab UI can become quite slow. This is particularly true when serving\nclones and fetches for large and busy monorepos, which can consume large\namounts of CPU and memory.\n\n\n[Bundle URI](https://docs.gitlab.com/administration/gitaly/bundle_uris/) takes significant load off of Gitaly servers during clones by allowing Git to pre-download a bundled repository from object storage before calling the Gitaly servers to fetch the remaining objects.\n\n\nHere is a graph that shows the difference between clones without and with bundle URI.\n\n\n![Graph that shows the difference between clones without and with bundle URI](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750705069/rvbm4ru1w58msd6zv4x7.png)\n\n\nThis graph shows the results of a small test we ran on an isolated GitLab installation, with Gitaly running on a machine with 2 CPUs. We wanted to test bundle URI with a large repository, so we pushed the [GitLab repository](https://gitlab.com/gitlab-org/gitlab) to the instance. We also generated a bundle beforehand.\n\n\nThe big CPU spike is from when we performed a single clone of the GitLab repository with bundle URI disabled. It's quite noticeable. A little later, we turned on bundle URI and launched three concurrent clones of the GitLab repository. Sure enough, turning on bundle URI provides massive performance gain. We can't even distinguish the CPU usage of the three clones from normal usage.\n\n\n## Configure Gitaly to use bundle URI\n\n\nTo enable bundle URI on your GitLab installation, there are a couple of things you need to configure.\n\n\n### Create a cloud bucket\n\n\nBundles need to be stored somewhere. The ideal place is in a cloud storage bucket. Gitaly uses the [gocloud.dev](https://pkg.go.dev/gocloud.dev) library to read and write from cloud storage. Any cloud storage solution supported by this library can be used. Once you have a cloud bucket URL, you can add it in the Gitaly configuration here:\n\n\n```toml\n[bundle_uri]\ngo_cloud_url = \"\u003Cbucket-uri>\"\n```\n\n\nIt must be noted that Gitaly does not manage the lifecycle of the bundles stored in the bucket. To avoid cost issues, object lifecycle policies must be enabled on the bucket in order to delete unused or old objects.\n\n\n### Enable the feature flags\n\n\nThere are two feature flags to enable:\n\n\n- `gitaly_bundle_generation` enables [auto-generation](#auto-generated) of bundles.\n\n\n- `gitaly_bundle_uri` makes Gitaly advertise bundle URIs when they are available (either manually created or auto-generated) and allows the user to [manually](#manual) generate bundles.\n\n\nThese feature flags can be enabled at-large on a GitLab installation, or per repository. See the [documentation on how to enable a GitLab feature behind a feature flag](https://docs.gitlab.com/administration/feature_flags/#how-to-enable-and-disable-features-behind-flags).\n\n\n### How to generate bundles\n\n\nGitaly offers two ways for users to use bundle URI: a [manual](#manual) way and an [auto-generated](#auto-generated) way.\n\n\n#### Manual\n\n\nIt is possible to create a bundle manually by connecting over SSH with the Gitaly node that stores the repository you want to create a bundle for, and run the following command:\n\n```shell\nsudo -u git -- /opt/gitlab/embedded/bin/gitaly bundle-uri \n--config=\u003Cconfig-file>\n--storage=\u003Cstorage-name>\n--repository=\u003Crelative-path>\n```\n\nThis command will create a bundle for the given repository and store it into the bucket configured above. When a subsequent `git clone` request will reach Gitaly for the same repository, the bundle URI mechanism described above will come into play.\n\n\n#### Auto-generated\n\n\nGitaly can also generate bundles automatically, using a heuristic to determine if it is currently handling frequent clones for the same repository.\n\n\nThe current heuristic keeps track of the number of times a `git fetch` request is issued for each repository. If the number of requests reaches a certain `threshold` in a given time `interval`, a bundle is automatically generated. Gitaly also keeps track of the last time it generated a bundle for a repository. When a new bundle should be regenerated, based on the `threshold` and `interval`, Gitaly looks at the last time a bundle was generated for the given repository. It will only generate a new bundle if the existing bundle is older than some `maxBundleAge` configuration. The old bundle is overwritten. There can only be one bundle per repository in cloud storage.\n\n\n## Using bundle URI\n\n\nWhen a bundle exists for a repository, it can be used by the `git clone` command.\n\n\n### Cloning from your terminal\n\n\nTo clone a repository from your terminal, make sure your Git configuration enables bundle URI. The configuration can be set like so:\n\n\n```shell\ngit config --global transfer.bundleuri true\n```\n\nTo verify that bundle URI is used during a clone, you can run the `git clone` command with `GIT_TRACE=1` and see if your bundle is being downloaded:\n```shell\n➜  GIT_TRACE=1 git clone https://gitlab.com/gitlab-org/gitaly\n...\n14:31:42.374912 run-command.c:667       trace: run_command: git-remote-https '\u003Cbundle-uri>'\n...\n```\n\n### Cloning during CI/CD pipelines\n\n\nOne scenario where using bundle URI would be beneficial is during a CI/CD pipeline, where each job needs a copy of the repository in order to run. Cloning a repository during a CI/CD pipeline is the same as cloning a repository from your terminal, except that the Git client in this case is the GitLab Runner. Thus, we need to configure the GitLab Runner in such a way that it can use bundle URI.\n\n\n**1. Update the helper-image**\n\n\nThe first thing to do to configure the GitLab Runner is to [overwrite the helper-image](https://docs.gitlab.com/runner/configuration/advanced-configuration/#override-the-helper-image) that your GitLab Runner instances use. The `helper-image` is the image that is used to run the process of cloning a repository before the job starts. To use bundle URI, the image needs the following:\n\n\n- Git Version 2.49.0 or later\n\n\n- [`GitLab Runner helper`](https://gitlab.com/gitlab-org/gitlab-runner/-/tree/main/apps/gitlab-runner-helper?ref_type=heads) Version 18.1.0 or later\n\n\nThe helper-images can be found [here](https://gitlab.com/gitlab-org/gitlab-runner/container_registry/1472754?orderBy=PUBLISHED_AT&sort=desc&search[]=v18.1.0). Select an image that corresponds to the OS distribution and the architecture you use for your GitLab Runner instances, and verify that the image satisfies the requirements.\n\n\nAt the time of writing, the `alpine-edge-\u003Carch>-v18.1.0*` tag meets all requirements.\n\nYou can validate the image meets all requirements with:\n\n```shell\ndocker run -it \u003Cimage:tag>\n$ git version ## must be 2.49.0 or newer\n$ gitlab-runner-helper -v ## must be 18.0 or newer\n```\n\nIf you do not find an image that meets the requirements, you can also use the helper-image as a base image and install the requirements yourself in a custom-built image that you can host on [GitLab Container Registry](https://docs.gitlab.com/user/packages/container_registry/).\n\n\nOnce you have found the image you need, you must configure your GitLab Runner instances to use it by updating your `config.toml` file:\n\n\n```toml\n[[runners]]\n (...)\n executor = \"docker\"\n [runners.docker]\n    (...)\n    helper_image = \"image:tag\" ## \u003C-- put the image name and tag here\n```\n\n\nOnce the configuration is changed, you must restart the runners for the new configuration to take effect.\n\n\n**2. Turn on the feature flag**\n\n\nNext, you must enable the `FF_USE_GIT_NATIVE_CLONE` [GitLab Runner feature flags](https://docs.gitlab.com/runner/configuration/feature-flags/) in your `.gitlab-ci.yml` file. To do that, simply add it as a variable and set to `true` :\n\n```yaml\nvariables:\n  FF_USE_GIT_NATIVE_CLONE: \"true\"\n```\n\n\nThe `GIT_STRATEGY` must also be [set to `clone`](\u003Chttps://docs.gitlab.com/ci/runners/configure_runners/#git-strategy>), as Git bundle URI only works with `clone` commands.\n\n\n## How bundle URI works\n\n\nWhen a user clones a repository with the `git clone` command, a process called [`git-receive-pack`](https://git-scm.com/docs/git-receive-pack) is launched on the client's machine. This process communicates with the remote repository's server (it can be over HTTP/S, SSH, etc.) and asks to start a [`git-upload-pack`](https://git-scm.com/docs/git-receive-pack) process. Those two processes then exchange information using the Git protocol (it must be noted that bundle URI is only supported with [Git protocol v2](https://git-scm.com/docs/protocol-v2)). The capabilities both processes support and the references and objects the client needs are among the information exchanged. Once the Git server has determined which objects to send to the client, it must package them into a packfile, which, depending on the size of the data it must process, can consume a good amount of resources.\n\n\nWhere does bundle URI fit into this interaction? If bundle URI is advertised as a capability from the `upload-pack` process and the client supports bundle URI, the Git client will ask the server if it knows about any bundle URIs. The server sends those URIs back and the client downloads those bundles.\n\n\nHere is a diagram that shows those interactions:\n\n\n```mermaid\n\nsequenceDiagram\n\n\n    participant receive as Client\n\n\n    participant upload as Server\n\n\n    participant cloud as File server\n\n\n    receive ->> upload: issue git-upload-pack\n\n\n    upload -->> receive: list of server capabilities\n\n\n    opt if bundle URI is advertised as a capability\n\n\n    receive ->> upload: request bundle URI\n\n\n    upload -->> receive: bundle URI\n\n\n    receive ->> cloud: download bundle at URI\n\n\n    cloud -->> receive: bundle file\n\n\n    receive ->> receive: clone from bundle\n\n\n    end\n\n\n    receive ->> upload: requests missing references and objects\n\n\n    upload -->> receive: packfile data\n\n```\n\n\nAs such, Git [bundle URI](https://git-scm.com/docs/bundle-uri) is a mechanism by which, during a `git clone`, a Git server can advertise the URI of a bundle for the repository being cloned by the Git client. When that is the case, the Git client can clone the repository from the bundle and request from the Git server only the missing references or objects that were not part of the bundle. This mechanism really helps to alleviate pressure from the Git server.\n\n\n## Alternatives\n\n\nGitLab also has a feature [Pack-objects cache](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#pack-objects-cache). This feature works slightly differently than bundle URI. When the server packs objects together into a so-called packfile, this feature will keep that file in the cache. When another client needs the same set of objects, it doesn't need to repack them, but it can just send the same packfile again.\n\n\nThe feature is only beneficial when many clients request the exact same set of objects. In a repository that is quick-changing, this feature might not give any improvements. With bundle URI, it doesn't matter if the bundle is slightly out-of-date because the client can request missing objects after downloading the bundle and apply those changes on top. Also bundle URI in Gitaly stores the bundles on external storage, which the Pack-objects Cache stores them on the Gitaly node, so using the latter doesn't reduce network and I/O load on the Gitaly server.\n\n\n## Try bundle URI today\n\n\nYou can try the bundle URI feature in one of the following ways:\n\n\n* Download a [free, 60-day trial version of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n\n* If you already run a self-hosted GitLab installation, upgrade to 18.1.\n\n\n* If you can't upgrade to 18.1 at this time, [download GitLab](https://about.gitlab.com/install/) to a local machine.",[14,710,711],"DevSecOps","git",[713],"Olivier Campeau",{"featured":6,"template":674,"slug":715},"reduce-the-load-on-gitlab-gitaly-with-bundle-uri","content:en-us:blog:reduce-the-load-on-gitlab-gitaly-with-bundle-uri.yml","Reduce The Load On Gitlab Gitaly With Bundle Uri","en-us/blog/reduce-the-load-on-gitlab-gitaly-with-bundle-uri.yml","en-us/blog/reduce-the-load-on-gitlab-gitaly-with-bundle-uri",{"_path":721,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":722,"content":725,"config":733,"_id":735,"_type":16,"title":736,"_source":17,"_file":737,"_stem":738,"_extension":20},"/en-us/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":723,"title":724},"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":724,"description":723,"body":726,"category":14,"tags":727,"authors":728,"heroImage":731,"date":732},"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/).",[282,14,109,710],[729,730],"Mike Flouton","Andy Bradfield","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png","2025-06-23",{"featured":91,"template":674,"slug":734},"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":740,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":741,"content":744,"config":753,"_id":756,"_type":16,"title":757,"_source":17,"_file":758,"_stem":759,"_extension":20},"/en-us/blog/gitlab-18-1-released",{"noIndex":91,"title":742,"description":743},"GitLab 18.1 released","This release includes Maven virtual registry (beta), Duo Code Review, compromised password detection, and SLSA level 1 with components.",{"heroImage":745,"title":742,"description":746,"authors":747,"date":749,"body":750,"category":14,"tags":751},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750333905/erq4ak30f6zxjjcsmt4y.png","This release includes Maven virtual registry (beta), Duo Code Review, compromised password detection, and SLSA Level 1 with components.",[748],"Tim Rizzi","2025-06-19","This is the article for [GitLab 18.1 release](https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/).",[752,14],"releases",{"featured":91,"template":674,"slug":754,"externalUrl":755},"gitlab-18-1-released","https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/","content:en-us:blog:gitlab-18-1-released.yml","Gitlab 18 1 Released","en-us/blog/gitlab-18-1-released.yml","en-us/blog/gitlab-18-1-released",{"_path":761,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":762,"content":764,"config":770,"_id":773,"_type":16,"title":774,"_source":17,"_file":775,"_stem":776,"_extension":20},"/en-us/blog/gitlab-patch-release-18-0-2-17-11-4-17-10-8",{"noIndex":91,"title":763,"description":685},"GitLab Patch Release: 18.0.2, 17.11.4, 17.10.8",{"title":763,"description":685,"authors":765,"heroImage":689,"date":767,"body":768,"category":14,"tags":769},[766],"Costel Maxim","2025-06-11","This is the [patch release for GitLab Community Edition (CE) and Enterprise Edition (EE)](https://about.gitlab.com/releases/2025/06/11/patch-release-gitlab-18-0-2-released/).",[14,692],{"featured":6,"template":674,"externalUrl":771,"slug":772},"https://about.gitlab.com/releases/2025/06/11/patch-release-gitlab-18-0-2-released/","gitlab-patch-release-18-0-2-17-11-4-17-10-8","content:en-us:blog:gitlab-patch-release-18-0-2-17-11-4-17-10-8.yml","Gitlab Patch Release 18 0 2 17 11 4 17 10 8","en-us/blog/gitlab-patch-release-18-0-2-17-11-4-17-10-8.yml","en-us/blog/gitlab-patch-release-18-0-2-17-11-4-17-10-8",{"_path":778,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":779,"content":787,"config":795,"_id":797,"_type":16,"title":798,"_source":17,"_file":799,"_stem":800,"_extension":20},"/en-us/blog/ai-native-gitlab-premium-transform-higher-education-software-development",{"title":780,"description":781,"ogTitle":780,"ogDescription":781,"noIndex":6,"ogImage":782,"ogUrl":783,"ogSiteName":784,"ogType":785,"canonicalUrls":783,"schema":786},"AI-native GitLab Premium: Transform higher education software development","The DevSecOps platform's enterprise-grade features for academic workflows, data protection, and support ensure better collaboration, security, and efficiency.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659537/Blog/Hero%20Images/display-article-image-0679-1800x945-fy26.png","https://about.gitlab.com/blog/ai-native-gitlab-premium-transform-higher-education-software-development","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI-native GitLab Premium: Transform higher education software development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jessica Hurwitz\"},{\"@type\":\"Person\",\"name\":\"Elisabeth Burrows\"}],\n        \"datePublished\": \"2025-06-10\",\n      }",{"title":780,"description":781,"authors":788,"heroImage":782,"date":791,"body":792,"category":14,"tags":793},[789,790],"Jessica Hurwitz","Elisabeth Burrows","2025-06-10","Educational institutions increasingly rely on modern software development practices to support teaching, research, and administrative functions. As development needs grow more complex in university and college environments, GitLab Premium with Duo provides essential capabilities that address the unique challenges faced by higher education – particularly around open source development, remote collaboration, and enterprise-grade security.\n\nGitLab's comprehensive, intelligent DevSecOps platform delivers value that extends far beyond fundamental version control. Built on an open source foundation with enterprise-grade features, GitLab Premium helps prevent costly security incidents involving student data, provides cloud-based development environments for distributed teams, and offers the professional support that educational institutions need for mission-critical systems. And now [Premium includes GitLab Duo AI essentials](https://about.gitlab.com/blog/gitlab-premium-with-duo/) Code Suggestions and Chat at no additional cost.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## The unique development environment in higher education\n\nUniversities and colleges operate in a distinctly challenging technical environment. Development teams must support multidisciplinary collaboration across technical and non-technical departments while managing vast amounts of sensitive data – from student records and financial information to research findings and faculty evaluations.\n\nMost institutions face these challenges with limited IT resources, yet must support thousands of concurrent users across numerous projects and research initiatives. Research integrity requirements add another layer of complexity, as development work often needs to maintain traceability and reproducibility standards.\n\n## Premium solutions for educational institutions\n\nGitLab Premium with Duo has the functionality that higher education needs.\n\n### Enhanced collaboration and workflow capabilities\n\nCross-departmental projects are common in educational settings – from multi-department research initiatives to custom module development for systems like Ellucian Banner, an enterprise resource planning application used by higher education. These complex projects require sophisticated workflow management that goes beyond basic version control. \n\nGitLab Premium addresses these challenges with powerful collaboration and project visualization features, including epics, roadmaps, and advanced Kanban boards for Agile development workflows. When you assign multiple approvers to certain merge requests and protected branches, you ensure higher code quality and accountability across teams. These tools allow institutions to coordinate work across departments while aligning with institution-wide objectives – essential for managing multiphase campus technology initiatives.\n\nIn Australia, [Deakin University’s](https://about.gitlab.com/customers/deakin-university/) enablement team uses GitLab to build standardized processes and reusable templates — such as custom merge request templates, templated build pipelines, and a security and compliance framework — that can be shared with the broader university community and citizen developers, driving innovation and collaboration both inside the university and with key partners. “We were trying to bring in a community of practice and help it thrive for quite some time, but we were never successful until we had this tool,” said Aaron Whitehand, director of Digital Enablement at Deakin University.\n\n> #### Read more about [how Deakin University uses GitLab to drive improvements](https://about.gitlab.com/customers/deakin-university/) in collaboration and productivity, including a 60% reduction in manual tasks.\n\n### Advanced data protection and governance\n\nEducational institutions generate and manage vast amounts of data, ranging from student records and financial information to research findings and faculty evaluations. The security stakes are particularly high. The [2023 MOVEit breach](https://universitybusiness.com/in-just-3-months-this-data-breach-has-compromised-nearly-900-institutions/), which spanned three months and compromised approximately 900 educational institutions, exposed the sensitive information of more than 62 million people. This demonstrates the critical need for proactive security measures integrated directly into higher education development workflows. \n\nVulnerability scanning stops code releases that contain security risks, enabling institutions to establish and enforce governance protocols that protect sensitive information. These capabilities help universities implement proper access controls and permission structures for research databases, creating a secure framework where authorized researchers maintain appropriate access – effectively balancing robust protection with necessary collaboration.\n\nGitLab is built from the ground up to secure your source code. Scalable Git-based repositories, granular access controls, and built-in compliance features eliminate bottlenecks in your workflow while meeting security requirements. GitLab Premium provides audit tracking and compliance capabilities essential for educational environments. Complete audit trails capture detailed logs of all code changes, access attempts, and system modifications with timestamps and user attribution. Full change management documentation ensures traceability of who made what changes, when, and why – critical for research integrity – while access control auditing monitors repository access and permissions changes. \n\n### Cloud-based development environments and remote collaboration\n\nModern educational institutions require flexible development environments that support distributed teams, remote learning scenarios, and diverse technical requirements. GitLab Premium provides:\n\n* **[GitLab Workspaces](https://docs.gitlab.com/user/workspace/):** Cloud-based development environments accessible from any device  \n* **[Web IDE integration](https://docs.gitlab.com/user/project/web_ide/):** Browser-based coding with full GitLab feature integration  \n* **[Container-based development](https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces/):** Consistent, reproducible development environments across different projects and user groups\n\nThese capabilities are particularly valuable for supporting remote and hybrid learning models, enabling students and researchers to access standardized development environments regardless of their physical location or local hardware constraints.\n\n### Professional support for critical systems\n\nSmall IT teams in educational settings often support large, complex infrastructure with minimal resources. Reaching out to user forums for answers doesn't always mean you'll get an accurate reply and isn't efficient for large teams. GitLab Premium includes dedicated professional support, providing faster issue resolution and upgrade assistance during critical periods like class enrollment or research deadlines.\n\nThis minimizes downtime for critical services and ensures continuity of operations during peak usage periods, giving stretched IT departments the enterprise-grade reliability they need for essential academic systems.\n\n### Built on open source with enterprise capabilities\n\nOpen source software is developed collaboratively in a public manner, with source code freely available for anyone to view, modify, and distribute. This development model fosters innovation through community contributions and ensures transparency in how software functions. GitLab's open source foundation resonates strongly with educational institutions' values around collaboration, transparency, and community contribution. GitLab Premium features extend this foundation with enterprise-grade capabilities while maintaining the ability to contribute back to the open source ecosystem.\n\nKey open source advantages include:\n\n* **Transparency:** Complete visibility into platform capabilities and security measures – you can examine exactly how the software works  \n* **Community contribution:** Ability to contribute improvements back to the broader community and benefit from global developer expertise  \n* **Vendor independence:** Reduced lock-in risk with open source alternatives and the freedom to modify code as needed  \n* **Co-creation opportunities:** Collaborative development with the broader community, including other educational institutions, to build shared solutions\n\n### AI assistant for software development tasks\n\nGitLab Premium with [Duo](https://about.gitlab.com/gitlab-duo/) brings powerful AI-native capabilities directly into the development workflow, including:  \n* [**Code Suggestions**](https://docs.gitlab.com/user/project/repository/code_suggestions/), which provides real-time code completion and suggestions, helping developers write code faster and more efficiently  \n* [**Chat**](https://docs.gitlab.com/user/gitlab_duo_chat/), which allows team members to get instant answers to questions, troubleshoot issues, and access documentation directly within the GitLab environment\n\nThese AI tools significantly enhance productivity, reduce errors, and streamline collaboration, making GitLab Premium an even more valuable asset for software development teams in higher education.\n\n### Transparency at the core\n\nHigher education institutions handle incredibly sensitive data — from student records and research findings to proprietary academic work and federal grant information. \n\nThe [GitLab AI Transparency Center ](https://about.gitlab.com/ai-transparency-center/)demonstrates our commitment to transparency, accountability, and protection of customer data and intellectual property, providing the privacy guarantees that educational institutions require.\n\nGitLab launched the AI Transparency Center to help customers, community, and team members better understand how GitLab upholds ethics and transparency in our AI-powered features. \n\nOur publicly available documentation highlights the comprehensive measures we take to protect your institution's data and intellectual property. [GitLab's AI Ethics Principles for Product Development](https://handbook.gitlab.com/handbook/legal/ethics-compliance-program/ai-ethics-principles/) guide us as we continue to build and evolve our AI functionality, helping higher education organizations harness the promise of AI while maintaining complete control and oversight of their most valuable information assets.\n\n## Get started with GitLab Premium today\n\nFor educational institutions, GitLab Premium with Duo represents a strategic technical investment that combines the benefits of open source development with enterprise-grade, AI-native capabilities. By providing professional-grade tools ready for the challenges familiar to the complex technical environment of higher education, GitLab Premium with Duo helps institutions address security vulnerabilities, streamline development workflows, and maintain the reliable infrastructure that academic and research operations depend on.\n\n> [Learn more about GitLab for Public Sector](https://about.gitlab.com/solutions/public-sector/) or  [speak to our sales team today](https://about.gitlab.com/sales/).\n\n## Read more\n\n- [Unlocking AI for every GitLab Premium and Ultimate customer](https://about.gitlab.com/blog/gitlab-premium-with-duo/)\n- [GitLab Duo Code Suggestions](https://docs.gitlab.com/user/project/repository/code_suggestions/)\n- [GitLab Duo Chat](https://docs.gitlab.com/user/gitlab_duo_chat/)",[546,475,14,794,184],"features",{"slug":796,"featured":91,"template":674},"ai-native-gitlab-premium-transform-higher-education-software-development","content:en-us:blog:ai-native-gitlab-premium-transform-higher-education-software-development.yml","Ai Native Gitlab Premium Transform Higher Education Software Development","en-us/blog/ai-native-gitlab-premium-transform-higher-education-software-development.yml","en-us/blog/ai-native-gitlab-premium-transform-higher-education-software-development",{"_path":802,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":803,"content":809,"config":817,"_id":819,"_type":16,"title":820,"_source":17,"_file":821,"_stem":822,"_extension":20},"/en-us/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"title":804,"description":805,"ogTitle":804,"ogDescription":805,"noIndex":6,"ogImage":806,"ogUrl":807,"ogSiteName":784,"ogType":785,"canonicalUrls":807,"schema":808},"4 ways to accelerate embedded development with GitLab","Learn how automated hardware testing, standard builds, collaborative workflows, and integrated compliance eliminate bottlenecks in firmware development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 ways to accelerate embedded development with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt DeLaney\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2025-06-05\",\n      }",{"title":804,"description":805,"authors":810,"heroImage":806,"date":813,"body":814,"category":14,"tags":815},[811,812],"Matt DeLaney","Darwin Sanoy","2025-06-05","Software in embedded systems is no longer just a part number — it's a critical differentiator. This shift has led to enormous complexity in the firmware running in our cars, airplanes, and industrial machines. The number of lines of code in the average car is expected to reach [650 million](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/) by the end of 2025, up from 200 million just five years ago. In aerospace systems, the complexity of embedded software has nearly [doubled every four years](https://www.mckinsey.com/industries/aerospace-and-defense/our-insights/debugging-the-software-talent-gap-in-aerospace-and-defense) for the last several decades. \n\nTraditional embedded development approaches cannot effectively handle the software challenges of modern machines. This shortcoming slows engineers down, in part, by exacerbating challenges such as: \n\n* [Hardware testing bottlenecks](#challenge-1-hardware-testing-bottlenecks) \n* [Inconsistent build environments](#challenge-2-inconsistent-build-environments)\n* [Siloed development practices](#challenge-3-siloed-development-practices)\n* [Manual functional safety compliance processes](#challenge-4-manual-functional-safety-compliance-processes)\n\nEmbedded developers need a new approach to deal with the rapid increase in code. In this article, we’ll explain four ways you can use the GitLab AI-native DevSecOps platform to shorten feedback loops, work collaboratively and iteratively, and streamline compliance.\n\n## Challenge 1: Hardware testing bottlenecks\n\nUnlike enterprise software that can run on virtually any cloud server, embedded automotive software must be tested on specialized hardware that precisely matches production environments. Traditional hardware-in-the-loop (HIL) testing processes often follow this pattern:\n\n1. Developers write code for an embedded system (e.g., an electronic control unit)  \n2. They request access to limited, expensive hardware test benches (costing $500,000-$10M each)  \n3. They wait days or weeks for their scheduled access window  \n4. They manually deploy and test their code on physical hardware at their desks  \n5. They document results, pass the hardware to the next developer, and go to the back of the hardware testing queue\n\nThis process is extremely inefficient. Embedded developers may finish writing their code today and wait weeks to test it on a hardware target. By then, they've moved on to other tasks. This context switching drains productivity. Not only that, developers may wait weeks to learn they had a simple math error in their code. \n\n### Solution: Automated hardware allocation and continuous integration\n\nYou can streamline hardware testing through automation using the [GitLab On-Premises Device Cloud](https://gitlab.com/guided-explorations/embedded/ci-components/device-cloud), a CI/CD component. This lets you automate the orchestration of scarce hardware resources, turning a manual, time-intensive process into a streamlined, continuous workflow.\n\nThe On-Premises Device Cloud:\n\n1. Creates pools of shared hardware resources  \n2. Automatically — and exclusively — allocates hardware to a developer’s hardware testing pipeline tasks based on availability  \n3. Deploys and executes tests without manual intervention  \n4. Collects and reports results through integrated pipelines  \n5. Automatically deallocates hardware back into the “available” pool\n\nAfter submitting code, you’ll receive results in hours instead of days, often without ever physically touching the test hardware.\n\nWhat this video for an introduction to the GitLab On-Premises Device Cloud CI/CD Component to orchestrate the remote allocation of shared hardware for HIL:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ltr2CIM9Zag?si=NOij3t1YYz4zKajC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nYou can also adopt multi-pronged testing strategies that balance speed and quality. Bring the following embedded test patterns and environments into automated GitLab CI pipelines:\n\n* **Software-in-the-loop (SIL):** Testing on virtual hardware simulators for quicker initial feedback  \n* **Processor-in-the-loop (PIL):** Testing on representative processor hardware for faster feedback at a lower cost  \n* **Hardware-in-the-loop (HIL):** Testing on full production-equivalent hardware and test benches for late-stage verification\n\nBy automating the orchestration of these tests within CI pipelines, you’ll be able to identify issues earlier, iterate faster, and accelerate time to market.\n\n## Challenge 2: Inconsistent build environments\n\nAnother significant challenge in embedded development is build environment inconsistency. Embedded developers often manually execute builds on their local machines with varying configurations, compiler versions, and dependencies. Then they’ll paste the binaries from their local build to a shared codebase.\n\nThis approach creates several problems:\n\n* **Inconsistent outputs:** Builds for the same source code produce different results on different machines  \n* **\"Works on my machine\" syndrome:** Code that builds locally fails in shared environments  \n* **Poor traceability:** Limited audit trail of who built what and when  \n* **Knowledge silos:** Build expertise becomes concentrated in a few individuals\n\nThis approach can lead to errors, bottlenecks, and costly delays. \n\n### Solution: Standardized build automation\n\nYou can address these challenges by implementing standardized build automation within CI/CD pipelines in GitLab. This approach creates consistent, repeatable, container-based build environments that eliminate machine-specific variations. Through the use of special Embedded Gateway Runner provisioning scripts, containers can interface with hardware for flashing and port monitoring for automated testing.\n\nKey elements of this solution include:\n\n* **Lifecycle managed environments:** Define complex embedded simulation environments as code; automatically deploy environments for testing and destroy them afterward  \n* **Containerization:** Use Docker containers to ensure identical build environments  \n* **Automated dependency management:** Control and version all dependencies  \n* **Central build execution:** Run builds on shared infrastructure rather than local machines\n\n> Follow this tutorial to learn [how to automate embedded software builds within a GitLab CI pipeline](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci/-/blob/main/TUTORIAL2.md%20).\n\nBy standardizing and automating the build process, you can ensure that every build follows the same steps with the same dependencies, producing consistent outputs regardless of who initiated it. This not only improves quality but also democratizes the build process, enabling more team members to participate without specialized knowledge.\n\n## Challenge 3: Siloed development practices\n\nEnterprise development teams have widely adopted collaborative practices such as DevOps, underpinned by shared source code management (SCM) and continuous integration/continuous delivery (CI/CD) systems. Embedded developers, on the other hand, have historically worked alone at their desks. There are valid technical reasons for this. \n\nFor example, consider hardware virtualization, which is a key enabler of DevOps automation. The industry has been slower to virtualize the massive range of specialized processors and boards used in embedded systems. This is due in large part to the difficulties of virtualizing production real-time systems and the associated lack of economic incentives. Compare that to cloud virtualization which has been commoditized and benefited enterprise SaaS development for over a decade.\n\nMany providers are now embracing virtualization-first for the sake of speeding up embedded development. If teams fail to adopt virtual testing options, however, their silos will remain and negatively impact the business through: \n\n* **Knowledge fragmentation**: Critical insights remain scattered across individuals and teams  \n* **Redundant development**: Multiple teams solve identical problems, creating inconsistencies  \n* **Late-stage discovery during big-bang integrations**: Problems are found late in the process when multiple developers integrate their code at once, when errors are more costly to fix  \n* **Stifled innovation**: Solutions from one domain rarely influence others, hampering the development of new product ideas\n\n### Solution: Collaborative engineering through a unified platform\n\nAn important step in breaking down these silos is to standardize embedded development around GitLab’s unified DevSecOps platform. In this regard, GitLab is aligned with the shift of embedded systems toward more consolidated, shared platforms on embedded devices. GitLab enables:\n\n* **Shared visibility:** Make all code, Issues, and documentation visible across teams  \n* **Collaborative workflows:** Enable peer review and knowledge sharing through merge requests  \n* **Centralized knowledge:** Maintain a single source of truth for all development artifacts  \n* **Asynchronous collaboration:** Allow teams to work together across different locations and time zones\n\nHuman-AI agent collaboration is a fundamental ingredient to fueling the customer-facing innovations that digital natives and established embedded brands desire. GitLab enables human-AI collaboration as well. By creating transparency across the development lifecycle, GitLab changes embedded development from an isolated activity to a collaborative practice. Engineers can see each other's work in progress, learn from collective experiences, and build upon shared solutions.\n\nWatch this presentation from Embedded World Germany 2025, which explains the power of embedded developers collaborating and sharing “work in progress”. The demo portion from 24:42 to 36:51 shows how to integrate HIL into a GitLab CI pipeline and enable collaborative development.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/F_rlOyq0hzc?si=eF4alDY6HK98uZPj\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nPerhaps most importantly, by achieving greater collaboration through DevSecOps, teams can unlock embedded systems innovations that would otherwise remain hidden. Indeed, collaboration fuels innovation. [One study](https://www.sciencedirect.com/science/article/abs/pii/S0749597800928887), for example, found that group brainstorming, when properly structured, can lead to more innovative and creative outcomes than individuals working alone. Collaborative development is crucial in the race to develop software-defined products. \n\n## Challenge 4: Manual functional safety compliance processes\n\nEmbedded systems in the automotive and aerospace industries must comply with rigorous functional safety standards, including ISO 26262, MISRA C/C++, DO-178C, and DO-254. Traditional compliance approaches involve manual reviews, extensive documentation, and separate verification activities that occur late in the development cycle. This often creates security review bottlenecks. When specialized embedded security and code quality scanners detect vulnerabilities in a developer’s code, the scan issue gets added to a pile of other issues that haven’t been resolved. Developers can’t integrate their code, and security personnel need to wade through a backlog of code violations. This creates delays and makes compliance more difficult. \n\nSome of the challenges can best be summed up as: \n\n* **Late-stage compliance issues**: Problems discovered after development is complete  \n* **Documentation burden**: Extensive manual effort to create and maintain compliance evidence  \n* **Process bottlenecks**: Serial compliance activities that block development progress  \n* **Expertise dependence**: Reliance on limited specialists for compliance activities\n\nAs a result, teams often need to choose between velocity and compliance — a precarious trade-off in safety-critical systems.\n\n### Solution: Automated functional safety compliance workflow building blocks\n\nRather than treating security and compliance as post-development verification activities, you can codify compliance requirements and enforce them automatically through [customizable frameworks in GitLab](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/). To do this for functional safety standards, in particular, you can integrate GitLab with specialized embedded tools, which provide the depth of firmware scanning required by functional safety standards. Meanwhile, GitLab provides automated compliance checks, full audit trails, and merge request gating — all features needed to support a robust continuous compliance program. \n\nThis integrated approach includes:\n\n* **Compliance-as-code:** Define compliance requirements as automated checks  \n* **Integrated specialized tools:** Connect tools like CodeSonar into the DevSecOps platform for automotive-specific compliance  \n* **Continuous compliance verification:** Verify requirements throughout development  \n* **Automated evidence collection:** Gather compliance artifacts as a by-product of development\n\nWatch this video to learn how to use Custom Compliance Frameworks in GitLab to create your own compliance policies. You can create compliance policies related to any standard (e.g., ISO 26262) and automatically enforce those policies in GitLab.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/S-FQjzSyVJw?si=0UdtGNuugLPG0SLL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nBy shifting compliance left and embedding it within normal development workflows, you can maintain safety standards without sacrificing velocity. Automated checks catch issues early when they're easier and less expensive to fix, while continuous evidence collection reduces the documentation burden.\n\n## Realizing the power of embedded DevOps\n\nEmbedded development is changing fast. Teams that remain stuck in manual processes and isolated workflows will find themselves increasingly left behind, while those that embrace automated, collaborative practices will define the future of software-defined smart systems.\n\nExplore our [Embedded DevOps Workshop](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci) to start automating embedded development workflows with GitLab, or [watch this presentation from GitLab's Field Chief Cloud Architect](https://content.gitlab.com/viewer/0a35252831bd130f879b0725738f70ed) to learn how leading organizations are bringing hardware-in-the-loop testing into continuous integration workflows to accelerate embedded development.\n\n## Learn more\n\n- [Why GitLab Premium with Duo for embedded systems development?](https://content.gitlab.com/viewer/438451cba726dd017da7b95fd0fb1b59)\n- [Why GitLab Ultimate with Duo for embedded systems development?](https://content.gitlab.com/viewer/87f5104c26720e2c0d73a6b377522a44)\n- [More embedded development systems presentations from GitLab](https://content.gitlab.com/viewer/e59c40099d5e3c8f9307afb27c4a923f)",[475,671,794,816],"embedded DevOps",{"slug":818,"featured":6,"template":674},"4-ways-to-accelerate-embedded-development-with-gitlab","content:en-us:blog:4-ways-to-accelerate-embedded-development-with-gitlab.yml","4 Ways To Accelerate Embedded Development With Gitlab","en-us/blog/4-ways-to-accelerate-embedded-development-with-gitlab.yml","en-us/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"_path":824,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":825,"content":831,"config":839,"_id":841,"_type":16,"title":842,"_source":17,"_file":843,"_stem":844,"_extension":20},"/en-us/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"title":826,"description":827,"ogTitle":826,"ogDescription":827,"noIndex":6,"ogImage":828,"ogUrl":829,"ogSiteName":784,"ogType":785,"canonicalUrls":829,"schema":830},"GitLab named a Leader in The Forrester Wave™: DevOps Platforms, Q2 2025","Forrester calls GitLab platform the \"most all-in-one of the all-in-one solutions,\" adding it \"suits enterprises looking to standardize with a single purchase.\"","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named a Leader in The Forrester Wave™: DevOps Platforms, Q2 2025\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2025-06-02\",\n      }",{"title":826,"description":827,"authors":832,"heroImage":828,"date":834,"body":835,"category":14,"tags":836},[833],"Dave Steer","2025-06-02","Choosing a DevSecOps platform is one of the biggest technology decisions enterprises make. That's why we are thrilled to be named a [**Leader in The Forrester Wave™: DevOps Platforms, Q2 2025**](https://about.gitlab.com/forrester-wave-devops-platform/), receiving the highest scores possible across the criteria our customers tell us they care about most, including day zero experience, developer tooling, build automation and CI, deployment automation, AI risk mitigation, AI infusion, directly incorporated security tools, and platform cohesion.\n\n***\"GitLab is the most all-in-one of the all-in-one solutions and suits enterprises looking to standardize with a single purchase.” -*** Forrester Wave™: DevOps Platforms, Q2 2025\n\nFor us, this recognition reflects what we've been hearing from customers: They need to deliver secure software faster, but existing solutions force them to compromise on speed, security, or simplicity. GitLab delivers all three. And with our [GitLab 18.0 release](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) in May, we’ve taken this a step further by [including AI-native GitLab Duo capabilities](https://about.gitlab.com/blog/gitlab-premium-with-duo/) — such as test generation, code suggestions, and code refactoring — directly in GitLab Premium and GitLab Ultimate at no additional cost.\n\n> [Access the report today!](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n![ Forrester Wave™: DevOps Platforms, Q2 2025 graphic ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## Staying at the forefront of AI transformation, with enterprise control\n\nDevSecOps is rapidly evolving, with AI at the forefront of that change. Unfortunately, many AI tools force a choice: cutting-edge capabilities or enterprise security. \n\nForrester scored GitLab a 5 – the highest on their scale – for both the **AI infusion** and **AI risk mitigation** criteria. We’re pleased to see our focus on building innovative AI capabilities that maintain security is being noticed by more than just our customers.\n\nThis dual strength shows up across our GitLab Duo AI offerings, including:\n\n* Duo Workflow (private beta): Autonomous AI agents that handle complex tasks across development, security, and operations — with enterprise-grade guardrails and audit trails.  \n* Agentic Chat: Contextual, conversational AI assistance for everything from code explanations to test creation — with IP protection and privacy controls built in.  \n* Code Suggestions: AI assistance that can predictively complete code blocks, define function logic, generate tests, and propose common code like regex patterns.  \n* AI-native Vulnerability Resolution: Find and fix vulnerabilities with auto explanation and auto-generated merge requests, ensuring a streamlined development process.\n\n## Doing more with less \n\nWe’ve heard loud and clear that DevSecOps teams don’t need more tools and integrations that help them with part of their software delivery lifecycle. They need a seamless, integrated developer experience that covers the entire SDLC.\n\nWe believe GitLab’s scores in the following criteria are validation of our customer-focused strategy:\n\n* **Day zero experience:** Forrester cited our “strong day zero experience,” noting that “everything is ready to run out-of-the-box,” supported by extensive migration tools and tutorials. \n* **Developer tooling:** Forrester pointed to [GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), our agentic AI offering for AWS customers, as well as our cloud development environment, integrated developer platform, and wikis for documentation as examples.  \n* **Project planning and alignment:** Forrester noted our \"strong compliance center,\" and that we have tools to drive alignment top-down and bottom-up.  \n* **Pipeline security:** Forrester gave us the highest score possible in the pipeline security criterion.  \n* **Build automation and CI:** Forrester cited our build automation and CI with multistage build pipelines and strong self-hosted support.\n\n## Read the report\n\nFor us, being named a Leader in The Forrester Wave™: DevOps Platforms, Q2 2025 speaks to the breadth and depth of our platform’s capabilities, providing a single source of truth for the entire software development lifecycle. No more juggling multiple tools and integrations – GitLab provides a seamless, integrated experience that boosts productivity and reduces friction. We believe this placement reflects the hard work of our team, the many contributions from GitLab’s open source community, the invaluable feedback from our customers, and our dedication to shaping the future of software development.\n\n> #### [Access the report today!](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n*Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. For more information, read about Forrester’s objectivity [here](https://www.forrester.com/about-us/objectivity/).*",[837,14,838,475],"research","news",{"slug":840,"featured":91,"template":674},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","content:en-us:blog:gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","Gitlab Named A Leader In The Forrester Wave Devops Platforms Q2 2025","en-us/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","en-us/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"_path":846,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":847,"content":853,"config":861,"_id":863,"_type":16,"title":864,"_source":17,"_file":865,"_stem":866,"_extension":20},"/en-us/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"title":848,"description":849,"ogTitle":848,"ogDescription":849,"noIndex":6,"ogImage":850,"ogUrl":851,"ogSiteName":784,"ogType":785,"canonicalUrls":851,"schema":852},"Getting started with GitLab: Working with CI/CD variables","Learn what CI/CD variables are, why they are important in DevSecOps, and best practices for utilizing them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659525/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25.png","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with GitLab: Working with CI/CD variables\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2025-05-27\",\n      }",{"title":848,"description":849,"authors":854,"heroImage":850,"date":856,"body":857,"category":14,"tags":858},[855],"GitLab Team","2025-05-27","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nIn an earlier article, we explored [GitLab CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/). Now, let's dive deeper into the world of **CI/CD variables** and unlock their full potential.\n\n### What are CI/CD variables?\n\nCI/CD variables are dynamic key-value pairs that you can define at different levels within your GitLab environment (e.g., project, group, or instance). These variables act as placeholders for values that you can use in your `.gitlab-ci.yml` file to customize your pipelines, securely store sensitive information, and make your CI/CD configuration more maintainable.\n\n### Why are CI/CD variables important?\n\nCI/CD variables offer numerous benefits:\n\n* **Flexibility** - Easily adapt your pipelines to different environments, configurations, or deployment targets without modifying your core CI/CD script.  \n* **Security** - Securely store sensitive information like API keys, passwords, and tokens, preventing them from being exposed directly in your code.  \n* **Maintainability** - Keep your CI/CD configuration clean and organized by centralizing values in variables, making updates and modifications easier.  \n* **Reusability** - Define variables once and reuse them across multiple projects, promoting consistency and reducing duplication.\n\n### Scopes of CI/CD variables: Project, group, and instance\n\nGitLab allows you to define CI/CD variables with different scopes, controlling their visibility and accessibility:\n\n* **Project-level variables** - These variables are specific to a single project and are ideal for storing project-specific settings, such as:\n  * Deployment URLs: Define different URLs for staging and production environments.  \n  * Database credentials: Store database connection details for testing or deployment.  \n  * Feature flags: Enable or disable features during different stages of your pipeline.  \n  * Example: You have a project called \"MyWebApp\" and want to store the production deployment URL. You create a project-level variable named `DPROD_DEPLOY_URL` with the value `https://mywebapp.com`.  \n* **Group-level variables** - These variables are shared across all projects within a GitLab group. They are useful for settings that are common to multiple projects, such as:\n\n  * API keys for shared services: Store API keys for services like AWS, Google Cloud, or Docker Hub that are used by multiple projects within the group.  \n  * Global configuration settings: Define common configuration parameters that apply to all projects in the group.  \n  * Example: You have a group called \"Web Apps\" and want to store an API key for Docker Hub. You create a group-level variable named `DOCKER_HUB_API_KEY` with the corresponding API key value.  \n* **Instance-level variables** - These variables are available to all projects on a GitLab instance. They are typically used for global settings that apply across an entire organization such as:\n\n  * Default runner registration token: Provide a default token for registering new [runners](https://docs.gitlab.com/runner/).  \n  * License information: Store license keys for GitLab features or third-party tools.  \n  * Global environment settings: Define environment variables that should be available to all projects.  \n  * Example: You want to set a default Docker image for all projects on your GitLab instance. You create an instance-level variable named `DEFAULT_DOCKER_IMAGE` with the value `ubuntu:latest`.\n\n### Defining CI/CD variables\n\nTo define a CI/CD variable:\n\n1. Click on the **Settings > CI/CD** buttons for  your project, group, or instance.  \n2. Go to the **Variables** section.  \n3. Click **Add variable**.  \n4. Enter the **key** (e.g., `API_KEY`) and **value**.  \n5. Optionally, check the **Protect variable** box for sensitive information. This ensures that the variable is only available to pipelines running on protected branches or tags.  \n6. Optionally, check the **Mask variable** box to hide the variable's value from job logs, preventing accidental exposure.  \n7. Click **Save variable**.\n\n### Using CI/CD variables\n\nTo use a CI/CD variable in your `.gitlab-ci.yml` file, simply prefix the variable name with `$`:\n\n```yaml\ndeploy_job:\n  script:\n    - echo \"Deploying to production...\"\n    - curl -H \"Authorization: Bearer $API_KEY\" https://api.example.com/deploy\n```\n\n### Predefined CI/CD variables\n\nGitLab provides a set of [predefined CI/CD variables](https://docs.gitlab.com/ci/variables/predefined_variables/) that you can use in your pipelines. These variables provide information about the current pipeline, job, project, and more.\n\nSome commonly used predefined variables include:\n\n* `$CI_COMMIT_SHA`: The commit SHA of the current pipeline.  \n* `$CI_PROJECT_DIR`: The directory where the project is cloned.  \n* `$CI_PIPELINE_ID`: The ID of the current pipeline.  \n* `$CI_ENVIRONMENT_NAME`: The name of the environment being deployed to (if applicable).\n\n### Best practices\n\n* Securely manage sensitive variables: Use protected and masked variables for API keys, passwords, and other sensitive information.  \n* Avoid hardcoding values: Use variables to store configuration values, making your pipelines more flexible and maintainable.  \n* Organize your variables: Use descriptive names and group related variables together for better organization.  \n* Use the appropriate scope: Choose the correct scope (project, group, or instance) for your variables based on their intended use and visibility.\n\n### Unlock the power of variables\n\nCI/CD variables are a powerful tool for customizing and securing your GitLab pipelines. By mastering variables and understanding their different scopes, you can create more flexible, maintainable, and efficient workflows.\n\nWe hope you found it helpful and are now well-equipped to leverage the power of GitLab for your development projects.\n\n> Get started with CI/CD variables today with a [free, 60-day trial of GitLab Ultimate with Duo Enterprise](https://about.gitlab.com/free-trial/).\n\n## \"Getting Started with GitLab\" series\nRead more articles in our \"Getting Started with GitLab\" series:\n\n- [How to manage users](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n-  [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Mastering project management](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automating Agile workflows with the gitlab-triage gem](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Understanding CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)\n",[14,671,859,860,109,794],"CI","CD",{"slug":862,"featured":91,"template":674},"getting-started-with-gitlab-working-with-ci-cd-variables","content:en-us:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","en-us/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","en-us/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":868,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":869,"content":874,"config":880,"_id":883,"_type":16,"title":884,"_source":17,"_file":885,"_stem":886,"_extension":20},"/en-us/blog/gitlab-patch-release-18-0-1-17-11-3-17-10-7",{"title":870,"description":871,"ogTitle":870,"ogDescription":871,"noIndex":91,"ogImage":689,"ogUrl":872,"ogSiteName":784,"ogType":785,"canonicalUrls":872,"schema":873},"GitLab Patch Release: 18.0.1, 17.11.3, 17.10.7","Learn more about this critical patch for GitLab Community Edition and Enterprise Edition.","https://about.gitlab.com/blog/gitlab-patch-release-18-0-1-17-11-3-17-10-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 18.0.1, 17.11.3, 17.10.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\" Rohit Shambhuni\"}],\n        \"datePublished\": \"2025-05-21\",\n      }",{"title":870,"description":871,"authors":875,"heroImage":689,"date":876,"body":877,"category":14,"tags":878},[688],"2025-05-21","This is the post for the [GitLab Patch Release: 18.0.1, 17.11.3, 17.10.7](https://about.gitlab.com/releases/2025/05/21/patch-release-gitlab-18-0-1-released/).\n",[879,692],"security releases",{"slug":881,"featured":6,"template":674,"externalUrl":882},"gitlab-patch-release-18-0-1-17-11-3-17-10-7","https://about.gitlab.com/releases/2025/05/21/patch-release-gitlab-18-0-1-released/","content:en-us:blog:gitlab-patch-release-18-0-1-17-11-3-17-10-7.yml","Gitlab Patch Release 18 0 1 17 11 3 17 10 7","en-us/blog/gitlab-patch-release-18-0-1-17-11-3-17-10-7.yml","en-us/blog/gitlab-patch-release-18-0-1-17-11-3-17-10-7",{"_path":888,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":889,"content":895,"config":901,"_id":903,"_type":16,"title":904,"_source":17,"_file":905,"_stem":906,"_extension":20},"/en-us/blog/gitlab-dedicated-for-government-now-fedramp-authorized",{"title":890,"description":891,"ogTitle":890,"ogDescription":891,"noIndex":6,"ogImage":892,"ogUrl":893,"ogSiteName":784,"ogType":785,"canonicalUrls":893,"schema":894},"GitLab Dedicated for Government now FedRAMP-authorized","Learn how our single-tenant SaaS solution empowers public sector customers to securely accelerate their modernization initiatives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662023/Blog/Hero%20Images/display-dedicated-for-government-article-image-0679-1800x945-fy26.png","https://about.gitlab.com/blog/gitlab-dedicated-for-government-now-fedramp-authorized","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Dedicated for Government now FedRAMP-authorized\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Deepa Mahalingam\"},{\"@type\":\"Person\",\"name\":\"Elisabeth Burrows\"}],\n        \"datePublished\": \"2025-05-19\",\n      }",{"title":890,"description":891,"authors":896,"heroImage":892,"date":898,"body":899,"category":14,"tags":900},[897,790],"Deepa Mahalingam","2025-05-19","We're excited to announce that GitLab Dedicated for Government has achieved FedRAMP Authorization at the Moderate Impact Level, marking a significant milestone in our commitment to serving public sector organizations. GitLab Dedicated for Government is now listed as \"Authorized\" on the [FedRAMP Marketplace](https://marketplace.fedramp.gov/products/FR2411959145). Our single-tenant solution provides all the benefits of an enterprise DevSecOps platform with enhanced data residency, isolation, and private networking capabilities to meet the most stringent compliance requirements. GitLab Dedicated for Government provides the flexibility and scalability of a SaaS solution, enabling government agencies to modernize and secure their software supply chain from code to cloud. \n\nThe [Federal Risk and Authorization Management Program](https://www.fedramp.gov/) (FedRAMP) is the gold standard for cloud security across US government agencies. As a mandatory security framework for federal cloud adoption since its 2011 launch, it provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. \n\n## Meeting the growing demand for secure cloud solutions\n\nAs more public sector organizations move away from costly legacy systems and migrate their mission-critical workloads to the cloud, cloud-native development and multi-cloud adoption will grow significantly. At GitLab, we serve a wide variety of customers in the public sector – from federally-funded research and development centers, service providers, and contractors working on behalf of the government, to the largest government agencies across the globe. We understand that no single deployment model will serve the needs of all of our customers. \n\nOur customers have told us they need a SaaS offering that provides additional deployment control and data residency to meet stringent compliance requirements. We see this need with large enterprises and companies in regulated industries that are coming under increased scrutiny, facing global internet policy fragmentation, and dealing with the expanding complexity of data governance. GitLab has consistently observed that security is a top priority for organizations and our [2024 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) showed that this trend continued, with security remaining the primary investment area.\n\nGitLab Dedicated for Government was specifically designed to address these needs – enabling organizations to accelerate their digital transformation initiatives with confidence.\n\n## Key benefits of GitLab Dedicated for Government\n\n**1. Toolchain consolidation**\n\nToolchain management continues to be a significant challenge for DevSecOps teams. According to our 2024 Global DevSecOps Survey, 64% of respondents expressed the need to consolidate their toolchains, with security professionals particularly affected – 63% reported using six or more tools.\n\nThis proliferation of tools results in unnecessary expenditure and introduces complexities and vulnerabilities that increase the risk of cyber attacks. GitLab Dedicated for Government unites DevSecOps teams on a single platform with a unified workflow, eliminating the need to purchase or maintain multiple tools. Organizations can strengthen security, improve efficiency, and accelerate collaboration by consolidating their complex toolchains. Additionally, consolidation supports zero trust architecture implementation by centralizing access control, making it easier to enforce consistent security policies and authentication requirements across the entire development lifecycle. GitLab also enables flexibility by allowing you to utilize existing critical tools through our integration capabilities.\n\n**2. Data residency and protection**\n\nGitLab Dedicated for Government is built on FedRAMP-authorized infrastructure that meets U.S. data sovereignty requirements, including access restricted to U.S. citizens. To further enhance data protection, our solution supports secure, private connections between the customer's virtual private cloud network and GitLab, ensuring users, data, and services have secure access to isolated instances without direct internet exposure. All data is [encrypted at rest](https://docs.gitlab.com/subscriptions/gitlab\\_dedicated/\\#data-encryption) and in transit using the latest encryption standards, with the option to use your own AWS Key Management Service encryption key for data at rest, giving you full control over stored data. GitLab Dedicated for Government also ensures CVEs are patched continuously. It is an ideal platform for teams to build a centralized DevSecOps platform while offboarding compliance burdens to GitLab.\n\n**3. Managed and hosted by GitLab**\n\nOur solution is single-tenant (providing physical isolation from other customers), U.S.-based, privately connected, and fully managed and hosted by GitLab. Organizations can quickly realize the value of a comprehensive DevSecOps platform with the advanced flexibility and customization of a self-managed instance – without requiring staff to build and manage infrastructure.\n\nThis approach delivers all the benefits of GitLab – shorter cycle times, lower costs, stronger security, and more productive developers – with a lower total cost of ownership and quicker time-to-value compared to self-hosting.\n\n**4. Comprehensive native security capabilities**\n\nOur 2024 Global DevSecOps Survey revealed that 60% of public sector security professionals report vulnerabilities are mostly discovered after code is merged into test environments, and only 51% consider their DevSecOps practices mature and well-ingrained. GitLab's comprehensive security scanning capabilities, built into the DevSecOps platform,  provide superior control and protection throughout the entire software development lifecycle, helping public sector organizations address these issues. These features eliminate the need for third-party security tools that could potentially compromise compliance. \n\nFor example, organizations gain access to a complete suite of native security scanners including API Security, Container Scanning, Dynamic Application Security Testing, and Fuzz Testing. This integrated approach ensures federal security standards are met without disrupting development workflows.\n\nWith the GitLab DevSecOps unified platform, public sector organizations avoid the painful scenario of discovering security limitations mid-implementation and having to choose between compromising on security features or implementing non-compliant solutions. \n\n## How to get started with GitLab Dedicated for Government\n\nGitLab Dedicated for Government provides the efficiencies of the cloud combined with infrastructure-level isolation and data residency controls. To learn more about how GitLab Dedicated for Government can help secure your software supply chain, reach out to our [sales team](https://about.gitlab.com/sales/). Whether you are a new customer or looking to migrate from your existing GitLab instance, we will ensure a smooth transition with comprehensive [migration support](https://about.gitlab.com/services/) tailored to your needs. \n\n**Note:** GitLab has also achieved the [Texas Risk and Authorization Management Program Certification](https://dir.texas.gov/resource-library-item/tx-ramp-certified-cloud-products) (TX_RAMP), which allows us to work with Texas state agencies.",[475,794,838,14,184],{"slug":902,"featured":91,"template":674},"gitlab-dedicated-for-government-now-fedramp-authorized","content:en-us:blog:gitlab-dedicated-for-government-now-fedramp-authorized.yml","Gitlab Dedicated For Government Now Fedramp Authorized","en-us/blog/gitlab-dedicated-for-government-now-fedramp-authorized.yml","en-us/blog/gitlab-dedicated-for-government-now-fedramp-authorized",{"_path":908,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":909,"content":915,"config":921,"_id":924,"_type":16,"title":925,"_source":17,"_file":926,"_stem":927,"_extension":20},"/en-us/blog/gitlab-18-released",{"title":910,"description":911,"ogTitle":910,"ogDescription":911,"noIndex":91,"ogImage":912,"ogUrl":913,"ogSiteName":784,"ogType":785,"canonicalUrls":913,"schema":914},"GitLab 18 released","This release includes GitLab Premium and Ultimate with Duo, automatic reviews with Duo Code Review, improved Duo Code Review context, repository X-Ray now available on Gitlab Duo Self-Hosted, and much more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662010/Blog/Hero%20Images/product-gl18-blog-release-cover-18-0-0750-1800x945-fy26.png","https://about.gitlab.com/blog/gitlab-18-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 18 released\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeff Tucker\"}],\n        \"datePublished\": \"2025-05-15\",\n      }",{"title":910,"description":911,"authors":916,"heroImage":912,"date":918,"body":919,"category":14,"tags":920},[917],"Jeff Tucker","2025-05-15","This is the post for the [GitLab 18 release](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/).",[752,14],{"slug":922,"featured":6,"template":674,"externalUrl":923},"gitlab-18-released","https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/","content:en-us:blog:gitlab-18-released.yml","Gitlab 18 Released","en-us/blog/gitlab-18-released.yml","en-us/blog/gitlab-18-released",{"_path":929,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":930,"content":936,"config":942,"_id":944,"_type":16,"title":945,"_source":17,"_file":946,"_stem":947,"_extension":20},"/en-us/blog/gitlab-premium-with-duo",{"title":931,"description":932,"ogTitle":931,"ogDescription":932,"noIndex":6,"ogImage":933,"ogUrl":934,"ogSiteName":784,"ogType":785,"canonicalUrls":934,"schema":935},"Unlocking AI for every GitLab Premium and Ultimate customer","GitLab Premium and Ultimate now include GitLab Duo essentials for creating and understanding code throughout the software development lifecycle, all at no additional cost.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660188/Blog/Hero%20Images/blog-premium-with-duo-cover-0756-fy26-v2-1800x945.png","https://about.gitlab.com/blog/gitlab-premium-with-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unlocking AI for every GitLab Premium and Ultimate customer\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2025-05-15\",\n      }",{"title":931,"description":932,"authors":937,"heroImage":933,"date":918,"body":939,"category":14,"tags":940},[938],"David DeSanto, Chief Product Officer, GitLab","Today, we launch GitLab 18.0, which highlights our latest innovations and plans in core DevSecOps workflows, security and compliance, and AI. __As part of this release, we're excited to announce that GitLab Premium and Ultimate now include essential GitLab Duo AI capabilities at no additional cost.__ All Premium and Ultimate customers will have immediate access to GitLab Duo Code Suggestions and Chat directly in their preferred supported source code editors and IDEs.\n\n## AI for every development team\n\nArtificial intelligence is now at the center of the developer experience. AI enhances coding in many ways: It analyzes your codebase and provides real-time suggestions as you type, creates functions and methods based on your project's context, reduces repetitive tasks, and automates code reviews.\n\nOver the past few years, we've built [GitLab Duo](https://about.gitlab.com/gitlab-duo/) to infuse generative and agentic AI capabilities like these into our platform. Because writing code is just the start of the software lifecycle – our [global DevSecOps study](https://about.gitlab.com/developer-survey/) found that developers spend 79% of their time on tasks other than code creation – we have adopted a strategy to integrate AI throughout the entire software development lifecycle. \n\nNow, we’re excited to take the next step forward by including essential GitLab Duo capabilities in our GitLab Premium and Ultimate tiers, enabling developers to get the benefits of AI at no additional cost.\n\nBy including GitLab Duo Chat and Duo Code Suggestions in Premium and Ultimate, every software engineer can accelerate their workflow within the IDE — without requiring separate tooling, licensing, or governance. All existing Premium and Ultimate customers now have instant access to Duo Chat and Code Suggestions, once they upgrade to GitLab 18.0, and this enhancement becomes standard for all new customers.\n\n> **\"GitLab has already been instrumental in eliminating our reliance on a fragmented toolchain, which cut costs from disconnected solutions, and streamlined our workflow. Enhancing GitLab Premium with Duo will give us even greater efficiency and cost savings as our developers spend less time on routine coding tasks and more time tackling complex challenges that drive real business value.”**\n>\n>- Andrei Nita, Chief Technology Officer at McKenzie Intelligence Services\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\nPremium and Ultimate customers now have these AI-native capabilities:\n\n#### GitLab Duo Code Suggestions\n\n* Generate complete functions and code blocks from comments  \n* Get intelligent code completions as you type  \n* Support for 20+ programming languages  \n* Available in most popular IDEs\n\nTake this interactive tour to learn about GitLab Duo Code Suggestions (click on the image to start the tour).\n\n\u003Ca href=\"https://gitlab.navattic.com/code-suggestions\">\u003Cimg src=\"//images.ctfassets.net/r9o86ar0p03f/4nclgZ2JUeQ0hR4wjOS30P/ba948ae1a0dce0cff4469ca06490efb1/Screenshot_2024-08-27_at_9.24.32_AM.png\" alt=\"GitLab Duo Code Suggestions cover image\">\u003C/a>\n\nLearn more in our [Duo Code Suggestions documentation](https://docs.gitlab.com/user/project/repository/code_suggestions/).\n\n#### GitLab Duo Chat\n\n* Explain unfamiliar code to understand complex functionality  \n* Refactor existing code to improve quality and maintainability  \n* Generate comprehensive test cases to help catch bugs earlier  \n* Fix code issues directly in your workflow\n\n![Duo Chat - API endpoint explanation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Duo_Chat_-_gif_-_API_endpoint_explanation__3_.gif)\n\nLearn more in our [Duo Chat documentation](https://docs.gitlab.com/user/gitlab_duo_chat/).\n\n> **\"For us, as GitLab users, Duo's intelligent code suggestions have become a daily asset for our developers. Combined with the chat feature, it allows for immediate feedback and iteration, resulting in faster development cycles and a more secure codebase. It's a seamless and powerful addition to our workflows.\"**\n>\n>- Felix Kortmann, Chief Technology Officer, Ignite by FORVIA HELLA\n\n## Duo Enterprise now available to GitLab Premium customers\n\nDue to strong customer demand, we're also excited to share that [GitLab Premium](https://about.gitlab.com/pricing/premium/) customers now can purchase Duo Enterprise, our full suite of AI offerings, without needing to upgrade to GitLab Ultimate. Premium customers can enjoy a rich AI experience seamlessly integrated across the software development lifecycle. This includes exciting GitLab Duo capabilities like:\n\n* [Root Cause Analysis](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases) helps resolve CI/CD pipeline failures quickly, ensuring your CI/CD pipelines remain green.  \n* [Code Review](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) enables faster merge request reviews by leveraging Duo as a code reviewer.  \n* [Advanced Chat](https://docs.gitlab.com/user/gitlab_duo_chat/) summarizes conversations, helps understand code changes, and provides advanced configuration assistance.  \n* [Self-Hosted](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/) enables Duo to be leveraged within air-gapped and offline environments by hosting approved AI models for Duo to use.\n\nIn addition to Duo Enterprise availability, we continue to invest in the success of GitLab Premium customers. Since the launch of GitLab 17, [we’ve shipped more than a hundred features and improvements](https://gitlab.com/gitlab-org/gitlab/-/releases), including: \n\n* [**CI/CD Catalog**](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) enables developers to share, discover, and reuse   \npre-existing CI/CD components and configurations.  \n* [**Artifact registry**](https://docs.gitlab.com/user/packages/virtual_registry/) gives developers secure access to artifacts and seamless integration with CI/CD pipelines.  \n* [**Remote development**](https://docs.gitlab.com/user/project/remote_development/) enables developers to work in on-demand,  \ncloud-based development environments.\n\n> [Learn more about GitLab Premium features.](https://about.gitlab.com/pricing/premium/#wp-premium-features)\n\n## GitLab Duo: AI that meets organizations where they are\n\nGitLab customers have a comprehensive menu of Duo offerings, across our Pro and Enterprise solutions, to meet you where you are in the AI adoption cycle – the further along your teams are, the more capabilities you can use to build, test, and deploy secure software faster.\n\n![Key features in Duo plans](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Screenshot_2025-05-14_at_8.50.34_AM.png)\n\n## How current GitLab Ultimate and Premium customers can get started with Duo\n\nStarting with GitLab 18.0, for existing Ultimate and Premium customers, Duo Code Suggestions and Chat features will be off by default but can easily be enabled – learn how below.\n\nTo start experiencing GitLab Premium and Ultimate with Duo: \n\n1. Ensure you're on GitLab Premium or Ultimate. If not, you can start a free, 60-day trial. \n\n2. Enable GitLab Duo in your organization settings.\n\n3. If using a local IDE, install the appropriate GitLab [Editor Extension](https://docs.gitlab.com/editor_extensions/#available-extensions). \n\n4. Start using Code Suggestions and Chat in your preferred supported local IDE or the GitLab Web IDE.\n\n**Note:** For new customers and trials, GitLab's AI capabilities will be enabled automatically.\n\n## AI-native development requires a DevSecOps platform\n\nAI is fundamentally reshaping the developer experience. Organizations won't just have more people building software. They'll have more production-ready code generated by AI – **making GitLab more essential than ever.** \n\nWe built GitLab Premium and Ultimate with Duo specifically for this new reality, giving teams one secure foundation for all their code. As AI generates code across your organization, GitLab becomes your control center: no separate tools for security scanning, compliance checks, or managing pipelines. Just a single, unified platform that scales with your organization and helps ensure all code meets your standards before reaching production. As AI accelerates your development, GitLab enables you to maintain control, security, and quality from end to end.\n\n> To learn more about GitLab Duo and all the ways it can transform how your team works, [visit our GitLab Premium page](https://about.gitlab.com/pricing/premium/) or if you are a GitLab customer, reach out to your GitLab representative to schedule a demo. Finally, we invite you to join us on June 24, 2025, for our [GitLab 18 virtual launch event](https://about.gitlab.com/eighteen/) to learn about the future of AI-native software development.\n",[941,475,838,794,14],"AI/ML",{"slug":943,"featured":91,"template":674},"gitlab-premium-with-duo","content:en-us:blog:gitlab-premium-with-duo.yml","Gitlab Premium With Duo","en-us/blog/gitlab-premium-with-duo.yml","en-us/blog/gitlab-premium-with-duo",{"_path":949,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":950,"content":954,"config":960,"_id":963,"_type":16,"title":964,"_source":17,"_file":965,"_stem":966,"_extension":20},"/en-us/blog/gitlab-patch-release-17-11-2-17-10-6-17-9-8",{"title":951,"description":685,"ogTitle":951,"ogDescription":685,"noIndex":91,"ogImage":689,"ogUrl":952,"ogSiteName":784,"ogType":785,"canonicalUrls":952,"schema":953},"GitLab Patch Release: 17.11.2, 17.10.6, 17.9.8","https://about.gitlab.com/blog/gitlab-patch-release-17-11-2-17-10-6-17-9-8","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.11.2, 17.10.6, 17.9.8\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Hauenstein\"}],\n        \"datePublished\": \"2025-05-08\",\n      }",{"title":951,"description":685,"authors":955,"heroImage":689,"date":957,"body":958,"category":14,"tags":959},[956],"Daniel Hauenstein","2025-05-08","This is the post for [GitLab Patch Release: 17.11.2, 17.10.6, 17.9.8](https://about.gitlab.com/releases/2025/05/07/patch-release-gitlab-17-11-2-released/).",[692,879],{"slug":961,"featured":6,"template":674,"externalUrl":962},"gitlab-patch-release-17-11-2-17-10-6-17-9-8","https://about.gitlab.com/releases/2025/05/07/patch-release-gitlab-17-11-2-released/","content:en-us:blog:gitlab-patch-release-17-11-2-17-10-6-17-9-8.yml","Gitlab Patch Release 17 11 2 17 10 6 17 9 8","en-us/blog/gitlab-patch-release-17-11-2-17-10-6-17-9-8.yml","en-us/blog/gitlab-patch-release-17-11-2-17-10-6-17-9-8",{"_path":968,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":969,"content":974,"config":980,"_id":982,"_type":16,"title":983,"_source":17,"_file":984,"_stem":985,"_extension":20},"/en-us/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":970,"description":971,"ogTitle":970,"ogDescription":971,"noIndex":6,"ogImage":850,"ogUrl":972,"ogSiteName":784,"ogType":785,"canonicalUrls":972,"schema":973},"Getting started with GitLab: Understanding CI/CD","Learn the basics of continuous integration/continuous delivery in this beginner's guide, including what CI/CD components are and how to create them.","https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with GitLab: Understanding CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-25\",\n      }",{"title":970,"description":971,"authors":975,"heroImage":850,"date":977,"body":978,"category":14,"tags":979},[976],"GitLab","2025-04-25","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nImagine a workflow where every code change is automatically built, tested, and deployed to your users. That's the power of [Continuous Integration/Continuous Delivery (CI/CD)](https://about.gitlab.com/topics/ci-cd/)! CI/CD helps you catch bugs early, ensures code quality, and delivers software faster and more frequently.\n\n### What is CI/CD?\n\n* **Continuous Integration** is a development practice where developers integrate code changes into a shared repository frequently, preferably several times a day. Each integration is then verified by an automated build and test process, allowing teams to detect problems early.  \n* **Continuous Delivery** extends CI by automating the release pipeline, ensuring that your code is *always* in a deployable state. You can deploy your application to various environments (e.g., staging, production) with a single click or automatically.  \n* **Continuous Deployment** takes it a step further by automatically deploying *every successful build* to production. This requires a high degree of confidence in your automated tests and deployment process.\n\n### Why GitLab CI/CD?\n\nGitLab CI/CD is a powerful, integrated system that comes built-in with GitLab. It offers a seamless experience for automating your entire software development lifecycle. With GitLab CI/CD, you can:\n\n* **Automate everything:** Build, test, and deploy your applications with ease.  \n* **Catch bugs early:** Detect and fix errors before they reach production.  \n* **Get faster feedback:** Receive immediate feedback on your code changes.  \n* **Improve collaboration:** Work together more effectively with automated workflows.  \n* **Accelerate delivery:** Release software faster and more frequently.  \n* **Reduce risk:** Minimize deployment errors and rollbacks.\n\n### The elements of GitLab CI/CD\n\n* `.gitlab-ci.yml`**:** This [YAML file](https://docs.gitlab.com/ee/ci/yaml/), located in your project's root directory, defines your CI/CD pipeline, including stages, jobs, and runners.  \n* [**GitLab Runner**](https://docs.gitlab.com/runner/)**:** This agent executes your CI/CD jobs on your infrastructure (e.g. physical machines, virtual machines, Docker containers, or Kubernetes clusters).  \n* [**Stages**](https://docs.gitlab.com/ee/ci/yaml/#stages)**:** Stages define the order of execution for your jobs (e.g. build, test, and deploy).  \n* [**Jobs**](https://docs.gitlab.com/ee/ci/yaml/#job-keywords)**:** Jobs are individual units of work within a stage (e.g. compile code, run tests, and deploy to staging).\n\n### Setting up GitLab CI\n\nGetting started with GitLab CI is simple. Here's a basic example of a `.gitlab-ci.yml` file:\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the application...\"\n\ntest_job:\n  stage: test\n  script:\n    - echo \"Running tests...\"\n\ndeploy_job:\n  stage: deploy\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n\n```\n\nThis configuration defines three stages: \"build,\" \"test,\" and \"deploy.\" Each stage contains a job that executes a simple script.\n\n### CI/CD configuration examples\n\nLet's explore some more realistic examples.\n\n**Building and deploying a Node.js application**\n\nThe pipeline definition below outlines using npm to build and test a Node.js application and [dpl](https://docs.gitlab.com/ci/examples/deployment/) to deploy the application to Heroku. The deploy stage of the pipeline makes use of [GitLab CI/CD variables](https://docs.gitlab.com/ci/variables/), which allow developers to store sensitive information (e.g. credentials) and securely use them in CI/CD processes. In this example, an API key to deploy to Heroku is stored under the variable key name `$HEROKU_API_KEY` used by the dpl tool.\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild:\n  stage: build\n  image: node:latest\n  script:\n    - npm install\n    - npm run build\n\ntest:\n  stage: test\n  image: node:latest\n  script:\n    - npm run test\n\ndeploy:\n  stage: deploy\n  image: ruby:latest\n  script:\n    - gem install dpl\n    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY\n\n```\n\n**Deploying to different environments (staging and production)**\n\nGitLab also offers the idea of [Environments](https://docs.gitlab.com/ci/environments/) with CI/CD. This feature allows users to track deployments from CI/CD to infrastructure targets. In the example below, the pipeline adds stages with an environment property for a staging and production environment. While the deploy_staging stage will always run its script, the deploy_production stage requires manual approval to prevent accidental deployment to production.  \n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy_staging\n  - deploy_production\n\nbuild:\n  # ...\n\ntest:\n  # ...\n\ndeploy_staging:\n  stage: deploy_staging\n  script:\n    - echo \"Deploying to staging...\"\n  environment:\n    name: staging\n\ndeploy_production:\n  stage: deploy_production\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n  when: manual  # Requires manual approval\n\n```\n\n### GitLab Auto DevOps\n\n[GitLab Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) simplifies CI/CD by providing a pre-defined configuration that automatically builds, tests, and deploys your applications. It leverages best practices and industry standards to streamline your workflow.\n\nTo enable Auto DevOps:\n\n1. Go to your project's **Settings > CI/CD > General pipelines**.  \n2. Enable the **Auto DevOps** option.\n\nAuto DevOps automatically detects your project's language and framework and configures the necessary build, test, and deployment stages. You don’t even need to create a `.gitlab-ci.yml` file.\n\n### CI/CD Catalog\n\nThe [CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) is a list of projects with published [CI/CD components](https://docs.gitlab.com/ee/ci/components/) you can use to extend your CI/CD workflow. Anyone can create a component project and add it to the CI/CD Catalog or contribute to an existing project to improve the available components. You can find published components in the [CI/CD Catalog](https://gitlab.com/explore/catalog) on GitLab.com.\n\n> [Tutorial: How to set up your first GitLab CI/CD component](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n\n### CI templates\n\nYou can also create your own [CI templates](https://docs.gitlab.com/ee/ci/examples/) to standardize and reuse CI/CD configurations across multiple projects. This promotes consistency and reduces duplication.\n\nTo create a CI template:\n\n1. Create a `.gitlab-ci.yml` file in a dedicated project or repository.  \n2. Define your CI/CD configuration in the template.  \n3. In your project's `.gitlab-ci.yml` file, use the `include` keyword to include the template.\n\n## Take your development to the next level\n\nGitLab CI/CD is a powerful tool that can transform your development workflow. By understanding the concepts of CI/CD, configuring your pipelines, and leveraging features like Auto DevOps, the CI/CD Catalog, and CI templates, you can automate your entire software development lifecycle and deliver high-quality software faster and more efficiently.\n\n> Want to take your learning to the next level? Sign up for [GitLab University courses](https://university.gitlab.com/). Or you can get going right away with a [free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## \"Getting Started with GitLab\" series\n\nCheck out more articles in our \"Getting Started with GitLab\" series:\n\n- [How to manage users](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Mastering project management](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automating Agile workflows with the gitlab-triage gem](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Working with CI/CD variables](https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables/)\n",[109,859,860,475,14,671],{"slug":981,"featured":91,"template":674},"getting-started-with-gitlab-understanding-ci-cd","content:en-us:blog:getting-started-with-gitlab-understanding-ci-cd.yml","Getting Started With Gitlab Understanding Ci Cd","en-us/blog/getting-started-with-gitlab-understanding-ci-cd.yml","en-us/blog/getting-started-with-gitlab-understanding-ci-cd",{"_path":987,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":988,"content":992,"config":998,"_id":1001,"_type":16,"title":1002,"_source":17,"_file":1003,"_stem":1004,"_extension":20},"/en-us/blog/gitlab-patch-release-17-11-1-17-10-5-17-9-7",{"title":989,"description":685,"ogTitle":989,"ogDescription":685,"noIndex":91,"ogImage":689,"ogUrl":990,"ogSiteName":784,"ogType":785,"canonicalUrls":990,"schema":991},"GitLab Patch Release: 17.11.1, 17.10.5, 17.9.7","https://about.gitlab.com/blog/gitlab-patch-release-17-11-1-17-10-5-17-9-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.11.1, 17.10.5, 17.9.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\" Félix Veillette-Potvin\"}],\n        \"datePublished\": \"2025-04-23\",\n      }",{"title":989,"description":685,"authors":993,"heroImage":689,"date":995,"body":996,"category":14,"tags":997},[994]," Félix Veillette-Potvin","2025-04-23","This is [GitLab Patch Release: 17.11.1, 17.10.5, 17.9.7](https://about.gitlab.com/releases/2025/04/23/patch-release-gitlab-17-11-1-released/) for GitLab Community Edition (CE) and Enterprise Edition (EE).",[692],{"slug":999,"featured":6,"template":674,"externalUrl":1000},"gitlab-patch-release-17-11-1-17-10-5-17-9-7","https://about.gitlab.com/releases/2025/04/23/patch-release-gitlab-17-11-1-released/","content:en-us:blog:gitlab-patch-release-17-11-1-17-10-5-17-9-7.yml","Gitlab Patch Release 17 11 1 17 10 5 17 9 7","en-us/blog/gitlab-patch-release-17-11-1-17-10-5-17-9-7.yml","en-us/blog/gitlab-patch-release-17-11-1-17-10-5-17-9-7",{"_path":1006,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1007,"content":1013,"config":1021,"_id":1023,"_type":16,"title":1024,"_source":17,"_file":1025,"_stem":1026,"_extension":20},"/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"title":1008,"description":1009,"ogTitle":1008,"ogDescription":1009,"noIndex":6,"ogImage":1010,"ogUrl":1011,"ogSiteName":784,"ogType":785,"canonicalUrls":1011,"schema":1012},"A guide to the breaking changes in GitLab 18.0","Prepare now for the removals in our upcoming major release. Assess your impact and then review the mitigation steps provided in the documentation to ensure a smooth transition to GitLab 18.0.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A guide to the breaking changes in GitLab 18.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Martin Brümmer\"},{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Sam Wiskow\"}],\n        \"datePublished\": \"2025-04-18\",\n      }",{"title":1008,"description":1009,"authors":1014,"heroImage":1010,"date":1018,"body":1019,"category":14,"tags":1020},[1015,1016,1017],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","2025-04-18","GitLab 18.0, our next major release, will be packed with new features that push the boundaries of DevSecOps innovation. At the same time, we’ll be removing some deprecated features from GitLab. Here is what you need to know about these breaking changes and how you can mitigate their impact.\n\n## Deployment windows\n\n### GitLab.com  \n\nBreaking changes for GitLab.com will be limited to these three windows. \n\n- April 21-23, 2025  \n- April 28-30, 2025  \n- May 5-7, 2025\n\nMany other changes will continue to roll out throughout the month. You can learn more about the high-impact changes occurring within each of these windows in this [breaking changes documentation](https://docs.gitlab.com/update/breaking_windows/).\n\n***Note:** Breaking changes may fall slightly outside of these windows in exceptional circumstances.*\n\n### GitLab Self-Managed\n\nGitLab 18.0 will be available starting on May 15. You can learn more about the release schedule [here](https://about.gitlab.com/releases/).\n\n### GitLab Dedicated\n\nThe upgrade to GitLab 18.0 will take place during your maintenance window from June 24-29, 2025. You can learn more and find your assigned maintenance window [here](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule).\n\nWe’ve also developed custom tooling and resources to help you assess the impact of these changes on your environment and plan any necessary actions ahead of the 18.0 upgrade. You can find [information about these mitigation tools and resources](#tools-and-resources-to-manage-your-impact).\n\nVisit the [Deprecations page](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0) to see a full list of items scheduled for removal in 18.0. Read on to learn what’s coming and how to prepare for this year’s release based on your specific deployment.\n\n## Breaking changes\n\n### High impact\n\n**1. CI/CD job token - “Limit access from your project” setting removal**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 14.4, we introduced a setting to **[limit access *from* your project's CI/CD job tokens (CI_JOB_TOKEN)](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)** for added security. This setting was called **Limit CI_JOB_TOKEN access**. In GitLab 16.3, we renamed this setting **Limit access *from* this project** for clarity.\n\nIn GitLab 15.9, we introduced an alternative setting called **[Authorized groups and projects](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)**. This setting controls job token access to your project by using an allowlist. This new setting is a significant improvement over the original. The first iteration was deprecated in GitLab 16.0 and scheduled for removal in GitLab 18.0.\n\nThe **Limit access *from* this project** setting is disabled by default for all new projects. In GitLab 16.0 and later, you cannot re-enable this setting after it is disabled in any project. Instead, use the **Authorized groups and projects** setting to control job token access to your projects.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [GitLab Detective check available](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. CI/CD job token - Authorized groups and projects allowlist enforcement**\n\nGitLab.com | Self-Managed | Dedicated\n\nWith the **[Authorized groups and projects setting](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)** introduced in GitLab 15.9 (renamed from **Limit access to this project** in GitLab 16.3), you can manage CI/CD job token access to your project. When set to **Only this project and any groups and projects in the allowlist**, only groups or projects added to the allowlist can use job tokens to access your project.\n\n* **Prior to GitLab 15.9**, the allowlist was disabled by default ([**All groups and projects**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project) access setting selected), allowing job token access from any project.   \n* **Since GitLab 17.6**, administrators for GitLab Self-Managed and Dedicated instances have had the option to [**enforce a more secure setting for all projects**](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions), which prevents project maintainers from selecting **All groups and projects**. This change ensures a higher level of security between projects.   \n* In GitLab 18.0, this setting will be enabled by default. On GitLab.com, we will automatically populate your projects’ allowlists based on your project authentication logs.   \n* To prepare for this change on **GitLab.com**, project maintainers using the job token for cross-project authentication should populate their project's **Authorized groups and projects** allowlists. They should then change the setting to **Only** **this project and any groups and projects in the allowlist**. We encourage the use of available [migration tooling](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist) to ***automate*** the creation of the allowlist based on the project’s [authentication logs](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log) prior to GitLab 18.0.   \n* **Self-Managed users** should populate the allowlists before completing the 18.0 upgrade.   \n* **Dedicated users** should work with their GitLab account team to develop the appropriate strategy for their specific instance.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [Documentation](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [GitLab Detective check available](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. Dependency Proxy token scope enforcement**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe Dependency Proxy for containers accepts **`docker login`** and **`docker pull`** requests using **personal, project,** or **group** access tokens without validating their scopes.\n\nIn GitLab 18.0, the Dependency Proxy will require both **`read_registry`** and **`write_registry`** scopes for authentication. After this change, authentication attempts using tokens without these scopes will be **rejected**.\n\nBefore upgrading, create new access tokens with the [**required scopes**](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images), and update your workflow variables and scripts with these new tokens.\n\nYou also have the option to use [**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/), a community-developed script that allows you to view tokens and rotate them automatically.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### Medium impact\n\n**1. New data retention limits for vulnerabilities on GitLab.com**\n\nGitLab.com - **Ultimate tier customers only**\n\nStarting in GitLab 18.1 with a phased six-month rollout, we will be introducing a **new data retention limit** for GitLab.com **Ultimate** customers to improve system performance and reliability. The data retention limit affects how long your vulnerability data is stored.\n\nVulnerabilities older than 12 months that have not been updated will be automatically moved to cold storage archives. These archives:\n\n* Remain accessible and downloadable through the GitLab UI  \n* Are retained for 3 years  \n* Are permanently deleted after 3 years \n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [Documentation](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. Reject container image pull policies not in `allowed_pull_policies`**\n\nGitLab.com | Self-Managed | Dedicated  \n\nAll configured pull policies should be present in the [**allowed_pull_policies configuration**](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies) specified in the runner's **`config.toml`** file. If they are not, the job should fail with an **`incompatible pull policy`** error.\n\nIn the current implementation, when multiple pull policies are defined, jobs pass if at least one pull policy matches those in **`allowed-pull-policies`**, even if other policies are not included.\n\nIn GitLab 18.0, jobs will fail only if none of the pull policies match those in **`allowed-pull-policies`**. However, unlike past behavior, jobs will use only the pull policies listed in **`allowed-pull-policies`**. This distinction can cause jobs that currently pass to fail in GitLab 18.0.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [Documentation](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. PostgreSQL 14 and 15 no longer supported**\n\nSelf-Managed \n\nGitLab follows an [**annual upgrade cadence for PostgreSQL**](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/).\n\nSupport for PostgreSQL 14 and 15 is scheduled for removal in GitLab 18.0. In GitLab 18.0, PostgreSQL 16 becomes the minimum required version of PostgreSQL.\n\nPostgreSQL 14 and 15 will be supported for the full GitLab 17 release cycle. PostgreSQL 16 will also be supported for instances that want to upgrade prior to GitLab 18.0.\n\nTo prepare for this change on instances that don't use [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) (for example, if you are running a single PostgreSQL instance you installed with an Omnibus Linux package), upgrades to GitLab 17.11 will attempt to automatically upgrade PostgreSQL to Version 16. If you use [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) or [**opt out of this automated upgrade**](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades), you must [**manually upgrade to PostgreSQL 16**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server) to be able to upgrade to GitLab 18.0. Make sure you have sufficient disk space to accommodate the upgrade.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [Documentation](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [Migration guidelines](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Deprecate the Terraform CI/CD templates**\n\nSelf-Managed\n\nThe Terraform CI/CD templates are deprecated and will be removed in GitLab 18.0. This affects the following templates:\n\n* `Terraform.gitlab-ci.yml`  \n* `Terraform.latest.gitlab-ci.yml`  \n* `Terraform/Base.gitlab-ci.yml`  \n* `Terraform/Base.latest.gitlab-ci.yml`\n\nGitLab won't be able to update the **`terraform`** binary in the job images to any version that is licensed under the BSL.\n\nTo continue using Terraform, clone the templates and [**Terraform image**](https://gitlab.com/gitlab-org/terraform-images), and maintain them as needed. GitLab provides [**detailed instructions**](https://gitlab.com/gitlab-org/terraform-images) for migrating to a custom-built image.\n\n**As an alternative, we recommend using the new OpenTofu CI/CD component on GitLab.com or the new OpenTofu CI/CD template on GitLab Self-Managed.** CI/CD components are not yet available on GitLab Self-Managed, however, [**Issue #415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638) proposes adding this feature. If CI/CD components become available on GitLab Self-Managed, the OpenTofu CI/CD template will be removed.\n\nRead more about the new [OpenTofu CI/CD component](https://gitlab.com/components/opentofu).\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Major update of the Prometheus subchart**\n\nSelf-Managed\n\nWith GitLab 18.0 and GitLab chart 9.0, the Prometheus subchart will be updated from 15.3 to 27.3.\n\nAlong with this update, Prometheus 3 will be shipped by default.\n\nManual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter, or Pushgateway enabled, you will also need to update your Helm values.\n\nPlease refer to the [**migration guide**](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade) for more information.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### Low impact\n\n**1. No longer building SUSE Linux Enterprise Server 15 SP2 packages**\n\nSelf-Managed\n\nLong-term service and support (LTSS) for SUSE Linux Enterprise Server (SLES) 15 SP2 ended in December 2024.\n\nTherefore, we will no longer support the SLES SP2 distribution for Linux package installs. You should upgrade to SLES 15 SP6 for continued support.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Remove Gitaly rate limiter**\n\nSelf-Managed\n\nGitaly used to support [**RPC-based rate limiting**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55). We are deprecating this feature as it does not achieve the desired results. Please see the deprecation issue for details.\n\nIf customers have the rate limiter configured (which is being deprecated), no error will be returned and the config will simply be ignored.\n\nCustomers should utilize the [**Concurrency Limiter**](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/) instead.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. Deprecate NGINX controller image 1.3.1 support**\n\nSelf-Managed\n\nWe're upgrading the default NGINX controller image to 1.11.2. This new version requires new RBAC rules and some users set **nginx-ingress.rbac.create: false** to manage their own RBAC rules.\n\nThese users will need to add the RBAC rules before migrating to 1.11.2 or later. We added a fallback mechanism to only deploy 1.3.1 if this Helm value is set as above. We've also added **nginx-ingress.controller.image.disableFallback**, which defaults to false. Users who manage their own RBAC can set this to true to enable their deployments to also use 1.11.2, after ensuring the new RBAC rules are in place.\n\nWe plan to deprecate the 1.3.1 image support as well as the fallback mechanism as part of 17.5, so that we can remove this support completely and use only 1.11.2, which offers numerous security benefits.\n\n[Deprecation notice](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. Application Security Testing analyzers major version update**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe Application Security Testing stage will be bumping the major versions of its analyzers in tandem with the GitLab 18.0 release.\n\nIf you are not using the default included templates, or have pinned your analyzer versions, you must update your CI/CD job definition to either remove the pinned version or update the latest major version.\n\nUsers of GitLab 17.0-17.11 will continue to experience analyzer updates as normal until the release of GitLab 18.0. After GitLab 18.0, all newly fixed bugs and features will be released only in the new major version of the analyzers.\n\nWe do not backport bugs and features to deprecated versions as per our maintenance policy. As required, security patches will be backported to the latest three minor releases.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API Discovery will use branch pipelines by default**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 18.0, we'll update the default behavior of the CI/CD template for API Discovery (**API-Discovery.gitlab-ci.yml**).\n\nBefore GitLab 18.0, this template configures jobs to run in [**merge request pipelines**](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) by default when an MR is open.\n\nStarting in GitLab 18.0, we'll align this template's behavior with the behavior of the [**Stable template editions**](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions) for other AST scanners:\n\n* By default, the template will run scan jobs in branch pipelines.  \n* You'll be able to set the CI/CD variable **AST_ENABLE_MR_PIPELINES: true** to use MR pipelines instead when an MR is open. The implementation of this new variable is tracked in [**Issue #410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880).\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. DAST DAST_DEVTOOLS_API_TIMEOUT will have a lower default value**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe **DAST_DEVTOOLS_API_TIMEOUT** environment variable determines how long a DAST scan waits for a response from the browser. Before GitLab 18.0, the variable has a static value of 45 seconds. After GitLab 18.0, **DAST_DEVTOOLS_API_TIMEOUT** environment variable has a dynamic value, which is calculated based on other timeout configurations.\n\nIn most cases, the 45-second value was higher than the timeout value of many scanner functions. The dynamically calculated value makes the __DAST_DEVTOOLS_API_TIMEOUT__ variable more useful by increasing the number of cases to which it applies.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value) \n\n## Tools and resources to manage your impact\n\nWe’ve developed specific tooling to help our customers understand how these planned changes impact their GitLab instance(s). Once you’ve assessed your impact, we recommend reviewing the mitigation steps provided in the documentation to ensure a smooth transition to GitLab 18.0.\n\n* [Advanced Search Deprecations](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations): This tool uses GitLab's Advanced Search API to find strings related to deprecations across GitLab groups and projects. It also reports which files should be manually checked. *__Note:__ May have some false positives.*  \n* [Dependency Scanning Build Support Detection Helper](https://gitlab.com/security-products/tooling/build-support-detection-helper): This tool identifies projects impacted by three Dependency Scanning deprecations ([1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries), [2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner), [3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects); all postponed to 19.0). It uses API to scan for relevant files and CI job names.\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md) (Self-Managed only): This experimental tool automatically checks a GitLab installation for known issues. It completes complex checks by looking at config files or database values. **Note:** Needs to run directly on your GitLab nodes.\n\nWe’ve also launched a series of micro courses (15 minutes or less!) on GitLab University to help you plan and execute mitigation activities for several of these changes. [Start your learning journey here](https://university.gitlab.com/catalog?query=18.0). \n\nIf you have a paid plan and have questions or require assistance with these changes, please [open a support ticket](https://about.gitlab.com/support/portal/) on the GitLab Support Portal. \n\nIf you are a [free Gitlab.com user](https://about.gitlab.com/support/statement-of-support/#free-users), you can access additional support through community sources, such as [GitLab Documentation](https://docs.gitlab.com/), [GitLab Community Forum](https://forum.gitlab.com/), and [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab).\n",[14,475],{"slug":1022,"featured":6,"template":674},"a-guide-to-the-breaking-changes-in-gitlab-18-0","content:en-us:blog:a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0","en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"_path":1028,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1029,"content":1035,"config":1041,"_id":1044,"_type":16,"title":1045,"_source":17,"_file":1046,"_stem":1047,"_extension":20},"/en-us/blog/gitlab-17-11-released",{"title":1030,"description":1031,"ogTitle":1030,"ogDescription":1031,"noIndex":91,"ogImage":1032,"ogUrl":1033,"ogSiteName":784,"ogType":785,"canonicalUrls":1033,"schema":1034},"GitLab 17.11 released","The release includes Custom Compliance Frameworks, more AI features on GitLab Duo Self-Hosted, custom epic, issue, and task fields, CI/CD pipeline inputs, and much more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662237/Blog/Hero%20Images/product-gl17-blog-release-cover-17-11-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-11-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.11 released\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Meadzinger\"}],\n        \"datePublished\": \"2025-04-17\",\n      }",{"title":1030,"description":1031,"authors":1036,"heroImage":1032,"date":1038,"body":1039,"category":14,"tags":1040},[1037],"Sara Meadzinger","2025-04-17","This is the [release post for GitLab 17.11](https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/).",[752],{"slug":1042,"featured":6,"template":674,"externalUrl":1043},"gitlab-17-11-released","https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/","content:en-us:blog:gitlab-17-11-released.yml","Gitlab 17 11 Released","en-us/blog/gitlab-17-11-released.yml","en-us/blog/gitlab-17-11-released",{"_path":1049,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1050,"content":1054,"config":1059,"_id":1062,"_type":16,"title":1063,"_source":17,"_file":1064,"_stem":1065,"_extension":20},"/en-us/blog/gitlab-patch-release-17-10-4-17-9-6-17-8-7",{"title":1051,"description":685,"ogTitle":1051,"ogDescription":685,"noIndex":91,"ogImage":689,"ogUrl":1052,"ogSiteName":784,"ogType":785,"canonicalUrls":1052,"schema":1053},"GitLab Patch Release: 17.10.4, 17.9.6, 17.8.7","https://about.gitlab.com/blog/gitlab-patch-release-17-10-4-17-9-6-17-8-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.10.4, 17.9.6, 17.8.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Costel Maxim\"}],\n        \"datePublished\": \"2025-04-09\",\n      }",{"title":1051,"description":685,"authors":1055,"heroImage":689,"date":1056,"body":1057,"category":14,"tags":1058},[766],"2025-04-09","Learn more about [this patch release](https://about.gitlab.com/releases/2025/04/09/patch-release-gitlab-17-10-4-released/) for GitLab Community Edition (CE) and Enterprise Edition (EE).",[879,692],{"slug":1060,"featured":6,"template":674,"externalUrl":1061},"gitlab-patch-release-17-10-4-17-9-6-17-8-7","https://about.gitlab.com/releases/2025/04/09/patch-release-gitlab-17-10-4-released/","content:en-us:blog:gitlab-patch-release-17-10-4-17-9-6-17-8-7.yml","Gitlab Patch Release 17 10 4 17 9 6 17 8 7","en-us/blog/gitlab-patch-release-17-10-4-17-9-6-17-8-7.yml","en-us/blog/gitlab-patch-release-17-10-4-17-9-6-17-8-7",{"_path":1067,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1068,"content":1074,"config":1080,"_id":1083,"_type":16,"title":1084,"_source":17,"_file":1085,"_stem":1086,"_extension":20},"/en-us/blog/gitlab-patch-release-17-9-5",{"title":1069,"description":1070,"ogTitle":1069,"ogDescription":1070,"noIndex":91,"ogImage":1071,"ogUrl":1072,"ogSiteName":784,"ogType":785,"canonicalUrls":1072,"schema":1073},"GitLab Patch Release 17.9.5","Learn about this patch release for GitLab Community Edition and Enterprise Edition.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","https://about.gitlab.com/blog/gitlab-patch-release-17-9-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release 17.9.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mayra Cabrera\"}],\n        \"datePublished\": \"2025-04-02\",\n      }",{"title":1069,"description":1070,"authors":1075,"heroImage":1071,"date":1077,"body":1078,"category":14,"tags":1079},[1076],"Mayra Cabrera","2025-04-02","This is the [17.9.5 patch release](https://about.gitlab.com/releases/2025/04/02/gitlab-17-9-5-released/) for GitLab Community Edition and Enterprise Edition.",[692],{"slug":1081,"featured":6,"template":674,"externalUrl":1082},"gitlab-patch-release-17-9-5","https://about.gitlab.com/releases/2025/04/02/gitlab-17-9-5-released/","content:en-us:blog:gitlab-patch-release-17-9-5.yml","Gitlab Patch Release 17 9 5","en-us/blog/gitlab-patch-release-17-9-5.yml","en-us/blog/gitlab-patch-release-17-9-5",{"_path":1088,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1089,"content":1095,"config":1102,"_id":1104,"_type":16,"title":1105,"_source":17,"_file":1106,"_stem":1107,"_extension":20},"/en-us/blog/improving-oauth-ropc-security-on-gitlab-com",{"title":1090,"description":1091,"ogTitle":1090,"ogDescription":1091,"noIndex":6,"ogImage":1092,"ogUrl":1093,"ogSiteName":784,"ogType":785,"canonicalUrls":1093,"schema":1094},"Improving OAuth ROPC security on GitLab.com","GitLab.com is improving the security of OAuth Resource Owner Password Credentials (ROPC) by requiring client authentication, effective April 8, 2025.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663239/Blog/Hero%20Images/AdobeStock_1023776629.jpg","https://about.gitlab.com/blog/improving-oauth-ropc-security-on-gitlab-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Improving OAuth ROPC security on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Security Team\"}],\n        \"datePublished\": \"2025-04-01\",\n      }",{"title":1090,"description":1091,"authors":1096,"heroImage":1092,"date":1098,"body":1099,"category":14,"tags":1100},[1097],"GitLab Security Team","2025-04-01","GitLab.com will require client authentication for OAuth Resource Owner Password Credentials (ROPC) beginning on **April 8, 2025**. ROPC was omitted by the OAuth working group in RFC Version 2.1. Existing ROPC integrations without client credentials will experience service disruption after this date. Please update your integrations to include client credentials before the deadline. \n\n## What is changing\n\nGitLab.com is improving the security of OAuth ROPC by requiring client authentication for all requests, effective **April 8, 2025**. For more details about ROPC and authentication mechanisms, read more in the [“Example ROPC Request Types” section of this notice](#example-ropc-request-types) or read about [ROPC in the OAuth API GitLab page](https://docs.gitlab.com/api/oauth2/#resource-owner-password-credentials-flow). \n\n## Why this change matters\n\n* **Enhanced security:** Client authentication provides an additional layer of security by ensuring that only authorized applications can request access tokens.  \n* **Standards compliance:** This change brings GitLab's OAuth implementation into alignment with industry best practices and OAuth 2.0 specifications.  \n* **Improved auditing:** Client authentication improves application request traceability and monitoring.\n\n## Required action\n\nWe strongly recommend updating your implementation before **April 8, 2025,** by following these steps:\n\n1. **Register your application** in GitLab to obtain client credentials:  \n   * Navigate to **User Settings > Applications** (or register a group or instance OAuth application as desired).  \n   * Create a new application or use an existing one.  \n   * Note the provided `Application ID` (client_id) and `Secret` (client_secret).  \n2. **Update your authentication requests** to include the client credentials:  \n   * Add the `client_id` and `client_secret` parameters to your token requests.  \n   * Test your implementation in our staging environment.  \n3. **Review our implementation documentation** for detailed guidance:  \n   * [GitLab OAuth Authentication Guide](https://docs.gitlab.com/ee/api/oauth2.html)\n\n## Example ROPC request types\n\nDetailed examples of authorization requests as documented in the [OAuth API GitLab page](https://docs.gitlab.com/api/oauth2/#resource-owner-password-credentials-flow) are listed below. \n\n**Insecure ROPC method example:**\n\n*This insecure ROPC method does not use client authentication, and will not work on GitLab.com after April 8, 2025.* \n\n```\nPOST /oauth/token\nContent-Type: application/x-www-form-urlencoded\n\ngrant_type=password&username=user@example.com&password=secret\t\n```\n\n**Insecure ROPC JSON method example:**\n\n*This insecure ROPC method does not use client authentication, and will not work on GitLab.com after April 8, 2025.* \n\n```\nPOST /oauth/token\nContent-Type: application/json\n{\n  \"grant_type\": \"password\",\n  \"username\": \"user@example.com\",\n  \"password\": \"secret\"\n}\n```\n\n**Required method going forward:**\n\n```\nPOST /oauth/token\nContent-Type: application/x-www-form-urlencoded\n\ngrant_type=password&username=user@example.com&password=secret&client_id=APP_ID&client_secret=APP_SECRET\n```\n\n**Required method - JSON example:** \n\n```\nPOST /oauth/token\nContent-Type: application/json\n\n{\n  \"grant_type\": \"password\",\n  \"username\": \"user@example.com\",\n  \"password\": \"secret\",\n  \"client_id\": \"APP_ID\",\n  \"client_secret\": \"APP_SECRET\"\n}\n```\n\n## Need further guidance?\n\n* **Documentation:** [GitLab OAuth 2.0 Guide](https://docs.gitlab.com/ee/api/oauth2.html)  \n* **Support:** Contact [GitLab Support](https://about.gitlab.com/support/)  \n* **Community Forum:** Discuss this change in the [GitLab Forum](https://forum.gitlab.com/)\n",[14,1101,475],"security",{"slug":1103,"featured":6,"template":674},"improving-oauth-ropc-security-on-gitlab-com","content:en-us:blog:improving-oauth-ropc-security-on-gitlab-com.yml","Improving Oauth Ropc Security On Gitlab Com","en-us/blog/improving-oauth-ropc-security-on-gitlab-com.yml","en-us/blog/improving-oauth-ropc-security-on-gitlab-com",{"_path":1109,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1110,"content":1114,"config":1119,"_id":1122,"_type":16,"title":1123,"_source":17,"_file":1124,"_stem":1125,"_extension":20},"/en-us/blog/gitlab-patch-release-17-10-1-17-9-3-17-8-6",{"title":1111,"description":685,"ogTitle":1111,"ogDescription":685,"noIndex":91,"ogImage":689,"ogUrl":1112,"ogSiteName":784,"ogType":785,"canonicalUrls":1112,"schema":1113},"GitLab Patch Release: 17.10.1, 17.9.3, 17.8.6","https://about.gitlab.com/blog/gitlab-patch-release-17-10-1-17-9-3-17-8-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.10.1, 17.9.3, 17.8.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\" Félix Veillette-Potvin\"}],\n        \"datePublished\": \"2025-03-26\",\n      }",{"title":1111,"description":685,"authors":1115,"heroImage":689,"date":1116,"body":1117,"category":14,"tags":1118},[994],"2025-03-26","This is the [patch release post](https://about.gitlab.com/releases/2025/03/26/patch-release-gitlab-17-10-1-released/) for GitLab 17.10.1, 17.9.3, 17.8.6.",[879],{"slug":1120,"featured":6,"template":674,"externalUrl":1121},"gitlab-patch-release-17-10-1-17-9-3-17-8-6","https://about.gitlab.com/releases/2025/03/26/patch-release-gitlab-17-10-1-released/","content:en-us:blog:gitlab-patch-release-17-10-1-17-9-3-17-8-6.yml","Gitlab Patch Release 17 10 1 17 9 3 17 8 6","en-us/blog/gitlab-patch-release-17-10-1-17-9-3-17-8-6.yml","en-us/blog/gitlab-patch-release-17-10-1-17-9-3-17-8-6",{"_path":1127,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1128,"content":1134,"config":1140,"_id":1142,"_type":16,"title":1143,"_source":17,"_file":1144,"_stem":1145,"_extension":20},"/en-us/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated",{"title":1129,"description":1130,"ogTitle":1129,"ogDescription":1130,"noIndex":6,"ogImage":1131,"ogUrl":1132,"ogSiteName":784,"ogType":785,"canonicalUrls":1132,"schema":1133},"More granular product usage insights for GitLab Self-Managed and Dedicated","Learn how event-level data helps GitLab improve the DevSecOps platform. Opt-out option is always available.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099221/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750099221690.png","https://about.gitlab.com/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"More granular product usage insights for GitLab Self-Managed and Dedicated\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tanuja Jayarama Raju\"}],\n        \"datePublished\": \"2025-03-26\",\n      }",{"title":1129,"description":1130,"authors":1135,"heroImage":1131,"date":1116,"body":1137,"category":14,"tags":1138,"updatedDate":1139},[1136],"Tanuja Jayarama Raju","In GitLab 18.0, we plan to enable event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances – while ensuring privacy, transparency, and customer control every step of the way.\n\nWe know data powers valuable insights to help you understand the performance of your DevSecOps practices. Similarly, platform usage data enables us to prioritize the investments and product improvements that drive more impact for you.\t\n\nHistorically, we’ve collected both event and aggregate product usage data from GitLab.com. However, for GitLab Self-Managed and Dedicated instances, the absence of event data has required the GitLab Customer Success team to rely on manual data extraction methods to gather key insights, including job runtimes, runner usage for cost optimization, pipeline success rates, and deployment frequency for assessing DevSecOps maturity. Access to event-level data reduces the need for workarounds and enables more efficient reporting and optimizations. \n\n**Note: Throughout this blog, when we discuss event collection, we are exclusively referring to the collection of events for all features except those included in GitLab Duo. For more details, please refer to our [Customer Product Usage Information page](https://handbook.gitlab.com/handbook/legal/privacy/customer-product-usage-information/).**\n\n## Understanding event-level data\n\nEvent-level data tracks product usage interactions within the GitLab platform, such as initiating CI/CD pipelines, merging a merge request, triggering a webhook, or creating a new issue. User identifiers are pseudonymized to protect privacy, and GitLab does not undertake any processes to re-identify or associate the metrics with individual users. Importantly, event-level data does not include source code or other customer-created content stored within GitLab. To learn more, visit our [Customer Product Usage Information page](https://handbook.gitlab.com/handbook/legal/privacy/customer-product-usage-information/) and [event data documentation](https://docs.gitlab.com/administration/settings/event_data/).\n\nHere is an example of a data sample we collect:\n\n![event-level data - code example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099231/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099230972.png)\n\n## How event-level data collection benefits you\n\nEvent-level data offers a wealth of insights beyond what aggregated data can provide. It enables slicing and aggregating pseudonymized system instrumentation to identify trends, highlight unused or underused areas, and signal product improvements. By analyzing usage patterns in context, we can understand which features are used, how, and in what sequence. This visibility uncovers bottlenecks and optimization opportunities that aggregated data would miss.\n\n* **In-depth feature usage analysis**  \n  Rather than just knowing which features are used weekly or monthly, event-level data provides a clearer picture of how users experience GitLab and the frequency of their usage. This enables us to gain a deeper understanding of user behavior and highlights areas for improvement.  \n* **Trend discovery**  \n  Event-level data helps identify trends in GitLab adoption that can’t be seen with rolling aggregates. With these insights, the GitLab Customer Success team can help customers make more informed decisions on feature adoption and usage, improving overall efficiency.  \n* **Smarter product improvements**  \n  Event-level data gives GitLab’s Product team a clearer picture of real-world customer needs. By analyzing usage patterns, product improvements can be aligned with customer priorities, leading to continuous enhancements that make GitLab more powerful, efficient, and user-friendly.  \n* **Custom insights for your use case**  \n  Event-level data will enable GitLab Customer Success to provide tailored insights based on your organization's overall product usage without identifying individual users. This flexibility helps our teams provide recommendations that address your unique needs and challenges.\n\n## You stay in control of your data\n\n![event-level data - screen of choices](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099231/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-04-02_at_12.14.12_PM_aHR0cHM6_1750099230972.png)\n\nWe’re committed to rolling this out with a strong focus on privacy. Here’s what we’re doing to ensure transparency and choice:\n\n✅ **Pre-deployment early opt-out** – Data sharing can be disabled by instance admins in the 17.11 release before event collection begins in 18.0. The pre-deployment early opt-out option will remain available after 18.0; just upgrade to 17.11 first and disable data sharing.\n\n✅ **Proactive communication** – Updates on the progress of this initiative shared via blog posts, emails to GitLab admins, and updates through your GitLab account team.\n\n ✅ **No third-party collectors** - GitLab’s event-level instrumentation will not use any third-party collectors; it’s built and operated by GitLab, and events are sent directly to GitLab-managed environments, similar to [Service Ping](https://handbook.gitlab.com/handbook/legal/privacy/customer-product-usage-information/#service-ping-formerly-known-as-usage-ping).\n\n✅ **Detailed documentation** – Detailed documentation is available [here](https://docs.gitlab.com/administration/settings/event_data/), and a list of FAQs is available [here](http://handbook.gitlab.com/handbook/legal/privacy/product-usage-events-faq/).\n\n✅ **De-identification approach** – We will continue to apply aggregation and/or pseudonymization to any event-level data collected from Self-Managed and Dedicated.\n\n## What’s next\n\n* **Product enhancements (coming up!)** - Improvements to GitLab user experiences and adoption insights made possible by event-level data.\n\n*Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog 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 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.*",[14,475,794],"2025-05-14",{"slug":1141,"featured":91,"template":674},"more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated","content:en-us:blog:more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated.yml","More Granular Product Usage Insights For Gitlab Self Managed And Dedicated","en-us/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated.yml","en-us/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated",{"_path":1147,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1148,"content":1154,"config":1159,"_id":1162,"_type":16,"title":1163,"_source":17,"_file":1164,"_stem":1165,"_extension":20},"/en-us/blog/gitlab-17-10-released",{"title":1149,"description":1150,"ogTitle":1149,"ogDescription":1150,"noIndex":91,"ogImage":1151,"ogUrl":1152,"ogSiteName":784,"ogType":785,"canonicalUrls":1152,"schema":1153},"GitLab 17.10 released","Learn about the improvements in this release, including Duo Code Review Beta, Root Cause Analysis for GitLab Duo Self-Hosted, GitLab Query Language Views Beta, and more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662230/Blog/Hero%20Images/product-gl17-blog-release-cover-17-10-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-10-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.10 released\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-03-20\",\n      }",{"title":1149,"description":1150,"authors":1155,"heroImage":1151,"date":1156,"body":1157,"category":14,"tags":1158},[748],"2025-03-20","This is the post for the [GitLab 17.0 release](https://about.gitlab.com/releases/2025/03/20/gitlab-17-10-released/).",[752],{"slug":1160,"featured":91,"template":674,"externalUrl":1161},"gitlab-17-10-released","https://about.gitlab.com/releases/2025/03/20/gitlab-17-10-released/","content:en-us:blog:gitlab-17-10-released.yml","Gitlab 17 10 Released","en-us/blog/gitlab-17-10-released.yml","en-us/blog/gitlab-17-10-released",{"_path":1167,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1168,"content":1173,"config":1179,"_id":1181,"_type":16,"title":1182,"_source":17,"_file":1183,"_stem":1184,"_extension":20},"/en-us/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"title":1169,"description":1170,"ogTitle":1169,"ogDescription":1170,"noIndex":6,"ogImage":850,"ogUrl":1171,"ogSiteName":784,"ogType":785,"canonicalUrls":1171,"schema":1172},"Automating Agile workflows with the gitlab-triage gem","Learn how to automate repetitive tasks like triaging issues and merge requests to free up valuable developer time in our \"Getting Started with GitLab\" series.","https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automating Agile workflows with the gitlab-triage gem\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":1169,"description":1170,"authors":1174,"heroImage":850,"date":1175,"body":1176,"category":14,"tags":1177},[976],"2025-03-13","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nThis post dives into the [`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) gem, a powerful tool that lets you create bots to automate your Agile workflow. Say goodbye to manual tasks and hello to streamlined efficiency.\n\n## Why automate your workflow?\n\nEfficiency is key in software development. Automating repetitive tasks like triaging issues and merge requests frees up valuable time for your team to focus on what matters most: building amazing software.\n\nWith `gitlab-triage`, you can:\n\n* **Ensure consistency:** Apply labels and assign issues automatically based on predefined rules.  \n* **Improve response times:** Get immediate feedback on new issues and merge requests.  \n* **Reduce manual effort:** Eliminate the need for manual triage and updates.  \n* **Boost productivity:** Free up your team to focus on coding and innovation.\n\n## Introducing the `gitlab-triage` gem\n\nThe `gitlab-triage` gem is a Ruby library that allows you to create bots that interact with your GitLab projects. These bots can automatically perform a wide range of actions, including:\n\n* **Labeling:** Automatically categorize issues and merge requests.  \n* **Commenting:** Provide updates, request information, or give feedback.  \n* **Assigning:** Assign issues and merge requests to the appropriate team members.  \n* **Closing:** Close stale or resolved issues and merge requests.  \n* **Creating:** Generate new issues based on specific events or conditions.  \n* **And much more!**\n\nCheck out the [`gitlab-triage` gem repository](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage). \n\n## Setting up your triage bot\n\nLet's get your first triage bot up and running!\n\n1. Install the gem. (Note: The gem command is available with Ruby programming language installed.)\n\n```bash\ngem install gitlab-triage\n```\n\n2. Get your GitLab API token.\n\n* Go to your GitLab [profile settings](https://gitlab.com/-/profile/preferences).  \n* Navigate to **Access Tokens**.  \n* Create a new token with the `api` scope.  \n* **Keep your token secure and set an expiration date for it based on when you will be done with this walkthrough!**\n\n3. Define your triage policies.\n\nCreate a file named `.triage-policies.yml` in your project's root directory. This file will contain the rules that govern your bot's behavior. Here's a simple example:\n\n```yaml\n\n---\n- name: \"Apply 'WIP' label\"\n  condition:\n    draft: true\n  action:\n    labels:\n      - status::wip\n\n- name: \"Request more information on old issue\"\n  condition:\n   date:\n    attribute: updated_at\n    condition: older_than\n    interval_type: months\n    interval: 12\n  action:\n    comment: |\n      {{author}} This issue has been open for more than 12 months, is this still an issue?\n```\n\nThis configuration defines two policies:\n\n* The first policy applies the `status::wip` label to any issue that is in draft.  \n* The second policy adds a comment to an issue that the issue has not been updated in 12 months.\n\n4. Run your bot.\n\nYou can run your bot manually using the following command:\n\n```bash\ngitlab-triage -t \u003Cyour_api_token> -p \u003Cyour_project_id>\n```\n\nReplace `\u003Cyour_api_token>` with your GitLab API token and `\u003Cyour_project_id>` with the [ID of your GitLab project](https://docs.gitlab.com/user/project/working_with_projects/#access-a-project-by-using-the-project-id). If you would like to see the impact of actions before they are taken, you can add the `-n` or `--dry-run` to test out the policies first.\n\n## Automating with GitLab CI/CD\n\nTo automate the execution of your triage bot, integrate it with [GitLab CI/CD](https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/). Here's an example `.gitlab-ci.yml` configuration:\n\n```yaml\n\ntriage:\n  script:\n    - gem install gitlab-triage\n    - gitlab-triage -t $GITLAB_TOKEN -p $CI_PROJECT_ID\n  only:\n    - schedules\n```\n\nThis configuration defines a job named \"triage\" that installs the `gitlab-triage` gem and runs the bot using the `$GITLAB_TOKEN` (a predefined [CI/CD variable](https://docs.gitlab.com/ci/variables/)) and the `$CI_PROJECT_ID` variable. The `only: schedules` clause ensures that the job runs only on a schedule.\n\nTo create a [schedule](https://docs.gitlab.com/ee/ci/pipelines/schedules.html), go to your project's **CI/CD** settings and navigate to **Schedules**. Create a new schedule and define the frequency at which you want your bot to run (e.g., daily, hourly).\n\n## Advanced triage policies\n\n`gitlab-triage` offers a range of advanced features for creating more complex triage policies:\n\n* **Regular expressions:** Use regular expressions for more powerful pattern matching.  \n* **Summary policies:** Consolidate related issues into a single summary issue.  \n* **Custom actions:** Define custom actions using [Ruby code blocks](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#can-i-customize) to perform more complex operations using the GitLab API.\n\nHere are two advanced real-world examples from the triage bot used by the Developer Advocacy team at GitLab. You can view the full policies in [this file](https://gitlab.com/gitlab-da/projects/devrel-bot/-/blob/master/.triage-policies.yml?ref_type=heads).\n\n```yaml\n- name: Issues where DA team member is an assignee outside DA-Meta project i.e. DevRel-Influenced\n  conditions:\n    assignee_member:\n      source: group\n      condition: member_of\n      source_id: 1008\n    state: opened\n    ruby: get_project_id != 18 \n    forbidden_labels:\n      - developer-advocacy\n  actions:   \n    labels:\n      - developer-advocacy\n      - DevRel-Influenced\n      - DA-Bot::Skip\n```\n\nThis example for issues across a group, excluding those in the project with the ID of 18, have assignees who are members of the group with ID of 1008 and do not have the label `developer-advocacy` on them. This policy helps the Developer Advocacy team at GitLab to find issues members of the team are assigned to but are not in their team’s project. This helps the team identify and keep track of contributions made outside of the team by adding the teams’ labels.\n\n```\n- name: Missing Due Dates\n  conditions:\n    ruby: missing_due_date\n    state: opened\n    labels:\n      - developer-advocacy\n    forbidden_labels:\n      - DA-Due::N/A\n      - DA-Bot::Skip\n      - DA-Status::FYI\n      - DA-Status::OnHold\n      - CFP\n      - DA-Bot::Triage\n  actions:\n    labels:\n      - DA-Bot-Auto-Due-Date\n    comment: |\n      /due #{get_current_quarter_last_date}\n```\n\nThis second example checks for all issues with the `developer-advocacy` label, which do not include labels in the forbidden labels list and when their due dates have passed. It updates the due dates automatically by commenting on the issue with a slash command and a date that is generated using Ruby.\n\nThe Ruby scripts used in the policies are defined in a separate file as shown below. This feature allows you to be flexible in working with your filters and actions. You can see functions are created for different Ruby commands that we used in our policies. \n\n```\nrequire 'json'\nrequire 'date'\nrequire \"faraday\"\nrequire 'dotenv/load'\n\nmodule DATriagePlugin\n  def last_comment_at\n    conn = Faraday.new(\n      url: notes_url+\"?sort=desc&order_by=created_at&pagination=keyset&per_page=1\",\n      headers: {'PRIVATE-TOKEN' => ENV.fetch(\"PRIV_KEY\"), 'Content-Type' => 'application/json' }\n    )\n\n    response = conn.get()\n    if response.status == 200\n      jsonData = JSON.parse(response.body)\n      if jsonData.length > 0\n        Date.parse(jsonData[0]['created_at'])\n      else\n        Date.parse(resource[:created_at])\n      end\n    else\n      Date.parse(resource[:created_at])\n    end\n  end\n\n  def notes_url\n    resource[:_links][:notes]\n  end\n\n  def get_project_id\n    resource[:project_id]\n  end\n\n  def get_current_quarter_last_date()\n    yr = Time.now.year\n    case Time.now.month\n    when 2..4\n      lm = 4\n    when 5..7\n      lm = 7\n    when 8..10\n      lm = 10\n    when 11..12\n      lm = 1\n      yr = yr + 1\n    else\n      lm = 1    \n    end\n\n    return Date.new(yr, lm, -1) \n  end\n\n  def one_week_to_due_date\n    if(resource[:due_date] == nil)\n      false\n    else\n      days_to_due = (Date.parse(resource[:due_date]) - Date.today).to_i\n      if(days_to_due > 0 && days_to_due \u003C 7)\n        true\n      else\n        false\n      end\n    end\n  end\n\n  def due_date_past\n    if(resource[:due_date] == nil)\n      false\n    else\n      Date.today > Date.parse(resource[:due_date])\n    end\n  end\n\n  def missing_due_date\n    if(resource[:due_date] == nil)\n      true\n    else\n      false\n    end\n  end\n\nend\n\nGitlab::Triage::Resource::Context.include DATriagePlugin\n\n```\nThe triage bot is executed using the command:\n\n``` \n`gitlab-triage -r ./triage_bot/issue_triage_plugin.rb --debug --token $PRIV_KEY --source-id gitlab-com --source groups`  \n```\n\n- `-r`: Passes in a  file of requirements for the performing triage. In this case we are passing in our Ruby functions.  \n- `--debug`: Prints debugging information as part of the output.  \n- `--token`: Is used to pass in a valid GitLab API token.  \n- `--source`: Specifies if the sources of the issues it will search is within a group or a project.  \n- `--source-id`: Takes in the ID of the selected source type – in this case, a group.\n\nThe GitLab [triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) project is another real-world example that is more complex and you can learn how to build your own triage bot.\n\n## Best practices\n\n* **Start simple:** Begin with basic policies and gradually increase complexity as needed. \n* **Test thoroughly:** Test your policies in a staging environment before deploying them to production.  \n* **Monitor regularly:** Monitor your bot's activity to ensure it's behaving as expected. \n* **Use descriptive names:** Give your policies clear and descriptive names for easy maintenance. \n* **Be mindful of the scope of your filters:** You might be tempted to filter issues across groups where thousands of issues exist. However, this can slow down the triage and also make the process fail due to rate limitations against the GitLab API.  \n* **Prioritize using labels for triages:** To avoid spamming other users, labels are a good way to perform triages without cluttering comments and issues.\n\n## Take control of your workflow\n\nWith the `gitlab-triage` gem, you can automate your GitLab workflow and unlock new levels of efficiency. Start by creating simple triage bots and gradually explore the more advanced features. You'll be amazed at how much time and effort you can save\\!\n\n> #### Want to take your learning to the next level? [Sign up for GitLab University courses](https://university.gitlab.com/). Or you can get going right away with a [free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## \"Getting started with GitLab\" series\nRead more articles in our \"Getting started with GitLab\" series:\n\n- [How to manage users](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Mastering project management](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Understanding CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)\n- [Working with CI/CD variables](https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables/)\n",[475,671,14,1178,109],"agile",{"slug":1180,"featured":6,"template":674},"automating-agile-workflows-with-the-gitlab-triage-gem","content:en-us:blog:automating-agile-workflows-with-the-gitlab-triage-gem.yml","Automating Agile Workflows With The Gitlab Triage Gem","en-us/blog/automating-agile-workflows-with-the-gitlab-triage-gem.yml","en-us/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"_path":1186,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1187,"content":1192,"config":1198,"_id":1201,"_type":16,"title":1202,"_source":17,"_file":1203,"_stem":1204,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-17-9-2-17-8-5-17-7-7",{"title":1188,"description":1189,"ogTitle":1188,"ogDescription":1189,"noIndex":91,"ogImage":689,"ogUrl":1190,"ogSiteName":784,"ogType":785,"canonicalUrls":1190,"schema":1191},"GitLab Critical Patch Release: 17.9.2, 17.8.5, 17.7.7","Learn more about this critical patch release for GitLab Community Edition (CE) and Enterprise Edition (EE).","https://about.gitlab.com/blog/gitlab-critical-patch-release-17-9-2-17-8-5-17-7-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Patch Release: 17.9.2, 17.8.5, 17.7.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kevin Morrison\"}],\n        \"datePublished\": \"2025-03-12\",\n      }",{"title":1188,"description":1189,"authors":1193,"heroImage":689,"date":1195,"body":1196,"category":14,"tags":1197},[1194],"Kevin Morrison","2025-03-12","This is the post for [GitLab Critical Patch Release: 17.9.2, 17.8.5, 17.7.7](https://about.gitlab.com/releases/2025/03/12/patch-release-gitlab-17-9-2-released/).",[879],{"slug":1199,"featured":6,"template":674,"externalUrl":1200},"gitlab-critical-patch-release-17-9-2-17-8-5-17-7-7","https://about.gitlab.com/releases/2025/03/12/patch-release-gitlab-17-9-2-released/","content:en-us:blog:gitlab-critical-patch-release-17-9-2-17-8-5-17-7-7.yml","Gitlab Critical Patch Release 17 9 2 17 8 5 17 7 7","en-us/blog/gitlab-critical-patch-release-17-9-2-17-8-5-17-7-7.yml","en-us/blog/gitlab-critical-patch-release-17-9-2-17-8-5-17-7-7",{"_path":1206,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1207,"content":1213,"config":1222,"_id":1224,"_type":16,"title":1225,"_source":17,"_file":1226,"_stem":1227,"_extension":20},"/en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience",{"title":1208,"description":1209,"ogTitle":1208,"ogDescription":1209,"noIndex":6,"ogImage":1210,"ogUrl":1211,"ogSiteName":784,"ogType":785,"canonicalUrls":1211,"schema":1212},"Beautifying our UI: Enhancing GitLab's deployment experience","Go inside our innovative approach to improving our user interface, including pairing product designers and frontend engineers to make usability improvements across the platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097783/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5KLUrr4DkY2u0JTMA12FVm_1750097783460.png","https://about.gitlab.com/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Beautifying our UI: Enhancing GitLab's deployment experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Bauman\"}],\n        \"datePublished\": \"2025-03-06\",\n      }",{"title":1208,"description":1209,"authors":1214,"heroImage":1210,"date":1216,"body":1217,"category":14,"tags":1218},[1215],"Emily Bauman","2025-03-06","At GitLab, we’ve implemented an innovative approach to improving our experience called [Beautifying our UI](https://handbook.gitlab.com/handbook/product/ux/product-design/#beautifying-our-ui). This unique initiative pairs one product designer with a frontend engineer for a milestone or two, and empowers them to make self-directed usability improvements across the platform. Ultimately, this helps build a more polished product experience, as these pairs can quickly address pain points, refine interactions, and deliver thoughtful improvements that make the platform more efficient and enjoyable to use.\n\nIn this iteration, [Anna Vovchenko](https://gitlab.com/anna_vovchenko) and I decided to focus on the continuous deployment ([CD](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-deployment)) area of the product. Here is how we did it and what we learned.\n\n## Trying something new\n\nAs this was our second round going through the process, we wanted to make several small adjustments that in the end helped us deliver even more quality improvements to the product. These process improvements included: \n\n* **Extended timeline:** We decided this time around we wanted to extend the initiative to span two milestones. This gave us the time to tackle more complex problems, but also gave us space for additional planning at the start. \n* **Structured planning:** While it was encouraged in the past to work directly in merge requests, we found it helped to use the initial issue as a place to plan and seek out problems ahead of time. Rather than purely focusing on the ad-hoc, we incorporated a planning phase similar to milestone planning, helping the partnership identify and prioritize potential improvements beforehand.\n* **Product manager integration:** As we focused on one area for this round of the project, we also decided to involve the product manager of the team more actively in the process. This ensured alignment on larger changes, reduced surprises when MRs were merged and allowed us to gather valuable feedback throughout the implementation.\n* **Engaging the community:** We expanded our improvement efforts by inviting contributions from community members, accelerating our ability to implement fixes and enhancements across the platform.\n* **Strategic timing:** We chose to run this iteration during a traditionally slower period, allowing teams to focus more deeply on these improvements without competing priorities.\n\nThese refinements maintained the initiative's core strength of direct designer-engineer collaboration, while adding structure that helped our pair work more effectively.\n\n## What were the main improvements?\n\nDuring the two milestones, our pairing implemented several significant improvements that enhance the user experience across the CD space. Here's a look at what we accomplished:\n\n### Enhanced environment list view\n\nOne of the larger changes made during this cycle of \"Beautifying our UI\" was a redesigned Environment List page to make deployment information more accessible. Previously, users had to click through collapsible sections to view crucial deployment details, and viewing important details at a glance was difficult. Now, this information is immediately visible, bringing the most important deployment information to the forefront where users need it.\n\n![Beautifying UI - Environments page before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Before_Environments_Page_aHR0cHM6_1750097793301.png)\n\n**Before:** The original design relied on collapsible sections, requiring users to click to reveal deployment information. This meant that users couldn't immediately see the status of their deployments, making it harder to quickly assess the state of their environments.\n\n![Beautifying UI - Environments page after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/After_Environments_Page_aHR0cHM6_1750097793301.png)\n\n**After:** The new design surfaces critical deployment information directly in the list view, including:\n\n* Deployment status with clear visual indicators\n* Who triggered the deployment along with timestamps\n* Commit information and version tags\n* Actions to take on the environment\n* Latest deployment indicators\n\nThis redesign eliminates the need for extra clicks and gives users immediate visibility into their deployment and environment statuses. The new layout maintains a clean interface while presenting more actionable information upfront.\n\n### Improved deploy keys filtering\n\nAnother larger enhancement was made to our deploy keys interface to improve searchability while maintaining performance. This change addresses a critical user need for quickly finding specific deploy keys in large repositories, which was broken when pagination was introduced earlier last year.\n\n![Beautifying UI - Deploy key before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Deploy_Key_Before_aHR0cHM6_1750097793303.png)\n\n**Before:** The previous interface displayed deploy keys in a paginated list without a dedicated search function. While pagination helped with performance when handling thousands of keys, users had lost the ability to quickly search through their deploy keys using the browser search functionality, forcing them to manually scan through multiple pages.\n\n![Beautifying UI - Deploy key after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Deploy_Key_After_aHR0cHM6_1750097793306.png)\n\n**After:** The new design introduces a dedicated search field at the top of the deploy keys list, allowing users to:\n\n* Quickly filter deploy keys by name or SHA\n* Maintain the performance benefits of pagination\n* Find specific keys without browsing through multiple pages\n\nThis improvement strikes the right balance between performance and usability, especially beneficial for teams managing numerous deploy keys across multiple projects.\n\n### Better Kubernetes agent management\n\nWe made significant improvements to the Kubernetes agent experience by simplifying the registration process and providing better visibility into agent status. These enhancements work together to create a smoother onboarding experience for teams getting started.\n\nOur first area of focus was streamlining how users register agents when they have configuration files ready to use. Previously, this process had several pain points that we wanted to address.\n\n![Beautifying UI - Agent before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Agent_Before_aHR0cHM6_1750097793309.png)\n\n**Before:**\n\n* Only showed connected and previously connected agents\n* Connection status was limited to \"Never connected\" or \"Not connected\"\n* No clear path to register new agents\n\n![Beautifying UI - Agent after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Agent_After_aHR0cHM6_1750097793310.png)\n\n**After:**\n\n* Added a new Available configurations tab showing all potential agent configurations\n* Clear \"Register an agent\" call-to-action button for each available configuration\n\nNext, we turned our attention to making the agent registration modal more intuitive. The previous design created some confusion that we wanted to resolve.\n\n![Beautifying UI - Registration before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Registration_Before_aHR0cHM6_1750097793311.png)\n\n**Before:**\n\n* Users faced a confusing dual-purpose search box that both found existing agents and created new ones\n* The workflow had too many decision points instead of a clear path forward\n* The process for creating vs. selecting an agent wasn't clearly separated\n\n![Beautifying UI - Registration after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Registration_After_aHR0cHM6_1750097793312.png)\n\n**After:**\n\n* Separated the interface into two clear options: bootstrap with Flux or create an agent through the UI\n* Streamlined the workflow into a more linear process\n* Made the distinction between creating new agents and selecting existing ones more obvious\n* Added a success message that clearly shows where to create the optional config file\n\nThese improvements make it immediately clear which agents need attention and provide a straightforward path to register new agents. The reorganized interface better supports both new users setting up their first agent and experienced users managing multiple agents.\n\n## Additional usability enhancements\n\nWhile working on major interface improvements, we also addressed several focused usability issues that significantly improve the day-to-day experience:\n\n* **Enhanced Kubernetes pod search:** Added search functionality for Kubernetes pods on the environment page, making it easier to locate specific pods in large deployments. This was showcased in the [GitLab 17.8 release post](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#search-for-pods-on-the-dashboard-for-kubernetes).\n* **Improved Flux status visibility:** Added a \"stopped\" badge to the dashboard view when Flux sync is stopped, providing immediate visibility into sync status. This was also showcased in the [GitLab 17.8 release post](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#view-paused-flux-reconciliations-on-the-dashboard-for-kubernetes). \n* **Better release information:** Implemented a clear view of deployments related to a release, improving deployment tracking and visibility.\n* **Streamlined environment search:** Fixed an issue where users couldn't effectively search the Environments page, improving navigation in large environment lists.\n* **Enhanced error message display:** Resolved issues with viewing Flux details when long error messages were present, making troubleshooting more straightforward.\n\n## Looking forward\n\nThe success of these improvements demonstrates the value of empowering our teams to make direct, meaningful changes to our experience. Beyond the product enhancements, one of the most valuable outcomes has been the strengthened relationship between our Frontend and Design teams. Working together closely on these improvements has fostered better understanding of each other's perspectives, workflows, and constraints, leading to more effective collaboration.\n\nThis deepened partnership has created a foundation for even better collaboration in our regular workflow, as team members now have stronger working relationships and shared understanding of each other's domains. We're excited to continue this initiative in future iterations, not just for the product improvements it generates, but also for its role in building stronger, more cohesive teams.\n\n> [Follow along with the \"Beautifying our UI\" project](https://handbook.gitlab.com/handbook/product/ux/product-design/#beautifying-our-ui) as we continue to make improvements to GitLab.\n\n## Read more\n\n- [How we overhauled GitLab navigation](https://about.gitlab.com/blog/navigation-research-blog-post/)\n- [GitLab dark mode is getting a new look](https://about.gitlab.com/blog/gitlab-dark-mode-is-getting-a-new-look/)\n- [Beautifying our UI: Giving GitLab build features a fresh look](https://about.gitlab.com/blog/beautifying-of-our-ui/)",[1219,1220,1221,14,475],"design","UX","UI",{"slug":1223,"featured":6,"template":674},"beautifying-our-ui-enhancing-gitlabs-deployment-experience","content:en-us:blog:beautifying-our-ui-enhancing-gitlabs-deployment-experience.yml","Beautifying Our Ui Enhancing Gitlabs Deployment Experience","en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience.yml","en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience",{"_path":1229,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1230,"content":1236,"config":1242,"_id":1244,"_type":16,"title":1245,"_source":17,"_file":1246,"_stem":1247,"_extension":20},"/en-us/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"title":1231,"description":1232,"ogTitle":1231,"ogDescription":1232,"noIndex":6,"ogImage":1233,"ogUrl":1234,"ogSiteName":784,"ogType":785,"canonicalUrls":1234,"schema":1235},"Build a new website in a few easy steps with GitLab Pages ","This tutorial shows you how to create and host your personal website using GitLab Pages with a ready-to-use template that you can customize in minutes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097716/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_7c3TDgNgct9xQbmTJSw0de_1750097716096.png","https://about.gitlab.com/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Build a new website in a few easy steps with GitLab Pages \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alex Fracazo\"}],\n        \"datePublished\": \"2025-03-03\",\n      }",{"title":1231,"description":1232,"authors":1237,"heroImage":1233,"date":1239,"body":1240,"category":14,"tags":1241},[1238],"Alex Fracazo","2025-03-03","A personal website is more than just a utility for digital creators and professionals in tech. It's a representation of your brand. But creating one from scratch can be time-consuming and expensive.\n\nWith [GitLab Pages](https://docs.gitlab.com/user/project/pages/), you can host your website with built-in features, including SSL certificates and a GitLab-provided domain. All of this is available on GitLab's free tier, making it an efficient solution for hosting your professional presence.\n\nWe're going to take you on a fun journey to craft a stunning personal website using GitLab Pages! We’ve got a super simple, versatile template that you can easily jazz up to reflect your unique style. So grab your favorite snack, get comfy, and let’s turn your online presence into something truly fabulous!\n\n## Prerequisites\n\nYou will need the following prerequisites before getting started:\n\n* A GitLab account (the [free tier](https://about.gitlab.com/pricing/) is sufficient)  \n* Basic familiarity with HTML/CSS  \n* Content and images you want to add to your website (optional)\n\nOnce you’re set up with a GitLab account and have your content handy, you can move on to the next steps.\n\n## Step 1: Create a new project\n\n1. Sign on to your GitLab account and create a project.\n\n![GitLab Pages tutorial - welcome screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097724/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183716_aHR0cHM6_1750097724662.png)\n\n2. Click **Create blank project**.\n\n![GitLab Pages tutorial - Create new project screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183814_aHR0cHM6_1750097724663.png)\n\n3. Fill in your project details:\n    * Name your project `yourusername.gitlab.io`. Replace `yourusername` with your GitLab username. **Tip:** The project name determines your website’s URL. If you name your project `yourusername.gitlab.io`, your website will be available at `https://yourusername.gitlab.io` with no additional path. However, if you use any other project name, your site will be available at `https://yourusername.gitlab.io/project-name`.\n    * Make the project public.\n4. Click **Create project**.\n\n![GitLab Pages tutorial - Create blank project screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097724666.png)\n\n![GitLab Pages tutorial - customized get started page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097724668.png)\n\n## Step 2: Add the template files\n\nStart by creating two new files in your repository:\n\n![GitLab Pages tutorial - Add new files to personal page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097724669.png)\n\n1. First, create `index.html`:\n    * In your project, click the **+** button and select **New file**.\n    * Name the file `index.html`.\n![GitLab Pages tutorial - new file page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097724671.png)\n    * Add your HTML content.\n        * Use the example HTML provided below. (Pro tip: Users can ask GitLab Duo Chat to generate HTML for enhanced functionality.)\n\n```    \n\u003C!DOCTYPE html>\n\u003Chtml>\n\u003Chead>\n    \u003Cmeta charset=\"utf-8\"/>\n    \u003Ctitle>[Your Name] - [Your Title]\u003C/title>\n    \u003Cmeta name=\"description\" content=\"[Your Name] is a [Your Title].\"/>\n    \u003Cmeta name=\"author\" content=\"[Your Name]\"/>\n    \u003Cmeta property=\"og:title\" content=\"[Your Name]\" />\n    \u003Cmeta property=\"og:description\" content=\"[Your Title]\" />\n    \u003Cmeta property=\"og:image\" content=\"og.png\" />\n    \u003Cmeta name=\"viewport\" content=\"width=device-width,initial-scale=1\"/>\n    \u003Clink href=\"https://unpkg.com/basscss@8.0.2/css/basscss.min.css\" rel=\"stylesheet\">\n    \u003Clink href=\"style.css\" rel=\"stylesheet\">\n    \u003Clink rel=\"shortcut icon\" type=\"image/png\" href=\"favicon.png\"/>\n\u003C/head>\n\u003Cbody>\n\u003Cdiv class=\"content\" id=\"content\">\n  \u003Cdiv class=\"p2 sm-p4 mt2 sm-mt4 mb2 sm-mb4\">  \n  \u003Cdiv class=\"fade mt3\">\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">\n      \u003Cimg class=\"photo\" src=\"profile.png\" width=\"64\" height=\"64\">\n    \u003C/a>\n  \u003C/div>\n  \u003Ch2 class=\"mb0 mt4 fade\">\n    Hello, I'm [Your Name] \n    \u003Cspan class=\"smallcaps\">(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Your Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/h2>\n  \u003Ch2 class=\"mt0 mb4 fade gray\">\n    I'm a [Your Title]\n  \u003C/h2>\n  \u003Cp class=\"mb4 fade\">\n    I'm a [Your Role] at [Your Company], [Brief company description].\n  \u003C/p>\n  \u003Cdiv class=\"fade\">\n    \u003Cp class=\"fade mb4\">\n      Your personal statement about what you do and what you're interested in. Add your contact preferences here.\n    \u003C/p>\n  \u003C/div>\n  \u003Cp class=\"fade mb4\">\n    \u003Cspan class=\"gray\">—\u003C/span> \n    [Your Name] \n    \u003Cspan class=\"smallcaps>(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Your Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/p>\n  \u003C/div>\n\u003C/div>\n\u003C/body>\n\u003C/html> \n```\n\n* Add a commit message (e.g., \"Added index.html\").\n  * Click **Commit changes**.\n\n2. Create `style.css` (follow same steps above).\n\n```\nbody {\n  margin: 0;\n  padding: 0;\n  background: #000;\n  color: #f4f4f4;\n  font-family: \"Graphik Web\", system-ui, -apple-system, BlinkMacSystemFont, \"Helvetica Neue\", \"Helvetica\", \"Segoe UI\", Roboto, Ubuntu, sans-serif;\n  font-weight: 400;\n  font-smooth: antialiased;\n  -webkit-font-smoothing: antialiased;\n  -moz-osx-font-smoothing: grayscale;\n}\n\na {\n  color: #ff310a;\n  text-decoration: none;\n}\n\na:hover {\n  color: #CFEF54\n}\n\n.content {\n  max-width: 40rem;\n  margin: 0 auto;\n}\n\nimg.photo {\n  border-radius: 50%;\n}\n\np {\n  font-size: 1.5rem;\n  line-height: 1.4;\n  margin: 0;\n  letter-spacing: -0.05rem;\n}\n\nh2 {\n  font-weight: 400;\n  line-height: 1.3;\n  letter-spacing: -0.05rem;\n}\n\n.smallcaps {\n  font-variant: small-caps;\n  color:#333;\n}\n\n.gray{\n  color: #999;\n}\n\n.preloader {\n  display: flex;\n  justify-content: center;\n  align-items: center;\n  height: 100vh;\n  height: -moz-available;\n  height: -webkit-fill-available;\n  height: fill-available;\n  width: 100%;\n  background: #000;\n  position: fixed;\n  top: 0;\n  left: 0;\n  z-index: 9999;\n  transition: opacity 0.3s linear;\n  transform: translate3d(0, 0, 0);\n}\n\nbody.loaded .preloader {\n  opacity: 0;\n}\n\n.fade {\n  animation: fadeIn 1s ease-in-out both;\n}\n\n.fade:nth-child(2) {\n\tanimation-delay: 1s;\n}\n\n.fade:nth-child(3) {\n\tanimation-delay: 2s;\n}\n\n.fade:nth-child(4) {\n\tanimation-delay: 3s;\n}\n\n.fade:nth-child(5) {\n\tanimation-delay: 4s;\n}\n\n.fade:nth-child(6) {\n\tanimation-delay: 5s;\n}\n\n.fade:nth-child(7) {\n\tanimation-delay: 6s;\n}\n\n.fade:nth-child(8) {\n\tanimation-delay: 7s;\n}\n\n.fade:nth-child(9) {\n\tanimation-delay: 8s;\n}\n\n.fade:nth-child(10) {\n\tanimation-delay: 9s;\n}\n\n.fade:nth-child(11) {\n\tanimation-delay: 10s;\n}\n\n.fade:nth-child(12) {\n\tanimation-delay: 11s;\n}\n\n.fade:nth-child(13) {\n\tanimation-delay: 12s;\n}\n\n@keyframes fadeIn {\n\tfrom {\n\t\topacity: 0;\n\t\ttransform: translate3d(0, 0%, 0);\n\t}\n\tto {\n\t\topacity: 1;\n\t\ttransform: translate3d(0, 0, 0);\n\t}\n} \n\n```\n\n## Step 3: Configure GitLab CI file\n\nThere are two ways to create the GitLab CI configuration file that tells GitLab how to build and deploy your site:\n\n![GitLab Pages tutorial - optimize your workflow with CI/CD pipelines screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097724672.png)\n\n**Option 1: Use Pipeline Editor (recommended)**\n\n1. Go to your project's **Build > Pipeline Editor**.\n\n![GitLab Pages tutorial - pipeline editor/main branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097724673.png)\n\n2. The `.gitlab-ci.yml` file will be automatically created. \n3. Copy and paste the following configuration: \n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\n![GitLab Pages Tutorial - New file in window](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097724674.png)\n\n**Option 2: Manual creation**\n\nIf you prefer to create the file manually: \n1. Create a new file named `.gitlab-ci.yml`. \n2. Add the following configuration:\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\nThe key to getting your site running is the GitLab CI configuration file. This file tells GitLab how to build and deploy your site.\n\nLet's break down what each part does:\n\n**The script part**\n\n```\nscript:\n  - mkdir .public\n  - cp -r * .public\n  - mv .public public\n```\n\nThis creates a folder called `public` and copies all your website files into it. GitLab Pages uses this folder to serve your website by default, though you can [customize the publishing folder](https://docs.gitlab.com/user/project/pages/introduction/#customize-the-default-folder) if needed.\n\n**The only part**\n\n```\nonly:\n  - main\n\n```\n\nThis tells GitLab to only update your website when changes are made to the main branch. This helps prevent accidental updates from experimental changes.\n\n## Step 4: Watch the magic happen\n1. Commit all your changes.\n2. Go to **Build > Pipelines** to watch your deployment.\n3. Wait for the pipeline to complete successfully (indicated by a green checkmark).\n\n![GitLab Pages tutorial - pipeline running for new page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097724676.png)\n\n![GitLab Pages tutorial - pipeline passed for new page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097724677.png)\n\n## Step 5: Access your website\n\nOnce the pipeline completes successfully, your website will be available at: **https://[yourusername].gitlab.io/** .\n\nYou can find an overview of your deployed website and additional settings in your project's **Deploy > Pages** section. Here you'll find useful information. including: \n\n* Your website's access URLs   \n* Domain settings  \n  * By default GitLab enables **Unique domain**. Make sure to disable it if you want to use the GitLab-provided domain. Learn more with the [unique domain documentation](https://docs.gitlab.com/ee/user/project/pages#unique-domains).  \n* HTTPS certificates status   \n* Recent deployments   \n* Additional configuration options\n* Custom domains\n\nThis section is particularly helpful when setting up custom domains or troubleshooting deployment issues.\n\n**Customize your site**\n\n![GitLab Pages tutorial - customize site](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097724678.png)\n\n1. Replace all “Your ...” placeholders in `index.html` with your information.\n\n![GitLab Pages tutorial - upload file to customize page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097724679.png)\n\n2. Add your images:\n    - profile.png - your profile photo (64x64px)\n    - favicon.png - your site favicon (32x32px)\n    - Og.png - OpenGraph image for social media preview (1200x630px)\n\n**See it in action**\n\nIf you're familiar with GitLab, feel free to [fork my repository](https://gitlab.com/fracazo/fracazo.gitlab.io) to get started quickly. \n\nHere is the final result:\n[https://fracazo.gitlab.io/](https://fracazo.gitlab.io/)\n\n**Common issues and solutions**\n- By default, GitLab enables \"Unique domain\" for Pages projects. To use the simpler GitLab-provided domain (like `username.gitlab.io`), go to **Deploy > Pages** and disable the \"Use unique domain\" option. While unique domains offer some technical advantages, like better asset path handling, you might prefer the cleaner URL structure for a personal website.\n- If your pipeline fails, check that you're using `main` instead of `master` in your `.gitlab-ci.yml` file.\n- Ensure your group and project is public for GitLab Pages to work.\n- If any jobs fail in your pipeline, you can check the job log for detailed error messages to help with troubleshooting.\n\nWith GitLab Pages and this template, you can have a professional/personal website up and running in minutes. The template is clean, responsive, and easy to customize. As you grow professionally, you can easily update your site directly through GitLab. \n\nYou can automate the deployment process by leveraging GitLab's CI/CD capabilities and focusing on creating great content.\n\nThe best part? All of this is available on GitLab's free tier, making it an excellent option for free hosting of your personal projects, documentation sites, or even small business websites. For more advanced features and configurations, check out our [Pages documentation](https://docs.gitlab.com/ee/user/project/pages/).\n\n## What’s next for GitLab Pages?\nWe're constantly working to make GitLab Pages even better for creators and developers. Here are some exciting improvements coming soon: \n\n### Simplified domain management \nWe have some exciting updates coming to GitLab Pages that will make managing your domains even easier and more fun! You can look forward to a streamlined dashboard that brings all your domain settings together in one friendly space, making everything easily accessible. \n\nYou’ll stay informed with real-time updates on your DNS and SSL certificate statuses, helping you keep your domains secure and running smoothly. \n\n### Custom domain setup\nSetting up custom domains will be a breeze with our easy-to-follow process, guiding you every step of the way. Plus, you'll be able to set up your custom domains to automatically redirect visitors from your old website address to your new one – perfect for when you want all your traffic to go to one main website. Learn more about [custom domains](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#set-up-a-custom-domain).\n\n> Get started with GitLab Pages today with [GitLab's free tier](https://about.gitlab.com/pricing/)! \n\n## Learn more\n- [GitLab Pages features review apps and multiple website deployment](https://about.gitlab.com/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment/)\n- [GitLab Pages: Multiple website deployment documentation](https://docs.gitlab.com/user/project/pages/#parallel-deployments)\n- [GitLab Pages examples](https://gitlab.com/pages)",[671,475],{"slug":1243,"featured":6,"template":674},"build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","content:en-us:blog:build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","Build A New Website In A Few Easy Steps With Gitlab Pages","en-us/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","en-us/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"_path":1249,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1250,"content":1256,"config":1261,"_id":1263,"_type":16,"title":1264,"_source":17,"_file":1265,"_stem":1266,"_extension":20},"/en-us/blog/build-and-run-containers-in-remote-development-workspaces",{"title":1251,"description":1252,"ogTitle":1251,"ogDescription":1252,"noIndex":6,"ogImage":1253,"ogUrl":1254,"ogSiteName":784,"ogType":785,"canonicalUrls":1254,"schema":1255},"Build and run containers in Remote Development workspaces","Use this easy-to-follow tutorial to create a secure, ephemeral, reproducible development environment in GitLab that can replace your local environments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663857/Blog/Hero%20Images/blog-image-template-1800x945__12_.png","https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Build and run containers in Remote Development workspaces\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vishal Tak\"}],\n        \"datePublished\": \"2025-03-03\",\n      }",{"title":1251,"description":1252,"authors":1257,"heroImage":1253,"date":1239,"body":1259,"category":14,"tags":1260},[1258],"Vishal Tak","Development environments often require the ability to build and run containers as part of their local development. Securely running containers within containers can be challenging. This article will provide a step-by-step guide to securely build and run containers in a workspace.\n\nYou will learn how to:\n- [Create a Kubernetes cluster on AWS EKS](#create-a-kubernetes-cluster-on-aws-eks)\n- [Configure Sysbox](#configure-sysbox)\n- [Configure GitLab agent for Kubernetes and GitLab Workspaces Proxy](#configure-gitlab-agent-for-kubernetes-and-gitlab-workspaces-proxy)\n- [Configure sudo access for a workspace with Sysbox](#configure-sudo-access-for-a-workspace-with-sysbox)\n- [Configure Ingress Controller](#configure-ingress-controller)\n- [Build containers inside a workspace](#build-containers-inside-a-workspace)\n- [Run containers inside a workspace](#run-containers-inside-a-workspace)\n- [Get started today](#get-started-today)\n\n## Create a Kubernetes cluster on AWS EKS\nInstall the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) on your local machine. Next, configure a [named profile](https://docs.aws.amazon.com/cli/latest/reference/configure/) and export it to ensure all the following `aws` commands use the set credentials.\n\n```\naws configure --profile gitlab-workspaces-container-demo\nexport AWS_PROFILE=gitlab-workspaces-container-demo\n```\n\nInstall [eksctl](https://eksctl.io/installation/), a CLI to interact with AWS EKS. Let’s now create a Kubernetes 1.31 cluster on AWS EKS with 1 node of Ubuntu 22.04 of `c5.2xlarge` instance type. The nodes can autoscale from 0-20 nodes and each node will have a label `sysbox-install: yes` . This will be explained later in the article.\n\n```\nexport CLUSTER_NAME=\"gitlab-workspaces-container-demo-eks-sysbox\"\n\neksctl create cluster \\\n  --name \"${CLUSTER_NAME}\" \\\n  --version 1.31 \\\n  --node-ami-family=Ubuntu2204 \\\n  --nodes=1 \\\n  --nodes-min=0 \\\n  --nodes-max=20 \\\n  --instance-types=c5.2xlarge \\\n  --node-labels \"sysbox-install=yes\" \\\n  --asg-access \\\n  --external-dns-access \\\n  --full-ecr-access\n```\n\nCreate an [IAM OIDC](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) provider for your cluster.\n\n```\neksctl utils associate-iam-oidc-provider --cluster \"${CLUSTER_NAME}\" --approve\n```\n\nCreate IAM role for [EBS add-on](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) for EKS.\n\n```\neksctl create iamserviceaccount \\\n  --name ebs-csi-controller-sa \\\n  --namespace kube-system \\\n  --cluster \"${CLUSTER_NAME}\" \\\n  --role-name \"AmazonEKS_EBS_CSI_DriverRole_${CLUSTER_NAME}\" \\\n  --role-only \\\n  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \\\n  --approve\n```\n\nCreate Amazon EBS CSI driver add-on for Amazon EKS cluster.  \n\n```\neksctl utils describe-addon-versions --kubernetes-version 1.31 | grep aws-ebs-csi-driver\n\nexport AWS_ACCOUNT_ID=\"UPDATE_ME\"\n\neksctl create addon \\\n  --cluster \"${CLUSTER_NAME}\" \\\n  --name aws-ebs-csi-driver \\\n  --version latest \\\n  --service-account-role-arn \"arn:aws:iam::${AWS_ACCOUNT_ID}:role/AmazonEKS_EBS_CSI_DriverRole_${CLUSTER_NAME}\" \\\n  --force\n```\n\nInstall [kubectl](https://kubernetes.io/docs/reference/kubectl/), a command line tool for communicating with a Kubernetes cluster's control plane, using the Kubernetes API.\n\nLet’s get the [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) of the created cluster.\n\n```\naws eks update-kubeconfig --name \"${CLUSTER_NAME}\"\n```\n\n## Configure Sysbox\n\n[Sysbox](https://github.com/nestybox/sysbox) is a container runtime that improves container isolation and enables containers to run the same workloads as virtual machines.\n\n[Install](https://github.com/nestybox/sysbox#installation) Sysbox on the Kubernetes cluster using the `sysbox-deploy-k8s daemonset`.\n\n```\ncurl https://raw.githubusercontent.com/nestybox/sysbox/refs/tags/v0.6.6/sysbox-k8s-manifests/sysbox-install.yaml -o sysbox-install.yaml\n```\n\nBecause of how Sysbox releases itself, it first created a git tag, which runs a pipeline to build assets after which the YAML files for the `sysbox-deploy-k8s daemonset` are updated. Thus, we need to update the DaemonSet's `spec.template.soec.containers[0].image` to [registry.nestybox.com/nestybox/sysbox-deploy-k8s:v0.6.6-0](https://github.com/nestybox/sysbox/blob/46ba726e8e894aa22e20465a32d22dfa2863ec12/sysbox-k8s-manifests/sysbox-install.yaml#L66) .\n\n```\nnew_image_value=\"registry.nestybox.com/nestybox/sysbox-deploy-k8s:v0.6.6-0\"\ntemp_file=$(mktemp)\nsed -E \"s|^([[:space:]]*image:)[[:space:]]*.*|\\1 $new_image_value|\" \"sysbox-install.yaml\" > \"$temp_file\"\nmv \"$temp_file\" \"sysbox-install.yaml\"\n```\n\nApply the YAML file to Kubernetes and ensure all the pods of the DaemonSet are running.\n\n```\nkubectl apply -f sysbox-install.yaml\nkubectl get pod -A\nkubectl -n kube-system get daemonset\n```\n\nVerify the installation by creating a pod which uses Sysbox container runtime.\n\n```\ncat \u003C\u003CEOF | kubectl apply -f -\napiVersion: v1\nkind: Pod\nmetadata:\n  name: sysbox-verification-pod\n  namespace: default\n  annotations:\n    io.kubernetes.cri-o.userns-mode: \"auto:size=65536\"\nspec:\n  runtimeClassName: sysbox-runc\n  containers:\n  - image: \"hello-world\"\n    imagePullPolicy: Always\n    name: main\n  restartPolicy: Always\nEOF\n\nkubectl -n default get pod sysbox-verification-pod\nkubectl exec -it sysbox-verification-pod -- echo \"Pod is running successfully on a Kubernetes cluster configured with Sysbox.\"\nkubectl -n default delete pod sysbox-verification-pod\n```\n\n## Configure GitLab agent for Kubernetes and GitLab Workspaces Proxy\n\nFollow our [documentation tutorial](https://docs.gitlab.com/ee/user/workspace/set_up_gitlab_agent_and_proxies.html) to set up GitLab agent and GitLab Workspaces Proxy.  \n\n## Configure sudo access for a workspace with Sysbox\n\nFollow our [documentation](https://docs.gitlab.com/ee/user/workspace/configuration.html#with-sysbox) to configure sudo access for a workspace with Sysbox.\n\n## Configure Ingress Controller\n\nSetup [Ingress NGINX Controller for Kubernetes](https://github.com/kubernetes/ingress-nginx)\n\n```\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx --force-update\nhelm repo update\n\nhelm upgrade --install \\\n  ingress-nginx ingress-nginx/ingress-nginx \\\n  --namespace ingress-nginx \\\n  --create-namespace \\\n  --version 4.11.1 \\\n  --timeout=600s --wait --wait-for-jobs\n\nkubectl -n ingress-nginx get pod\n```\n\n## Build containers inside a workspace\n\nWe’ll use [example-go-http-app](https://gitlab.com/gitlab-org/workspaces/examples/example-go-http-app) as the project to create a workspace from. Open the workspace, start a terminal, and install [Docker](https://docs.docker.com/engine/install/).\n\n```\n# Add Docker's official GPG key:\nsudo apt-get update\nsudo apt-get install ca-certificates curl\nsudo install -m 0755 -d /etc/apt/keyrings\nsudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc\nsudo chmod a+r /etc/apt/keyrings/docker.asc\n\n# Add the repository to Apt sources:\necho \\\n  \"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \\\n  $(. /etc/os-release && echo \"${UBUNTU_CODENAME:-$VERSION_CODENAME}\") stable\" | \\\n  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null\nsudo apt-get update\nsudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin\n\n# Start the Docker Daemon\nsudo dockerd\n```\n\nBuild the container image.\n\n```\nsudo docker build -t workspaces-golang-server .\n```\n\n## Run containers inside a workspace\n\nLet’s run the container built above and expose port 3000 from the container onto the host (workspace).\n\n```\nsudo docker run -p 3000:3000 workspaces-golang-server\n```\n\nThe port `3000` is exposed in the [.devfile.yaml](https://gitlab.com/gitlab-org/workspaces/examples/example-go-http-app/-/blob/dd3dbb38cdce1143f7ed023980f34630cea991a5/.devfile.yaml#L15) used to create the workspace. Access the server running inside the container from the browser. Here is a video clip.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/JQErF0U6oFk?si=6oiK48q5ghZq312g\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Get started today\n\nFrom GitLab 17.4, you can build and run containers securely in GitLab Workspaces. See our [documentation](https://docs.gitlab.com/ee/user/workspace/configuration.html#build-and-run-containers-in-a-workspace) for more information. Replace your local development environments to GitLab Workspaces for a secure, ephemeral, reproducible development environment. \n\n## Read more\n\n- [Enable secure sudo access for GitLab Remote Development workspaces](https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces/)\n- [Quickstart guide for GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/)\n- [Create a workspace quickly with the GitLab default devfile](https://about.gitlab.com/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile/)\n- [Contributor how-to: Remote Development workspaces and GitLab Developer Kit](https://about.gitlab.com/blog/gitlab-gdk-remote-development/)\n",[671,475,794,14],{"slug":1262,"featured":91,"template":674},"build-and-run-containers-in-remote-development-workspaces","content:en-us:blog:build-and-run-containers-in-remote-development-workspaces.yml","Build And Run Containers In Remote Development Workspaces","en-us/blog/build-and-run-containers-in-remote-development-workspaces.yml","en-us/blog/build-and-run-containers-in-remote-development-workspaces",{"_path":1268,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1269,"content":1275,"config":1282,"_id":1284,"_type":16,"title":1285,"_source":17,"_file":1286,"_stem":1287,"_extension":20},"/en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile",{"title":1270,"description":1271,"ogTitle":1270,"ogDescription":1271,"noIndex":6,"ogImage":1272,"ogUrl":1273,"ogSiteName":784,"ogType":785,"canonicalUrls":1273,"schema":1274},"Create a workspace quickly with the GitLab default devfile","The GitLab default devfile makes it easier than ever to try out workspaces for new projects. Learn how to share developer environment configurations effortlessly with this tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097860/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%281%29_2XDPsbkjQ3o6tcdom6IGxI_1750097859914.png","https://about.gitlab.com/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Create a workspace quickly with the GitLab default devfile\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Zhaochen Li\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":1270,"description":1271,"authors":1276,"heroImage":1272,"date":1278,"body":1279,"category":14,"tags":1280},[1277],"Zhaochen Li","2025-02-27","Software development environments can be complex to set up and maintain. Developers often spend a significant amount of time configuring their local environments with the right dependencies, tools, and settings. GitLab aims to solve this by providing a default devfile that enables you to create workspaces and to start developing quickly.\n\n## GitLab Workspaces\n\nGitLab Workspaces provide isolated development environments for making changes to your GitLab projects without the complexity of setting up local dependencies. Workspaces ensure reproducible development setups, allowing developers to share their environment configurations effortlessly.\n\nBy default, GitLab Workspaces are configured to use the GitLab VS Code fork and include the GitLab Workflow extension. To learn more, visit [the GitLab Workspaces documentation](https://docs.gitlab.com/ee/user/workspace/).\n\n## Understand devfiles\n\nA [**devfile**](https://devfile.io/docs/2.2.0/devfile-ecosystem) is a YAML-based declarative configuration file that defines a project's development environment. It specifies the necessary tools, languages, runtimes, and other components required for development.\n\nPreviously, [setting up a workspace](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) required a custom devfile at the root of the repository. For example, a `.devfile.yaml` file. A typical devfile looked like this:\n\n![typical default devfile](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-26_at_8.15.58_AM_aHR0cHM6_1750097868229.png)\n\n## GitLab default devfile\n\nStarting in GitLab 17.9, a GitLab default devfile is available for all projects when creating a workspace. This eliminates the need to manually create a devfile before starting a workspace.\nHere is the content of the default devfile:\n\n![GitLab default devfile content](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-26_at_8.16.20_AM_aHR0cHM6_1750097868230.png)\n\nWhen creating a workspace with the GitLab UI, the option **Use GitLab default devfile** is always available – regardless of whether custom devfiles exist in the repository. Simply select this option to start exploring GitLab Workspaces with one less setup step.\n\n![Use GitLab default devfile screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097868232.png)\n\n## Create your own custom devfiles\nWhile the GitLab default devfile provides a quick way to start a workspace, you may want to customize your development environment to better fit your project's needs. By creating a custom devfile, you can tailor your development environment with the exact tools, dependencies, and configurations needed for your workflow.\n\nConsider creating a custom devfile if you need to:\n\n- Add project-specific dependencies beyond the base development image.\n- Adjust CPU and memory resource limits.\n- Configure multiple containers for additional services like databases.\n- Define custom, project-specific, environment variables.\n- Set up specific port mappings.\n- Integrate specialized development tools like debuggers or language servers.\n\nFor more details, see the [Workspaces devfile documentation](https://docs.gitlab.com/ee/user/workspace/#devfile).\n\n## Read more\n\n- [Build and run containers in Remote Development workspaces](https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces/)\n- [Use GitLab AI features out-of-the-box in a GitLab Workspace](https://about.gitlab.com/blog/use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace/)\n- [Quickstart guide for GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/)\n- [Enable secure sudo access for GitLab Remote Development workspaces](https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces/)\n",[1281,475,794,671,14],"collaboration",{"slug":1283,"featured":6,"template":674},"create-a-workspace-quickly-with-the-gitlab-default-devfile","content:en-us:blog:create-a-workspace-quickly-with-the-gitlab-default-devfile.yml","Create A Workspace Quickly With The Gitlab Default Devfile","en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile.yml","en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile",{"_path":1289,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1290,"content":1295,"config":1300,"_id":1303,"_type":16,"title":1304,"_source":17,"_file":1305,"_stem":1306,"_extension":20},"/en-us/blog/gitlab-patch-release-17-9-1-17-8-4-17-7-6",{"title":1291,"description":1292,"ogTitle":1291,"ogDescription":1292,"noIndex":91,"ogImage":689,"ogUrl":1293,"ogSiteName":784,"ogType":785,"canonicalUrls":1293,"schema":1294},"GitLab Patch Release: 17.9.1, 17.8.4, 17.7.6","Learn more about this release for GitLab Community Edition (CE) and Enterprise Edition (EE).","https://about.gitlab.com/blog/gitlab-patch-release-17-9-1-17-8-4-17-7-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.9.1, 17.8.4, 17.7.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Costel Maxim\"}],\n        \"datePublished\": \"2025-02-26\",\n      }",{"title":1291,"description":1292,"authors":1296,"heroImage":689,"date":1297,"body":1298,"category":14,"tags":1299},[766],"2025-02-26","This is the post for [GitLab Patch Release: 17.9.1, 17.8.4, 17.7.6](https://about.gitlab.com/releases/2025/02/26/patch-release-gitlab-17-9-1-released/).\n",[879],{"slug":1301,"featured":6,"template":674,"externalUrl":1302},"gitlab-patch-release-17-9-1-17-8-4-17-7-6","https://about.gitlab.com/releases/2025/02/26/patch-release-gitlab-17-9-1-released/","content:en-us:blog:gitlab-patch-release-17-9-1-17-8-4-17-7-6.yml","Gitlab Patch Release 17 9 1 17 8 4 17 7 6","en-us/blog/gitlab-patch-release-17-9-1-17-8-4-17-7-6.yml","en-us/blog/gitlab-patch-release-17-9-1-17-8-4-17-7-6",{"_path":1308,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1309,"content":1315,"config":1321,"_id":1324,"_type":16,"title":1325,"_source":17,"_file":1326,"_stem":1327,"_extension":20},"/en-us/blog/gitlab-17-9-released",{"title":1310,"description":1311,"ogTitle":1310,"ogDescription":1311,"noIndex":91,"ogImage":1312,"ogUrl":1313,"ogSiteName":784,"ogType":785,"canonicalUrls":1313,"schema":1314},"GitLab 17.9 released","Includes GitLab Duo Self-Hosted available in GA, the ability to run multiple GitLab Pages sites with parallel deployments, automatic deletion of older pipelines, and more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662202/Blog/Hero%20Images/product-gl17-blog-release-cover-17-9-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-9-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.9 released\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rutvik Shah\"}],\n        \"datePublished\": \"2025-02-20\",\n      }",{"title":1310,"description":1311,"authors":1316,"heroImage":1312,"date":1318,"body":1319,"category":14,"tags":1320},[1317],"Rutvik Shah","2025-02-20","This is the blog post for the [GitLab 17.9 release](https://about.gitlab.com/releases/2025/02/20/gitlab-17-9-released/).",[752],{"slug":1322,"featured":91,"template":674,"externalUrl":1323},"gitlab-17-9-released","https://about.gitlab.com/releases/2025/02/20/gitlab-17-9-released/","content:en-us:blog:gitlab-17-9-released.yml","Gitlab 17 9 Released","en-us/blog/gitlab-17-9-released.yml","en-us/blog/gitlab-17-9-released",{"_path":1329,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1330,"content":1336,"config":1342,"_id":1344,"_type":16,"title":1345,"_source":17,"_file":1346,"_stem":1347,"_extension":20},"/en-us/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":1331,"description":1332,"ogTitle":1331,"ogDescription":1332,"noIndex":6,"ogImage":1333,"ogUrl":1334,"ogSiteName":784,"ogType":785,"canonicalUrls":1334,"schema":1335},"Structuring the GitLab Package Registry for enterprise scale","Learn how to leverage GitLab's unique project-based publishing model alongside root-group-level consumption to create a secure, flexible package management strategy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662332/Blog/Hero%20Images/blog-image-template-1800x945__23_.png","https://about.gitlab.com/blog/structuring-the-gitlab-package-registry-for-enterprise-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Structuring the GitLab Package Registry for enterprise scale\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":1331,"description":1332,"authors":1337,"heroImage":1333,"date":1338,"body":1339,"category":14,"tags":1340},[748],"2025-02-19","As organizations grow, managing internal packages becomes increasingly complex. While traditional package managers, like JFrog Artifactory and Sonatype Nexus, use a centralized repository approach, GitLab takes a different path that aligns with modern development teams' work. In this post, we'll explore how to effectively structure your GitLab Package Registry for enterprise scale, focusing on Maven and npm packages as examples.\n\n## Understanding the GitLab Package Registry model\n\nIf you're coming from a traditional package manager, GitLab's approach might initially seem different. Instead of a single centralized repository, GitLab integrates package management directly into your existing project and group structure. This means:\n\n- Teams publish packages to specific projects where the code lives\n- Teams consume packages from root group registries that aggregate all packages below them\n- Access control inherits from your existing GitLab permissions\n\nThis model offers several advantages:\n\n- Clear ownership of packages alongside their source code\n- Granular access control without additional configuration\n- Simplified CI/CD integration\n- Natural alignment with team structures\n- Single URL for accessing all company packages through root group consumption\n\n### The power of root group package registry\n\nWhile GitLab supports package consumption at various group levels, using the root group level has emerged as a best practice among our users. Here's why:\n\n- **Single access point:** One URL provides access to all private packages across your organization\n- **Consistent package naming:** Group-level endpoints allow teams to maintain their preferred naming conventions without conflicts\n- **Simplified configuration:** All developers can use the same configuration to access packages\n- **Secure access management:** Combines with deploy tokens for easy rotation and access control\n- **Hierarchical organization**: Naturally maps to your organizational structure while maintaining unified access\n\n## Real-world example: Enterprise structure\n\nLet's look at how this works in practice with a large enterprise:\n\n```\ncompany/ (root group)\n├── retail-division/\n│   ├── shared-libraries/     # Division-specific shared code\n│   └── teams/\n│       ├── checkout/        # Team publishes packages here\n│       └── inventory/       # Team publishes packages here\n├── banking-division/\n│   ├── shared-libraries/    # Division-specific shared code\n│   └── teams/\n│       ├── payments/       # Team publishes packages here\n│       └── fraud/         # Team publishes packages here\n└── shared-platform/        # Enterprise-wide shared code\n    ├── java-commons/      # Shared Java libraries\n    └── ui-components/     # Shared UI components\n```\n\n### Publishing configuration\n\nTeams publish packages to their specific project registries, maintaining clear ownership:\n\n1. Maven example\n\n```xml\n\u003C!-- checkout/pom.xml -->\n\u003CdistributionManagement>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/distributionManagement>\n```\n\n2. npm example\n\n```json\n// ui-components/package.json\n{\n  \"name\": \"@company/ui-components\",\n  \"publishConfig\": {\n    \"registry\": \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/\"\n  }\n}\n```\n\n### Consuming configuration\n\nThe power of root group consumption comes into play here. All teams configure a single endpoint for package access:\n\n1. Maven example\n\n```xml\n\u003C!-- Any project's pom.xml -->\n\u003Crepositories>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>https://gitlab.example.com/api/v4/groups/company/-/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/repositories>\n```\n\n2. npm example\n\n```\n# Any project's .npmrc\n@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/\n```\n\nThis configuration automatically provides access to all packages across your organization while maintaining the benefits of project-based publishing.\n\n## Authentication and access control\n\nGitLab's model simplifies authentication through deploy tokens and CI/CD integration.\n\n### For CI/CD pipelines\n\nGitLab automatically handles authentication in pipelines using `CI_JOB_TOKEN`:\n\n```yaml\n# .gitlab-ci.yml\npublish:\n  script:\n    - mvn deploy  # or npm publish\n  # CI_JOB_TOKEN provides automatic authentication\n```\n\n### For development\n\nUse group deploy tokens for package consumption:\n\n- Create read-only deploy tokens at the root group level\n- Rotate tokens periodically for security\n- Share a single configuration across all developers\n\n## Benefits of root group package registry\n\n1. Simplified configuration\n   - One URL for all package access\n   - Consistent setup across teams\n   - Easy token rotation\n2. Clear ownership\n   - Packages stay with their source code\n   - Teams maintain control over publishing\n   - Version history tied to project activity\n3. Natural organization\n   - Matches your company structure\n   - Supports team autonomy\n   - Enables cross-team collaboration\n\n## Getting started\n\n1. Set up your root group\n   - Create a clear group structure\n   - Configure appropriate access controls\n   - Create group deploy tokens\n2. Configure team projects\n   - Set up project-level publishing\n   - Implement CI/CD pipelines\n   - Document package naming conventions\n3. Standardize consumption\n   - Configure root group registry access\n   - Share deploy tokens securely\n   - Document package discovery process\n\n## Summary\n\nGitLab's package registry model, particularly when leveraging root group consumption, offers a powerful solution for enterprise package management. By combining project-based publishing with root group consumption, organizations get the best of both worlds: clear ownership and simplified access. This approach scales naturally with your organization while maintaining security and ease of use.\n\nStart by implementing this model with a single team or division, and expand as you see the benefits of this integrated approach. Remember that while this post focused on Maven and npm, the same principles apply to all package types supported by GitLab.\n\n> Get started with package registries today! Sign up for a [free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n",[710,671,1341],"solutions architecture",{"slug":1343,"featured":91,"template":674},"structuring-the-gitlab-package-registry-for-enterprise-scale","content:en-us:blog:structuring-the-gitlab-package-registry-for-enterprise-scale.yml","Structuring The Gitlab Package Registry For Enterprise Scale","en-us/blog/structuring-the-gitlab-package-registry-for-enterprise-scale.yml","en-us/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"_path":1349,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1350,"content":1356,"config":1363,"_id":1365,"_type":16,"title":1366,"_source":17,"_file":1367,"_stem":1368,"_extension":20},"/en-us/blog/certificate-based-kubernetes-integration-sunsetting-on-gitlab-com",{"title":1351,"description":1352,"ogTitle":1351,"ogDescription":1352,"noIndex":6,"ogImage":1353,"ogUrl":1354,"ogSiteName":784,"ogType":785,"canonicalUrls":1354,"schema":1355},"Certificate-based Kubernetes integration sunsetting on GitLab.com","Learn how to check if you are impacted by the sunsetting in May 2026 and the steps needed to migrate to our proposed alternatives, including the GitLab agent for Kubernetes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662245/Blog/Hero%20Images/blog-image-template-1800x945__16_.png","https://about.gitlab.com/blog/certificate-based-kubernetes-integration-sunsetting-on-gitlab-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Certificate-based Kubernetes integration sunsetting on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n        \"datePublished\": \"2025-02-17\",\n      }",{"title":1351,"description":1352,"authors":1357,"heroImage":1353,"date":1359,"body":1360,"category":14,"tags":1361,"updatedDate":1018},[1358],"Viktor Nagy","2025-02-17","__*Note: In a previously published version of this article, we stated that the certificate-based Kubernetes integration would be sunset in GitLab 18.0 in May 2025. That timeline has been extended to GitLab 19.0, planned for May 2026. See the [deprecation notice](https://docs.gitlab.com/update/deprecations/#gitlab-self-managed-certificate-based-integration-with-kubernetes) for details.*__\n\nThe certificate-based Kubernetes integration was [deprecated in GitLab November 2021](https://about.gitlab.com/blog/deprecating-the-cert-based-kubernetes-integration/), and is available on GitLab.com only to previous users. In May 2026, the integration will sunset on GitLab.com and will stop working. Customers often use the integration to deploy applications to production and non-production environments. As a result, failure to migrate to other options could cause a critical incident in your application delivery pipelines. This post outlines the alternative features that GitLab offers, points out how you can identify the potential impact on your GitLab.com groups and projects, and offers links to the GitLab documentation to learn more about the necessary migration steps.\n\n## Recommended alternative: The GitLab agent for Kubernetes\n\nThe GitLab agent for Kubernetes represents a significant advancement over the certificate-based integration, offering enhanced security, reliability, and functionality. Here are the key benefits of migrating to the agent-based approach:\n\n### Enhanced security  \n- Eliminates the need for storing cluster credentials in GitLab  \n- Provides secure, bidirectional communication between GitLab and your clusters  \n- Supports fine-grained access control and authorization policies  \n- Enables secure GitOps workflows with pull-based deployments\n\n### Improved reliability  \n- Maintains persistent connections, reducing deployment failures  \n- Handles network interruptions gracefully  \n- Provides better logging and troubleshooting capabilities  \n- Supports automatic reconnection and state recovery\n\n### Advanced features  \n- Real-time cluster information integrated into the GitLab UI  \n- Integration with GitLab CI/CD pipelines  \n- Support for multiple clusters and multi-tenant environments  \n- Enhanced GitOps capabilities by integrating with FluxCD\n\n## Get started with the GitLab agent for Kubernetes\n\nIf you haven't tried the GitLab Agent for Kubernetes yet, we strongly recommend going through the [getting started guides](https://docs.gitlab.com/ee/user/clusters/agent/getting_started). These guides will walk you through the basic setup and help you understand how the agent works in your environment. The hands-on experience will help make the migration process smoother.\n\n## Impact assessment\n\nWe implemented a [dedicated API](https://docs.gitlab.com/ee/api/cluster_discovery.html) endpoint to query all the certificate-based clusters within a GitLab group hierarchy. We recommend starting with this API to see if you have any clusters that need to be migrated.\n\nOnce you identify the clusters, you should:\n1. Find group and project owners using the certificate-based integration.  \n2. Check CI/CD pipelines for direct Kubernetes API calls.  \n3. Identify Auto DevOps projects using the old integration.  \n4. List any GitLab-managed clusters in use.  \n5. Set up the agent in the affected clusters. \n6. Follow the guidance provided in this post and record your progress in a tracking issue.\n\n## Update your CI/CD integration\n\nThe legacy certificate-based integration works using GitLab CI/CD. Because the agent seamlessly integrates with GitLab CI/CD pipelines, you can use it to replace the certificate-based integration with relatively little effort. The agent-based CI/CD integration offers several improvements over the certificate-based approach:\n\n1. **Direct cluster access:** CI/CD jobs can interact with clusters through the agent without requiring separate credentials.  \n2. **Enhanced security:** You don't need to store cluster credentials in CI/CD variables. \n3. **Simplified configuration:** A single agent configuration file manages all cluster interactions.  \n4. **Better performance:** Persistent connections reduce deployment overhead.  \n5. **Flexible authorization:** On GitLab Premium and Ultimate, you can rely on impersonation features to restrict CI/CD jobs in the cluster.\n\nAt a high level, there are three steps to migrating your existing CI/CD pipelines:  \n1. Set up the agent by following [the getting started guides](https://docs.gitlab.com/ee/user/clusters/agent/getting_started).  \n2. [Share the agent connection with the necessary groups and projects.](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html#authorize-the-agent). \n3. [Select the agent in the pipeline jobs.](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html#update-your-gitlab-ciyml-file-to-run-kubectl-commands)\n\nYou can read more about [migrating Kubernetes deployments in general](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html) or about [the agent CI/CD integration](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html) in the documentation.\n\n## Migrate your Auto DevOps configuration\n\nAuto DevOps is a set of CI/CD templates that are often customized by users. With Auto DevOps, you can automatically configure your CI/CD pipelines to build, test, and deploy your applications based on best practices. It's commonly used with the certificate-based integration for deploying applications to Kubernetes clusters. \n\nIf you use Auto DevOps and you rely on the certificate-based integration, you need to transition to the agent-based deployment mechanism. The migration process is straightforward:\n1. Set up the CI/CD integration as described above.  \n2. Configure the `KUBE_CONTEXT` environment variable to select an agent.  \n4. Remove the old certificate-based cluster integration.\n\nYou can read more about [using Auto DevOps with the agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html\\#environments-that-use-auto-devops) in the documentation.\n\n## Transition from GitLab-managed clusters to GitLab-managed Kubernetes resources\n\nWith GitLab-managed clusters, GitLab automatically creates and manages Kubernetes resources for your projects. When you allow GitLab to manage your cluster, it creates RBAC resources like a Namespace and ServiceAccount. \n\nIf you use GitLab-managed clusters, you should transition to GitLab-managed Kubernetes resources, which offers a more flexible and secure approach to cluster management.\n\nTo migrate: \n1. Document your existing cluster configuration.  \n2. Create corresponding Kubernetes resource definitions.  \n3. Store configurations in your repository.  \n4. Configure the GitLab agent to manage these resources.  \n5. Verify resource management and deployment. \n6. Remove the old cluster integration.\n\nYou can read more about [GitLab-managed Kubernetes resources](https://docs.gitlab.com/ee/user/clusters/agent/getting\\_started) in the documentation.\n\n## Manage cloud provider clusters created through GitLab\n\nIf you created Kubernetes clusters through the GitLab integration with Google Kubernetes Engine (GKE) or Amazon Elastic Kubernetes Service (EKS), these clusters were provisioned in your respective cloud provider accounts. After the certificate-based integration is removed:\n1. Your clusters will remain fully operational in Google Cloud or AWS.  \n2. You will need to manage these clusters directly through your cloud provider's console:  \n   - GKE clusters through Google Cloud Console  \n   - EKS clusters through AWS Management Console\n\nTo view cluster information within GitLab:\n 1. Install the GitLab agent for Kubernetes. \n 1. Configure the Kubernetes dashboard integration.  \n 1. Check the dashboard for cluster details and resource information.\n\nThis change only affects how you interact with the clusters through GitLab – it does not impact the clusters' operation or availability in your cloud provider accounts.\n\nYou should still migrate your deployment setups as described above.\n\n## What should I do next?\n\nTo minimize the impact to you and your infrastructure, you should follow these steps:\n1. Check if you are impacted as soon as possible.  \n2. Plan your migration timeline before May 2026.  \n3. Start with non-production environments to gain experience.  \n4. Document your current setup and desired state.  \n5. Test the agent-based approach in a staging environment.  \n6. Gradually migrate production workloads.  \n7. Monitor and validate the new setup.\n\nThe migration to the GitLab agent for Kubernetes represents a significant improvement in how GitLab interacts with Kubernetes clusters. While the migration requires careful planning and execution, the benefits in terms of security, reliability, and functionality make it a worthwhile investment for your DevSecOps infrastructure.",[109,1362,14,475],"kubernetes",{"slug":1364,"featured":6,"template":674},"certificate-based-kubernetes-integration-sunsetting-on-gitlab-com","content:en-us:blog:certificate-based-kubernetes-integration-sunsetting-on-gitlab-com.yml","Certificate Based Kubernetes Integration Sunsetting On Gitlab Com","en-us/blog/certificate-based-kubernetes-integration-sunsetting-on-gitlab-com.yml","en-us/blog/certificate-based-kubernetes-integration-sunsetting-on-gitlab-com",{"_path":1370,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1371,"content":1375,"config":1380,"_id":1383,"_type":16,"title":1384,"_source":17,"_file":1385,"_stem":1386,"_extension":20},"/en-us/blog/gitlab-patch-release-17-8-2-17-7-4-17-6-5",{"title":1372,"description":1292,"ogTitle":1372,"ogDescription":1292,"noIndex":91,"ogImage":689,"ogUrl":1373,"ogSiteName":784,"ogType":785,"canonicalUrls":1373,"schema":1374},"GitLab Patch Release: 17.8.2, 17.7.4, 17.6.5","https://about.gitlab.com/blog/gitlab-patch-release-17-8-2-17-7-4-17-6-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.8.2, 17.7.4, 17.6.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\" Rohit Shambhuni\"}],\n        \"datePublished\": \"2025-02-12\",\n      }",{"title":1372,"description":1292,"authors":1376,"heroImage":689,"date":1377,"body":1378,"category":14,"tags":1379},[688],"2025-02-12","This is the post for [GitLab Patch Release: 17.8.2, 17.7.4, 17.6.5](https://about.gitlab.com/releases/2025/02/12/patch-release-gitlab-17-8-2-released/).",[752,879],{"slug":1381,"featured":6,"template":674,"externalUrl":1382},"gitlab-patch-release-17-8-2-17-7-4-17-6-5","https://about.gitlab.com/releases/2025/02/12/patch-release-gitlab-17-8-2-released/","content:en-us:blog:gitlab-patch-release-17-8-2-17-7-4-17-6-5.yml","Gitlab Patch Release 17 8 2 17 7 4 17 6 5","en-us/blog/gitlab-patch-release-17-8-2-17-7-4-17-6-5.yml","en-us/blog/gitlab-patch-release-17-8-2-17-7-4-17-6-5",{"_path":1388,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1389,"content":1395,"config":1400,"_id":1402,"_type":16,"title":1403,"_source":17,"_file":1404,"_stem":1405,"_extension":20},"/en-us/blog/getting-started-with-gitlab-mastering-project-management",{"title":1390,"description":1391,"ogTitle":1390,"ogDescription":1391,"noIndex":6,"ogImage":1392,"ogUrl":1393,"ogSiteName":784,"ogType":785,"canonicalUrls":1393,"schema":1394},"Getting started with GitLab: Mastering project management","Discover the key components of project management and how to put them to use for better organization and tracking.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097294/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097293924.png","https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with GitLab: Mastering project management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-02-11\",\n      }",{"title":1390,"description":1391,"authors":1396,"heroImage":1392,"date":1397,"body":1398,"category":14,"tags":1399},[976],"2025-02-11","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nGitLab is much more than just a place to store your code. It is an AI-powered DevSecOps platform with tools to help you plan, organize, track, and successfully deliver your projects. This post will guide you through GitLab's key project management features and show you how to leverage them effectively.\n\n## Why GitLab for project management?\n\nImagine having your code repository, issue tracker, and communication platform all seamlessly integrated in one place. That's the power of GitLab. By centralizing everything, you can streamline your workflow, enhance collaboration, and keep your projects moving forward. No more jumping between different tools and losing track of information. GitLab brings it all together, making it easier to manage your projects from start to finish.\n\n## Key components of GitLab project management\n\nLet's break down the essential elements:\n\n* [Epics](https://docs.gitlab.com/ee/user/group/epics/): Think of epics as the big picture. They represent major features, overarching goals, or long-term initiatives within your project. Need to revamp your website? That's an epic! Epics help you organize your work into larger, manageable chunks.  \n* [Issues](https://docs.gitlab.com/ee/user/project/issues/): Issues are the individual tasks or work items that contribute to your project goals. Each issue represents a specific action, like \"design the homepage\" or \"write the 'about us' page.\" Issues are the building blocks of your project, and they provide a clear way to track individual tasks.  \n* [Labels](https://docs.gitlab.com/ee/user/project/labels.html): Labels are like tags that help you categorize and filter your work. You can use labels to indicate priority (e.g., high, medium, low), status (e.g., to do, in progress, done), or assign issues to specific teams or individuals. Labels provide a flexible way to organize and prioritize your work.  \n* Boards: GitLab's issue boards are your visual workspace. They provide a Kanban-style view of your project, allowing you to see the status of all your issues at a glance. Drag and drop issues across different lists (e.g., \"To Do,\" \"Doing,\" \"Done\") to visualize your workflow and track progress. In GitLab, you can create boards for [issues](https://docs.gitlab.com/ee/user/project/issue_board.html) and [Epics](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html).  \n* [Milestones](https://docs.gitlab.com/ee/user/project/milestones/): Milestones mark significant checkpoints or target dates within your project. They help you track progress towards specific goals and deadlines. For example, you might have milestones for completing a major feature, releasing a beta version, or launching the final product.  \n* [Tasks](https://docs.gitlab.com/ee/user/tasks.html): For those extra granular steps, break down your issues into smaller tasks. This helps with delegation, clarifies individual responsibilities, and ensures nothing gets overlooked. Tasks provide a way to create checklists within issues, making it easier to track progress on complex tasks.\n\n## Deep dive into the features\n\n### 1. Epics: The big picture\n\n* Creating epics: Navigate to your group's \"Epics\" menu under “Plan”. Click **New epic** and give it a descriptive title and a clear description outlining the goal. You can also specify the start and end date of the epic – this is useful when using [Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/).\n\n![Epic creation page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097300817.png)\n\n* [Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/): Add your epics to a roadmap to visualize your project timeline and long-term goals. Roadmaps provide a bird's-eye view of your project plan, making it easy to see the big picture and track progress towards major milestones.\n\n![Roadmap view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097300818.png)\n\n### 2. Issues: Getting things done\n\n* Creating issues: In your project, go to the \"Issues\" menu under “Plan” and click **New issue**. Provide a concise and descriptive title like \"Design Homepage Wireframes,\" assign it to a team member, set a due date, and add a detailed description outlining the task's requirements.  \n* GitLab Duo: You can leverage the power of [GitLab Duo to create detailed issue descriptions](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#populate-an-issue-with-issue-description-generation) with just a little hint of what you want to achieve.  \n* Weighting: Estimate the effort required for each issue by assigning weights. This helps with planning and prioritization. For example, a simple task might have a weight of **1**, while a more complex task might have a weight of **5**.\n\n![Issue with weight of 4 assigned](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097300819.png)\n\n### 3. Labels: Organizing your work\n\n* Creating labels: Go to your project's \"Issues\" tab and click Labels. Create custom labels with clear names to categorize your issues. For example, create labels like **Priority: High**, **Status: In Progress**, or **Team: Design**. Apply these labels to your issues to keep them organized and easily filterable.\n\n![Labels screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097300820.png)\n\n### 4. Boards: Visualizing your workflow\n\n* Kanban boards: GitLab's boards provide a Kanban-style view of your project. Create lists like \"To Do,\" \"Doing,\" and \"Done\" to represent the stages of your workflow. Drag and drop issues across these lists to visualize their progress.\n* Customizing boards: Tailor your boards to match your specific workflow. Add more columns, filter issues by labels or assignees, and set up swim lanes to categorize issues by epics or other criteria.\n\n![Visualize workflow with issue boards](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097300820.png)\n\n### 5. Tasks: Breaking down the work\n\n* Creating tasks: Within an issue, use the checklist markdown syntax to create a task list. Each item in the list represents a smaller step within the larger issue. For example, in the issue \"Design Homepage Wireframes,\" you might have tasks like \"Sketch initial concepts,\" \"Create digital wireframes,\" and \"Get feedback from stakeholders.\" To create a Task, click on the **Add** button in the \"Child Items\" section of an issue’s page. Then, enter the title of the task, and click **Create Task**.\n\n![Issue with create task button](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097300822.png)\n\n### 6. Milestones: Tracking progress\n* Setting milestones: Define milestones to mark significant points in your project, like completing a specific feature or reaching a key deadline. Give your milestones clear titles and due dates.\n* Associating with issues: Link issues and epics to milestones to track progress towards those goals. This helps you see how individual tasks contribute to the overall project plan.\nCreating a milestone: Under the \"Plan\" dropdown menu, click on **Milestones > New milestone**. Specify the milestone title, description, and start and due dates.\n\n![New milestone screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097300823.png)\n\n\u003Cbr>\u003C/br>\n\n![New page wtih milestone on it](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097300823.png)\n\n### 7. [Iterations](https://docs.gitlab.com/ee/user/group/iterations/): Working in sprints\n\n* Defining iterations: If you're using an Agile workflow, define iterations (sprints) with specific start and end dates. This helps you break down your work into smaller, more manageable time boxes.  \n* Assigning issues: Assign issues to iterations to plan your work in shorter cycles and focus on delivering incremental value.\n\n### 8. [Time tracking](https://docs.gitlab.com/ee/user/project/time_tracking.html): Measuring effort\n\n* Logging time: Within an issue, use the \"/spend\" quick action followed by the time spent (e.g., \"/spend 2h 30m\") to log your work. This helps you track the actual time spent on each task.  \n* Analyzing data: Generate time tracking reports to gain insights into project progress, team efficiency, and identify potential bottlenecks.\n\n![Time tracking report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097300824.png)\n\n### 9. Dependencies: Managing workflow\n\n* [Linking issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html): Create dependencies between issues to ensure tasks are completed in the correct order. For example, if issue A must be completed before issue B can begin, you can create a dependency between them. This helps you visualize the workflow and avoid potential roadblocks.\n\n### 10. Templates: Streamlining issue creation\n\n* [Creating templates](https://docs.gitlab.com/ee/user/project/description_templates.html): Create issue templates to standardize the information captured for common tasks, saving you time and ensuring consistency. For example, you could create a template for bug reports that includes fields for steps to reproduce expected behavior and actual behavior.\n\n### Collaboration is key\n\nGitLab fosters collaboration through the following:\n\n* [Comments](https://docs.gitlab.com/ee/user/discussions/): Discuss issues and epics directly within GitLab. Use comments to provide updates, ask questions, and share feedback.  \n* [Mentions](https://docs.gitlab.com/ee/user/discussions/#mentions): Use **@** to mention specific team members and notify them of updates or request their input.  \n* Discussions: Engage in threaded discussions within issues and epics to brainstorm ideas, solve problems together, and keep everyone informed.\n\n### Ready to get started?\n\nNow that you've explored the power of GitLab's project management features, it's time to put them into practice! Create a sample project, experiment with different features, and discover how GitLab can transform your workflow. You can also learn more about how GitLab can help you facilitate [Kanban](https://docs.gitlab.com/ee/tutorials/kanban/) and [Scrum](https://docs.gitlab.com/ee/tutorials/scrum_events/) in the GitLab documentation.\n\n> #### Want to take your learning to the next level? [Sign up for GitLab University courses](https://university.gitlab.com/). Or you can get going right away with a [free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## \"Getting started with GitLab\" series\nRead more articles in our \"Getting started with GitLab\" series:\n\n- [How to manage users](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Automating Agile workflows with the gitlab-triage gem](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Understanding CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)\n- [Working with CI/CD variables](https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables/)",[671,14,475,1178],{"slug":1401,"featured":6,"template":674},"getting-started-with-gitlab-mastering-project-management","content:en-us:blog:getting-started-with-gitlab-mastering-project-management.yml","Getting Started With Gitlab Mastering Project Management","en-us/blog/getting-started-with-gitlab-mastering-project-management.yml","en-us/blog/getting-started-with-gitlab-mastering-project-management",{"_path":1407,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1408,"content":1414,"config":1421,"_id":1423,"_type":16,"title":1424,"_source":17,"_file":1425,"_stem":1426,"_extension":20},"/en-us/blog/deploy-a-server-using-go-with-gitlab-google-cloud",{"title":1409,"description":1410,"ogTitle":1409,"ogDescription":1410,"noIndex":6,"ogImage":1411,"ogUrl":1412,"ogSiteName":784,"ogType":785,"canonicalUrls":1412,"schema":1413},"Deploy a server using Go with GitLab + Google Cloud","This tutorial shows how to use GitLab’s Google Cloud integration to deploy a Golang server in less than 10 minutes, helping developers become more independent and efficient.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098028/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945_fJKX41PJHKCfSOWw4xQxm_1750098028126.png","https://about.gitlab.com/blog/deploy-a-server-using-go-with-gitlab-google-cloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Deploy a server using Go with GitLab + Google Cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Claire Champernowne\"},{\"@type\":\"Person\",\"name\":\"Noah Ing\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":1409,"description":1410,"authors":1415,"heroImage":1411,"date":1418,"body":1419,"category":14,"tags":1420},[1416,1417],"Claire Champernowne","Noah Ing","2025-01-28","Deploying an application to the cloud often requires assistance from production or DevOps engineers. GitLab's Google Cloud integration empowers developers to handle deployments independently. In this tutorial, you'll learn how to deploy a server to Google Cloud in less than 10 minutes using Go. Whether you’re a solo developer or part of a large team, this setup allows you to deploy applications efficiently.\n\n## You'll learn how to:\n\n1. Create a new project in GitLab\n2. Create a Go server utilizing `main.go`\n3. Use the Google Cloud integration to create a Service account\n4. Use the Google Cloud integration to create Cloud Run via a merge request\n5. Access your newly deployed Go server\n6. Clean up your environment\n\n## Prerequisites\n\n- Owner access on a Google Cloud Platform project\n- Working knowledge of Golang\n- Working knowledge of GitLab CI\n- 10 minutes\n\n## Step-by-step Golang server deployment to Google Cloud\n\n### 1. Create a new blank project in GitLab.\n\nWe decided to call our project `golang-cloud-run` for simplicity.\n\n![Create a new blank project in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098035249.png)\n\n### 2. Create a server utilizing this `main.go` demo.\n\nFind the `main.go` demo [here](https://gitlab.com/demos/applications/golang-cloud-run).\n\n```\n// Sample run-helloworld is a minimal Cloud Run service.\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\t\"net/http\"\n\t\"os\"\n)\n\nfunc main() {\n\tlog.Print(\"starting server...\")\n\thttp.HandleFunc(\"/\", handler)\n\n\t// Determine port for HTTP service.\n\tport := os.Getenv(\"PORT\")\n\tif port == \"\" {\n\t\tport = \"8080\"\n\t\tlog.Printf(\"defaulting to port %s\", port)\n\t}\n\n\t// Start HTTP server.\n\tlog.Printf(\"listening on port %s\", port)\n\tif err := http.ListenAndServe(\":\"+port, nil); err != nil {\n\t\tlog.Fatal(err)\n\t}\n}\n\nfunc handler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Hello %s!\\n\", name)\n}\n```\n\n### 3. Use the Google Cloud integration to create a Service account.\n\nNavigate to **Operate \\> Google Cloud \\> Create Service account**.\n\n![Golang tutorial - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098036/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098035250.png)\n\n### 4. Configure the region you would like the Cloud Run instance deployed to.\n\n![Golang tutorial - image10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098035252.png)\n\n### 5. Use the Google Cloud integration to configure Cloud Run via Merge Request.\n\n![Golang tutorial - image4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098035254.png)\n\n### 6. This will open a merge request. Immediately merge the MR.\n\n![Golang tutorial - image6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098036/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098035257.png)\n\nThis merge request adds a CI/CD deployment job to your pipeline definition. In our case, this is also creating a pipeline definition, as we didn’t have one before.\n\n**Note:** The CI/CD variables `GCP_PROJECT_ID`, `GCP_REGION`, `GCP_SERVICE_ACCOUNT`, `GCP_SERVICE_ACCOUNT_KEY` will all be automatically populated from the previous steps. \n\n![Golang tutorial - image7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098035259.png)\n\n### 7. Voila! Check your pipeline and you will see you have successfully deployed to Google Cloud Run utilizing GitLab CI.\n\n![Golang tutorial - image2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098035261.png)\n\n\u003Cbr>\n\n![Golang tutorial - image3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098035262.png)\n\n## 8. Click the Service URL to view your newly deployed server.\n\nAlternatively, you can navigate to **Operate \\> Environments** to see a list of deployments for your environments.\n\n![Golang tutorial - image5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098035264.png)\n\nBy clicking on the environment called **main**, you’ll be able to view a complete list of deployments specific to that environment.\n\n![Golang tutorial - image8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098035265.png)\n\n## Next steps\n\nTo get started with developing your Go application, try adding another endpoint. For instance, in your `main.go` file, you can add a `/bye` endpoint as shown below (don’t forget to register the new handler function in main!):\n\n```\nfunc main() {\n\tlog.Print(\"starting server...\")\n\n\thttp.HandleFunc(\"/\", handler)\n\thttp.HandleFunc(\"/bye\", byeHandler)\n```\n\n```\nfunc byeHandler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Bye %s!\\n\", name)\n}\n```\n\nYour `main.go` file should now look something like this:\n\n```\n// Sample run-helloworld is a minimal Cloud Run service.\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\t\"net/http\"\n\t\"os\"\n)\n\nfunc main() {\n\tlog.Print(\"starting server...\")\n\n\thttp.HandleFunc(\"/\", handler)\n\n\thttp.HandleFunc(\"/bye\", byeHandler)\n\n\t// Determine port for HTTP service.\n\tport := os.Getenv(\"PORT\")\n\tif port == \"\" {\n\t\tport = \"8080\"\n\t\tlog.Printf(\"defaulting to port %s\", port)\n\t}\n\n\t// Start HTTP server.\n\tlog.Printf(\"listening on port %s\", port)\n\tif err := http.ListenAndServe(\":\"+port, nil); err != nil {\n\t\tlog.Fatal(err)\n\t}\n}\n\nfunc handler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Hello %s!\\n\", name)\n}\n\nfunc byeHandler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Bye %s!\\n\", name)\n}\n```\n\nPush the changes to the repo, and watch the `deploy-to-cloud-run job` deploy the updates. Once it’s complete, go back to the Service URL and navigate to the `/bye` endpoint to see the new functionality in action.\n\n## Clean up the environment\n\nTo prevent incurring charges on your Google Cloud account for the resources used in this tutorial, you can either delete the specific resources or delete the entire Google Cloud project. For detailed instructions, refer to the [cleanup guide](https://docs.gitlab.com/ee/tutorials/create_and_deploy_web_service_with_google_cloud_run_component/#clean-up).\n\n> Discover more tutorials like this in our [Solutions Architecture](https://about.gitlab.com/blog/tags/solutions-architecture/) area.\n",[710,475,671,1341,14,794],{"slug":1422,"featured":6,"template":674},"deploy-a-server-using-go-with-gitlab-google-cloud","content:en-us:blog:deploy-a-server-using-go-with-gitlab-google-cloud.yml","Deploy A Server Using Go With Gitlab Google Cloud","en-us/blog/deploy-a-server-using-go-with-gitlab-google-cloud.yml","en-us/blog/deploy-a-server-using-go-with-gitlab-google-cloud",{"_path":1428,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1429,"content":1435,"config":1441,"_id":1443,"_type":16,"title":1444,"_source":17,"_file":1445,"_stem":1446,"_extension":20},"/en-us/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"title":1430,"description":1431,"ogTitle":1430,"ogDescription":1431,"noIndex":6,"ogImage":1432,"ogUrl":1433,"ogSiteName":784,"ogType":785,"canonicalUrls":1433,"schema":1434},"From code to production: A guide to continuous deployment with GitLab","Learn how to get started building a robust continuous deployment pipeline in GitLab. Follow these step-by-step instructions, practical examples, and best practices.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"From code to production: A guide to continuous deployment with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":1430,"description":1431,"authors":1436,"heroImage":1432,"date":1418,"body":1439,"category":14,"tags":1440},[1437,1438],"Benjamin Skierlak","James Wormwell","Continuous deployment is a game-changing practice that enables teams to deliver value faster, with higher confidence. However, diving into advanced deployment workflows — such as GitOps, container orchestration with Kubernetes, or dynamic environments — can be intimidating for teams just starting out.\n\nAt GitLab, we're committed to making delivery seamless and scalable. By enabling teams to focus on the fundamentals, we empower them to build a strong foundation that supports growth into more complex strategies over time. This guide provides essential steps to begin implementing continuous deployment with GitLab, laying the foundation for your long-term success.\n\n## Start with a workflow plan\n\nBefore diving into the technical implementation, take time to map out your deployment workflow. Success lies in careful planning and a methodical approach.\n\n### Artifact management strategy\n\nIn the context of continuous deployment, artifacts are the packaged outputs of your build process that need to be stored, versioned, and deployed. These could be:\n\n- container images for your applications\n- packages\n- compiled binaries or executables\n- libraries\n- configuration files\n- documentation packages\n- other artifacts\n\nEach type of artifact plays a specific role in your deployment process. For example, a typical web application might generate:\n\n- a container image for the backend service\n- a ZIP archive of compiled frontend assets\n- SQL files for database changes\n- environment-specific configuration files\n\nManaging these artifacts effectively is crucial for successful deployments. Here's how to approach artifact management.\n\n#### Artifacts and releases versioning strategies\n\nA best practice to get you started with a clean structure is to establish a clear versioning strategy for your artifacts. When creating releases:\n\n- Use semantic versioning (major.minor.patch) for release tags\n  - Example: `myapp:1.2.3` for a stable release\n  - Major version changes (2.0.0) for breaking changes\n  - Minor version changes (1.3.0) for new features\n  - Patch version changes (1.2.4) for bug fixes\n- Maintain a 'latest' tag for the most recent stable version\n  - Example: `myapp:latest` for automated deployments\n- Include commit SHA for precise version tracking\n  - Example: `myapp:1.2.3-abc123f` for debugging\n- Consider branch-based tags for development environments\n  - Example: `myapp:feature-user-auth` for feature testing\n\n#### Build artifacts retention\n\nImplement defined retention rules:\n\n- Set explicit expiration timeframes for temporary artifacts\n- Define which artifacts need permanent retention\n- Configure cleanup policies to manage storage\n\n#### Registry access and authentication\n\nSecure your artifacts with proper access controls:\n\n- Implement Personal Access Tokens for developer access\n- Configure CI/CD variables for pipeline authentication\n- Set up proper access scopes\n\n### Environment strategy\n\nConsider your environments early, as they shape your entire deployment pipeline:\n\n- Development, staging, and production environment configurations\n- Environment-specific variables and secrets\n- Access controls and protection rules\n- Deployment tracking and monitoring approach\n\n### Deployment targets\n\nBe intentional as to where and how you'll deploy, these decisions matter and the benefits and drawbacks of each should be consider:\n\n- Infrastructure requirements (VMs, containers, cloud services)\n- Network access and security configurations\n- Authentication mechanisms (SSH keys, access tokens)\n- Resource allocation and scaling considerations\n\nWith our strategy defined and foundational decisions made, we can now translate these plans into a working pipeline. We'll build a practical example that demonstrates these concepts, starting with a simple application and progressively adding deployment capabilities.\n\n## Implementing your CD pipeline\n\n### A step-by-step example\n\nLet's walk through implementing a basic continuous deployment pipeline for a web application. We'll use a simple HTML application as an example, but these principles apply to any type of application. We’re also going to deploy our application as a Docker image on a simple virtual machine. This will allow us to lean on a curated image with minimum dependencies, and to ensure no environment specific requirements are unintentionally brought in. By working on a virtual machine, we won’t be leveraging GitLab’s native integrations, allowing us to work on an easier but less scalable setup to begin with.\n\n#### Prerequisites\n\nIn this example, we’ll aim to containerize an application that we’ll run on a virtual machine hosted on a cloud provider. We’ll also test this application locally on our machine. This list of prerequisites is only needed for this scenario.\n\n##### Virtual machine setup\n\n- Provision a VM in your preferred cloud provider (e.g., GCP, AWS, Azure)\n- Configure network rules to allow access on ports 22, 80, and 443\n- Record the machine's public IP address for deployment\n\n##### Set up SSH authentication:\n\n- Generate a public/private key pair for the machine\n- In GitLab, go to **Settings > CI/CD > Variables**\n- Create a variable called `GITLAB_KEY`\n- Set Type to \"File\" (required for SSH authentication)\n- Paste the private key in the Value field\n- Define a USER variable, this is the user logging in and running the scripts on your VM\n\n##### Configure deployment variables\n\n- Create variables for your deployment targets:\n  - `STAGING_TARGET`: Your staging server IP/domain\n  - `PRODUCTION_TARGET`: Your production server IP/domain\n\n##### Local development setup\n\n- Install Docker on your local machine for testing deployments\n\n##### GitLab Container Registry access\n\n- Locate your registry path:\n  - Navigate to **Deploy > Container Registry**\n  - Copy the registry path (e.g., registry.gitlab.com/group/project)\n- Set up authentication:\n  - Go to **Settings > Access Tokens**\n  - Create a new token with registry access\n  - Token expiration: Maximum 1 year\n  - Save the token securely\n- Configure local registry access:\n\n```\ndocker login registry.gitlab.com\n# The username if you are using a PAT is gitlab-ci-token\n# Password: your-access-token\n```\n\n#### 1. Create your application\n\nStart with a basic web application. For our example, we're using a simple HTML page:\n\n```\n\u003C!-- index.html -->\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!-- Your content here -->\n  \u003C/body>\n\u003C/html>\n```\n\n#### 2. Containerize your application\n\nCreate a Dockerfile to package your application:\n\n```\nFROM nginx:1.26.2\nCOPY index.html /usr/share/nginx/html/index.html\n```\n\nThis Dockerfile:\n\n- Uses nginx as a base image for serving web content\n- Copies your HTML file to the correct location in the nginx directory structure\n\n#### 3. Set up your CI/CD pipeline\n\nCreate a `.gitlab-ci.yml` file to define your pipeline stages:\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\nLet's break it down:\n\n`TAG_LATEST` is made up of three parts:\n\n- `$CI_REGISTRY_IMAGE` is the path to your project's container registry in GitLab\n\nFor example: `registry.gitlab.com/your-group/your-project`\n\n- `$CI_COMMIT_REF_NAME` is the name of your branch or tag\n\nFor example, if you're on main branch: `/main`, and if you're on a feature branch: `/feature-login`\n\n- `:latest` is a fixed suffix\n\nSo if you're on the main branch, `TAG_LATEST` becomes: `registry.gitlab.com/your-group/your-project/main:latest`.\n\n`TAG_COMMIT` is almost identical, but instead of `:latest`, it uses: `$CI_COMMIT_SHA` which is the commit identifier, for example: `:abc123def456`.\n\nSo for that same commit on main branch, `TAG_COMMIT` becomes:` registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\nThe reason for having both is `TAG_LATEST` gives you an easy way to always get the newest version, and `TAG_COMMIT` gives you a specific version you can return to if needed.\n\n#### 4. Publish to the container registry\n\nAdd the publish job to your pipeline:\n\n```\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\nThis job:\n\n- Uses Docker-in-Docker to build images\n- Creates two tagged versions of your image\n- Authenticates with the GitLab registry\n- Pushes both versions to the registry \n\nNow that our images are safely stored in the registry, we can focus on deploying them to our target environments. Let's start with local testing to validate our setup before moving to production deployments.\n\n#### 5. Deploy to your environment\n\nBefore deploying to production, you can test locally. We just published our image to the GitLab repository, which we’ll pull locally. If you’re unsure of the exact path, navigate to **Deploy > Container Registry**, and you should see an icon to copy the path of your image at the end of the line for the container image you want to test.\n\n```\ndocker login registry.gitlab.com \ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n```\n\nBy doing so you should be able to access your application locally on your localhost address through your web browser.\n\nYou can now add a deployment job to your pipeline:\n\n```\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\nThis job:\n\n- Sets up SSH access to your deployment target\n- Pulls the latest image\n- Removes any existing container\n- Deploys the new version\n\n#### 6. Track deployments\n\nEnable deployment tracking by adding environment configuration:\n\n```\ndeploy:\n  environment:\n    name: production\n    url: https://your-application-url.com \n```\n\nThis creates an environment object in GitLab's **Operate > Environments** section, providing:\n\n- Deployment history\n- Current deployment status\n- Quick access to your application\n\nWhile a single environment pipeline is a good starting point, most teams need to manage multiple environments for proper testing and staging. Let's expand our pipeline to handle this more realistic scenario.\n\n#### 7. Set up multiple environments\n\nFor a more robust pipeline, configure staging and production deployments:\n\n```\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\nThis setup:\n\n- Deploys to staging from your main branch\n- Uses GitLab tags to trigger production deployments\n- Provides separate tracking for each environment\n\nHere and in our next step, we’re leveraging a very useful GitLab feature: tags. By manually creating a tag in the **Code > Tags** section, the `$CI_COMMIT_TAG` gets created, which allows us to trigger jobs accordingly.\n\n#### 8. Create automated release notes\n\nWe'll be using GitLab's release capabilities through our CI/CD pipeline. First, update your stages in `.gitlab-ci.yml`:\n\n```\nstages:\n\n- publish\n- staging\n- release # New stage for releases\n- version\n- production\n```\n\nNext, add the release job:\n\n```\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\nYou can enhance this by adding links to your container images:\n\n```\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\nFor meaningful automated release notes:\n\n- Use conventional commits (feat:, fix:, etc.)\n- Include issue numbers (#123)\n- Separate subject from body with blank line\n\nIf you want custom release notes with deployment info:\n\n```\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\nOnce configured, releases will be created automatically when you create a Git tag. You can view them in GitLab under **Deploy > Releases**.\n\n#### 9. Put it all together\n\nThis is what our final YAML file looks like:\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\nThis complete pipeline:\n\n- Publishes images to the registry (main branch)\n- Deploys to staging (main branch)\n- Creates releases (on tags)\n- Versions images with release tags\n- Deploys to production (on tags)\n\nKey benefits:\n\n- Clean reproducible, local development and testing environment\n- Clear path to production environments with structure to build confidence in what is deployed\n- Pattern to recover from unexpected failures, etc.\n- Ready to scale/adopt more complex deployment strategies\n\n### Best practices\n\nThroughout implementation, maintain these principles:\n\n- Document everything, from variable usage to deployment procedures\n- Use GitLab's built-in features (environments, releases, registry)\n- Implement proper access controls and security measures\n- Plan for failure with robust rollback procedures\n- Keep your pipeline configurations DRY (Don't Repeat Yourself)\n\n## Scale your deployment strategy\n\nWhat next? Here are some aspects to consider as your continuous deployment strategy matures.\n\n### Advanced security measures\n\nEnhance security through:\n\n- Protected environments with restricted access\n- Required approvals for production deployments\n- Integrated security scanning\n- Automated vulnerability assessments\n- Branch protection rules for deployment-related changes\n\n### Progressive delivery strategies\n\nImplement advanced deployment strategies:\n\n- Feature flags for controlled rollouts\n- Canary deployments for risk mitigation\n- Blue-green deployment strategies\n- A/B testing capabilities\n- Dynamic environment management\n\n### Monitoring and optimization\n\nEstablish robust monitoring practices:\n\n- Track deployment metrics\n- Set up performance monitoring\n- Configure deployment alerts\n- Establish deployment SLOs\n- Regular pipeline optimization\n\n## Why GitLab?\n\nGitLab's continuous deployment capabilities make it a standout choice for modern deployment workflows. The platform excels in streamlining the path from code to production, offering built-in container registry, environment management, and deployment tracking all within a single interface. GitLab's environment-specific variables, deployment approval gates, and rollback capabilities provide the security and control needed for production deployments, while features like review apps and feature flags enable progressive delivery approaches. As part of GitLab's complete DevSecOps platform, these CD capabilities seamlessly integrate with your entire software lifecycle.\n\n## Get started today\n\nThe journey to continuous deployment is an evolution, not a revolution. Start with the fundamentals, build a solid foundation, and gradually incorporate advanced features as your team's needs grow. GitLab provides the tools and flexibility to support you at every stage of this journey, from your first automated deployment to complex, multi-environment delivery pipelines.\n\n> Sign up for a [free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/) to get started with continous deployment today.",[860,109,794,14,671],{"slug":1442,"featured":6,"template":674},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:en-us:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","en-us/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","en-us/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":1448,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1449,"content":1455,"config":1460,"_id":1462,"_type":16,"title":1463,"_source":17,"_file":1464,"_stem":1465,"_extension":20},"/en-us/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"title":1450,"description":1451,"ogTitle":1450,"ogDescription":1451,"noIndex":6,"ogImage":1452,"ogUrl":1453,"ogSiteName":784,"ogType":785,"canonicalUrls":1453,"schema":1454},"Getting started with GitLab: How to import your projects to GitLab","Learn how to import your projects from various sources, including Bitbucket, Gitea, GitHub, and GitLab Self-Managed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097248/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097247785.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with GitLab: How to import your projects to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":1450,"description":1451,"authors":1456,"heroImage":1452,"date":1418,"body":1458,"category":14,"tags":1459},[1457],"Abubakar Siddiq Ango","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nKnowing how to import your projects to GitLab is an essential skill to make the most of the GitLab DevSecOps platform. You’ve [set up your account](https://university.gitlab.com/pages/getting-started), invited users, and [organized](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/) them based on your use case or team structure. Now, you need to bring your existing projects into GitLab and start collaborating. These projects can be local files on your computer or hosted on a different source code management platform. Let's explore the options.\n\n## Importing local project files\n\nYou don't want to start from scratch every time you import a project. Follow these steps to get into GitLab existing legacy projects or applications that exist without version control or use version control.\n\n### Git project\n\n1. If Git is [already initiated](https://docs.gitlab.com/ee/topics/git/commands.html#git-init) in your local project, create a new project in GitLab and obtain the SSH or HTTPS URL by clicking on the **Code** button in the top right corner of your project page.\n\n![create a new project in GitLab with SSH/HTTPS URLs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097254/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097252717.png)\n\n2. Switch to your terminal and ensure you are in your project folder:\n\n```bash  \ncd /project_folder  \n```\n\n3. Backup your existing [Git origin](https://git-scm.com/book/ms/v2/Git-Basics-Working-with-Remotes):\n\n```bash\n\ngit remote rename origin old-origin\n\n```\n\n4. Add the [GitLab remote](https://git-scm.com/book/ms/v2/Git-Basics-Working-with-Remotes) URL for the new origin, when using SSH:\n\n```bash  \ngit remote add origin [git@gitlab.com](mailto:git@gitlab.com):gitlab-da/playground/abubakar/new-test-repo.git  \n```\n\nAnd for HTTPS: \n\n```bash  \ngit remote add origin https://gitlab.com/gitlab-da/playground/abubakar/new-test-repo.git  \n```\n\n5. Then push all existing [branches](https://docs.gitlab.com/ee/user/project/repository/branches/) and [tags](https://docs.gitlab.com/ee/user/project/repository/tags/) to GitLab:\n\n```bash  \ngit push --set-upstream origin --all  \ngit push --set-upstream origin --tags  \n```\n\nAll your file project files, branches, and tags will be pushed to GitLab and you can start collaborating.\n\n### Non-Git project\n\nAlternatively, if you have not initiated Git in your project, you will need to initialize Git, commit existing files, and push to GitLab as follows:\n\n```bash  \ngit init --initial-branch=main  \ngit remote add origin git@gitlab.com:gitlab-da/playground/abubakar/new-test-repo.git  \ngit add .  \ngit commit -m \"Initial commit\"  \ngit push --set-upstream origin main  \n```\n\n## Importing from online sources\n\nIf you have your project on GitLab.com or other platforms and you want to move it to another GitLab instance (like a self-managed instance) or from another platform to GitLab.com, GitLab provides the import project feature when you want to create a new project.\n\n![Create a new project screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097252718.png)\n\nImporting a project migrates the project files and some other components of the project depending on the source. You can import from different sources like Bitbucket, GitHub, Gitea, and a GitLab instance, among other sources. Import sources are enabled by default on GitLab.com, but they need to be [enabled for self-managed](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources) by an administrator. We will look at a few of these sources in the following sections.\n\n![Import project from third-party sources](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097252719.png)\n\n## GitLab sources\n\nYou can export projects from GitLab.com and GitLab Self-Managed instances using the Export project feature in a project’s settings. \n\n![Export project screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097252720.png)\n\nTo access it:\n\n- Go to your project’s settings and click into the **General** area.\n- Scroll to and **Expand Advanced** section.\n- Select **Export project**.\n- A notification will be shown stating: “Project export started. A download link will be sent by email and made available on this page.”\n- After the export is generated, you can follow the link contained in the email or refresh the project settings page to reveal the “Download export” option.\n\n### Importing the project\n\n![Import an exported GitLab project](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097252722.png)\n\n- Click on the **New project** button in your target GitLab instance.  \n- Select **Import project** and click on **GitLab Export** in the list of import sources.  \n- Specify a project name and select the export file, then click **Import project**.  \n- An \"import in progress\" page will be shown and once complete, you will be redirected to the imported project.\n\nDepending on the size of your project, the import time may vary. It's important to note that not everything in a project might be exported and a few things might change after import. Review the [documentation](https://docs.gitlab.com/ee/user/project/settings/import_export.html#export-a-project-and-its-data) to understand the limitations. If you want to migrate a whole group instead of individual projects, the [Direct Transfer method](https://docs.gitlab.com/ee/user/group/import/index.html) is recommended; this creates a copy of an entire group.\n\n## Third-party providers\n\nGitLab supports importing from Bitbucket Cloud, Bitbucket Server, FogBugz, Gitea, and GitHub. The import process is similar across all the supported third parties — the main difference is in the method of authentication. Let's look at a few of them.\n\n### GitHub\n\n![Authenticate with GitHub screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097252723.png)\n\nThere are three methods to import GitHub projects in to GitLab:\n\n- [Using GitHub OAuth](https://docs.gitlab.com/ee/user/project/import/github.html#use-github-oauth)\n- [Using a GitHub personal access token](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token)\n- [Using the API](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api)\n\nImporting using GitHub OAuth and personal access token are similar. The difference lies in how your authorize GitLab to access your repositories. The OAuth method is easier because you only need to click on the “Authorize with GitHub” button and your are redirected to your GitHub account to authorize the connection. Then the list of your projects is loaded for you to pick those you want to import.\n\n![Import repositories from GitHub screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097252725.png)\n\nAlternatively, you will need to generate a GitHub personal access token, selecting the `repo` and `read:org` scopes, and then provide it on the \"Import\" page.  For API imports, you can use the same personal access token with our [Import REST API endpoints](https://docs.gitlab.com/ee/api/import.html#import-repository-from-github) in your script or application.\n\nIn this demo, GitLab Senior Developer Advocate Fernando Diaz explains how to import a project from GitHub using the OAuth method:\n\n\u003C!-- blank line -->  \n\u003Cfigure class=\"video_container\"> \n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=esF6wbz2j2JlhDVL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>  \n\u003C/figure>\n\u003C!-- blank line -->\n\nYou can learn about prerequisites, known issues, importing from GitHub Enterprise, and other valuable information from the GitLab [import documentation](https://docs.gitlab.com/ee/user/project/import/github.html).\n\n### Bitbucket\n\nImporting projects from Bitbucket is similar to importing them from GitHub. While using OAuth is applicable to [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html), the SaaS version of Bitbucket, you'll need to provide a URL, username, and personal access token for [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html), the enterprise self-hosted version. Clicking on the Bitbucket Cloud option on the \"Import\" screen automatically takes you to Atlassian authentication for Bitbucket.\n\n![Import project from BitBucket](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097252726.png)\n\nYou can also import Bitbucket projects using the [GitLab Import API](https://docs.gitlab.com/ee/api/import.html).\n\n### Gitea\n\n![Import project from Gitea](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097252727.png)\n\nImporting projects from [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html) requires the creation of a [personal access token](https://docs.gitea.com/next/development/api-usage#authentication-via-the-api) on the Gitea platform and providing it along with the Gitea server URL on the GitLab import page. OAuth authentication is not supported. \n\n### Generic remote Git repository\n\n![Import project from remote Git repository](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097252728.png)\n\nWhere your Git provider is not supported or import is not possible using the supported methods, a repository can be imported using its accessible `https://` or `git://` URL.  If it's not publicly accessible, you will provide the repository URL along with username and password (or access token where applicable due to multifactor authentication).\n\nThis method can also be used for maintaining a copy of a remote project and keeping it in sync, i.e., [mirroring](https://docs.gitlab.com/ee/user/project/repository/mirror/). Mirroring allows you to maintain repositories across different platforms and keep them synced. This can be to separate private and public access to project while ensuring both ends have the same copy, which is useful when open-sourcing  internal projects. It can also be used when working with contractors and both parties use different platforms, and access to codebase is necessary on both ends. \n\n## Summary\n\nImporting and migrating between GitLab instances and from other sources is an important process that needs to be planned to ensure the expectations are clear on what gets imported and with which method. While most third-party methods import project items, including files, issues, and merge requests, some methods have known issues and limitations. The [GitLab import section](https://docs.gitlab.com/ee/user/project/import/) of the documentation has detailed information on all the supported methods that can help you plan your migration.   \n\n> #### Want to take your learning to the next level? [Sign up for GitLab University courses](https://university.gitlab.com/). Or you can get going right away with [a free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/).\n\n## \"Getting started with GitLab\" series\n\n- [How to manage users](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Mastering project management](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automating Agile workflows with the gitlab-triage gem](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Working with CI/CD variables](https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables/)\n",[14,671,475],{"slug":1461,"featured":6,"template":674},"getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","content:en-us:blog:getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","Getting Started With Gitlab How To Import Your Projects To Gitlab","en-us/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","en-us/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"_path":1467,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1468,"content":1474,"config":1479,"_id":1481,"_type":16,"title":1482,"_source":17,"_file":1483,"_stem":1484,"_extension":20},"/en-us/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features",{"title":1469,"description":1470,"ogTitle":1469,"ogDescription":1470,"noIndex":6,"ogImage":1471,"ogUrl":1472,"ogSiteName":784,"ogType":785,"canonicalUrls":1472,"schema":1473},"Secure, compliant, and AI-powered: Get to know 3 new GitLab features","Enhance security, leverage new AI capabilities, and protect sensitive data with our latest platform improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","https://about.gitlab.com/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure, compliant, and AI-powered: Get to know 3 new GitLab features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jessica Hurwitz\"}],\n        \"datePublished\": \"2025-01-27\",\n      }",{"title":1469,"description":1470,"authors":1475,"heroImage":1471,"date":1476,"body":1477,"category":14,"tags":1478},[789],"2025-01-27","AI capabilities are rapidly reshaping how teams build, secure, and deploy applications. As part of our ongoing commitment to helping you navigate the evolving marketplace, GitLab has introduced more than 440 improvements in the past three releases. We're excited to spotlight three standout features making an immediate impact on how teams approach AI-powered DevSecOps. In addition, we announced we are partnering with AWS to launch [GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai/), combining our strengths to transform software development. We're creating an experience, together, that makes AI-powered development feel seamless and upholds the security, compliance, and reliability that enterprises require.\n\n> Learn how GitLab can [deliver 483% ROI over the next three years](https://about.gitlab.com/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years/), according to Forrester Consulting.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://player.vimeo.com/video/1056012314?badge=0\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" title=\"GitLab 17.6-17.8 Quarterly Release Overview\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 1. Vulnerability Resolution: Streamline security remediation\n\nGitLab’s 2024 [Global DevSecOps Report](https://about.gitlab.com/developer-survey/) found that 66% of companies are releasing software twice as fast — or faster — than in previous years, as businesses strive to deliver more value to their customers than competitors. However, speed introduces risk. With security teams [outnumbered by dev teams 80:1](https://www.opentext.com/assets/documents/en-US/pdf/developer-driven-appsec-security-at-the-speed-of-devops-pp-en.pdf), threat actors are able to exploit applications at a record pace. Last year alone, [80% of the top data breaches](https://www.crowdstrike.com/2024-state-of-application-security-report/) stemmed from attacks at the application layer.\n\n[GitLab Duo Vulnerability Resolution](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution) addresses this challenge head-on. When vulnerabilities are detected in your code, you can now access detailed information right from the vulnerability report and invoke GitLab Duo to automatically create a merge request that updates your code and mitigates the risk. While developers must review these auto-generated merge requests before merging to verify the changes, this automation significantly streamlines the remediation process. Vulnerability Resolution pairs with [Vulnerability Explanation](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/), which also recently became generally available. Vulnerability Explanation gives developers a detailed description of the vulnerability infecting their code, real-world examples of how attackers can exploit the vulnerable code, and practical suggestions for remediation.\n\nBy expediting the vulnerability remediation process, your teams can focus on delivering software faster while maintaining strong security practices. With less time spent researching and remediating vulnerabilities, developers can concentrate on building features that drive business value.\n\n_GitLab Duo Vulnerability Resolution is available as a [GitLab Duo Enterprise add-on](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro)._\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"\nhttps://www.youtube.com/embed/VJmsw_C125E?si=W7n1ESS63xkPyH4H\" frameborder=\"0\" title=\"GitLab Vulnerability Resolution\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 2. Model Registry: Breaking down silos between Data Science and Development teams\n\nFor organizations building AI-powered applications, bridging the gap between data science and software development teams has been a persistent challenge. Data scientists and developers often work in disconnected tools and workflows, leading to friction, delays, and potential errors when deploying models to production.\n\n[GitLab Model Registry](https://docs.gitlab.com/ee/user/project/ml/model_registry/) directly addresses this challenge by providing a centralized hub where data science and development teams can collaborate seamlessly within their existing GitLab workflow. Built with [MLflow](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/mlflow_client.html#model-registry) native integration, the registry allows data scientists to continue using their preferred tools while making models and artifacts instantly accessible to the broader development team.\nThis unified approach transforms team collaboration. Data scientists can version models, store artifacts, and document model behavior through comprehensive model cards, while developers can easily integrate these models into their applications using GitLab CI/CD pipelines for automated testing and deployment.\n\nAdditionally, the Model Registry's semantic versioning and GitLab API integration enables teams to implement robust governance and automate production deployments, creating a streamlined environment where data scientists and developers can work together effectively to deliver AI-powered innovation.\n\n_Model Registry is available across all tiers for SaaS and self-managed customers. See the [release blog for 17.6](https://about.gitlab.com/releases/2024/11/21/gitlab-17-6-released/#model-registry-now-generally-available) and [documentation](https://docs.gitlab.com/ee/user/project/ml/model_registry/) for more._\n\n## 3. Secret Push Protection: Shift security left with proactive secret detection\n\nTeams often face a critical security challenge: Developers may hardcode sensitive information like API keys, tokens, and credentials as plain text in source code repositories, sometimes without even realizing it. This creates an easy target for threat actors and puts your organization at risk.\n\n[Secret Push Protection](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection/) directly addresses this problem by blocking developers from pushing code that contains secrets, significantly reducing the likelihood of a breach. It works by leveraging customizable rules to identify high-confidence secrets before they ever reach your repository.\n\nWhat makes this solution particularly powerful is its integration with our pipeline secret detection, creating a comprehensive defense strategy.\n\n_Secret Push Protection is now generally available for all [GitLab Ultimate tier](https://about.gitlab.com/pricing/ultimate/) and [GitLab Dedicated](https://about.gitlab.com/dedicated/) customers._\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"\nhttps://www.youtube.com/embed/SFVuKx3hwNI?si=aV_3Lazs2AiDH3Jf\" title=\"Introduction to Secret Push Protection\" frameborder=\"0\" title=\"GitLab Vulnerability Resolution\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Put these features to work today\n\nAt GitLab, we’re committed to making it easier for teams to build software, faster. Capabilities like GitLab Duo Vulnerability Resolution, Model Registry, and Secret Push Protection are just a few of the recent innovations we’ve delivered to help developers and security teams level up their DevSecOps workflows. To learn more, check out our [releases page](https://about.gitlab.com/releases/categories/releases/).\n\n> Get started with these new features today with [a free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n",[710,475,794,14,1101],{"slug":1480,"featured":91,"template":674},"secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features","content:en-us:blog:secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features.yml","Secure Compliant And Ai Powered Get To Know 3 New Gitlab Features","en-us/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features.yml","en-us/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features",{"_path":1486,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1487,"content":1493,"config":1499,"_id":1501,"_type":16,"title":1502,"_source":17,"_file":1503,"_stem":1504,"_extension":20},"/en-us/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability",{"title":1488,"description":1489,"ogTitle":1488,"ogDescription":1489,"noIndex":6,"ogImage":1490,"ogUrl":1491,"ogSiteName":784,"ogType":785,"canonicalUrls":1491,"schema":1492},"Hosted runners for GitLab Dedicated: Now in limited availability"," Simplify CI/CD infrastructure management with hosted runners for GitLab Dedicated, a fully managed solution that handles all aspects of runner infrastructure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664751/Blog/Hero%20Images/AdobeStock_640077932.jpg","https://about.gitlab.com/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Hosted runners for GitLab Dedicated: Now in limited availability\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gabriel Engel\"}],\n        \"datePublished\": \"2025-01-23\",\n      }",{"title":1488,"description":1489,"authors":1494,"heroImage":1490,"date":1496,"body":1497,"category":14,"tags":1498},[1495],"Gabriel Engel","2025-01-23","We are excited to announce that hosted runners for [GitLab Dedicated](https://about.gitlab.com/dedicated/), our single-tenant SaaS solution, have transitioned from [beta](https://about.gitlab.com/blog/hosted-runners-for-gitlab-dedicated-available-in-beta/) to limited availability, marking a significant milestone in our commitment to simplifying CI/CD infrastructure management for our customers.\n\n## Streamlined CI/CD infrastructure management\n\nManaging runner infrastructure has traditionally been a complex undertaking, requiring dedicated resources and expertise to maintain optimal performance. Hosted runners for GitLab Dedicated eliminates these challenges by providing a fully managed solution that handles all aspects of runner infrastructure. This allows your teams to focus on what matters most – building and deploying great software.\n\n## Key benefits\n\n### Reduced operational overhead\n\nBy choosing hosted runners, you can eliminate the complexity of provisioning, maintaining, and securing your runner infrastructure. Our fully managed service handles all aspects of runner operations, from deployment to updates and security patches.\n\n### Automatic scaling\n\nHosted runners automatically scale to match your CI/CD demands, ensuring consistent performance during high-traffic periods and for large-scale projects. This dynamic scaling capability means you'll always have runners available to pick up your CI/CD jobs and ensure optimal efficiency of your development teams.\n\n### Cost optimization\n\nWith hosted runners, you only pay for the resources you actually use. This consumption-based model eliminates the need to maintain excess capacity for peak loads, potentially reducing your infrastructure costs while ensuring resources are available when needed.\n\n### Enterprise-grade security\n\nFollowing the same security principles as GitLab Dedicated, hosted runners provide complete isolation from other tenants and are secure by default. Jobs are executed in fully-isolated VMs with no inbound traffic allowed. This means you can maintain the highest security standards without the complexity of implementing and maintaining security measures yourself.\n\n## Introducing native Arm64 support\n\nOur hosted runners now include native Arm64 support in addition to our existing x86-64 runners, offering significant advantages for modern development workflows.\n\n### Enhanced performance for Arm-based development\n\nNative Arm64 runners enable you to build, test, and deploy Arm-based applications in their native environment, ensuring optimal performance and compatibility. Teams developing Docker images or services targeting Arm-based cloud platforms can see build times cut significantly, accelerating their development cycles and deployments.\n\n### Cost-efficient computing\n\nArm-based runners can significantly reduce your computing costs, due to their efficient processing architecture and lower cost per minute. For compatible jobs, this means more affordable pipeline execution.\n\n### Native building capabilities\n\nWith support for both x86-64 and Arm64 architectures, you can:\n- build and test applications natively on either architecture\n- create multi-architecture container images efficiently\n- validate cross-platform compatibility in your CI/CD pipeline\n- optimize your delivery pipeline for specific target platforms\n- eliminate the performance overhead of emulation when building for Arm targets\n\nThis dual-architecture support ensures you have the flexibility to choose the right environment for each specific workload while maintaining a consistent and efficient CI/CD experience across all your projects.\n\n## Available runner sizes\n\nWe're expanding our runner offerings to include both x86-64 and Arm64 architectures with a range of configurations. The following sizes are available:\n\n| Size | vCPUs | Memory | Storage |\n|------|--------|---------|----------|\n| Small    | 2      | 8 GB    | 30 GB    |\n| Medium    | 4      | 16 GB   | 50 GB    |\n| Large    | 8      | 32 GB   | 100 GB   |\n| X-Large   | 16     | 64 GB   | 200 GB   |\n| 2X-Large  | 32     | 128 GB  | 200 GB   |\n\nThis expanded size support allows you to optimize your CI/CD pipeline performance based on your application's specific requirements.\n\n## What's next for hosted runners\n\nWe plan to release hosted runners in general availability in May 2025. The release includes compute minute visualization to help you better understand and control your CI/CD usage across your organization.\n\nWe'll be expanding our hosted runners offering with several new features coming later this year:\n- Network controls for enhanced security and compliance\n- MacOS runners to support application development for the Apple ecosystem\n- Windows runners for .NET and Windows-specific workloads\n\nThese additions will provide even more flexibility and coverage for your CI/CD needs, allowing you to consolidate all your build and test workflows on GitLab Dedicated hosted runners.\n\nReady to simplify your CI/CD infrastructure? Contact your GitLab representative or [reach out to our sales team](https://about.gitlab.com/dedicated/) to learn more about hosted runners for GitLab Dedicated.\n",[710,475,794,838,109,184],{"slug":1500,"featured":6,"template":674},"hosted-runners-for-gitlab-dedicated-now-in-limited-availability","content:en-us:blog:hosted-runners-for-gitlab-dedicated-now-in-limited-availability.yml","Hosted Runners For Gitlab Dedicated Now In Limited Availability","en-us/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability.yml","en-us/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability",{"_path":1506,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1507,"content":1511,"config":1517,"_id":1520,"_type":16,"title":1521,"_source":17,"_file":1522,"_stem":1523,"_extension":20},"/en-us/blog/gitlab-patch-release-17-8-1-17-7-3-17-6-4",{"title":1508,"description":685,"ogTitle":1508,"ogDescription":685,"noIndex":91,"ogImage":689,"ogUrl":1509,"ogSiteName":784,"ogType":785,"canonicalUrls":1509,"schema":1510},"GitLab Patch Release: 17.8.1, 17.7.3, 17.6.4","https://about.gitlab.com/blog/gitlab-patch-release-17-8-1-17-7-3-17-6-4","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.8.1, 17.7.3, 17.6.4\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2025-01-22\",\n      }",{"title":1508,"description":685,"authors":1512,"heroImage":689,"date":1514,"body":1515,"category":14,"tags":1516},[1513],"Ottilia Westerlund","2025-01-22","This is the post for [GitLab Patch Release: 17.8.1, 17.7.3, 17.6.4](https://about.gitlab.com/releases/2025/01/22/patch-release-gitlab-17-8-1-released/).",[879,692],{"slug":1518,"featured":6,"template":674,"externalUrl":1519},"gitlab-patch-release-17-8-1-17-7-3-17-6-4","https://about.gitlab.com/releases/2025/01/22/patch-release-gitlab-17-8-1-released/","content:en-us:blog:gitlab-patch-release-17-8-1-17-7-3-17-6-4.yml","Gitlab Patch Release 17 8 1 17 7 3 17 6 4","en-us/blog/gitlab-patch-release-17-8-1-17-7-3-17-6-4.yml","en-us/blog/gitlab-patch-release-17-8-1-17-7-3-17-6-4",{"_path":1525,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1526,"content":1532,"config":1538,"_id":1541,"_type":16,"title":1542,"_source":17,"_file":1543,"_stem":1544,"_extension":20},"/en-us/blog/gitlab-17-8-released",{"title":1527,"description":1528,"ogTitle":1527,"ogDescription":1528,"noIndex":91,"ogImage":1529,"ogUrl":1530,"ogSiteName":784,"ogType":785,"canonicalUrls":1530,"schema":1531},"GitLab 17.8 released","Includes enhanced security for container repositories, list deployments related to a release, ML model experiments tracking, Hosted runners on Linux for GitLab Dedicated, and more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662175/Blog/Hero%20Images/product-gl17-blog-release-cover-17-8-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-8-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.8 released\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joe Randazzo\"}],\n        \"datePublished\": \"2025-01-16\",\n      }",{"title":1527,"description":1528,"authors":1533,"heroImage":1529,"date":1535,"body":1536,"category":14,"tags":1537},[1534],"Joe Randazzo","2025-01-16","This is the [release post for GitLab 17.8](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/).",[752,14],{"slug":1539,"featured":91,"template":674,"externalUrl":1540},"gitlab-17-8-released","https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/","content:en-us:blog:gitlab-17-8-released.yml","Gitlab 17 8 Released","en-us/blog/gitlab-17-8-released.yml","en-us/blog/gitlab-17-8-released",{"_path":1546,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1547,"content":1552,"config":1557,"_id":1560,"_type":16,"title":1561,"_source":17,"_file":1562,"_stem":1563,"_extension":20},"/en-us/blog/gitlab-patch-release-17-7-2",{"title":1548,"description":1549,"ogTitle":1548,"ogDescription":1549,"noIndex":91,"ogImage":1071,"ogUrl":1550,"ogSiteName":784,"ogType":785,"canonicalUrls":1550,"schema":1551},"GitLab Patch Release: 17.7.2","Patch Release for 17.7.2 for GitLab Community Edition and Enterprise Edition.","https://about.gitlab.com/blog/gitlab-patch-release-17-7-2","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.7.2\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-01-15\",\n      }",{"title":1548,"description":1549,"authors":1553,"heroImage":1071,"date":1554,"body":1555,"category":14,"tags":1556},[976],"2025-01-15","This is the post for Patch Release 17.7.2 for GitLab Community Edition and Enterprise Edition.",[692],{"slug":1558,"featured":6,"template":674,"externalUrl":1559},"gitlab-patch-release-17-7-2","https://about.gitlab.com/releases/2025/01/15/gitlab-17-7-2-released/","content:en-us:blog:gitlab-patch-release-17-7-2.yml","Gitlab Patch Release 17 7 2","en-us/blog/gitlab-patch-release-17-7-2.yml","en-us/blog/gitlab-patch-release-17-7-2",{"_path":1565,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1566,"content":1572,"config":1580,"_id":1582,"_type":16,"title":1583,"_source":17,"_file":1584,"_stem":1585,"_extension":20},"/en-us/blog/google-cloud-integrations-for-secure-cloud-run-deployments-at-gitlab",{"title":1567,"description":1568,"ogTitle":1567,"ogDescription":1568,"noIndex":6,"ogImage":1569,"ogUrl":1570,"ogSiteName":784,"ogType":785,"canonicalUrls":1570,"schema":1571},"Google Cloud integrations for secure Cloud Run deployments at GitLab","This tutorial demonstrates how to use GitLab’s Google Artifact Management integration to deploy to Google Cloud Run, a serverless runtime for containers application.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099336/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945_fJKX41PJHKCfSOWw4xQxm_1750099336757.png","https://about.gitlab.com/blog/google-cloud-integrations-for-secure-cloud-run-deployments-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Google Cloud integrations for secure Cloud Run deployments at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"},{\"@type\":\"Person\",\"name\":\"Matt Genelin\"}],\n        \"datePublished\": \"2025-01-15\",\n      }",{"title":1567,"description":1568,"authors":1573,"heroImage":1569,"date":1554,"body":1576,"category":14,"tags":1577},[1574,1575],"Regnard Raquedan","Matt Genelin","*This tutorial is from a recent Arctiq, GitLab, and Google in-person workshop. The goal was to explore common security challenges faced by organizations as they journey to the cloud.*\n\nThis tutorial will help you learn about the [Google Cloud integrations in GitLab](https://cloud.google.com/docs/gitlab). These features are meant to help accelerate and improve security of deployments to Google Cloud.\n\n![Google integrations list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099345/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099345112.png)\n\n## Prerequisites\n\n1. [Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects)  \n2. Appropriate [IAM permissions](https://cloud.google.com/iam/docs/) for security, Artifact Registry, and Cloud Run usage. For this tutorial, ensure you have the \"Owner\" role with the aforementioned project.\n\n## Setting up Workload Identity Federation\n\nIn this step, we configure GitLab to connect Google Cloud's Workload Identity Federation to reduce the need for service accounts and let the two platforms use short-lived credentials on-demand.\n\n1. On the left sidebar, select **Search** or go to and find your group or project. If you configure this in a group, settings apply to all projects within by default.  \n2. Select **Settings \\> Integrations**.  \n3. Select **Google Cloud IAM**.  \n4. Input the Project ID and Project number in the respective fields. This information can be obtained from the Google Cloud console [Welcome](https://console.cloud.google.com/welcome) page of your project.  \n5. Input the desired Pool ID and Provider ID in the respective fields. These are values that you provide and must be unique from other Pool and Provider IDs.  \n6. Copy the generated command and then go to the **Google Cloud console**.  \n7. Run **Cloud Shell** and execute the generated command from the Workload Identity Federation integration page.  \n8. Once successful, the **Google Cloud IAM** integration will be designated as active in the Integrations list at the GitLab project.\n\n## Artifact Registry configuration\n\nAs an alternative to GitLab's own place to host artifacts, deploying to Google Cloud's Artifact Registry is another way to leverage their infrastructure. This section will provide steps on how to use GitLab's native integration with Artifact Registry. Note that Workload Identity Federation must already be configured prior to this.\n\n1. At the **Google Cloud** console, go to **Artifact Registry** via search or the main navigation.  \n2. Create a new repository by clicking the **\"+\"** icon. At the creation page, provide a name and keep the **Docker** format and **Standard** mode selected. Select **Region** and choose **us-central1**. Leave the rest at the default settings and click **Create**.  \n3. Once the repository is created and confirmed, go back to your GitLab project.  \n4. In your GitLab project, on the left sidebar, select **Settings > Integrations**. Then select **Google Artifact Registry**.  \n5. Under Enable integration, select the **Active** checkbox, then complete the fields:  \n   * Google Cloud project ID: The ID of the Google Cloud project where your Artifact Registry repository is located.  \n   * Repository name: The name of your Artifact Registry repository.  \n   * Repository location: The location of your Artifact Registry repository. (`us-central1` is assumed.)  \n6. In **Configure Google Cloud IAM policies**, follow the onscreen instructions to set up the IAM policies in Google Cloud. These policies are required to use the Artifact Registry repository in your GitLab project. Select **Save** changes.  \n7. To view your Google Cloud artifacts, on the left sidebar, select **Deploy > Google Artifact Registry**.\n\n## Cloud Run configuration\n\n1. Enable the Cloud Run API, if not done already. Go to **APIs & Services > Enabled APIs & Services**. From there, click **Enable APIs & Services** at the top and search for **Cloud Run Admin API**. Select the search result and enable the API.  \n2. Configure the IAM policies in Google Cloud to grant permissions to allow the Cloud Run CI/CD component to deploy to Cloud Run.\n\n```\nGCP_PROJECT_ID=\"\u003CPROJECT ID>\"\nGCP_PROJECT_NUMBER=\"\u003CPROJECT NUMBER>\"\nGCP_WORKLOAD_IDENTITY_POOL=\"\u003CPOOL ID>\"\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/run.admin'\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/iam.serviceAccountUser'\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/cloudbuild.builds.editor'\n```\n\n## Deploy to Cloud Run\n\nIn this section, you will use Gitlab's CI/CD components to deploy to Cloud Run, Google Cloud's serverless runtime for containers.\n\n1. Go to the GitLab project and from the list of files in the source code, find `.gitlab-ci.yaml`. Click the **file name** and the single file editor will show up. Click the **Edit** button and select the **Open in Web IDE** option.  \n2. In Web IDE, copy-paste the following code:\n\n```\nstages:\n    - build\n    - upload\n    - deploy\n```\n\nThis code snippet sets up three stages in the pipeline: build, upload, and deploy.\n\n1. The next step is to create two CI/CD variables in the same YAML file:\n\n```\nvariables:\n    GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA\n    AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA\n```\n\nThe first variable, `GITLAB\\_IMAGE`, denotes the container image that the pipeline creates by default. The second one, `AR\\_IMAGE`, denotes the location at Google Cloud's Artifact Registry where the container image will be pushed to.\n\n2. Next, define the code that will build the container image:\n\n```\nbuild:\n    image: docker:24.0.5\n    stage: build\n    services:\n        - docker:24.0.5-dind\n    before_script:\n        - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    script:\n        - docker build -t $GITLAB_IMAGE .\n        - docker push $GITLAB_IMAGE\n```\n\nThis code uses [pre-defined CI/CD variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) for the Docker commands.\n\n3. The final step is using two CI/CD components to deploy to Google Cloud. The first component integrates with Artifact Registry and the second is the deployment to Cloud Run:\n\n```\ninclude:\n    - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main\n      inputs:\n        stage: upload\n        source: $GITLAB_IMAGE\n        target: $AR_IMAGE\n\n    - component: gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@main\n      inputs:\n        stage: deploy\n        project_id: \"\u003CPROJECT_ID>\"\n        service: \"tanuki-racing\"\n        region: \"\u003CREGION>\"\n        image: $AR_IMAGE\n```\n\nReplace \u003CPROJECT_ID> with your Google Cloud Project ID. Replace with the [Google Cloud region](https://cloud.google.com/compute/docs/regions-zones) most appropriate to your location. `us-central1` is assumed.\n\nCommit the changes and push to the main branch. For reference, the final `.gitlab-ci.yaml` should look like this, noting to replace the \u003CPROJECT ID> and \u003CREGION> with the appropriate values:\n\n```\nstages:\n    - build\n    - upload\n    - deploy\nvariables:\n    GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA\n    AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA\n\nbuild:\n    image: docker:24.0.5\n    stage: build\n    services:\n        - docker:24.0.5-dind\n    before_script:\n        - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    script:\n        - docker build -t $GITLAB_IMAGE .\n        - docker push $GITLAB_IMAGE\n\ninclude:\n    - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main\n      inputs:\n        stage: upload\n        source: $GITLAB_IMAGE\n        target: $AR_IMAGE\n\n    - component: gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@main\n      inputs:\n        stage: deploy\n        project_id: \"\u003CPROJECT_ID>\"\n        service: \"tanuki-racing\"\n        region: \"\u003CREGION>\"\n        image: $AR_IMAGE\n```\n\n1. Go back to the main GitLab project and view the pipeline that was just initiated. Take note of the stages that should be the same stages that were defined in Step 2.  \n2. Once the pipeline is complete, go to the Google Cloud console and then **Cloud Run** via search or navigation. A new Cloud Run service called `tanuki-racing` should be created.  \n3. Click the **service name** and then go to the **Security** tab. Ensure that the service is set to **Allow unauthenticated invocations**. This will make the deployed app publicly available. The app URL posted on screen is now available and should open a new browser tab when clicked.\n\nBy utilizing GitLab’s CI/CD pipelines to build and push a containerized application to Google Artifact Registry, you can see the power of GitLab’s AI-powered DevSecOps Platform as a means to building secure applications. GitLab also deployed the containerized application to Google’s Cloud Run as a low-cost running application on the public internet. Using GitLab to instrument building an application, pushing a container and triggering a cloud run deployment allows DevOps engineers to have the assurance that secure applications are being run on the public-facing internet.\n\n> [Sign up for a 60-day free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/) to begin working with these integrations. Also, check out our [solutions architecture area](https://about.gitlab.com/blog/tags/solutions-architecture/) for more Gitlab and Google Cloud tutorials.",[231,1578,1579,671,1341],"google","GKE",{"slug":1581,"featured":6,"template":674},"google-cloud-integrations-for-secure-cloud-run-deployments-at-gitlab","content:en-us:blog:google-cloud-integrations-for-secure-cloud-run-deployments-at-gitlab.yml","Google Cloud Integrations For Secure Cloud Run Deployments At Gitlab","en-us/blog/google-cloud-integrations-for-secure-cloud-run-deployments-at-gitlab.yml","en-us/blog/google-cloud-integrations-for-secure-cloud-run-deployments-at-gitlab",{"_path":1587,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1588,"content":1594,"config":1599,"_id":1601,"_type":16,"title":1602,"_source":17,"_file":1603,"_stem":1604,"_extension":20},"/en-us/blog/getting-started-with-gitlab-how-to-manage-users",{"title":1589,"description":1590,"ogTitle":1589,"ogDescription":1590,"noIndex":6,"ogImage":1591,"ogUrl":1592,"ogSiteName":784,"ogType":785,"canonicalUrls":1592,"schema":1593},"Getting started with GitLab: How to manage users","Learn how to manage users using groups, roles, and permissions. Walk through the setup of secure collaboration with proper project access.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097273/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097273817.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with GitLab: How to manage users\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-14\",\n      }",{"title":1589,"description":1590,"authors":1595,"heroImage":1591,"date":1596,"body":1597,"category":14,"tags":1598},[1457],"2025-01-14","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nEnsuring a safe, compliant, and collaborative environment starts with the most basic of tasks - managing users. In this tutorial, we show you how to establish project members, assign roles and permissions, and create groups and subgroups.\n\nNote: To follow along with this tutorial, you should have a GitLab account either through GitLab.com or your organization's self-managed instance. If you need help, visit our fundamentals area on [GitLab University](https://university.gitlab.com/).\n\nLet's get started.\n\nWhen you create GitLab users, they only have access to [their private projects, public projects, and projects set with internal visibility](https://docs.gitlab.com/ee/user/public_access.html). For the purposes of this tutorial, your project is super secret and only invited members should have access to it – at varying permissions settings. To ensure this, you can invite users as [members of the project](https://docs.gitlab.com/ee/user/project/members/).\n\n## Project members\n\n![Project members screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097278487.png)\n\nGitLab users can be invited to a project and [assigned a role](https://docs.gitlab.com/ee/user/permissions.html), which determines what they can do in the project. The owner of a project can delegate administrative tasks to other users as maintainers, who can do almost everything an owner does, aside from changes to a project such as deleting, archiving, or transferring a project.\n\n![Invite members screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097278487.png)\n\n[Maintainers](https://docs.gitlab.com/ee/user/permissions.html#roles) of the project can invite other members as developers who have access to all the features to create, build, and deploy software. Users who are not developers but need project management access can be invited to the project as [planners](https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/), reporters, and guests with varying levels of permissions. These roles can also be used to determine who can make changes to certain branches with [protected branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html).\n\nIf you are working with contractors or your use requires user permissions to expire, you can set an expiry date after which the user loses access to the project. Project members can also be identified as direct or indirect members, based on their [membership type](https://docs.gitlab.com/ee/user/project/members/#membership-types). Direct members are invited directly into the project, whereas indirect members are often inherited from a [GitLab group](https://docs.gitlab.com/ee/user/group/) a project belongs to.\n\nNow, let's look at Group memberships.\n\n## Group memberships\n\nGroups in GitLab can be a top level created at the root of a GitLab instance like the [gitlab.com/gitlab-org](http://gitlab.com/gitlab-org). which is a parent group used to organize other subgroups like [gitlab.com/gitlab-org/charts](http://gitlab.com/gitlab-org/charts). Groups are useful even if you only have one project.\n\nGroups can be used for different reasons:\n\n- organizing similar or related projects  \n- organizing users into groups for better team coordination\n\nWhen using groups to organize users, you can organize teams in groups and [invite a group to a project](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html) with a specific role for an entire team. You can have a `dev` group for the developers of the team, `pm` group for the project managers and `leads` for team leads. When inviting the groups, `dev` can be assigned the Developer role, `pm` the Planner role, and `leads` the Maintainer role. \n\n![Invite a group screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097279/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097278488.png)\n\nMembers of each group can be can be added or removed without needing to update project permissions. This is particularly useful when your team has grown to have several projects. However, it is important to [observe best practices](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html#setting-up-a-group-for-collaboration) for using groups for collaboration.\n\nAnother helpful aspect of having users organized in groups is that you can [mention](https://docs.gitlab.com/ee/user/discussions/#mentions) the entire group in issues, merge requests, or comments, which makes keeping an entire team informed easier.\n\n### Create subgroups\n\n[Subgroups](https://docs.gitlab.com/ee/user/group/subgroups/) can be used to further organize users in a group and you can keep adding subgroups up to 20 nested levels. Users in a subgroup inherit the the permissions they have in a parent group. If you want to grant a user in a subgroup a role higher than what they inherited, you will need to [invite them to the subgroup](https://docs.gitlab.com/ee/user/group/subgroups/#override-ancestor-group-membership) with the new higher role. Note: You can not give them a lower role in the subgroup.\n\n### Manage groups\n\nGroup Owners have several management options to determine how users function in a group. For instance, you can set how a user can request access to a group, enable/disable [group mentions](https://docs.gitlab.com/ee/user/group/manage.html#disable-group-mentions), [restrict access](https://docs.gitlab.com/ee/user/group/manage.html#turn-on-restricted-access), or [moderate users](https://docs.gitlab.com/ee/user/group/moderate_users.html), among other options. An exciting new feature, which is still under development at the time of this article's publication, is the [automatic removal of dormant users](https://docs.gitlab.com/ee/user/group/moderate_users.html#automatically-remove-dormant-members) after a minimum of 90 days and a maximum of five years. This will help keep groups clean and better manage the release of license seats.\n\n## Learn more\n\nManaging users on GitLab depends on your use case. If your organization is larger with more advanced workflows and user management, GitLab provides more advanced ways to [manage enterprise users](https://docs.gitlab.com/ee/user/enterprise_user/index.html). You can also explore more options on how to [manage your organization](https://docs.gitlab.com/ee/topics/set_up_organization.html) and with [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/), you get more granularity and compliance features.\n\n> #### Want to take your learning to the next level? [Sign up for GitLab University courses](https://university.gitlab.com/). Or you can get going right away with [a free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## \"Getting started with GitLab\" series\nRead more articles in our \"Getting started with GitLab\" series:\n\n- [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Mastering project management](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automating Agile workflows with the gitlab-triage gem](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Understanding CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)\n- [Working with CI/CD variables](https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables/)\n",[475,794,671,1178,14],{"slug":1600,"featured":91,"template":674},"getting-started-with-gitlab-how-to-manage-users","content:en-us:blog:getting-started-with-gitlab-how-to-manage-users.yml","Getting Started With Gitlab How To Manage Users","en-us/blog/getting-started-with-gitlab-how-to-manage-users.yml","en-us/blog/getting-started-with-gitlab-how-to-manage-users",{"_path":1606,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1607,"content":1613,"config":1619,"_id":1622,"_type":16,"title":1623,"_source":17,"_file":1624,"_stem":1625,"_extension":20},"/en-us/blog/gitlab-17-7-released",{"title":1608,"description":1609,"ogTitle":1608,"ogDescription":1609,"noIndex":91,"ogImage":1610,"ogUrl":1611,"ogSiteName":784,"ogType":785,"canonicalUrls":1611,"schema":1612},"GitLab 17.7 released","Release includes a new Planner user role, auto-resolution policy for vulnerabilities, admin-controlled instance integration allowlists, access token rotation in the UI and much more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662186/Blog/Hero%20Images/product-gl17-blog-release-cover-17-7-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-7-released","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.7 released\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Courtney Meddaugh\"}],\n        \"datePublished\": \"2024-12-19\",\n      }",{"title":1608,"description":1609,"authors":1614,"heroImage":1610,"date":1616,"body":1617,"category":14,"tags":1618},[1615],"Courtney Meddaugh","2024-12-19","This is the [release post for GitLab 17.7](about.gitlab.com/releases/2024/12/19/gitlab-17-7-released/).",[752,14,475],{"slug":1620,"featured":91,"template":674,"externalUrl":1621},"gitlab-17-7-released","https://about.gitlab.com/releases/2024/12/19/gitlab-17-7-released/","content:en-us:blog:gitlab-17-7-released.yml","Gitlab 17 7 Released","en-us/blog/gitlab-17-7-released.yml","en-us/blog/gitlab-17-7-released",{"_path":1627,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1628,"content":1634,"config":1640,"_id":1642,"_type":16,"title":1643,"_source":17,"_file":1644,"_stem":1645,"_extension":20},"/en-us/blog/5-gitlab-premium-features-to-help-your-team-scale",{"title":1629,"description":1630,"ogTitle":1629,"ogDescription":1630,"noIndex":6,"ogImage":1631,"ogUrl":1632,"ogSiteName":784,"ogType":785,"canonicalUrls":1632,"schema":1633},"5 GitLab Premium features to help your team scale","Explore how GitLab Premium boosts team collaboration and productivity, enabling organizations to scale with streamlined workflows and advanced capabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665151/Blog/Hero%20Images/blog-image-template-1800x945__27_.png","https://about.gitlab.com/blog/5-gitlab-premium-features-to-help-your-team-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 GitLab Premium features to help your team scale\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Griffin\"}],\n        \"datePublished\": \"2024-12-18\",\n      }",{"title":1629,"description":1630,"authors":1635,"heroImage":1631,"date":1637,"body":1638,"category":14,"tags":1639},[1636],"Julie Griffin","2024-12-18","As development teams grow, what once worked for a small team often becomes a bottleneck. Code standards become inconsistent, operational silos develop, and technical debt accumulates faster. What was a well-oiled machine is now dysfunctional as more team members, projects, and tools are added on. \n\nMany teams experience these challenges as they grow, but how you handle and address these growing pains can save you time, energy, and money in the long run. In this article, we’ll explore the common pitfalls growing teams face and how successful organizations address them. \n\n## 1. Consistent code quality\n\nOne of the challenges growing teams face is [maintaining consistent code quality](https://about.gitlab.com/blog/transform-code-quality-and-compliance-with-automated-processes/) as more developers contribute to the codebase. Quality issues that were once caught quickly now take longer to identify and fix.\n\nSuccessful teams address these challenges through automated code analysis throughout their development workflow. Instead of relying solely on manual reviews, they implement systems to identify potential issues and enforce consistent standards before code even reaches human reviewers. This approach helps detect complexity issues early and flags potential security vulnerabilities, allowing reviewers to focus on more strategic aspects of code review.\n\n### Features that maintain consistent code quality\n\n* Start by automating code analysis in your workflow. With GitLab Premium, you can set up [Code Quality Reports](https://docs.gitlab.com/ee/ci/testing/code_quality.html) in your merge requests. This helps catch issues early by analyzing code complexity and quality before review begins. For example, when a developer submits changes that might increase technical debt, the report will flag these issues automatically.  \n* Next, establish automated quality standards. Configure Quality Gates to define what \"good code\" means for your team. This could include test coverage requirements, complexity limits, or specific coding patterns. When code doesn't meet these standards, merges are automatically blocked until issues are addressed.  \n* Finally, prevent issues before they even reach review. [Push Rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) let you enforce standards right at commit time. You might start with simple rules like requiring certain commit message formats, then gradually add more sophisticated checks as your team adapts.\n\n## 2. Improve collaboration and productivity\n\nThe priorities for startups are often budget and speed, but as businesses grow, tracking DevSecOps workflows across a patchwork of tools can actually deter productivity.\n\nDisparate tools cause developers to context switch between platforms, decreasing focus time and development speed. Toolchain sprawl also limits visibility among teams, creating operational silos that lead to miscommunication.\n\nTo address these challenges, teams often turn to Agile solutions to help with project management, align timelines, and improve cross-team collaboration. When combined with a DevSecOps environment, [Agile](https://about.gitlab.com/topics/agile-devsecops/) creates a powerful system for software development that marries the iterative Agile approach with a security-first mindset. \n\n### Features that improve collaboration and productivity\n\n* With GitLab Premium, teams can access enterprise-grade Agile tools within their DevSecOps platforms. You can start by creating [groups and projects](http://%20epics), assigning team members roles, and determining their level of permission.   \n* [Milestones](https://docs.gitlab.com/ee/user/project/milestones/) and [epics](https://docs.gitlab.com/ee/user/group/epics/index.html) help teams plan large-scale initiatives across multiple projects to track dependencies, progress, and align on deliverables. This gives everyone clear visibility into the process.  \n* Then, dive deeper into each task with [issues](https://docs.gitlab.com/ee/user/project/issue_board.html). With customizable workflows and multi-assignee capabilities, teams can visualize project progress, dynamically adjust priorities, and collaborate on issue resolution.\n\n## 3. Increase deployment velocity\n\nIn theory, teams should be more productive as they scale. However, if tools aren’t updated to accommodate a growing team, the CI/CD pipeline can feel clunky and inefficient. \n\nTeams turn to tools that help them automate and optimize the [CI/CD pipeline](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/). By automating components like code reviews, merge trains, and permissions, teams can streamline the CI/CD pipeline and improve deployment speed. \n\n### Features that increase deployment velocity\n\nGitLab Premium offers advanced features that help you build, maintain, deploy, and monitor complex pipelines. Increase the speed of deployment through the CI/CD pipeline with more control over code reviews and merge request processes.\n\n* You can automate the merging of multiple changes in a controlled sequence with Merge Trains. This reduces integration issues and improves deployment efficiency.  \n* Gain visibility into whether your jobs passed or failed with Multi-Project Pipeline Graphs. Access all related jobs for a single commit and the net result of each stage of your pipeline to quickly see what failed and fix it.  \n* Team leaders can access comprehensive insights and make data-informed decisions with [Code Review Analytics](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html) that provide detailed metrics and merge request analytics. This helps teams identify bottlenecks, optimize review cycles, and establish data-driven process improvements. \n\n## 4. Enhance security and compliance controls\n\nWithout rigorous governance policies, inefficient and insecure code may be released. With smaller companies, security reviews are often manual and the reviews often take a backseat to speed. This can lead to teams releasing incorrect or unsafe code to production causing costly delays. \n\nTo [evolve their security practices](https://about.gitlab.com/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab/), teams turn to stricter access controls, a more refined and delineated review process, as well as features that enable teams to review and track changes. \n\n### Features that enhance security and compliance controls\n\n* With stricter access controls, such as [Protected Branches and Protected Environments](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html), you can restrict push and merge access, securing those areas from unwanted changes by unauthorized users.  \n* To strengthen security review processes, implement [Multiple Approvers in Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/). This requires team members to review and approve code changes before they’re pushed through.  \n* Review who performed a certain action within the repository and at what time with [Audit Events](https://docs.gitlab.com/ee/administration/audit_event_reports.html). By tracking changes, you’re able to stay on top of compliance requirements. \n\n## 5. Avoid downtime and delays\n\nWithout support, teams are left to troubleshoot issues themselves. This can lead to major delays or periods of downtime where the company is unable to deliver value. As companies grow, this downtime becomes more and more detrimental to the business. \n\nIt’s important to evaluate what your company’s threshold is for downtime. When the value of the downtime outweighs the cost of support, it’s time to scale your DevSecOps platform to meet those needs. \n\n### Support services to avoid downtime and delays\n\nWith GitLab Premium, customers of both SaaS and self-managed instances have access to [Priority Support](https://about.gitlab.com/support/#priority-support). GitLab customer support offers Tiered Support response times, ranging from emergency to low-impact services, and can help you resolve issues quickly, minimizing downtime and disruption to your development cycle.\n\nPlus, for self-managed customers moving to Premium, GitLab offers support for any issues that occur after implementation and upgrade assistance to provide a seamless transition. \n\n## Build today, scale for tomorrow with GitLab Premium\n\nInstead of struggling with the challenges that growing teams face, scale your DevSecOps platform with GitLab Premium. \n\nGitLab Premium provides teams with the project management, pipeline tools, security, and support needed to work efficiently and effectively across the software development lifecycle. \n\n> #### Learn more about [why you should upgrade to GitLab Premium](https://about.gitlab.com/pricing/premium/why-upgrade/).",[475,794],{"slug":1641,"featured":6,"template":674},"5-gitlab-premium-features-to-help-your-team-scale","content:en-us:blog:5-gitlab-premium-features-to-help-your-team-scale.yml","5 Gitlab Premium Features To Help Your Team Scale","en-us/blog/5-gitlab-premium-features-to-help-your-team-scale.yml","en-us/blog/5-gitlab-premium-features-to-help-your-team-scale",{"_path":1647,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1648,"content":1654,"config":1660,"_id":1662,"_type":16,"title":1663,"_source":17,"_file":1664,"_stem":1665,"_extension":20},"/en-us/blog/transform-code-quality-and-compliance-with-automated-processes",{"title":1649,"description":1650,"ogTitle":1649,"ogDescription":1650,"noIndex":6,"ogImage":1651,"ogUrl":1652,"ogSiteName":784,"ogType":785,"canonicalUrls":1652,"schema":1653},"Transform code quality and compliance with automated processes","Learn how GitLab Premium features address the technical debt and security vulnerability challenges that plague traditional approaches.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","https://about.gitlab.com/blog/transform-code-quality-and-compliance-with-automated-processes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Transform code quality and compliance with automated processes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jessica Hurwitz\"}],\n        \"datePublished\": \"2024-12-13\",\n      }",{"title":1649,"description":1650,"authors":1655,"heroImage":1651,"date":1656,"body":1657,"category":14,"tags":1658},[789],"2024-12-13","While manual code review processes may suffice for a small team, as DevSecOps teams scale, the processes create significant bottlenecks that impede software development velocity and quality. Often slow, inconsistent, and frequently failing to catch critical vulnerabilities, the manual approach leads to technical debt and increased security risks.\n\nTo mitigate risks and drive innovation, organizations must prioritize automated code quality and compliance systems. The financial implications of poor code management are substantial, with technical debt consuming up to 40% of IT budgets ([McKinsey Digital: Tech Debt Report](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity)) and software vulnerabilities costing an average of $4.88 million per security breach ([IBM Cost of a Data Breach Report](https://www.ibm.com/reports/data-breach)). \n\nModern software development requires a strategic approach to code management and compliance that goes beyond traditional review processes. With more robust review systems and compliance controls, organizations can innovate and secure software faster than their competitors.\n\n## The power of code review and approval processes\n\nAccording to the [GitLab 2024 Global DevSecOps Report](https://about.gitlab.com/developer-survey/), C-level executives rank code quality as one of the top benefits of DevSecOps. With executives recognizing code quality as a strategic priority, systematic review processes have emerged as a cornerstone of modern development practices. \n\n[Code review](https://about.gitlab.com/topics/version-control/what-is-code-review/) processes benefit developers through knowledge sharing, the discovery of bugs earlier in the process, and improved security. However, developers say the top changes that could be made to improve job satisfaction are increasing automation and collaboration, according to our survey.\n\nAs code quality and code review processes are embedded into the software development lifecycle, focusing on systems that remove manual code review and enhance collaboration across teams will help keep developer workflows running smoothly. \n\n### Code review processes increase collaboration and development speed\n\nThe improvement in organizational efficiency can be seen in this example with [Airbus Intelligence](https://about.gitlab.com/customers/airbus/), a leader in the geospatial industry. The development teams at Airbus struggled with inefficient processes and needed tools that could help their team collaborate efficiently across the globe. After adopting GitLab Premium, Airbus quickly noticed the improvement in code quality. \n\nGitLab CI’s built-in security testing meant developers could identify bugs and vulnerabilities before they reached production. Instead of spending a full day setting up for production and doing manual tests, those simple tasks are now automated. \n\nAirbus’ release time dramatically decreased from 24 hours to just 10 minutes. \n\n“What used to happen is we would touch one part of the code and it would break another part. Now, each time a developer pushes code, we can immediately identify problems,” said Logan Weber, Software Automation Engineer at Airbus Defense and Space, Intelligence.\n\n### Features that enable higher code quality\n\nPowerful GitLab Premium features like [Multiple Approvers for Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html), [Code Quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html) checks integration with third-party code quality solutions, and [Protected Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html), enable companies to innovate faster than their competitors. \n\nBy reducing review cycle times while strengthening code integrity and compliance, DevSecOps teams address both the technical debt and security vulnerability challenges that plague traditional approaches. These security benefits help teams like AirBus Intelligence develop faster, more secure solutions.  \n\n## Why enhanced compliance controls matter\n\nThe implementation of effective code compliance strategies is constantly evolving due to [changing regulations](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), and keeping up with these regulations is a challenge for most companies. \n\nBy developing code compliance strategies and automated control mechanisms, companies ensure that quality and compliance policies are met. \n\nFor Airbus Intelligence, security and vulnerability scans built into integration testing enabled teams to catch security and compliance issues earlier in the process.\n\n[Continuous integration](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-integration-ci) gives teams visibility into more projects and allows all team members to manage deployments. Expanded access controls improve cross-team collaboration and accountability. \n\n### Features that increase accountability \n\nGitLab Premium's [advanced compliance controls](https://about.gitlab.com/solutions/security-compliance/) create an unbroken chain of accountability throughout the development process, enabling organizations to systematically track and validate every code change.\n\nUsers have greater auditability of any change and can track commits. This is in addition to strict [access controls](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html) that provide specific people with the ability to push and merge changes. With [audit logs](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html), users can track and review changes and activities within the repository.\n\n## Ship software faster with GitLab Premium\n\n“It’s simple. All teams operate around this one tool. Instantly, that made communication easier. We wouldn’t be where we are today if we didn’t have GitLab in our stack,” according to Airbus' Weber.\n\nGitLab Premium represents more than just a tool — it's a comprehensive approach to software engineering that empowers development teams to deliver high-quality, secure, and efficient software solutions. \n\n> #### Discover why [customers are upgrading to GitLab Premium](https://about.gitlab.com/pricing/premium/why-upgrade/).",[859,1659,475,14,1101,794],"code review",{"slug":1661,"featured":6,"template":674},"transform-code-quality-and-compliance-with-automated-processes","content:en-us:blog:transform-code-quality-and-compliance-with-automated-processes.yml","Transform Code Quality And Compliance With Automated Processes","en-us/blog/transform-code-quality-and-compliance-with-automated-processes.yml","en-us/blog/transform-code-quality-and-compliance-with-automated-processes",{"_path":1667,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1668,"content":1674,"config":1680,"_id":1682,"_type":16,"title":1683,"_source":17,"_file":1684,"_stem":1685,"_extension":20},"/en-us/blog/streamline-migrations-with-user-contribution-and-membership-mapping",{"title":1669,"description":1670,"ogTitle":1669,"ogDescription":1670,"noIndex":6,"ogImage":1671,"ogUrl":1672,"ogSiteName":784,"ogType":785,"canonicalUrls":1672,"schema":1673},"Streamline migrations with user contribution and membership mapping","New GitLab feature enhances project imports, allowing post-import user contribution mapping and greater flexibility and control.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663670/Blog/Hero%20Images/blog-image-template-1800x945__13_.png","https://about.gitlab.com/blog/streamline-migrations-with-user-contribution-and-membership-mapping","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Streamline migrations with user contribution and membership mapping\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Magdalena Frankiewicz\"}],\n        \"datePublished\": \"2024-11-25\",\n      }",{"title":1669,"description":1670,"authors":1675,"heroImage":1671,"date":1677,"body":1678,"category":14,"tags":1679},[1676],"Magdalena Frankiewicz","2024-11-25","We are excited to announce a new feature that enhances the group and project import process: improved [user contribution and membership mapping](https://docs.gitlab.com/ee/user/project/import/#user-contribution-and-membership-mapping). This feature represents a significant improvement in the project import process, offering greater flexibility and control for both users managing the import process and users receiving contribution reassignments. The feature is available in [GitLab migration by direct transfer](https://docs.gitlab.com/ee/user/group/import/), [GitHub importer](https://docs.gitlab.com/ee/user/project/import/github.html), [Bitbucket Server importer](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html), and [Gitea importer](https://docs.gitlab.com/ee/user/project/import/gitea.html).\n\n## What's changing?\n\n1. Post-import mapping: Previously unavailable, this feature allows you to assign imported contributions and memberships to users on the destination instance after the import has been completed. Imported memberships and contributions are first mapped to placeholder users. Until they are reassigned, contributions display as associated with placeholders.  \n2. Email-independent mapping: The new process doesn't rely on email addresses, allowing you to map contributions for users who may have different email addresses on source and destination instances.  \n3. User control: Each user on the destination instance who is assigned a contribution mapping has to [accept the assignment](https://docs.gitlab.com/ee/user/project/import/#accept-contribution-reassignment) before any imported contributions are attributed to them. They can also [reject the assignment](https://docs.gitlab.com/ee/user/project/import/#reject-contribution-reassignment).\n\n## Key points for your migration\n\nAs you prepare to migrate your resources, here are some important aspects to familiarize yourself with:\n\n1. Placeholder users: Take some time to understand the concept of [placeholder users](https://docs.gitlab.com/ee/user/project/import/#placeholder-users) in GitLab. Consider how the [placeholder limits](https://docs.gitlab.com/ee/user/project/import/#placeholder-user-limits) apply to your specific use case.\n2. [Reassignment process](https://docs.gitlab.com/ee/user/project/import/#reassign-contributions-and-memberships): Explore the reassignment interface in the UI. It's designed with security in mind, so be sure to [review these security considerations](https://docs.gitlab.com/ee/user/project/import/#security-considerations).  \n3. User involvement: Inform your team about the migration process, particularly how they can [accept contribution reassignment](https://docs.gitlab.com/ee/user/project/import/#accept-contribution-reassignment). This helps provide for a smooth transition for everyone involved.\n\nBy understanding these aspects, you'll be well prepared for a successful migration.\n\n## What’s next\n\nWe are committed to enhancing this feature further. Key upcoming currently planned improvements include:\n\n1. CSV-based contribution reassignment:  \n   * Enable group owners to [reassign contributions via CSV file upload](https://gitlab.com/gitlab-org/gitlab/-/issues/455901)  \n   * Particularly beneficial for large-scale customers managing numerous users  \n2. Enhanced UI [visibility of the placeholder limits and counts](https://gitlab.com/gitlab-org/gitlab/-/issues/486691)\n\nFor a full list of further anticipated improvements, see the [User Contribution Mapping epic](https://gitlab.com/groups/gitlab-org/-/epics/14774).\n\n## Availability\n\n* This feature is available by default for direct transfer migrations on GitLab.com, GitLab Self-managed, and GitLab Dedicated instances from GitLab Version 17.7.\n* This feature is available by default in GitHub, Bitbucket Server, and Gitea importers on GitLab.com from GitLab 17.7 and on GitLab Self-Managed and GitLab Dedicated instances from GitLab Version 17.8.\n\n## Feedback and support\n\nWe value your feedback! If you encounter any issues or have suggestions regarding this change, please add a comment in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/502565).",[475,794,14],{"slug":1681,"featured":6,"template":674},"streamline-migrations-with-user-contribution-and-membership-mapping","content:en-us:blog:streamline-migrations-with-user-contribution-and-membership-mapping.yml","Streamline Migrations With User Contribution And Membership Mapping","en-us/blog/streamline-migrations-with-user-contribution-and-membership-mapping.yml","en-us/blog/streamline-migrations-with-user-contribution-and-membership-mapping",{"_path":1687,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1688,"content":1694,"config":1699,"_id":1702,"_type":16,"title":1703,"_source":17,"_file":1704,"_stem":1705,"_extension":20},"/en-us/blog/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta",{"title":1689,"description":1690,"ogTitle":1689,"ogDescription":1690,"noIndex":91,"ogImage":1691,"ogUrl":1692,"ogSiteName":784,"ogType":785,"canonicalUrls":1692,"schema":1693},"GitLab 17.6 released with self-hosted Duo Chat in beta","GitLab 17.6 released with self-hosted Duo Chat in beta, adherence checks for SAST and DAST security scanners, vulnerability report grouping, model registry and much more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662194/Blog/Hero%20Images/product-gl17-blog-release-cover-17-6-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.6 released with self-hosted Duo Chat in beta\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Magdalena Frankiewicz\"}],\n        \"datePublished\": \"2024-11-21\",\n      }",{"title":1689,"description":1690,"authors":1695,"heroImage":1691,"date":1696,"body":1697,"category":14,"tags":1698},[1676],"2024-11-21","This is the [release post for GitLab 17.6](https://about.gitlab.com/releases/2024/11/21/gitlab-17-6-released/).",[14,475,752],{"slug":1700,"featured":91,"template":674,"externalUrl":1701},"gitlab-17-6-released-with-self-hosted-duo-chat-in-beta","https://about.gitlab.com/releases/2024/11/21/gitlab-17-6-released/","content:en-us:blog:gitlab-17-6-released-with-self-hosted-duo-chat-in-beta.yml","Gitlab 17 6 Released With Self Hosted Duo Chat In Beta","en-us/blog/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta.yml","en-us/blog/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta",{"_path":1707,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1708,"content":1714,"config":1720,"_id":1722,"_type":16,"title":1723,"_source":17,"_file":1724,"_stem":1725,"_extension":20},"/en-us/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":1709,"description":1710,"ogTitle":1709,"ogDescription":1710,"noIndex":6,"ogImage":1711,"ogUrl":1712,"ogSiteName":784,"ogType":785,"canonicalUrls":1712,"schema":1713},"Data-driven DevSecOps: Exploring GitLab Insights Dashboards","Learn how to leverage GitLab Insights Dashboards to visualize key metrics, track project progress, and boost team productivity with customizable, data-driven views.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Data-driven DevSecOps: Exploring GitLab Insights Dashboards\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }",{"title":1709,"description":1710,"authors":1715,"heroImage":1711,"date":1717,"body":1718,"category":14,"tags":1719},[1716],"Ricardo Amarilla Villalba","2024-11-20","Metrics and analytics play a crucial role in driving productivity, quality, and success. GitLab, as a comprehensive DevSecOps platform, offers powerful tools for tracking and visualizing these vital metrics through its Insights Dashboards. In this article, you'll learn how to use the Insights Dashboards in your environment.\n\n## Introduction to GitLab metrics and analytics \n\nGitLab provides an array of metrics and analytics tools that cover various aspects of the DevSecOps lifecycle:\n\n1. [Productivity Analytics](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html): Track team velocity, cycle time, and lead time.  \n2. [Code Review Analytics](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html): Measure code quality, test coverage, and review efficiency.  \n3. [CI/CD Analytics](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html): Monitor pipeline performance and deployment frequency.  \n4. [Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/): Visualize the flow of work from idea to production.  \n5. [Insights](https://docs.gitlab.com/ee/user/project/insights/): Explore and visualize data about your projects and groups.\n\nThese metrics offer invaluable insights into your development process, helping teams identify bottlenecks, optimize workflows, and make data-driven decisions.\n\n## Leveraging labels for specific metrics\n\nOne of GitLab's most powerful, yet understated features, is Labels, which allows you to filter and focus on specific metrics with pinpoint accuracy. By strategically applying labels to issues, merge requests, and epics, you can create custom views that provide targeted insights into your project's performance and progress.\n\nLabels in GitLab act as versatile identifiers, allowing you to categorize and organize your work items with great flexibility. Whether you're tracking feature development, bug fixes, or team-specific tasks, labels enable you to slice and dice your project data in ways that reveal meaningful patterns and trends. This concept parallels the use of tags in cloud deployments, where resources are labeled for easier management, cost allocation, and operational insights.\n\nBy thoughtfully labeling your work items, you're essentially creating a sophisticated labeling system that can be leveraged to generate custom dashboards and reports. This approach empowers you to zoom in on the metrics that matter most to your team or stakeholders, providing a clear and focused view of your project's health and momentum.\n\n## How to configure GitLab Insights\n\nGitLab Insights allow you to explore and visualize data about your projects and groups. They provide valuable analytics on various aspects such as issues created and closed during a specified period, average time for merge requests to be merged, and triage hygiene. Insights can be configured for both projects and groups.\n\nTo configure Insights:\n\n1. For project insights:  \n   * Create a file named `.gitlab/insights.yml` in the root directory of your project.  \n2. For group insights:  \n   * Create a `.gitlab/insights.yml` file in a project that belongs to your group.  \n   * Go to your group's **Settings > General**.  \n   * Expand the **Analytics section** and find the **Insights section**.  \n   * Select the project containing the configuration file and save changes.\n\nThe `.gitlab/insights.yml` file is a YAML file where you define the structure and order of charts in a report, as well as the style of charts to be displayed. Each chart definition includes parameters such as title, description, type, and query to specify the data source and filtering conditions.\n\nTo view insights, navigate to **Analyze > Insights** in your project or group.\n\n![View default Insights Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\n## Customize merge request insights\n\nWhile the default view provides valuable raw information, we can customize the Insights Dashboard to uncover additional layers of information, such as which team was responsible for each merge request and what type of problem each one solved.\n\n## Merge request insights for each squad and requirement type\n\nMeasuring squad productivity in GitLab can be challenging, especially when the GitLab group and subgroup structure doesn't align perfectly with your squad organization. Here's how to overcome these challenges and effectively track squad productivity:\n\n### **Setting up squad-based metrics**\n\n1. **Label creation:** Create unique scope labels for each squad (e.g., `squad::alpha`, `squad::beta`) and each requirement type (e.g., `type::bug`, `type::feature`, `type::maintenance`).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n2. **Label application:** Consistently apply these squad labels to all issues and merge requests handled by each squad, regardless of the project or group they're in.  \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Hints:**  \n   * Use GitLab API to apply labels massively to existing open, merged, and closed MRs.  \n   * Add/remove/update labels as part of your GitLab CI pipeline.  \n   * Leverage the GitLab Triage Bot to automate the labeling process.  \n\n3. Dashboard setup: Create a `.gitlab/insights.yml` file in your project repository with custom charts for team-specific and type-specific merge request insights.\n\n```\n\n## Default Merge Requests insights.yml \nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\nBy implementing these customizations, you can create insightful dashboards that provide a clear view of merge request activity per team and requirement type, allowing you to visualize trends over time, compare performance between squads, and analyze the distribution of different types of work for each squad. \n\n![dashboards with view of MR activity per team and requirement type](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n![dashboard comparing performance between squads](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)\n\n## Get started today\n\nGitLab Insights is just the tip of the iceberg when it comes to metrics and analytics. To explore the full range of GitLab's powerful analytics features, including Value Stream Analytics, CI/CD Analytics, and Code Review metrics, check out our Value Stream Management product tour:\n\n[![Value Stream Management product tour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-11-20_at_12.28.08_PM_aHR0cHM6_1750097217976.png)](https://gitlab.navattic.com/vsm)\n\n> Ready to start your own metrics journey? Sign up for a [free 60-day trial of GitLab Ultimate today](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F) and unlock the full potential of data-driven DevSecOps.\n\n## Read more\n- [Scheduled Reports Generation tool simplifies value stream management](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Getting started with the new GitLab Value Streams Dashboard](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n- [AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n",[109,475,14,794,671,1341],{"slug":1721,"featured":91,"template":674},"data-driven-devsecops-exploring-gitlab-insights-dashboards","content:en-us:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","en-us/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","en-us/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":1727,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1728,"content":1734,"config":1740,"_id":1742,"_type":16,"title":1743,"_source":17,"_file":1744,"_stem":1745,"_extension":20},"/en-us/blog/3-gitlab-features-to-level-up-devsecops-workflows",{"title":1729,"description":1730,"ogTitle":1729,"ogDescription":1730,"noIndex":6,"ogImage":1731,"ogUrl":1732,"ogSiteName":784,"ogType":785,"canonicalUrls":1732,"schema":1733},"3 GitLab features to level up DevSecOps workflows","Fix broken pipelines faster, better understand security vulnerabilities, and filter out false positives with our latest platform improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665762/Blog/Hero%20Images/blog-gl17-release-hero-17-0-93-1800x945-fy25__1_.png","https://about.gitlab.com/blog/3-gitlab-features-to-level-up-devsecops-workflows","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 GitLab features to level up DevSecOps workflows\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"}],\n        \"datePublished\": \"2024-10-29\",\n      }",{"title":1729,"description":1730,"authors":1735,"heroImage":1731,"date":1737,"body":1738,"category":14,"tags":1739},[1736],"Salman Ladha","2024-10-29","Last month, we, along with the GitLab community, introduced more than 140 improvements to our AI-powered DevSecOps platform to help you build better and more secure software, faster. With that much product innovation, we know it can be difficult to keep track of the latest GitLab has to offer. So, each quarter, we’re spotlighting the most impactful capabilities to help you consolidate toolchains, boost development efficiency, and improve application security. Here are three new features [released in GitLab](https://about.gitlab.com/releases/categories/releases/) over the past few months that make an immediate impact on your software development.\n\n > Learn why GitLab was named a Leader in the [2024 Gartner® Magic Quadrant™ for DevOps Platforms](https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops/) and the [2024 Gartner® Magic Quadrant™ for AI Code Assistants](https://about.gitlab.com/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/).\n\n## Root Cause Analysis: Diagnose broken pipelines faster\n\n[Developers spend less than a quarter of their time on code creation](https://about.gitlab.com/developer-survey/), according to our 2024 Global DevSecOps Survey. The bulk of their time is consumed by administrative tasks, planning, and troubleshooting — many of which can be accelerated with AI.\n\nFor example, diagnosing broken pipelines is a frustrating task for developers, which requires them to tediously scour through dense log files to identify the cause of the error. This often leads to trial-and-error fixes, sleuthing for solutions on Google, or asking a peer for support. This is a practical scenario where [GitLab Duo Root Cause Analysis](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/) can meaningfully help developers.\n\nRoot Cause Analysis analyzes log files to uncover the core issue behind an error message in a CI/CD pipeline. Not only does it provide teams with insight into what caused the issue, but it also suggests a fix to help resolve the issue faster.\n\nWith less time spent on troubleshooting, developers can focus on building differentiated products to help their organizations win.\n\nGitLab Duo Root Cause Analysis is available as a [GitLab Duo Enterprise add-on](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=JZSgd7GTTk4y6mre\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Vulnerability Explanation: Quickly understand security risks\n\nWe know that developers are playing [an even greater role in the remediation of security vulnerabilities](https://about.gitlab.com/developer-survey/). However, not every developer is well-versed in cybersecurity or has a working knowledge of the tactics, techniques, and procedures a threat actor will use to exploit an application. This creates a knowledge gap, which is exposed when vulnerabilities are uncovered.\n\n[GitLab Duo Vulnerability Explanation](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) bridges the knowledge gap between security and development teams. It gives developers a detailed description of the vulnerability infecting their code, real-world examples of how attackers can exploit the vulnerable code, and practical suggestions for remediation.\n\nWith this feature, you can level up your security skills, resolve vulnerabilities faster, and help create a proactive security culture — all while lightening the load on your security teams.\nGitLab Duo Vulnerability Explanation is available as a [GitLab Duo Enterprise add-on](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/MMVFvGrmMzw?si=Zsx-91078XSNNUSm\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Advanced SAST: Filter out the noise\n\nFalse positives are a [top frustration](https://about.gitlab.com/developer-survey/2024/security-compliance/) for both security and development teams. Unfortunately, this is a common complaint of traditional Static Application Security Testing (SAST). While SAST is great at integrating security early in the software development lifecycle, its value diminishes when it produces inaccurate results. “Drowning in a backlog of vulnerabilities” is a reality for many security and development teams, often resulting in tension between them.\n\n[Advanced SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/), our newest security scanner, uses a proprietary detection engine with rules informed by in-house security research to identify exploitable vulnerabilities. It delivers more accurate results, so security and development teams don’t have to sort through the noise of false-positive results, shortening triage time, improving development velocity, and decreasing friction between teams.\n\nAdvanced SAST is available in the [GitLab Ultimate tier](https://about.gitlab.com/pricing/ultimate/).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xDa1MHOcyn8?si=Ff4HjNpvv5eXsSNH\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Put these features to work today\n\nAt GitLab, we’re committed to making it easier for teams to build software, faster. Capabilities like GitLab Duo Root Cause Analysis, GitLab Duo Vulnerability Explanation, and GitLab Advanced SAST are just a few of the recent innovations we’ve delivered to help developers and security teams level up their DevSecOps workflows. To learn more, check out our [releases page](https://about.gitlab.com/releases/categories/releases/).\n\n> Get started with these new features today with [a free, 30-day trial of GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F).",[14,794,710,1101,109],{"slug":1741,"featured":91,"template":674},"3-gitlab-features-to-level-up-devsecops-workflows","content:en-us:blog:3-gitlab-features-to-level-up-devsecops-workflows.yml","3 Gitlab Features To Level Up Devsecops Workflows","en-us/blog/3-gitlab-features-to-level-up-devsecops-workflows.yml","en-us/blog/3-gitlab-features-to-level-up-devsecops-workflows",{"_path":1747,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1748,"content":1754,"config":1760,"_id":1763,"_type":16,"title":1764,"_source":17,"_file":1765,"_stem":1766,"_extension":20},"/en-us/blog/gitlab-17-5-release",{"title":1749,"description":1750,"ogTitle":1749,"ogDescription":1750,"noIndex":91,"ogImage":1751,"ogUrl":1752,"ogSiteName":784,"ogType":785,"canonicalUrls":1752,"schema":1753},"GitLab 17.5 Release","GitLab 17.5 released with Duo Quick Chat AI code assistance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666046/Blog/Hero%20Images/product-gl17-blog-release-cover-17-5-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-5-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.5 Release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Crowley\"}],\n        \"datePublished\": \"2024-10-17\",\n      }",{"title":1749,"description":1750,"authors":1755,"heroImage":1751,"date":1757,"body":1758,"category":14,"tags":1759},[1756],"John Crowley","2024-10-17","This is the blog post for [the GitLab 17.5 release](https://about.gitlab.com/releases/2024/10/17/gitlab-17-5-released/).",[752],{"slug":1761,"featured":6,"template":674,"externalUrl":1762},"gitlab-17-5-release","https://about.gitlab.com/releases/2024/10/17/gitlab-17-5-released/","content:en-us:blog:gitlab-17-5-release.yml","Gitlab 17 5 Release","en-us/blog/gitlab-17-5-release.yml","en-us/blog/gitlab-17-5-release",{"_path":1768,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1769,"content":1775,"config":1782,"_id":1784,"_type":16,"title":1785,"_source":17,"_file":1786,"_stem":1787,"_extension":20},"/en-us/blog/how-to-include-file-references-in-your-ci-cd-components",{"title":1770,"description":1771,"ogTitle":1770,"ogDescription":1771,"noIndex":6,"ogImage":1772,"ogUrl":1773,"ogSiteName":784,"ogType":785,"canonicalUrls":1773,"schema":1774},"How to include file references in your CI/CD components","Learn how to include scripts and dependencies in your CI/CD components to minimize duplications and simplify maintenance. This tutorial takes you step-by-step through the process.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/how-to-include-file-references-in-your-ci-cd-components","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to include file references in your CI/CD components\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2024-10-16\",\n      }",{"title":1770,"description":1771,"authors":1776,"heroImage":1772,"date":1778,"body":1779,"category":14,"tags":1780},[1777],"Itzik Gan Baruch","2024-10-16","I’m frequently asked whether included CI/CD components can reference additional files stored outside of the pipeline repository. While including components in your configuration is straightforward since they’re just YAML, many users want to know if those included components can access and execute additional files referenced by the components, like shell scripts or other dependencies. \n\nThis challenge has been a common topic of discussion in threads across the [GitLab Forum](https://forum.gitlab.com/t/gitlab-ci-includes-a-file-from-another-project-that-executes-a-script-file/111698) and [Reddit](https://www.reddit.com/r/gitlab/comments/18ma13x/gitlab_components_question/).\n\nNow for the good news: CI/CD components not only allow you to reuse pipeline configurations, saving time and effort, but you can also go a step further. With the new [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/), you can directly reuse centralized automation scripts and dependencies in your pipelines. You'll gain even greater flexibility, making your pipelines more powerful and adaptable than ever.\n\nBy storing your scripts in a central location and wrapping them in CI/CD Steps, you can easily call these steps from your CI/CD components. This eliminates the need to duplicate scripts across multiple repositories and CI/CD configurations, streamlining your workflow and reducing redundancy.\n\nBefore we dive into the step-by-step guide, let’s briefly explore what CI/CD components and CI/CD Steps are.\n\n## What are CI/CD components?\n\n[CI/CD components](https://docs.gitlab.com/ee/ci/components/) are reusable units of pipeline configurations that get included in a pipeline when it’s created. The components bring additional jobs into the pipeline, however they can’t bring additional files as such reusable scripts. \n\n## What are CI/CD Steps?\n\n[CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/) are reusable units of a job. Each step defines structured inputs and outputs that can be consumed by other steps. Steps can come from local files, GitLab.com repositories, or any other Git source. Steps offer a structured alternative to shell scripts for running jobs. They are modular, can be composed, tested, and easily reused, providing greater flexibility and maintainability.\n\n## What are the differences between CI/CD Steps and CI/CD components?\n\n- Component and step definitions look very similar but they take effect at different phases in pipeline execution. \n\n- Components are used when a pipeline is created while steps are used when individual jobs are running. \n\n- When a step is running, the whole repository is being downloaded into the job environment along with extra files. \n\n## A step-by-step guide\n\nHere is how CI/CD Steps and Components work together to access additional files.\n\n![CI/CD Steps flow diagram](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/steps-diagram-for-blog.png)\n\nThis diagram illustrates the process flow: Jobs defined within components are imported into the pipeline configuration (`.gitlab-ci.yml`) when the pipeline is created. During the pipeline's execution, a job’s steps are executed, and the entire Git repository is downloaded to the [Step runner](https://docs.gitlab.com/ee/ci/steps/#using-steps) within the job’s context. This ensures that references to dependencies function correctly.\n\n**1\\. Define a component with `run` keyword that runs CI/CD Steps**\n\nRun is a new keyword that supports running steps, see the example code below. You can use [this guide](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/) to learn more on how to create Components. \n\n![template-yml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/Screenshot_2024-10-13_at_8.22.00.png)\n\n**2\\. Create a `step.yml` file in the project where your scripts and dependencies are located.**\n\nIn this code example, format.sh exists in the same directory as the `step.yml`. \n\n![step.yml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/Screenshot_2024-10-13_at_8.23.52.png)\n\n While the job is running, the Step runner will download the entire Git repository where the step is defined. The `${{ step_dir }}` step expression references the directory of the locally cached step files, allowing you to access other files from the repository. In the example above, the “format” step invokes the format.sh script.\n\n**3\\. Make sure that any files accessed by the step are located in the same repository as the `step.yml` file.**\n\n**4\\. Include the component in your CI/CD configuration.**\n\nSee this example code:\n\n![.gitlab-ci.yml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/Screenshot_2024-10-13_at_8.26.22.png)\n\nCode example: You can find the entire code demonstrated in this blog in this [GitLab Group](https://gitlab.com/gitlab-da/use-cases/ci-steps). \n\n**Important note:** The CI/CD Steps feature is currently [Experimental](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment), and the syntax may change as we continue to iterate and refine it based on user feedback. Any feedback should be provided via [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/493694).\n\n## Learn more\n\n- Watch [this walkthrough](https://youtu.be/qxTbeYXEQLM) by [Joe Burnett](https://about.gitlab.com/company/team/#josephburnett), principal engineer at GitLab, as he demonstrates the example discussed in the blog post.\n\n- [Introducing CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/)\n\n- [Introducing CI/CD components](https://about.gitlab.com/blog/introducing-ci-components/)",[109,1781,794,14],"DevOps",{"slug":1783,"featured":6,"template":674},"how-to-include-file-references-in-your-ci-cd-components","content:en-us:blog:how-to-include-file-references-in-your-ci-cd-components.yml","How To Include File References In Your Ci Cd Components","en-us/blog/how-to-include-file-references-in-your-ci-cd-components.yml","en-us/blog/how-to-include-file-references-in-your-ci-cd-components",{"_path":1789,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1790,"content":1796,"config":1804,"_id":1806,"_type":16,"title":1807,"_source":17,"_file":1808,"_stem":1809,"_extension":20},"/en-us/blog/gitlab-dark-mode-is-getting-a-new-look",{"title":1791,"description":1792,"ogTitle":1791,"ogDescription":1792,"noIndex":6,"ogImage":1793,"ogUrl":1794,"ogSiteName":784,"ogType":785,"canonicalUrls":1794,"schema":1795},"GitLab dark mode is getting a new look","GitLab is enhancing dark mode for a cleaner, more polished experience, with incremental updates to improve usability and visual consistency. Get a sneak peek at this new design.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098523/Blog/Hero%20Images/Blog/Hero%20Images/hero%20%282%29_7nhIrZ08jWcLxhaH9rfbk1_1750098523498.png","https://about.gitlab.com/blog/gitlab-dark-mode-is-getting-a-new-look","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab dark mode is getting a new look\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sascha Eggenberger\"},{\"@type\":\"Person\",\"name\":\"Chris Micek\"},{\"@type\":\"Person\",\"name\":\"Jeremy Elder\"}],\n        \"datePublished\": \"2024-10-15\",\n      }",{"title":1791,"description":1792,"authors":1797,"heroImage":1793,"date":1801,"body":1802,"category":14,"tags":1803},[1798,1799,1800],"Sascha Eggenberger","Chris Micek","Jeremy Elder","2024-10-15","Dark mode has become an essential feature, providing a darker background with lighter content to reduce eye strain, enhance readability, and maintain continuity with system-wide settings. While we currently offer an experimental version of dark mode in GitLab, customers requested some improvements. We’ve taken that feedback seriously and now we’re excited to share our vision for the future of dark mode on the DevSecOps platform, and how we plan to roll this out over the next several months.\n\n## Challenges with the current dark mode\n\nGitLab’s dark mode, launched in 2020, has remained in an alpha state, largely due to its initial approach of algorithmically inverting colors. While this method allowed us to quickly offer a basic dark background with lighter text, there are several issues that require taking a different approach.\n\nThe current dark mode suffers from inconsistent visual hierarchy — some elements, like alerts, stand out too much, while others fade into the background. An overuse of color also makes certain elements, such as alerts and badges, overly saturated, distracting from key content. Additionally, some elements emit too much light, causing visual strain for those using GitLab for long periods of time.\n\nDue to these issues and the complexity of implementing fixes, our experimental dark mode has remained below our standard of quality, with many one-off adjustments adding unnecessary complexity. We know there’s room for improvement, and that’s why we’re committed to enhancing this experience in a way that feels seamless, comfortable, and visually appealing.\n\n## Principles guiding the new direction\n\nTo create a more cohesive dark mode, we’ve developed several design principles that will guide the new iterations. Similar to our work on a [Dark UI for GitLab’s Web IDE](https://about.gitlab.com/blog/creating-a-dark-ui-for-gitlabs-web-ide/), these principles and ideas helped us focus on ensuring the experience is not only aesthetically pleasing but also functional and accessible.\n\nTo see how these principles are applied in practice with examples watch this [walkthrough by Jeremy Elder](https://www.youtube.com/watch?v=QdiV6lRSFpE), a staff product designer working on dark mode.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/QdiV6lRSFpE?si=kFssresabK0JJrug\" title=\"GitLab Dark Mode\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### 1. Forward elements are lighter, receding ones are darker\n\nThis mimics natural light behavior: brighter elements come forward, while darker ones recede. In dark mode, brighter elements create depth, ensuring important content stands out without relying heavily on borders or shadows.\n\n![Using surfaces to make important components stand out more.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098533970.png)\n\u003Ccenter>\u003Ci>Using surfaces to make important components stand out more.\u003C/i>\u003C/center>\n\u003Cbr>\n\n![Applying the new design principles can create a visually better structured and more meaningful UI.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098533970.png)\n\n\u003Ccenter>\u003Ci>Applying the new design principles can create a visually better structured and more meaningful UI.\u003C/i>\u003C/center>\n\n### 2. Reduced color saturation\nIn a dark UI, color naturally stands out more, so we’re reducing the amount of color used. Instead of flooding backgrounds with color, we’re using color more selectively to draw attention where it’s needed.\n\n![Alerts are quieter than before.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098533971.png)\n\n\u003Ccenter>\u003Ci>Alerts are quieter than before.\u003C/i>\u003C/center>\n\n### 3. Dimmed, not inverted\n\nWe’re approaching dark mode as “dimming the lights” rather than fully inverting the interface. This means we’re making careful decisions about which elements to darken and which to brighten, so the content remains clear while the background recedes appropriately.\n\n![Dark mode subtly dims the background while keeping key content clear and visible instead of inverting colors.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098533971.png)\n\n\u003Ccenter>\u003Ci>Dark mode subtly dims the background while keeping key content clear and visible instead of inverting colors.\u003C/i>\u003C/center>\n\n## Iterative implementation\n\nThe new GitLab dark mode won’t be rolled out all at once. Instead, we’re taking an iterative approach, releasing updates incrementally. This process will begin with elements of the Pajamas Design System and gradually expand across the rest of the product. If you’re using the current dark mode, you’ll start to notice subtle changes to colors, contrast, typography, and component styling, all working towards our vision of a more polished, cohesive dark mode. \n\n> Follow our [progress in the dark mode epic](https://gitlab.com/groups/gitlab-org/-/epics/2902) as we continue working towards this vision.\n\n## Read more\n-  [Get to know the new GitLab typefaces](https://about.gitlab.com/blog/new-typefaces-in-gitlab/)\n- [Beautifying our UI: Giving GitLab build features a fresh look](https://about.gitlab.com/blog/beautifying-of-our-ui/)\n- [How visualization improves the GitLab merge train experience](https://about.gitlab.com/blog/how-visualization-improves-the-gitlab-merge-train-experience/)\n",[1219,1220,14,475],{"slug":1805,"featured":91,"template":674},"gitlab-dark-mode-is-getting-a-new-look","content:en-us:blog:gitlab-dark-mode-is-getting-a-new-look.yml","Gitlab Dark Mode Is Getting A New Look","en-us/blog/gitlab-dark-mode-is-getting-a-new-look.yml","en-us/blog/gitlab-dark-mode-is-getting-a-new-look",{"_path":1811,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1812,"content":1818,"config":1824,"_id":1826,"_type":16,"title":1827,"_source":17,"_file":1828,"_stem":1829,"_extension":20},"/en-us/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems",{"title":1813,"description":1814,"ogTitle":1813,"ogDescription":1814,"noIndex":6,"ogImage":1815,"ogUrl":1816,"ogSiteName":784,"ogType":785,"canonicalUrls":1816,"schema":1817},"Tutorial: Integrate GitLab Merge Request approvals with external systems","Learn how to improve GitLab extensibility and integration with external applications in this demo. The result: a seamless integration that provides more control over merge requests.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676011/Blog/Hero%20Images/blog-image-template-1800x945.svg","https://about.gitlab.com/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Integrate GitLab Merge Request approvals with external systems\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"}],\n        \"datePublished\": \"2024-10-08\",\n      }",{"title":1813,"description":1814,"authors":1819,"heroImage":1815,"date":1821,"body":1822,"category":14,"tags":1823},[1820],"Samer Akkoub","2024-10-08","GitLab customers often ask how to connect merge requests to external applications, such as ServiceNow or custom-built applications, to control approvals for the merging of code into a target branch from these external systems. To address this need, GitLab offers [External Status Check](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html), a powerful feature that allows the sending of API calls to external systems to request the status of an external requirement, providing seamless integration and control over your merge requests.\n\nIn this article, I'll demonstrate this feature by explaining how to deploy an application I developed. The application is designed to receive status check requests from GitLab Merge Requests, list them, and enable external users to approve/reject these requests without logging in to the GitLab console. As a result, GitLab platform architects will better understand GitLab extensibility and integration with external systems.\n\nThe provided sample application can:\n1. Receive API requests from merge requests.\n2. Store the requests in AlchemyDB running on the same instance.\n3. Show Approve/Reject buttons for each row to approve or reject the corresponding merge request status check.\n\n## How to deploy the status review demo application\n1. Import this [GitLab repo project](https://gitlab.com/sakkoub-publicgroup/external-approval-app) to your GitLab account.\n2. The project pipeline will deploy the application to a Kubernetes cluster. To achieve this, define a [GitLab Agent](https://docs.gitlab.com/ee/user/clusters/agent/install/index.html) for Kubernetes in a separate project and include a path to the cloned project under the “[user_access](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html)” section in the agent configuration.\n3. Add a new environment variable `KUBE_CONTEXT`, with the value equal to the used agent path:name, similar to the following structure `path/to/agent/project:agent-name`.\n4. The status check application will be deployed to the `approval-app` namespace by default.\n5. Create the `approval-app` namespace in the target Kubernetes cluster.\n6. In the created namespace, add a secret named `gitlab-token` with the value set to the personal access token (PAT) of the user who will be approving the requests. The approval application will use this PAT to communicate back to the GitLab instance.\n7. Run the status check application pipeline on the main branch.\n8. Once deployed, the application will be exposed behind a load balancer. Use this command to grab the public IP address of the load balancer: `kubectl get services -n approval-app`.\n9. The application can then be accessed using this URL: http://EXTERNAL-IP/approval-apps/. Replace the `EXTERNAL-IP` with the value of the external IP address from the previous step. The resulting page should look like below (the table would be empty as we have not added any new merge requests yet).\n\n![Table showing IP address](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676057/Blog/Content%20Images/image1.png)\n\n## Configure status check in GitLab\n\n1. In the GitLab project where the external status check needs to be configured, from the left menu, navigate under settings **-\\> Merge Request** and scroll down to **Status checks**.\n2. Click on **Add status check**.\n3. Add a service name.\n4. For the API to check enter: `[http://EXTERNAL-IP[/approval-apps/status_check`. Replace the `EXTERNAL-IP` with the external IP address found in the previous steps.\n5. Leave the `Target Branch` to the default, or select branch if you want this check to be triggered only for merge requests against certain branches.\n6. Leave `HMAC Shared Secret` as it is and click **Add status check**.\n\n![How to configure status check](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676060/Blog/Content%20Images/image1.png)\n\n## Test everything together\n\n1. In the project where you have configured the external check, create a new merge request from any branch targeting the main branch (assuming the main branch was selected when the external check was configured in the previous section).\n2. In the merge request details, look for the **Status checks** section and it should show `1 Pending`.\n3. Now, in a new tab, open the deployed external check application using this URL (replace `EXTERNAL-IP` with the value of the external IP address from the previous steps): `http://EXTERNAL-IP/approval-apps/`.\n4. A new entry should show in the list for the request external check from the merge request just created. Click on **Approve**.\n5. Switch back to the merge request's details screen and notice how the merge request is showing an approved status now.\n\n## Debugging tips\n\nUse the following notes to debug if something does not go as planned:\n\nIt is always helpful to view the logs for the external status check application. To do so: \n   1. Extract the name of the application pod using this command: `kubectl get pods -n approval-app`.\n   2. View the pod logs `kubectl logs [THE NAME OF THE POD] -n approval-app`.\n\nYou can SSH into the application pod and view the database (Alchemydb), which is used for the application. \n   1. `kubectl exec -it \\[POD-NAME\\] -n approval-app -- /bin/sh` \n   2. `cd instance`\n   3. `sqlite3 gitlab_status_checks.db` \n   4. To view the database tables, type `.tables`.\n   5. To describe the table structure, type `PRAGMA table_info('status_check');`.\n   6. To view all the records in the `status_check` table, type `select * from status_check`.\n\n> Discover more about [GitLab External Status Check](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html) and how to gain more control over merge requests.\n",[671,14,794,109],{"slug":1825,"featured":6,"template":674},"tutorial-integrate-gitlab-merge-request-approvals-with-external-systems","content:en-us:blog:tutorial-integrate-gitlab-merge-request-approvals-with-external-systems.yml","Tutorial Integrate Gitlab Merge Request Approvals With External Systems","en-us/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems.yml","en-us/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems",{"_path":1831,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1832,"content":1838,"config":1845,"_id":1847,"_type":16,"title":1848,"_source":17,"_file":1849,"_stem":1850,"_extension":20},"/en-us/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment",{"title":1833,"description":1834,"ogTitle":1833,"ogDescription":1834,"noIndex":6,"ogImage":1835,"ogUrl":1836,"ogSiteName":784,"ogType":785,"canonicalUrls":1836,"schema":1837},"GitLab Pages features review apps and multiple website deployment","GitLab Pages helps organizations reap the rewards of knowledge management, including better collaboration and accessibility. Learn how to use a new feature, Parallel Deployments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674550/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","https://about.gitlab.com/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Pages features review apps and multiple website deployment\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matthew Macfarlane\"},{\"@type\":\"Person\",\"name\":\"Janis Altherr\"}],\n        \"datePublished\": \"2024-09-23\",\n      }",{"title":1833,"description":1834,"authors":1839,"heroImage":1835,"date":1842,"body":1843,"category":14,"tags":1844,"updatedDate":1056},[1840,1841],"Matthew Macfarlane","Janis Altherr","2024-09-23","[GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) has long been a popular choice for hosting static websites, allowing users to showcase their projects, blogs, and documentation directly from their repositories.\n\nBefore GitLab 17.4, you could only have a single version of your GitLab Pages website. So you couldn’t preview your changes or have multiple versions of your website deployed simultaneously. Now, with a Premium or Ultimate license, you can do both!\n\n### Introducing Parallel Deployments\n\nWith Parallel Deployments, users can now easily preview changes and manage multiple environments for their GitLab Pages sites. This enhancement allows seamless experimentation with new ideas, enabling users to confidently test and refine their sites. By catching any issues early, users can ensure the live site remains stable and polished, building on the already great foundation of GitLab Pages.\n\n### Why Parallel Deployments is a game-changer\n\n1. **Version control made easy**\\\n   If your project involves software development or documentation that covers multiple versions (such as user guides for different software releases), Parallel Deployments makes it easy to manage. Or you can use the feature to localize your website for different languages.\n2. **Flexibility to experiment**\\\n   Want to try out a new design or feature? Parallel Deployments lets you experiment freely. You can create a separate version of your site to test new ideas without impacting the current site. This flexibility encourages creativity and continuous improvement.\n\n### How to add review apps to your GitLab Pages project\n\nTo add a review app to your GitLab Pages project, edit your `.gitlab-ci.yml` file to create a deployment for each merge request (MR). Let’s assume you start with a `.gitlab-ci.yml` file somewhat like this:\n\n```yaml\ncreate-pages:\n  stage: deploy\n  script:\n    - npm run build\n  pages: \n    publish: dist # the name of the folder containing the pages files\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # only run this job when there's a commit to the default branch\n```\n\nTo also run the pages pipeline when there’s an MR being opened or updated, we can add another rule to `pages.rules`:\n\n```yaml\n- if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n```\n\nIf we only add this rule, however, each Pages job will always replace the main deployment – each time an MR is opened! You likely don’t want that to happen.\n\nTo provide each individual deployment with its own URL, we’ve introduced the new `pages.path_prefix` property.\n\nA Pages deployment with this configuration...\n\n```yaml\ncreate-pages:\n  script:\n    - ...\n  pages:\n    ...\n    path_prefix: my-review-app\n```\n\n...will be available at `https://my-pages-app-7fe824.gitlab.io/my-review-app`, or, with unique domains disabled, `https://my-group.gitlab.io/my-project/my-review-app`.\n\nBut there’s no need to hardcode the path_prefix. You can dynamically generate it using CI variables. That’s particularly useful for review apps – to create a path for each MR, use the `CI_MERGE_REQUEST_IID variable`:\n\n```yaml\ncreate-pages:\n  script:\n    - ...\n  pages:\n    ...\n    path_prefix: mr-$CI_MERGE_REQUEST_IID\n```\n\nAn MR with the ID 114 would then automatically create a deployment at `https://my-pages-app-7fe824.gitlab.io/mr-114`.\n\nWith those concepts at hand, we’d like our pipeline to dynamically create either a main deployment for the default branch, or a path_prefixed-review app for MR events.\n\nFirst, let’s add a `create-pages-review-app` job to our pipeline config:\n\n```yaml\ncreate-pages-deployment:\n  # This job will create a pages deployment without path_prefix\n  # when there is a commit to the default branch\n  stage: deploy\n  script:\n    - npm run build\n  pages: \n    publish: dist \n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\ncreate-pages-review-app:\n  # This job will create a pages deployment with a path_prefix\n  # when there a merge request is created or updated.\n  stage: deploy\n  script:\n    - npm run build\n  pages:\n    publish: dist \n    path_prefix: 'mr-$CI_MERGE_REQUEST_IID' # Prefix with the mr-\u003Ciid>, like `mr-123`\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n```\n\nNow you’re creating a deployment both when pushing to the default branch, and prefixed parallel deployments when creating or updating MRs!\n\nFor the best experience, add the URL to the environment job property. This will add a link to the review app to the MR page:\n\n```yaml\ncreate-pages-deployment:\n  # This job will create a pages deployment without path_prefix\n  # when there is a commit to the default branch\n  stage: deploy\n  script:\n    - npm run build\n  pages: \n    publish: dist \n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\ncreate-pages-review-app:\n  # This job will create a pages deployment with a path_prefix\n  # when there a merge request is created or updated.\n  stage: deploy\n  script:\n    - npm run build\n  pages:\n    publish: dist \n    path_prefix: 'mr-$CI_MERGE_REQUEST_IID' # Prefix with the mr-\u003Ciid>, like `mr-123`\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n  environment:\n    name: \"Pages Review MR ${CI_MERGE_REQUEST_IID}\"\n    url: $CI_PAGES_URL\n```\n\nCongratulations, you’ve now set up MR review apps for your Pages site.\n\n## How to deploy documentation for different versions of your product\n\nThe Parallel Deployments feature is also a useful tool if you maintain the documentation of multiple versions of your software simultaneously.\n\nThe below CI config will not only create a pages deployment when there is a commit to the default branch, but also for any commit to branches named `v1`, `v2`, or `v3`.\n\n```yaml\ncreate-pages:\n  stage: deploy\n  script:\n    - ...\n  variables:\n    PAGES_PREFIX: \"$CI_COMMIT_BRANCH\" # Use the branch name by default\n  pages:\n    path_prefix: \"$PAGES_PREFIX\" # use whatever value is set in the variable\n  environment:\n    name: \"Pages ${PAGES_PREFIX}\"\n    url: $CI_PAGES_URL\n  artifacts:\n    paths:\n    - public\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n      variables:\n        PAGES_PREFIX: '' # No prefix\n    - if: $CI_COMMIT_BRANCH == 'v1'\n    - if: $CI_COMMIT_BRANCH == 'v2'\n    - if: $CI_COMMIT_BRANCH == 'v3'\n```\n\nBy using the `$CI_COMMIT_BRANCH` variable as the path_prefix value, each of these branches will deploy their documentation to their own sub-path of your website:\n\n- The branch named v1 has its docs published to \u003Cmy-domain>/v1.\n- The branch named v2 has its docs published to \u003Cmy-domain>/v2.\n- The branch named v3 has its docs published to \u003Cmy-domain>/v3.\n\nA new commit to one of these branches will then trigger a new deployment to its respective path, keeping the documentation of multiple versions up to date.\n\nThe Parallel Deployments feature is a significant upgrade to GitLab Pages, offering a more flexible and efficient way to manage your knowledge. Whether you're working on a small project or a large-scale site with multiple versions, this new capability will make your workflow smoother and more efficient\n\n> Visit our [Parallel Deployments documentation](https://docs.gitlab.com/ee/user/project/pages/#create-multiple-deployments) to get started today!\n\n### Feedback\n\nShare your ideas and other comments in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/482040)!\n",[1178,109,710,794,14,671],{"slug":1846,"featured":6,"template":674},"gitlab-pages-features-review-apps-and-multiple-website-deployment","content:en-us:blog:gitlab-pages-features-review-apps-and-multiple-website-deployment.yml","Gitlab Pages Features Review Apps And Multiple Website Deployment","en-us/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment.yml","en-us/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment",{"_path":1852,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1853,"content":1859,"config":1865,"_id":1868,"_type":16,"title":1869,"_source":17,"_file":1870,"_stem":1871,"_extension":20},"/en-us/blog/gitlab-17-4-release",{"title":1854,"description":1855,"ogTitle":1854,"ogDescription":1855,"noIndex":91,"ogImage":1856,"ogUrl":1857,"ogSiteName":784,"ogType":785,"canonicalUrls":1857,"schema":1858},"GitLab 17.4 Release","GitLab 17.4 released with improved context in GitLab Duo","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666419/Blog/Hero%20Images/product-gl17-blog-release-cover-17-4-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-4-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.4 Release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alex Martin\"}],\n        \"datePublished\": \"2024-09-19\",\n      }",{"title":1854,"description":1855,"authors":1860,"heroImage":1856,"date":1862,"body":1863,"category":14,"tags":1864},[1861],"Alex Martin","2024-09-19","This is the post for [GitLab 17.4 release](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/).",[752,14,475,838],{"slug":1866,"featured":6,"template":674,"externalUrl":1867},"gitlab-17-4-release","https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/","content:en-us:blog:gitlab-17-4-release.yml","Gitlab 17 4 Release","en-us/blog/gitlab-17-4-release.yml","en-us/blog/gitlab-17-4-release",{"_path":1873,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1874,"content":1880,"config":1886,"_id":1888,"_type":16,"title":1889,"_source":17,"_file":1890,"_stem":1891,"_extension":20},"/en-us/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"title":1875,"description":1876,"ogTitle":1875,"ogDescription":1876,"noIndex":6,"ogImage":1877,"ogUrl":1878,"ogSiteName":784,"ogType":785,"canonicalUrls":1878,"schema":1879},"Tutorial: Migrate from Google Cloud Source Repositories to GitLab","Google Cloud is deprecating Cloud Source Repositories. Learn how to migrate a CSR source code repository to GitLab, along with best practices.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097739/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2813%29_1zdtbfPDHZVe6JC2AbdHmb_1750097738370.png","https://about.gitlab.com/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Migrate from Google Cloud Source Repositories to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"}],\n        \"datePublished\": \"2024-08-28\",\n      }",{"title":1875,"description":1876,"authors":1881,"heroImage":1877,"date":1883,"body":1884,"category":14,"tags":1885},[1882,1574],"Tsukasa Komatsubara","2024-08-28","Google Cloud’s [deprecation of Cloud Source Repositories](https://cloud.google.com/source-repositories/docs/release-notes) (CSR) has prompted development teams to seek a full-featured alternative for their source code repositories. GitLab, a [Google Cloud Technology Partner](https://cloud.google.com/find-a-partner/partner/gitlab-inc), is a strong choice due to its comprehensive DevSecOps capabilities.\n\nIn this tutorial, you'll learn the steps to ensure a smooth transition from CSR to GitLab, whether you're using GitLab.com or a self-managed instance on Google Cloud.\n\n## Why GitLab?\nTransitioning from Google Cloud Source Repositories to GitLab is a recommended step. As a strategic partner of Google Cloud, GitLab seamlessly integrates with existing infrastructure with ease and brings value to customers in the following ways:\n- **Unified DevSecOps platform**\n    - Consolidate your entire development lifecycle into a single application, from planning to monitoring. Eliminate tool sprawl and dramatically boost productivity.\n- **Seamless Google Cloud integration**\n    - Effortlessly connect with GKE, Cloud Build, and Cloud Storage, ensuring a smooth migration and efficient operations within the Google Cloud ecosystem.\n- **Advanced CI/CD capabilities**\n    - Leverage [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) to automate everything from security scanning to deployment, accelerating your development cycles.\n- **Industry-recognized AI coding assistance**\n    - Benefit from built-in AI-assisted development with [GitLab Duo](https://about.gitlab.com/gitlab-duo/), fostering a secure and efficient coding environment.\n\n## Prerequisites\n\nBefore you start the migration, ensure you have:\n- GitLab account: Set up your account on GitLab.com or on a self-hosted instance.\n- GitLab project: Create a blank project in GitLab where the CSR repository will be migrated.\n\n## Migration steps\n\n1. Create a blank GitLab project: This will serve as the destination for your migrated CSR repository. Keep this project empty for now.\n2. Generate a personal access token (PAT): Navigate to GitLab settings and [generate a PAT](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) with `read_repository` and `write_repository` scopes enabled. This token will be used to authenticate your Git operations during the migration process.\n3. Edit code in Cloud Shell Editor: From your CSR repository, open the Cloud Shell Editor by clicking the “Edit code” button. You’ll need to authorize the Cloud Shell and select “Trust repo” to proceed.\n\n![Google Cloud Shell Editor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097750517.png)\n\n4. Inspect Git status: Run `git status` in the Cloud Shell to check the current branch and ensure everything is in order before pushing to GitLab.\n\n![Inspect Git status](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097750518.png)\n\n5. Set Up the Remote Repository: Add your GitLab project as a remote repository by running:\n\n```\ngit remote add origin [GITLAB_PROJECT_URL]\n\n```\n\n6. Replace `[GITLAB_PROJECT_URL]` with the actual URL of your GitLab project.\nPush to GitLab: Finally, push your local repository to GitLab by running: \n\n```\ngit push -u origin [BRANCH_NAME]\n\n```\n\n7. Replace `[BRANCH_NAME]` with the current branch name you noted earlier.\nWhen prompted, use your GitLab username and the PAT as the password to authenticate and complete the push.\n\n## Best practices\n\n- Back up before you begin: Always back up your CSR repository before starting the migration process.\n- Test after migration: Ensure all aspects of the repository, including branches and CI/CD pipelines, are functioning as expected in GitLab.\n- Leverage GitLab features: Take advantage of GitLab’s advanced DevSecOps features such as [AI](https://about.gitlab.com/gitlab-duo/), [CI/CD](https://docs.gitlab.com/ee/ci/), and [Enterprise Agile planning](https://about.gitlab.com/solutions/agile-delivery/) to enhance your development workflow.\n\nMoving from Google Cloud Source Repositories to GitLab is easy and offers more benefits than just managing source code. GitLab, with its integration with Google Cloud, makes it an ideal choice for developers seeking to enhance their workflow post-migration.\n\n> Read more about [GitLab's integration with Google Cloud](https://about.gitlab.com/blog/gitlab-google-cloud-integrations-now-in-public-beta/).",[671,1578,475],{"slug":1887,"featured":6,"template":674},"tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","content:en-us:blog:tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","Tutorial Migrate From Google Cloud Source Repositories To Gitlab","en-us/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","en-us/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"_path":1893,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1894,"content":1900,"config":1907,"_id":1909,"_type":16,"title":1910,"_source":17,"_file":1911,"_stem":1912,"_extension":20},"/en-us/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":1895,"description":1896,"ogTitle":1895,"ogDescription":1896,"noIndex":6,"ogImage":1897,"ogUrl":1898,"ogSiteName":784,"ogType":785,"canonicalUrls":1898,"schema":1899},"Ultimate guide to migrating from AWS CodeCommit to GitLab","Learn how to migrate from AWS Services to GitLab and seamlessly integrate with the DevSecOps platform in this comprehensive tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097810/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2828%29_4mi0l4wzUa5VI4wtf8gInx_1750097810027.png","https://about.gitlab.com/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ultimate guide to migrating from AWS CodeCommit to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"},{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"},{\"@type\":\"Person\",\"name\":\"Bart Zhang\"}],\n        \"datePublished\": \"2024-08-26\",\n      }",{"title":1895,"description":1896,"authors":1901,"heroImage":1897,"date":1903,"body":1904,"category":14,"tags":1905},[1882,812,1820,1902],"Bart Zhang","2024-08-26","On July 25, 2024, AWS made a significant announcement regarding its CodeCommit service. As detailed in their [official blog post](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/), AWS has decided to close new customer access to CodeCommit. While existing customers can continue using the service, AWS will not introduce new features, focusing only on security, availability, and performance improvements.\n\nThis announcement has prompted development teams to consider migrating their repositories to alternative Git providers. In light of these changes, we've prepared this comprehensive guide to assist teams in migrating to GitLab and integrating with other AWS services.\n\n**Note:** For more details on AWS's official migration recommendations, please refer to [their blog post](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/).\n\n## About this guide\n\nThis guide provides comprehensive information for development teams using GitLab who are considering integration with AWS services or planning to migrate from AWS-hosted Git repositories to GitLab.com. The guide is structured into three main sections:\n\n- [Parallel migration to GitLab](#section-1-parallel-migration-to-gitlab): Explains how to gradually migrate from existing AWS-hosted repositories to GitLab.com while minimizing risks.\n\n- [Integration with AWS CodeBuild](#section-2-integrating-gitlab-with-aws-codebuild): Provides steps to integrate GitLab repositories with AWS CodeBuild, setting up a powerful continuous integration (CI) environment.\n\n- [Integration with AWS CodePipeline](#section-3-integrating-gitlab-with-aws-codepipeline): Details how to connect GitLab repositories with AWS CodePipeline to build efficient continuous delivery (CD) pipelines.\n\n- [Downstream integrations for CodePipeline and CodeStar Connections](#section-4-migrating-to-gitlab): Explains how to leverage GitLab-AWS connections for widespread service access, unlocking a cascade of integration possibilities across the AWS ecosystem.\n\nThrough this guide, you'll learn how to combine the powerful features of GitLab and AWS to create an efficient and flexible development workflow.\n\n## Section 1: Parallel migration to GitLab \n\nFor those considering migrating Git repositories hosted on AWS to GitLab.com, this section, which is a phased approach, introduces methods to achieve migration while minimizing risks. By leveraging GitLab's mirroring capabilities, you can maintain existing development flows while testing the new environment.\n\n### Why is parallel migration important?\n\nLarge-scale system migrations always involve risks, particularly potential impacts on ongoing development work, existing integrations, and automated processes. Adopting a parallel migration approach offers the following benefits:\n\n1. Risk minimization: Test the new environment while keeping existing systems operational.\n2. Seamless transition: Development teams can gradually acclimate to the new system.\n3. Integration testing: Thoroughly test all integrations and automation in the new environment.\n4. Future-proofing: Enable teams to gradually migrate to GitLab CI/CD in parallel to existing CI.\n\nParallel migration is not required if it is already known that you want to cut over directly to GitLab.\n\n### Steps for migrating to GitLab.com\n\n#### Step 1: Get set up on GitLab.com\n\n- Check if your company already has a group in use on GitLab.com and whether they have single sign-on (SSO) set up – if they do, then you will want to use both.\n\n- If your company does not have a presence on GitLab.com, visit [GitLab.com](www.gitlab.com) and create a new account or log in to an existing one.\n- Create a new company namespace (a group at the root level of gitlab.com).\n- Pick a name that reflects your entire company (and is not already taken).\n\n#### Step 2: Import repository\nFor parallel migration: Use GitLab's pull mirroring feature to automatically sync changes from AWS-hosted repositories to GitLab.com.\n\n1. Navigate to the target group GitLab.com.\n2. In the upper right, click \"New project.\"\n3. On the \"Create new project\" page, click \"Import project.\"\n4. On the \"Import project\" page, click \"Repository by URL.\"\n5. Enter the URL of your AWS-hosted repository in the \"Git repository URL\" field.\n6. Underneath the Git repository URL field, check \"Mirror repository.\"\n7. Set up authentication: in the AWS CodeCommit console, select the clone URL for the repository you will migrate. If you plan on importing CodeCommit repositories into GitLab, you can use the HTTPS CodeCommit URL to clone the repository via GitLab Repository Mirroring. You will need to also provide your Git credentials from AWS for your identity and access management (IAM) user within GitLab. You can create Git credentials for AWS CodeCommit by following this [AWS guide](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html).\n\n![Clone URL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/clone-url-screenshot__1__aHR0cHM6_1750097822121.png)\n\nThis setup will automatically pull changes from the AWS-hosted repository to GitLab.com every five minutes by default.\n\nFor more information, read our [repository mirroring documentation](https://docs.gitlab.com/ee/user/project/repository/mirror/).\n\n#### Step 3: Test and validate integrations\n\n1. CI/CD pipelines: Set up the `.gitlab-ci.yml` file in GitLab CI to replicate existing pipelines. You can read more about [planning a migration from other CI tools into GitLab CI/CD](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html).\n2. Issue tracking: Import project issues and test workflows.\n3. Code review: Set up the merge request process and test review workflows.\n\n#### Step 4: Gradual migration\n\n1. Start with small or non-critical projects to familiarize yourself with working on GitLab.com.\n2. Provide training for team members and allow time to adapt to new workflows.\n3. Gradually migrate more projects while ensuring integrations and workflows are problem-free.\n\nFor more information, see [Automating Migrations from CodeCommit to GitLab](https://gitlab.com/guided-explorations/aws/migrating-from-codecommit-to-gitlab/-/blob/main/migrating_codecommit_to_gitlab.md).\n\n#### Step 5: Complete migration\nOnce all tests and validations are complete and the team is comfortable with the new environment, plan for full migration. For each project:\n\n1. Set a migration date and notify all stakeholders.\n2. Perform final data synchronization.\n3. Remove mirroring settings from the GitLab project.\n4. Set AWS-hosted repositories to read-only and transition all development work to GitLab.com.\n\n#### Step 6: Assess adoption of new capabilities\n\nGitLab collaboration and workflow automation for developers is far richer than CodeCommit. It merits some time to learn what these capabilities are. The merge request process is especially rich compared to CodeCommit.\n\nAfter repositories are stable on GitLab, it is very easy to experiment with GitLab CI/CD in parallel to an existing solution. Teams can take time to perfect their GitLab CI/CD automation while production workflows remain unaffected.\n\nGitLab artifact management is also very capable with the Releases feature and many package registries.\n\n### Section 1: Summary\nBy adopting a parallel migration approach to GitLab, you can achieve a smooth transition while minimizing risks. This process allows teams to gradually adapt to the new environment and ensure all integrations and automations function correctly. Cutover migrations only omit a single setting checkbox if it is known that a parallel migration is not necessary.\n\n## Section 2: Integrating GitLab with AWS CodeBuild\n\nFor those wanting to build and test code from GitLab repositories using AWS CodeBuild, this comprehensive guide will help you set up an efficient CI pipeline.\n\n### Prerequisites\n\n- GitLab.com account\n- AWS account\n- AWS CLI (configured)\n\n### Step 1: Create GitLab connection in AWS CodeStar Connections\n\n1. Log in to the AWS Management Console and navigate to the CodeBuild service.\n2. Select \"Settings\" > \"Connections\" from the left navigation panel.\n3. Click the \"Create connection\" button.\n4. Choose \"GitLab\" as the provider.\n5. Enter a connection name and click \"Connect to GitLab.\"\n6. You'll be redirected to the GitLab authentication page.\n7. Approve the necessary permissions.\n8. Once successful, the connection status will change to \"Available.\"\n\n![CodeStar Connect setup](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Step 2: Create AWS CodeBuild project\n\n1. Click \"Create build project\" on the CodeBuild dashboard.\n2. Enter a project name and description.\n3. For source settings, select \"GitLab\" as the provider.\n4. Choose the connection you just created and specify the GitLab repository and branch.\n\n![Add CodeBuild project](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_3_add_codebuild_aHR0cHM6_1750097822123.png)\n\n**Note: From Step 3 forward, please configure the settings according to your specific environment and needs.**\n\n### Summary of Section 2\nThis section explained in detail how to integrate GitLab repositories with AWS CodeBuild. This setup enables a continuous integration pipeline where code changes in GitLab are automatically built and tested using AWS CodeBuild.\n\n## Section 3: Integrating GitLab with AWS CodePipeline\n\nFor those looking to implement continuous delivery from GitLab repositories using AWS CodePipeline, this detailed guide will be helpful. The integration has become even easier now that GitLab is available as an AWS CodeStar Connections provider.\n\n### Prerequisites\n\n- GitLab.com account\n- AWS account\n- AWS CLI (configured)\n\n### Step 1: Create GitLab connection in AWS CodeStar Connections\n\n1. Log in to the AWS Management Console and navigate to the CodePipeline service.\n2. Select \"Settings\" > \"Connections\" from the left navigation panel.\n3. Click the \"Create connection\" button.\n4. Choose \"GitLab\" as the provider.\n5. Enter a connection name and click \"Connect to GitLab.\"\n6. You'll be redirected to the GitLab authentication page.\n7. Approve the necessary permissions.\n8. Once successful, the connection status will change to \"Available.\"\n\n![CodeStar Connections setup](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822125.png)\n\n### Step 2: Create AWS CodePipeline\n\n1. Click \"Create pipeline\" on the CodePipeline dashboard.\n2. Enter a pipeline name and click \"Next.\"\n3. Select \"GitLab\" as the source provider.\n4. Choose the connection you just created and specify the GitLab repository and branch.\n5. Select the Trigger type: You can trigger CodePipeline pipeline execution based on either pull or push events against specific branches and file types within your repository.\n\n![Add source provider](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_provider_aHR0cHM6_1750097822127.png)\n\n![Add source configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_configured_aHR0cHM6_1750097822129.png)\n\n**Note: From Step 3 forward, please configure the settings according to your specific environment and needs.**\n\n### Summary of Section 3\nThis section detailed how to integrate GitLab repositories with AWS CodePipeline. This setup enables a continuous delivery pipeline where code changes in GitLab are automatically deployed to your AWS environment.\n\n## Section 4: Migrating to GitLab\n\nIntegrating GitLab with AWS unlocks powerful capabilities for streamlining your development and deployment workflows and helps to solve your source code management woes. This integration can be achieved in several ways, each offering unique benefits:\n\n- Using AWS CodeStar Connections to link GitLab with AWS services enables a more cohesive workflow by allowing external Git repositories, like GitLab, to connect with various AWS services. This setup supports automated builds, deployments, and other essential actions directly from your GitLab repository, making your development process more integrated and streamlined.\n\n- Connecting GitLab with AWS CodePipeline via AWS CodeStar Connections takes automation to the next level by allowing you to create a full CI/CD pipeline. This approach integrates GitLab with AWS CodePipeline, enabling you to automate the entire process – from source control and builds to testing and deployment – using AWS services like CodeBuild and CodeDeploy. This ensures a robust, scalable, and efficient delivery process.\n\n![Chart of new technology and solutions for using GitLab and AWS together](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/Announcing_New_Technology_and_Solutions_for_using_GitLab_and_AWS_Together_aHR0cHM6_1750097822130.png)\n\n1\\. Connecting GitLab with AWS services using AWS CodeStar Connections\n\nAWS CodeStar Connections is a service that allows you to connect external Git repositories (such as GitHub or Bitbucket) to AWS services. You can also connect GitLab to AWS services via CodeStar Connections. When using GitLab, you may need to set up a custom connection as an HTTP Git server.\nThe following AWS services can be connected to GitLab using this method:\n\n- **AWS Service Catalog**\n\nAWS Service Catalog helps organizations standardize and manage AWS resources. Integrating it with GitLab improves transparency in resource management and simplifies change tracking. Specifically, you can automate catalog updates based on GitLab commits, enhancing operational efficiency.\n\n- __AWS CodeBuild__\n\nAWS CodeBuild is a managed build service that compiles source code, runs tests, and produces deployable software packages. Integrating GitLab with CodeBuild allows automated build processes to start whenever code changes are pushed to GitLab. This ensures consistency in builds and facilitates easier collaboration and version control.\n\n- __AWS Glue Notebook Jobs__\n\nAWS Glue Notebook Jobs is a service that allows you to interactively develop and run data preparation and ETL (Extract, Transform, Load) tasks. Integrating GitLab with Glue Notebook Jobs enables version control for notebooks and ETL scripts, promotes collaboration among team members, and improves the quality management of data processing pipelines.\n\n- __AWS Proton__\n\nAWS Proton is a service that automates the development and deployment of microservices and serverless applications. By integrating GitLab with AWS Proton, you can manage infrastructure as code, automate deployments, and ensure consistent environment management, leading to more efficient development processes.\n\nAs AWS CodeStar Connections supports more services, connecting GitLab with additional AWS services will become easier. It's advisable to regularly check for new services that support CodeStar Connections.\n\n2. Connecting CodePipeline with GitLab via AWS CodeStar Connections (including CodeDeploy)\n\nAWS CodePipeline is a continuous delivery service that automates the release process for software. To connect GitLab with CodePipeline, you need to use AWS CodeStar Connections. This setup allows you to designate a GitLab repository as the source and automate the entire CI/CD pipeline.\nThe primary actions supported by CodePipeline include:\n- **Source control:** AWS CodeCommit, GitHub, Bitbucket, GitLab\n- **Build and test:** AWS CodeBuild, Jenkins\n- **Deploy:** AWS CodeDeploy, Elastic Beanstalk, ECS, S3\n- **Approval:** Manual approval\n- **Infrastructure management:** AWS CloudFormation\n- **Serverless:** AWS Lambda\n- **Testing:** AWS Device Farm\n- **Custom Actions:** AWS Step Functions\n\nBy integrating GitLab with CodePipeline, you can automatically trigger the pipeline whenever code changes are pushed to GitLab, allowing a consistent process from build to deployment. Additionally, combining this with GitLab's version control capabilities makes it easier to track deployment history and states, leading to more flexible and reliable software delivery.\n\n## What you've learned\nThis guide has provided comprehensive information on migrating to and integrating GitLab with AWS. Through the four main topics, we've covered:\n- Parallel migration to GitLab: How to gradually migrate from existing AWS-hosted repositories to GitLab.com while minimizing risks.\n- Integration with AWS CodeBuild: Steps to set up a powerful CI environment integrated with GitLab repositories.\n- Integration with AWS CodePipeline: How to build efficient continuous delivery pipelines using GitLab repositories.\n- Downstream integrations for CodePipeline and CodeStar Connections: Leveraging GitLab-AWS connections for widespread service access, unlocking a cascade of integration possibilities across the AWS ecosystem.\n\nAs every organization's code hosting and integration implementation strategy is unique, this tutorial may be used as a starting point for your own GitLab + AWS integration and implementation strategy.\n\n## Additional resources\n\nFor more detailed information and advanced configurations, refer to the following resources:\n\n- [GitLab documentation](https://docs.gitlab.com/)\n- [AWS CodeBuild User Guide](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)\n- [AWS CodePipeline User Guide](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)\n- [GitLab CI/CD documentation](https://docs.gitlab.com/ee/ci/)\n- [Integrate with AWS](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html)\n\nIf you have questions or need support, please contact [GitLab Support](https://about.gitlab.com/support/) or AWS Support. We hope this comprehensive guide helps you in your AWS-GitLab integration journey.",[109,1906,475,671,1341,14,231],"AWS",{"slug":1908,"featured":91,"template":674},"ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","content:en-us:blog:ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","Ultimate Guide To Migrating From Aws Codecommit To Gitlab","en-us/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","en-us/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"_path":1914,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1915,"content":1921,"config":1927,"_id":1930,"_type":16,"title":1931,"_source":17,"_file":1932,"_stem":1933,"_extension":20},"/en-us/blog/gitlab-17-3-release",{"title":1916,"description":1917,"ogTitle":1916,"ogDescription":1917,"noIndex":91,"ogImage":1918,"ogUrl":1919,"ogSiteName":784,"ogType":785,"canonicalUrls":1919,"schema":1920},"GitLab 17.3 Release","GitLab 17.3 released with GitLab Duo Root Cause Analysis.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667608/Blog/Hero%20Images/product-gl17-blog-release-cover-17-3-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-3-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.3 Release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gabe Weaver\"}],\n        \"datePublished\": \"2024-08-15\",\n      }",{"title":1916,"description":1917,"authors":1922,"heroImage":1918,"date":1924,"body":1925,"category":14,"tags":1926},[1923],"Gabe Weaver","2024-08-15","This is the post for [the GitLab 17.3 release](https://about.gitlab.com/releases/2024/08/15/gitlab-17-3-released/).",[752,14],{"slug":1928,"featured":6,"template":674,"externalUrl":1929},"gitlab-17-3-release","https://about.gitlab.com/releases/2024/08/15/gitlab-17-3-released/","content:en-us:blog:gitlab-17-3-release.yml","Gitlab 17 3 Release","en-us/blog/gitlab-17-3-release.yml","en-us/blog/gitlab-17-3-release",{"_path":1935,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1936,"content":1941,"config":1947,"_id":1949,"_type":16,"title":1950,"_source":17,"_file":1951,"_stem":1952,"_extension":20},"/en-us/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation",{"title":1937,"description":1938,"ogTitle":1937,"ogDescription":1938,"noIndex":6,"ogImage":1631,"ogUrl":1939,"ogSiteName":784,"ogType":785,"canonicalUrls":1939,"schema":1940},"Introducing CI/CD Steps, a programming language for DevSecOps automation","Inside GitLab’s vision for CI/CD programmability and a look at how we simplified workflow automation.","https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing CI/CD Steps, a programming language for DevSecOps automation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Eastman\"}],\n        \"datePublished\": \"2024-08-06\",\n      }",{"title":1937,"description":1938,"authors":1942,"heroImage":1631,"date":1944,"body":1945,"category":14,"tags":1946},[1943],"Darren Eastman","2024-08-06","For years, the DevOps industry has tried to simplify how developers create automation scripts or workflows to automatically test a code change and to perform a task with the resulting artifact or binary. Today, we are introducing [CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/), a programming language for DevSecOps automation in experiment phase, as a solution to this challenge. With CI/CD Steps, software development teams can easily create complex automation workflows within GitLab.\n\n## The path to CI/CD Steps\n\nEarly in the company's history, GitLab founders and engineers decided that there must be a tight integration between source code management, the place you store your code, and continuous integration, the automation workflows that test your code changes. And we've continued to evolve that integration, focusing on workflow automation tasks and differentiating from the approaches of CI engines across the industry, including Jenkins CI's domain-specific language, GitHub Actions, and many more. \n\nAnd, yes, I did mean to use the term workflow automation tasks rather than [CI and continuous deployment (CD)](https://about.gitlab.com/topics/ci-cd/). This is simply a result of the code that I have seen our customers develop. In a lot of cases, the platform engineering teams that support development teams using GitLab are writing complex automation scripts (workflows). So we need to embrace a more expansive construct beyond simply CI and CD. In fact, I have seen some developers rave about the flexibility of new CI/CD solutions that allow for modularity and conditionals in writing automation workflows.\n\nAt GitLab, our initial approach for CI authoring was based on YAML. We can endlessly debate the pros and cons of such a choice, but for me, as a [DevOps](https://about.gitlab.com/topics/devops/) practitioner coming from a large Fortune 50 company with a moshpit of Jenkins Groovy code and hundreds of permutations of scripts basically performing the same job, the GitLab CI authoring and execution approach was a breath of fresh air. \n\nThe first time I read a GitLab CI file – this was back in mid-2019 – my first thought was, \"No, it could not be that simple.\" A non-developer can easily grasp the intent of a basic GitLab CI pipeline without prior knowledge of all of the intricacies of the syntax of the execution model. In fact, I had just spent a year working on a team that spent several hours each day helping other development teams debug Jenkins pipelines written in Groovy and trying to figure out how to test, and in some cases build, large Java monoliths; in other cases, tons of microservices.\n\nWhile there are benefits to a GitLab CI YAML-based authoring and a bash script execution type approach, there are also limitations. Limitations that developers or platform engineers bump into as they integrate more complex workflows into their CI pipelines. These issues seem to be amplified at enterprise scale as platform teams are trying to simplify or standardize workflows across multiple development teams. In fact, one of the quotes from a recent customer survey states: “GitLab needs to embrace a post-YAML world for CI.”\n\nSo, over the past two years, our pipeline authoring team, led by Product Manager [Dov Hershkovitch](https://gitlab.com/dhershkovitch), has been working extensively on improving the pipeline authoring experience. They've also been improving the management experience of the building blocks for workflow automation – especially at scale. In fact, a part of this work, the [GitLab CI/CD Catalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/), recently became generally available.\n\nThe logical next step was to build a new language for workflow automation.\n\n## Understanding CI/CD Steps\n\nGitLab CI/CD Steps is a concept incubated by our top-notch engineers. In [our documentation](https://docs.gitlab.com/ee/ci/steps/), we describe CI/CD Steps as reusable and composable pieces of a CI job that can be referenced in a GitLab CI pipeline configuration. But what does that really mean and what is the long-term value proposition?\n\nAs I was giving this some thought, a comment from one of our customers (paraphrased here) came to mind:\n\n“CI/CD Steps enables you to compose inputs and outputs for a CI/CD job. With CI/CD Steps, developers can define inputs and outputs and, therefore, use CI/CD Steps as a function as we do in any modern programming language. A key differentiator to a normal CI/CD component is that CI/CD Steps allows the use of the outputs of other steps without GitLab having to know certain values before running the pipeline. With CI/CD Steps, you could more easily auto-cancel redundant jobs when all jobs are running as part of the parent pipeline versus having to use child pipelines.”\n\nHaving CI/CD Steps alongside the current GitLab CI/CD execution mechanism and the [CI/CD component catalog](https://docs.gitlab.com/ee/ci/components/index.html) unlocks so many possibilities for creating and maintaining the most complex CI/CD workflows. \n\nA key feature is reusability. Now, I am not suggesting that once we release CI/CD Steps as generally available, you would immediately start refactoring your currently working CI/CD jobs to CI/CD Steps. Instead, you likely will find opportunities to introduce CI/CD Steps to optimize complex pipeline workflows, and, in doing so, you will begin to reuse a CI/CD Step that you author in multiple pipelines.\n\nCI/CD Steps is a marathon, not a sprint. When we release this in beta (currently targeted for late 2024) and start getting feedback from you, we will learn new information that will guide the evolution of this new CI programming language as well as the new Step Runner, which is designed specifically to run CI/CD Steps alongside the current CI/CD jobs.\n\nI'm sure there will be questions about our strategy: Why did we make certain syntax choices? Why didn't we use Starlark as the basis for this new approach? Why did we create something new that we all have to learn? My boilerplate response is: At GitLab we develop our software in the open. More importantly, as a customer, user, and community member, if you have an idea of how to make it better, we invite you to create a merge request so we can improve this feature together.\n\nWe are the only enterprise software platform where, as users and customers, **you** have a direct say in how the platform evolves and **you** can see the changes happening transparently and in real time. That’s the power of GitLab – we iterate and we collaborate. You have invested in a platform and community that is able to evolve with the ever-changing software industry.\n\n## Create your own CI/CD step\n\nTo get a deeper understanding of CI Steps and our direction, take a look at the detailed refactoring proof-of-concept writeup in [this issue](https://gitlab.com/gitlab-org/step-runner/-/issues/85). [Principal engineer Joe Burnett](https://gitlab.com/josephburnett) walks through in great detail the thought process for refactoring a CI/CD job used as part of our GitLab Runner automated test framework. There are also recommendations noted at the end that will inform the evolution of the CI Steps syntax.\n\nThen check out the [CI/CD Steps tutorial](https://docs.gitlab.com/ee/tutorials/setup_steps/) and try creating your own CI/CD step. We recently released the `run` keyword, so testing out a CI/CD step will be simpler than previous examples that required using environment variables. This feature set is experimental so please share your experiences on the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/460057). There also is a separate feedback issue if you are testing the [Run GitHub Actions with CI/CD Steps experimental feature](https://docs.gitlab.com/ee/ci/steps/#actions).\n\nWe look forward to working with you on this journey to continuously improve the GitLab CI/CD authoring experience.\n\n## Read more\n- [CI/CD Catalog goes GA](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)\n- [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n- [What is CI/CD?](https://about.gitlab.com/topics/ci-cd/)\n- [The basics of CI](https://about.gitlab.com/blog/basics-of-gitlab-ci-updated/)\n",[475,109,860,859,794],{"slug":1948,"featured":91,"template":674},"introducing-ci-cd-steps-a-programming-language-for-devsecops-automation","content:en-us:blog:introducing-ci-cd-steps-a-programming-language-for-devsecops-automation.yml","Introducing Ci Cd Steps A Programming Language For Devsecops Automation","en-us/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation.yml","en-us/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation",{"_path":1954,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1955,"content":1961,"config":1968,"_id":1970,"_type":16,"title":1971,"_source":17,"_file":1972,"_stem":1973,"_extension":20},"/en-us/blog/how-visualization-improves-the-gitlab-merge-train-experience",{"title":1956,"description":1957,"ogTitle":1956,"ogDescription":1957,"noIndex":6,"ogImage":1958,"ogUrl":1959,"ogSiteName":784,"ogType":785,"canonicalUrls":1959,"schema":1960},"How visualization improves the GitLab merge train experience","Merge train visualization lets users closely track merge train activities and take actions with a better understanding of the impact on other MRs in the queue.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098825/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2824%29_1KuzZLH1aSgBZsGVXGPIjf_1750098824773.png","https://about.gitlab.com/blog/how-visualization-improves-the-gitlab-merge-train-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How visualization improves the GitLab merge train experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Payton Burdette\"},{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":1956,"description":1957,"authors":1962,"heroImage":1958,"date":1965,"body":1966,"category":14,"tags":1967},[1963,1964],"Payton Burdette","Veethika Mishra","2024-07-25","GitLab's merge train feature on the DevSecOps platform has worked wonders for organizations looking for a solution to automatically manage conflicts among different merge requests that are merged in close proximity to each other. [Merge trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) support all merge methods and ensure all MRs work together, which saves time and reduces the stress of breaking the default branch, especially for teams dealing with long build times or a small fleet of runners. Merge trains also alleviate some of the burden on developers who have to track the progress of other MRs before pushing the \"Merge\" button.\n\nDespite the benefits of a merge train, without having a UI to visualize its inner workings, users find it hard to trust the process. Sometimes it is difficult to distinguish failures caused by user actions from those due to flaky runs. \n\nMoreover, the lack of visibility into what else is queued before or after a particular MR has made users less confident when taking actions such as merging immediately or removing MRs from the merge train.\n\nTo address this gap in user experience, we are introducing merge train visualization in GitLab (Premium and Ultimate tiers) for better visibility into and tracking of the merge train queue.\n\n## Merge train visualization\n\nBased on findings from user research and feedback, we have defined a set of requirements for the first iteration of this feature. Here’s what you can expect.\n\n### View merge trains\n\nCurrently, when a merge request is added to the train, a link to the merge train details page is surfaced on the pipeline widget.\n\n![Merge train running](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098833102.png)\n\n### View list of MRs queued in a train\n\nWith the new merge train visualization, users can see a list of all MRs queued in the train. This transparency helps developers understand the order of merges and anticipate potential conflicts or issues. Knowing what is queued provides clarity and allows for better planning and coordination among team members.\n\n![List of MRs queued in the train](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098833102.png)\n\n### View list of MRs already merged by the train\n\nIn addition to seeing what is queued, users can also view a list of MRs that have already been successfully merged by the train. This historical context is valuable for tracking progress and understanding the sequence of changes that have been integrated into the default branch.\n\n![List of merged MRs in the train](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098833104.png)\n\n### Remove a merge request from the train straight from visualization\nThe new visualization also enables quick actions. The first action implemented is removing an MR from the merge train. This streamlined workflow reduces the time and effort required to manage merge trains, making it easier to respond to issues as they arise and maintain a smooth CI/CD pipeline.\n\n![Remove a merge request screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098833107.png)\n\n## The benefits of merge train visualization\n\nMerge train visualization has the following benefits: \n\n1. Enhanced transparency and trust\n- By visualizing the merge train, GitLab provides users with the transparency they need to trust the system. Understanding what is happening within the merge train reduces uncertainty and builds confidence in the automated process.\n2. Improved efficiency and collaboration\n- Teams can work more efficiently by having a clear view of the merge train. Developers can better coordinate their efforts, avoid redundant work, and quickly address issues. This collaborative approach ensures smoother and faster integration of changes.\n3. Reduced risk of failures\n- With visibility into the merge train, users can identify and address potential conflicts or failures early. This proactive approach minimizes the risk of breaking the default branch, leading to more stable and reliable builds.\n\n## What’s next?\n\nAs we learn more about how users interact with the merge train visualization, we intend to [add more capabilities](https://gitlab.com/gitlab-org/gitlab/-/issues/277391/designs/mr-visualization-as-a-list.png) to the list view. Early ideas include displaying estimated time to merge, ability to re-order, and displaying removed merge requests from the train. If you have ideas that you want to share, don’t forget to leave a comment on [our feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/464774).\n\nWe believe that the merge train visualization will significantly enhance the user experience for developers using GitLab. By providing a clear and actionable view of the merge train, we aim to make the merge process more transparent, efficient, and reliable.\n\n> Sign up for a [free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial) to test-drive merge train visualization.\n",[109,794,14],{"slug":1969,"featured":91,"template":674},"how-visualization-improves-the-gitlab-merge-train-experience","content:en-us:blog:how-visualization-improves-the-gitlab-merge-train-experience.yml","How Visualization Improves The Gitlab Merge Train Experience","en-us/blog/how-visualization-improves-the-gitlab-merge-train-experience.yml","en-us/blog/how-visualization-improves-the-gitlab-merge-train-experience",{"_path":1975,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1976,"content":1982,"config":1988,"_id":1991,"_type":16,"title":1992,"_source":17,"_file":1993,"_stem":1994,"_extension":20},"/en-us/blog/gitlab-patch-release-17-2-1-17-1-3-17-0-5",{"title":1977,"description":1978,"ogTitle":1977,"ogDescription":1978,"noIndex":91,"ogImage":1979,"ogUrl":1980,"ogSiteName":784,"ogType":785,"canonicalUrls":1980,"schema":1981},"GitLab Patch Release: 17.2.1, 17.1.3, 17.0.5","Learn more about GitLab Patch Release: 17.2.1, 17.1.3, 17.0.5 for GitLab Community Edition (CE) and Enterprise Edition (EE).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","https://about.gitlab.com/blog/gitlab-patch-release-17-2-1-17-1-3-17-0-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.2.1, 17.1.3, 17.0.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Alfaro\"}],\n        \"datePublished\": \"2024-07-24\",\n      }",{"title":1977,"description":1978,"authors":1983,"heroImage":1979,"date":1985,"body":1986,"category":14,"tags":1987},[1984],"Greg Alfaro","2024-07-24","This is the blog for [GitLab Patch Release: 17.2.1, 17.1.3, 17.0.5](https://about.gitlab.com/releases/2024/07/24/patch-release-gitlab-17-2-1-released/).",[752,879],{"slug":1989,"featured":6,"template":674,"externalUrl":1990},"gitlab-patch-release-17-2-1-17-1-3-17-0-5","https://about.gitlab.com/releases/2024/07/24/patch-release-gitlab-17-2-1-released/","content:en-us:blog:gitlab-patch-release-17-2-1-17-1-3-17-0-5.yml","Gitlab Patch Release 17 2 1 17 1 3 17 0 5","en-us/blog/gitlab-patch-release-17-2-1-17-1-3-17-0-5.yml","en-us/blog/gitlab-patch-release-17-2-1-17-1-3-17-0-5",{"_path":1996,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1997,"content":2002,"config":2008,"_id":2010,"_type":16,"title":2011,"_source":17,"_file":2012,"_stem":2013,"_extension":20},"/en-us/blog/next-generation-gitlab-container-registry-goes-ga",{"title":1998,"description":1999,"ogTitle":1998,"ogDescription":1999,"noIndex":6,"ogImage":1333,"ogUrl":2000,"ogSiteName":784,"ogType":785,"canonicalUrls":2000,"schema":2001},"Next-generation GitLab container registry goes GA","Starting in GitLab 17.3, GitLab self-managed instances can access the generally available container registry, which features efficient zero-downtime garbage collection and other benefits.","https://about.gitlab.com/blog/next-generation-gitlab-container-registry-goes-ga","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Next-generation GitLab container registry goes GA\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-07-23\",\n      }",{"title":1998,"description":1999,"authors":2003,"heroImage":1333,"date":2004,"body":2005,"category":14,"tags":2006},[748],"2024-07-23","Last year, we embarked on an ambitious journey to [re-architect the GitLab container registry](https://gitlab.com/gitlab-org/container-registry/-/issues/199) and unlock powerful new capabilities like zero-downtime garbage collection. After successfully migrating GitLab.com to this next-generation registry, we [opened up a beta program](https://about.gitlab.com/blog/gitlabs-next-generation-container-registry-is-now-available/) for self-managed customers to test out the new architecture and provide feedback.\n\nThe results from the beta program have been outstanding – participants are already realizing major benefits, including the following:\n\n- significant storage cost and maintenance time savings from efficient zero-downtime garbage collection, with no required downtime or manual interventions\n- improved performance and reliability for tag cleanup policies and the container registry API and UI\n- early access to new features like better sorting/filtering and storage usage visibility\n\nBased on the positive feedback and successful migrations during the beta, we are excited to announce that the next-generation GitLab container registry will become generally available – but off by default – for self-managed deployments starting with GitLab 17.3.\n\nBelow are the goals and non-goals for reaching this point. The goals are what we need to have in place to officially call this feature GA. The non-goals clarify what will not be present or required at the start of GA support for bringing your own database; however, these features may be added later.\n\n__Goals__\n- The import process is free of known bugs.\n- Import documentation reflects known best practices and addresses feedback from the [beta program](https://gitlab.com/gitlab-org/gitlab/-/issues/423459).\n- Registry API, metadata database, and zero-downtime garbage collection are stable and reliable.\n- Able to automatically apply database schema migrations for Charts installs during upgrades.\n- Provide registry database as an opt-in improvement.\n\n__Non-goals__\n- Automatically provision registry database.\n- Automatically apply database schema migrations for omnibus installs during upgrades.\n- Automatically import object storage data.\n- Provide Geo support to ensure your registry is highly available.\n\nFor existing self-managed instances, here's what you can expect:\n\n- In GitLab 17.3, the new registry will be included, but disabled by default to allow time for planning migrations.\n- Enabling the database will be an opt-in process outlined in the [documentation](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html).\n- The legacy container registry will still receive security updates, but new features and improvements will only be developed for the next-gen version.\n- We will target GitLab 19.0 for the legacy registry to stop being supported after over a year of co-existence.\n- Our goal is to make this transition as seamless as possible while putting customers in control of their migration timeline. The [documentation](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html) covers all the details on how to plan and execute the move to the next-gen registry.\n\nThis architectural investment lays the foundation for an even more powerful container registry experience in the years ahead. Some of the significant improvements on our roadmap include:\n\n- protected repositories and immutable tags\n- improved Helm chart management\n- improved support for signing and attestations\n- many more UX/UI enhancements are only possible with the database architecture\n\nWe couldn't have reached this GA milestone without the valuable feedback from our beta participants. As always, please continue to share your experiences so we can make the GitLab container registry an indispensable part of your DevSecOps toolchain.\n\n> You can try the container registry today with a [free, 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).",[475,794,2007,14],"cloud native",{"slug":2009,"featured":91,"template":674},"next-generation-gitlab-container-registry-goes-ga","content:en-us:blog:next-generation-gitlab-container-registry-goes-ga.yml","Next Generation Gitlab Container Registry Goes Ga","en-us/blog/next-generation-gitlab-container-registry-goes-ga.yml","en-us/blog/next-generation-gitlab-container-registry-goes-ga",{"_path":2015,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2016,"content":2022,"config":2027,"_id":2030,"_type":16,"title":2031,"_source":17,"_file":2032,"_stem":2033,"_extension":20},"/en-us/blog/gitlab-17-2-release",{"title":2017,"description":2018,"ogTitle":2017,"ogDescription":2018,"noIndex":91,"ogImage":2019,"ogUrl":2020,"ogSiteName":784,"ogType":785,"canonicalUrls":2020,"schema":2021},"GitLab 17.2 Release","GitLab 17.2 released with log streaming, a new pipeline execution security policy, and vulnerability explanations now generally available","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667769/Blog/Hero%20Images/product-gl17-blog-release-cover-17-2-0093-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-17-2-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 17.2 Release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n        \"datePublished\": \"2024-07-18\",\n      }",{"title":2017,"description":2018,"authors":2023,"heroImage":2019,"date":2024,"body":2025,"category":14,"tags":2026},[1358],"2024-07-18","This is the post for the [GitLab 17.2 release](https://about.gitlab.com/releases/2024/07/18/gitlab-17-2-released/).",[752,14,475],{"slug":2028,"featured":91,"template":674,"externalUrl":2029},"gitlab-17-2-release","https://about.gitlab.com/releases/2024/07/18/gitlab-17-2-released/","content:en-us:blog:gitlab-17-2-release.yml","Gitlab 17 2 Release","en-us/blog/gitlab-17-2-release.yml","en-us/blog/gitlab-17-2-release",{"_path":2035,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2036,"content":2042,"config":2049,"_id":2051,"_type":16,"title":2052,"_source":17,"_file":2053,"_stem":2054,"_extension":20},"/en-us/blog/introducing-gitlab-dedicated-for-government",{"title":2037,"description":2038,"ogTitle":2037,"ogDescription":2038,"noIndex":6,"ogImage":2039,"ogUrl":2040,"ogSiteName":784,"ogType":785,"canonicalUrls":2040,"schema":2041},"Introducing GitLab Dedicated for Government","Learn how our single-tenant SaaS offering, along with our new FedRAMP \"In Process\" designation, will help public sector customers securely advance their modernization objectives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667636/Blog/Hero%20Images/Dedicated_Screengrab_1800x945.png","https://about.gitlab.com/blog/introducing-gitlab-dedicated-for-government","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab Dedicated for Government\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Balane\"},{\"@type\":\"Person\",\"name\":\"Corey Oas\"}],\n        \"datePublished\": \"2024-06-25\",\n      }",{"title":2037,"description":2038,"authors":2043,"heroImage":2039,"date":2046,"body":2047,"category":14,"tags":2048},[2044,2045],"Chris Balane","Corey Oas","2024-06-25","Public sector organizations, as well as companies in highly regulated industries, are transforming software development by adopting modern and efficient cloud-based technologies while safeguarding the security of federal information. Not an easy task. However, with the just-announced GitLab Dedicated for Government offering, we will be providing customers with a FedRAMP-compliant DevSecOps solution through a secure, single-tenant SaaS offering. Now [listed on the FedRAMP Marketplace](https://marketplace.fedramp.gov/products/FR2411959145), GitLab Dedicated for Government will provide all of the benefits of an enterprise DevSecOps platform, with an added focus on data residency, isolation, and private networking to help meet compliance needs.\n\n> To learn more about GitLab Dedicated for Government, and how to secure your software supply chain from code to cloud, reach out to our [sales team](mailto:public-sector@gitlab.com).\n\n## Achieving FedRAMP® certification\n\nThe [Federal Risk and Authorization Management Program](https://www.fedramp.gov/), otherwise known as FedRAMP, has become the gold standard in cloud security, not just for the federal government, but for state and local governments, contractors that aspire to work with government agencies, and security-minded organizations. The U.S. government mandates that cloud services for federal agencies meet strict security standards under FedRAMP. This supports the shift from legacy IT to cost-effective, secure, and scalable cloud-based systems. FedRAMP standards are very rigorous. Organizations must undergo a thorough assessment process, implement necessary security controls, conduct regular audits, and ensure continuous monitoring to meet the stringent criteria set by FedRAMP.\n\nGitLab achieved a major milestone, receiving an \"In Process\" designation for [FedRAMP Moderate Impact Level](https://www.fedramp.gov/baselines/#moderate-impact). This designation is given to cloud service providers working toward a FedRAMP “Authority to Operate” (ATO) status.\n\n**Note:** GitLab also has a provisional certification through the Texas Risk and Authorization Management Program, or [TX-RAMP](https://dir.texas.gov/resource-library-item/tx-ramp-certified-cloud-products), which allows us to work with Texas state agencies.\n\n## Navigating compliance complexities\n\nAs more public sector organizations move away from costly legacy systems and migrate their mission-critical workloads to the cloud, cloud and multi-cloud adoption will grow significantly. At GitLab, we serve a wide variety of customers in the public sector – from federally funded research and development centers and service providers working on behalf of the government, to some of the largest government agencies – and we know that no single deployment model will serve the needs of all of our customers.\n\nOur customers have told us they need a SaaS offering that provides additional deployment control and data residency to meet stringent compliance requirements. We see this need with large enterprises and companies in regulated industries that are coming under increased scrutiny, facing global internet policy fragmentation, and dealing with the expanding complexity of data governance. GitLab has consistently observed that security is a top priority for organizations and our [2024 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) showed that this trend continued, with security remaining the primary investment area. \n\n## The benefits of GitLab Dedicated for Government\n\nGitLab Dedicated for Government, which aligns to the Cybersecurity and Infrastructure Security Agency's [Secure by Design principles](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/), can help the public sector and highly regulated industries reduce toolchain complexity, and support data residency and protection, all while being hosted and managed by GitLab.\n\n### 1. Toolchain consolidation\nToolchain management continues to be an area where DevSecOps teams are feeling the pressure. Many organizations pay for numerous cybersecurity tools that only serve a single purpose, resulting in a surplus of unused or forgotten products and services. According to our [2024 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/), 64% of survey respondents expressed the need to consolidate their toolchains. Security professionals in particular reported using a lot of tools — 63% of security respondents said they use six or more tools. The result can be unnecessary spend, and added complexities and vulnerabilities, putting organizations at a higher risk of cyber attacks. GitLab Dedicated for Government unites DevSecOps teams in a single platform with a single workflow without the need to buy or maintain other tools. By consolidating complex toolchains, organizations can strengthen security and improve process and operational efficiency.\n\n### 2. Data residency and protection \nGitLab Dedicated for Government is built on top of a FedRAMP-authorized infrastructure, which meets U.S. data sovereignty requirements, including access that is restricted to U.S. citizens. \n\nTo help further protect customer data, GitLab Dedicated for Government supports a secure, private connection between the customer’s virtual private cloud network and GitLab. Therefore, users, data, and services have secure access to the isolated instance without exposing services directly to the internet.\n\n### 3. Managed and hosted by GitLab\nGitLab Dedicated for Government is not only single-tenant (physical isolation between other customers), U.S.-based, and privately connected, but it’s also managed and hosted by GitLab. Organizations can quickly realize the value of a DevSecOps platform, including the advanced flexibility of a self-managed instance, but without requiring staff to build out and manage infrastructure. Organizations get all of the benefits of GitLab — shorter cycle times, lower costs, stronger security, and more productive developers — with lower total cost of ownership and quicker time-to-value than self-hosting. \n\n## How to get started with GitLab Dedicated for Government\nGitLab Dedicated for Government will bring more flexibility and greater choice to the [public sector](https://about.gitlab.com/solutions/public-sector/) and organizations in highly regulated industries that have complex compliance and data residency requirements. The offering will provide the efficiencies of the cloud, but with infrastructure-level isolation and data residency controls. To learn more about GitLab Dedicated for Government, and how to secure your software supply chain from code to cloud, reach out to our [sales team](https://about.gitlab.com/sales/).\n",[184,1101,838,475,14],{"slug":2050,"featured":91,"template":674},"introducing-gitlab-dedicated-for-government","content:en-us:blog:introducing-gitlab-dedicated-for-government.yml","Introducing Gitlab Dedicated For Government","en-us/blog/introducing-gitlab-dedicated-for-government.yml","en-us/blog/introducing-gitlab-dedicated-for-government",{"_path":2056,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2057,"content":2063,"config":2070,"_id":2072,"_type":16,"title":2073,"_source":17,"_file":2074,"_stem":2075,"_extension":20},"/en-us/blog/monitor-application-performance-with-distributed-tracing",{"title":2058,"description":2059,"ogTitle":2058,"ogDescription":2059,"noIndex":6,"ogImage":2060,"ogUrl":2061,"ogSiteName":784,"ogType":785,"canonicalUrls":2061,"schema":2062},"Monitor application performance with Distributed Tracing","Learn how Distributed Tracing helps troubleshoot application performance issues by providing end-to-end visibility and seamless collaboration across your organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098000/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5x6kH5vwjz8cwKgSBh1w11_1750098000511.png","https://about.gitlab.com/blog/monitor-application-performance-with-distributed-tracing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Monitor application performance with Distributed Tracing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sacha Guyon\"}],\n        \"datePublished\": \"2024-06-13\",\n      }",{"title":2058,"description":2059,"authors":2064,"heroImage":2060,"date":2066,"body":2067,"category":14,"tags":2068},[2065],"Sacha Guyon","2024-06-13","Downtime due to application defects or performance issues can have devastating financial consequences for businesses. An hour of downtime is estimated to cost firms $301,000 or more, according to [Information Technology Intelligence Consulting's 2022 Global Server Hardware and Server OS Reliability Survey](https://itic-corp.com/server-and-application-by-the-numbers-understanding-the-nines/). These issues often originate from human-introduced changes, such as code or configuration changes.\n\nResolving such incidents requires development and operations teams to collaborate closely, investigating the various components of the system to find the root cause change, and promptly restore the system back to normal operation. However, these teams commonly use separate tools to build, manage, and monitor their application services and infrastructure. This approach leads to siloed data, fragmented communication, and inefficient context switching, increasing the time spent to detect and resolve incidents.\n\nGitLab aims to address this challenge by combining software delivery and monitoring functionalities within the same platform. Last year, we released [Error Tracking](https://docs.gitlab.com/ee/operations/error_tracking.html) as a general availability feature in [GitLab 16.0](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#error-tracking-is-now-generally-available). Now, we're excited to announce the [Beta release of Distributed Tracing](https://docs.gitlab.com/ee/operations/tracing), the next step toward a comprehensive observability offering seamlessly integrated into the GitLab DevSecOps platform.\n\n## A new era of efficiency: GitLab Observability\n\nGitLab Observability empowers development and operations teams to visualize and analyze errors, traces, logs, and metrics from their applications and infrastructure. By integrating application performance monitoring into existing software delivery workflows, context switching is minimized and productivity is increased, keeping teams focused and collaborative on a unified platform.\n\nAdditionally, GitLab Observability bridges the gap between development and operations by providing insights into application performance in production. This enhances transparency, information sharing, and communication between teams. Consequently, they can detect and resolve bugs and performance issues arising from new code or configuration changes sooner and more effectively, preventing those issues from escalating into major incidents that could negatively impact the business.\n\n## What is Distributed Tracing?\n\nWith Distributed Tracing, engineers can identify the source of application performance issues. A trace represents a single user request that moves through different services and systems. Engineers are able to analyze the timing of each operation and any errors as they occur.\n\nEach trace is composed of one or more spans, which represent individual operations or units of work. Spans contain metadata like the name, timestamps, status, and relevant tags or logs. By examining the relationships between spans, developers can understand the request flow, identify performance bottlenecks, and pinpoint issues.\n\nDistributed Tracing is especially valuable for [microservices architecture](https://about.gitlab.com/topics/microservices/), where a single request may involve numerous service calls across a complex system. Tracing provides visibility into this interaction, empowering teams to quickly diagnose and resolve problems.\n\n![tracing example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098009139.png)\n\nFor example, this trace illustrates a how a user request flows through difference services to fetch product recommendations on a e-commerce website:\n\n- `User Action`: This indicates the user's initial action, such as clicking a button to request product recommendations on a product page.\n-  `Web front-end`: The web front-end sends a request to the recommendation service to retrieve product recommendations.\n- `Recommendation service`: The request from the web front-end is handled by the recommendation service, which processes the request to generate a list of recommended products.\n- `Catalog service`: The recommendation service calls the catalog service to fetch details of the recommended products. An alert icon suggests an issue or delay at this stage, such as a slow response or error in fetching product details.\n- `Database`: The catalog service queries the database to retrieve the actual product details. This span shows the SQL query in the database.\n\nBy visualizing this end-to-end trace, developers can identify performance issues – here, an error in the Catalog service – and quickly diagnose and resolve issues across the distributed system.\n\n![End-to-end trace](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098009140.png)\n\n## How Distributed Tracing works\n\nHere is a breakdown of how Distributed Tracing works.\n\n### Collect data from any application with OpenTelemetry\n\nTraces and spans can be collected using [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/), an open-source observability framework that supports a wide array of SDKs and libraries across [major programming languages and frameworks](https://opentelemetry.io/docs/languages/). This framework offers a vendor-neutral approach for collecting and exporting telemetry data, enabling developers to avoid vendor lock-in and choose the tools that best fit their needs.\n\nThis means that if you are already using OpenTelemetry with another vendor, you can send data to us simply by adding our endpoint to your configuration file, making it very easy to try out our features!\n\n![Distributed tracing workflow diagram](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098009141.png)\n\n### Ingest and retain data at scale with fast, real-time queries\n\nObservability requires the storage and querying of vast amounts of data while maintaining low latency for real-time analytics. To meet these needs, we developed a horizontally scalable, long-term storage solution using ClickHouse and Kubernetes, based on our [acquisition of Opstrace](https://about.gitlab.com/press/releases/2021-12-14-gitlab-acquires-opstrace-to-expand-its-devops-platform-with-open-source-observability-solution/). This [open-source platform](https://gitlab.com/gitlab-org/opstrace/opstrace) ensures rapid query performance and enterprise-grade scalability, all while minimizing costs.   \n\n### Explore and analyze traces effortlessly\nAn advanced, native-level user interface is crucial for effective data exploration. We built such an interface from the ground up, starting with our Trace Explorer, which allows users to examine traces and understand their application's performance:\n- __Advanced filtering:__ Filter by services, operation names, status, and time range. Autocomplete helps simplify querying.\n- __Error highlighting:__ Easily identify error spans in search results.\n- __RED metrics:__ Visualize the Requests rate, Errors rate, and average Duration as a time-series chart for any search in real-time.\n- __Timeline view:__ Individual traces are displayed as a waterfall diagram, providing a complete view of a request distributed across different services and operations.\n- __Historical data:__ Users can query traces up to 30 days in the past.\n\n![Distributed Tracing - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098009141.png)\n\n## How we use Distributed Tracing at GitLab\n[Dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is a core value and practice at GitLab. We've been already using early versions of Distributed Tracing for our engineering and operations needs. Here are a couple example use cases from our teams:\n\n### 1. Debug errors and performance Issues in GitLab Agent for Kubernetes\n\nThe [Environments group](https://handbook.gitlab.com/handbook/engineering/development/ops/deploy/environments/) has been using Distributed Tracing to troubleshoot and resolve issues with the [GitLab Agent for Kubernetes](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent), such as timeouts or high latency issues. The Trace List and Trace Timeline views offer valuable insights for the team to address these concerns efficiently. These traces are shared and discussed in the [related GitLab issues](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/386#note_1576431796), where the team collaborates on resolution.\n\n\u003Ccenter>\u003Ci>\"The Distributed Tracing feature has been invaluable in pinpointing where latency issues are occurring, allowing us to focus on the root cause and resolve it faster.\" - Mikhail, GitLab Engineer\u003C/i>\u003C/center>\u003Cp>\n\n### 2. Optimize GitLab’s build pipeline duration by identifying performance bottlenecks \n\nSlow deployments of GitLab source code can significantly impact the productivity of the whole company, as well as our compute spending. Our main repository runs [over 100,000 pipelines every month](https://gitlab.com/gitlab-org/gitlab/-/pipelines/charts). If the time it takes for these pipelines to run changes by just one minute, it can add or remove more than 2,000 hours of work time. That's 87 extra days!\n\nTo optimize pipeline execution time, GitLab's [platform engineering teams](https://handbook.gitlab.com/handbook/engineering/infrastructure/) utilize a [custom-built tool](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace) that converts GitLab deployment pipelines into traces.\n\nThe Trace Timeline view allows them to visualize the detailed execution timeline of complex pipelines and pinpoint which jobs are part of the critical path and slowing down the entire process. By identifying these bottlenecks, they can optimize job execution – for example, making the job fail faster, or running more jobs in parallel – to improve overall pipeline efficiency.\n\n![Distributed Tracing - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098009143.gif)\n\n[The script is freely available](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace), so you can adapt it for your own pipelines.\n\n\u003Ccenter>\u003Ci>\"Using Distributed Tracing for our deployment pipelines has been a game-changer. It's helped us quickly identify and eliminate bottlenecks, significantly reducing our deployment times.\"- Reuben, GitLab Engineer\u003C/i>\u003C/center>\u003Cp>\n\n## What's coming next?\n\nThis release is just the start: In the next few months, we'll continue to expand our observability and monitoring features with the upcoming Metrics and Logging releases. Check out [our Observability direction page](https://about.gitlab.com/direction/monitor/platform-insights/) for more info, and keep an eye out for updates!\n\n## Join the private Beta\n\nInterested in being part of this exciting journey? [Sign up to enroll in the private Beta](https://about.gitlab.com/solutions/gitlab-observability/) and try out our features. Your contribution can help shape the future of observability within GitLab, ensuring our tools are perfectly aligned with your needs and challenges.\n\n> Help shape the future of GitLab Observability. [Join the Distributed Tracing Beta.](https://about.gitlab.com/solutions/gitlab-observability/)",[2069,794,838,475,1281],"performance",{"slug":2071,"featured":91,"template":674},"monitor-application-performance-with-distributed-tracing","content:en-us:blog:monitor-application-performance-with-distributed-tracing.yml","Monitor Application Performance With Distributed Tracing","en-us/blog/monitor-application-performance-with-distributed-tracing.yml","en-us/blog/monitor-application-performance-with-distributed-tracing",{"_path":2077,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2078,"content":2084,"config":2090,"_id":2092,"_type":16,"title":2093,"_source":17,"_file":2094,"_stem":2095,"_extension":20},"/en-us/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch",{"title":2079,"description":2080,"ogTitle":2079,"ogDescription":2080,"noIndex":6,"ogImage":2081,"ogUrl":2082,"ogSiteName":784,"ogType":785,"canonicalUrls":2082,"schema":2083},"CI/CD Catalog goes GA: No more building pipelines from scratch","The CI/CD Catalog becomes generally available in GitLab 17.0. Get to know the capabilities for discovering and sharing pipeline building blocks to help standardize and scale pipelines.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098794/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%289%29_DoeBNJVrhv9FpF3WCsHNc_1750098793762.png","https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI/CD Catalog goes GA: No more building pipelines from scratch\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2024-05-08\",\n      }",{"title":2079,"description":2080,"authors":2085,"heroImage":2081,"date":2087,"body":2088,"category":14,"tags":2089},[2086],"Dov Hershkovitch","2024-05-08","GitLab's [CI/CD Catalog](https://docs.gitlab.com/ee/ci/components/#cicd-catalog) becomes generally available in 17.0 (May 16, 2024), enabling all GitLab users to discover, reuse, and contribute CI/CD components easily. The CI/CD Catalog boosts collaboration and efficiency when creating pipeline configurations by allowing access to a treasure trove of pre-built components, ready to seamlessly integrate into DevSecOps workflows. Enterprises can use the CI/CD Catalog's centralized platform to standardize workflows across the whole organization.\n\nWith the CI/CD Catalog, GitLab is introducing several key capabilities that are also generally available.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)\n\n## Components and inputs\nThe [CI/CD Catalog](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/) draws its strength from two fundamental features: components and inputs. These capabilities form the backbone of the catalog, enabling developers and DevSecOps teams to streamline their pipeline development. Let’s dive into each of these features:\n\n### Components\n\n#### What are components?\nComponents are reusable, single-purpose building blocks that abstract away the complexity of pipeline configuration. Think of them as Lego pieces for your CI/CD workflows. By using components, you can assemble pipelines more efficiently without starting from scratch each time.\n\n#### Types of components\n- Template-type components: These components resemble CI templates and come with predefined input definitions. They are organized within a specific directory structure, which you can easily plug into your pipelines.\n- CI Steps (upcoming): This new type of component, which is available as an [experimental feature](https://docs.gitlab.com/ee/ci/steps/), will become a first-class object in the CI/CD Catalog, so stay tuned for this exciting addition.\n\n### Inputs\n\n#### What is Inputs Interpolation?\n\nInputs Interpolation is a powerful feature that allows you to define input parameters for includable configuration files. By using the [spec: inputs keyword](https://docs.gitlab.com/ee/ci/yaml/#specinputs) within your component configuration, you can dynamically replace almost any keywords within components with parameters. This flexibility extends to adjusting stages, scripts, or job names, supporting various data types making the component fully flexible to your needs.\n\n##### Scoped and effective\nImportantly, inputs are scoped exclusively to the included configuration. This prevents unintended effects on the rest of your pipeline. With Inputs Interpolation, you can declare and enforce constraints seamlessly, ensuring smooth integration of components.\n\nWhether you’re a seasoned DevOps pro or just starting out, the CI/CD Catalog, components, and Inputs Interpolation will transform your pipeline development experience.\n\n## How to access CI/CD Catalog components\nThe CI/CD Catalog is a powerful resource for developers and DevOps teams. It allows you to share and discover pre-built components, streamlining your pipeline development. Here’s how it works:\n\n1. Components are standalone building blocks that simplify pipeline configuration. You can create custom components tailored to your needs. But how do you make them available to others? That’s where the CI/CD Catalog comes in.\n\n2. How to publish to the CI/CD Catalog\n    - To share your components with the community, follow these steps:\n      - Use a simple CI job to publish your component and make it discoverable in the CI/CD Catalog.\n      - Whether it’s a reusable script, a deployment template, or any other pipeline element, the CI/CD Catalog is the perfect place to contribute.\nComponents released to the CI/CD Catalog should be tagged with a [semantic version](https://docs.gitlab.com/ee/ci/components/#semantic-versioning) using three digits.\n    - By sharing your components, you contribute to a growing library of resources that benefit the entire community.\n3. Catalog index page\n    - The main page of the CI/CD Catalog (also known as the index page) provides an overview of available projects with published components. Anyone can access the catalog and search for a component that suits their needs.\n    - The index page features two tabs:\n      - All: Displays all component projects that have been published and visible to you.\n      - Your groups: Shows components published within a namespace you’re part of.\n\n![CI/CD Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098805/Blog/Content%20Images/Blog/Content%20Images/catalog_index_aHR0cHM6_1750098804807.png)\n\n4.  Catalog details page\n\n- Upon clicking on one of the projects in the CI/CD Catalog, you will be redirected to the details page where you can view the available components in that project. \n    - Note that there could be multiple components in a single project.\n\n- The details page features two tabs:\n\u003Ccenter>\u003Ci>Readme: Displays the readme.md of the project that was previously configured by the user.\u003C/i>\u003C/center>\n\n![readme tab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098805/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098804808.png)\n\n\u003Ccenter>\u003Ci>Components: Displays the detailed information for each component such as inputs table syntax to use and more. This information is generated and displayed automatically to help keep it up to date.\u003C/i>\u003C/center>\n\n![components tab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098805/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098804809.png)\n\n## Using a component\n\nTo use a component from the CI/CD Catalog, simply copy the suggested snippet to your pipeline configuration. For example: \n\n```yaml\n\ninclude: \n  - component:   gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@0.1.0\n\n```\n\nNote that the snippet contains the fully qualified domain name of the component, so if you moved or clone the component to a different location, you should make sure the FQDN is accurate. You can use the $CI_SERVER_FQDN variable instead of hardcoding the FQDN in your pipeline configuration.\n\nA component can be referenced using the following:\n\n- a commit SHA, for example, e3262fdd0914fa823210cdb79a8c421e2cef79d. We highly recommend using this with $CI_COMMIT_SHA variable in your `.gitlab.ci.yml` file to test a component before publishing it to the CI/CD Catalog.\n- a branch name, for example, main\n- a tag, for example 1.0.0\n- shorthand abbreviation 1.0, which will provide you the latest patched 1.0.x version or 1, which will provide you the latest 1.x.x minor version. This is why it is recommended to use the best practices of semantic versioning and always reference a specific version (minor, major, or a specific patch).\n- ~latest, which always points to the latest semantic version published in the CI/CD Catalog. Use ~latest only if you want to use the absolute latest version at all times, which could include breaking changes., so please use it with caution.\n\n## Understanding the CI/CD Catalog across GitLab deployments\nThe CI/CD Catalog and components offer different flavors to cater to various needs and use cases.\n\n### Private and public components\n\n#### Public components\n\n- Public components are hosted in public repositories and are accessible to everyone.\n- When a public component is published from GitLab.com to the main catalog, it becomes discoverable and available for consumption by all users.\n- We encourage users to contribute their best components to the public catalog, helping us build a thriving community.\n\n#### Private components\n\n- Private components are hosted in private repositories.\n- Visibility based on permissions: Users who access the catalog can also see and search for private components if they have permission to view the repository where the component is hosted.\n    - Private catalog option: In GitLab.com, organizations can publish private components to the main catalog in GitLab.com, thereby creating a “private catalog” with content accessible only to authorized users. \n\n### GitLab.com vs. Self-managed\n- The “public” catalog in GitLab.com: The main catalog is the one that is hosted on GitLab.com and can be accessible to anyone by going to [gitlab.com/explore/catalog](http://gitlab.com/explore/catalog). The CI/CD Catalog is:\n    - Open access: The catalog hosted on GitLab.com is available for anyone to view.\n    - Contribute and grow: By sharing components, users around the world contribute to a growing library of resources that benefits the entire community.\n\n- Self-managed customers: The CI/CD Catalog is also available for self-managed customers however it has several differences: \n    - Empty catalog: For self-managed customers, the catalog initially appears empty since it doesn't contain any available components.\n    - Organizational catalog: Each organization is responsible for its own catalog, where it can create and maintain its own library of components within this flavor.\n    - Using a component from GitLab.com: If you want to use a component from the main catalog in GitLab.com, clone the project locally and publish it to your organizational catalog. Keep in mind that upstream updates will require mirroring to receive the latest changes. You can learn more about how to do that in our [CI/CD Components documentation](https://docs.gitlab.com/ee/ci/components/#use-a-gitlabcom-component-in-a-self-managed-instance).\n\n## What’s next?\n\nThe CI/CD Catalog is only the first step in revolutionizing the way you build and display your available pipelines. Here is a glimpse of what we plan to offer to our users in the upcoming milestones.\n\n### CI Steps\n\nSteps are reusable and composable pieces of a job that can be referenced in your pipeline configuration. Each step defines structured inputs and outputs that can be consumed by other steps. Steps can come from local files, GitLab.com repositories, or any other Git source.\n\nIn GitLab, we think of steps as another type of component. We are going to make sure CI Steps will become a first-class object in the CI/CD Catalog, where users can publish, unpublish, search, and consume steps in the same way as they are using components today.\n\n### Securing your catalog workflows\n\nWe aim to empower central administrators to manage component creation, usage, and publication within their organizational catalog. We are committed to ensuring the publishing process seamlessly integrates with the organization's standards and existing workflow. We want to enable the platform administrators with the capabilities to secure and govern the CI/CD Catalog and component workflows. More information can be found in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/12713).\n\n### Analytics\n\nOur goal is to empower users with seamless control over component management across pipelines, ensuring optimal version control and project alignment. This addresses the challenge of users currently lacking visibility into component usage across various project pipelines. Our objective is to provide users with the capability to swiftly identify outdated versions and take prompt corrective actions as needed. This enhancement will foster an environment where users can efficiently manage and update components, promoting both version control precision and project alignment. Read more in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/393326).\n\n## Get started with the CI/CD Catalog\n\nThe introduction of the CI/CD Catalog revolutionizes pipeline development by offering a vast array of pre-built components. Users don't have to start building pipelines from scratch because the CI/CD Catalog provides an access point to search components and pipeline configurations. The CI/CD Catalog's availability makes accessing and sharing components effortless, fostering collaboration and community growth. Whether utilizing public or private repositories, users can leverage these resources to enhance their pipeline development experience. Moreover, while GitLab.com users benefit from an open-access catalog, self-managed customers can establish organizational catalogs tailored to their needs.\n\n> [Get to know the CI/CD Catalog](https://about.gitlab.com/free-trial/devsecops/) with a free 30-day trial of GitLab Ultimate.\n\n> Learn more about the CI/CD Catalog and components:\n> \n> - [A CI/CD component builder's journey](https://about.gitlab.com/blog/a-ci-component-builders-journey/)\n>\n> - [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n>\n> - [Documentation: CI/CD components and CI/CD Catalog](https://docs.gitlab.com/ee/ci/components/)\n> \n> - [Introducing CI/CD components and how to use them in GitLab](https://about.gitlab.com/blog/introducing-ci-components/)\n> \n",[109,710,475,794],{"slug":2091,"featured":91,"template":674},"ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch","content:en-us:blog:ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch.yml","Ci Cd Catalog Goes Ga No More Building Pipelines From Scratch","en-us/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch.yml","en-us/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch",{"_path":2097,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2098,"content":2104,"config":2110,"_id":2113,"_type":16,"title":2114,"_source":17,"_file":2115,"_stem":2116,"_extension":20},"/en-us/blog/gitlab-16-8-release",{"title":2099,"description":2100,"ogTitle":2099,"ogDescription":2100,"noIndex":91,"ogImage":2101,"ogUrl":2102,"ogSiteName":784,"ogType":785,"canonicalUrls":2102,"schema":2103},"GitLab 16.8 Release","GitLab 16.8 released with GCP Secret Manager support and the ability to speed up your builds with the Maven dependency proxy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683452/Blog/Hero%20Images/Screenshot_2024-01-18_at_10.51.01_AM.png","https://about.gitlab.com/blog/gitlab-16-8-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 16.8 Release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jocelyn Eillis\"}],\n        \"datePublished\": \"2024-01-18\",\n      }",{"title":2099,"description":2100,"authors":2105,"heroImage":2101,"date":2107,"body":2108,"category":14,"tags":2109},[2106],"Jocelyn Eillis","2024-01-18","16.8 release page can be found [here](https://about.gitlab.com/releases/2024/01/18/gitlab-16-8-released/).",[752],{"slug":2111,"featured":6,"template":674,"externalUrl":2112},"gitlab-16-8-release","https://about.gitlab.com/releases/2024/01/18/gitlab-16-8-released/","content:en-us:blog:gitlab-16-8-release.yml","Gitlab 16 8 Release","en-us/blog/gitlab-16-8-release.yml","en-us/blog/gitlab-16-8-release",{"_path":2118,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2119,"content":2124,"config":2129,"_id":2131,"_type":16,"title":2132,"_source":17,"_file":2133,"_stem":2134,"_extension":20},"/en-us/blog/registration-features-program-expands-by-16-free-features",{"title":2120,"description":2121,"ogTitle":2120,"ogDescription":2121,"noIndex":6,"ogImage":1010,"ogUrl":2122,"ogSiteName":784,"ogType":785,"canonicalUrls":2122,"schema":2123},"Registration Features program expands by 16 free features","More features now available at no cost to free self-managed Enterprise Edition DevSecOps platform customers who register and turn on their Service Ping.","https://about.gitlab.com/blog/registration-features-program-expands-by-16-free-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Registration Features program expands by 16 free features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ian Pedowitz\"}],\n        \"datePublished\": \"2024-01-18\",\n      }",{"title":2120,"description":2121,"authors":2125,"heroImage":1010,"date":2107,"body":2127,"category":14,"tags":2128},[2126],"Ian Pedowitz","In GitLab 16.0 we [expanded](https://about.gitlab.com/blog/expanded-registration-features-program/) the [Registration Features program](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#registration-features-program), which offers free self-managed users running [GitLab Enterprise Edition](https://about.gitlab.com/enterprise/) free use of [paid features](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#available-features) by registering with GitLab and sending us activity data via Service Ping. In GitLab 16.5, 16.6, and 16.7 we’ve broadened the program to include the following 16 features:\n\n1. [Group wikis](https://docs.gitlab.com/ee/user/project/wiki/group.html): If you use GitLab groups to manage multiple projects, some of your documentation might span multiple groups. You can create group wikis, instead of [project wikis](https://docs.gitlab.com/ee/user/project/wiki/index.html), to ensure all group members have the correct access permissions to contribute.\n1. [Issue analytics](https://docs.gitlab.com/ee/user/group/issues_analytics/index.html): Issue analytics is a bar graph that illustrates the number of issues created each month. The default time span is 13 months, which includes the current month, and the 12 months prior. Issue analytics is available for projects and groups.\n1. [Custom text in emails](https://docs.gitlab.com/ee/administration/settings/email.html#custom-additional-text): You can add additional text at the bottom of any email that GitLab sends. This additional text can be used for legal, auditing, or compliance reasons.\n1. [Contribution analytics](https://docs.gitlab.com/ee/user/group/contribution_analytics/index.html): Contribution analytics provide an overview of the [contribution events](https://docs.gitlab.com/ee/user/profile/contributions_calendar.html#user-contribution-events) made by your group’s members.\n1. [Group file templates](https://docs.gitlab.com/ee/user/group/manage.html#group-file-templates): Use group file templates to share a set of templates for common file types with every project in a group. It is analogous to the [instance template repository](https://docs.gitlab.com/ee/administration/settings/instance_template_repository.html).\n1. [Group webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#group-webhooks): You can configure a group webhook, which is triggered by events that occur across all projects in the group and its subgroups.\n1. [Service Level Agreement countdown timer](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#service-level-agreement-countdown-timer): You can enable the SLA timer on incidents to track the SLAs you hold with your customers.\n1. [Lock project membership to group](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#prevent-members-from-being-added-to-projects-in-a-group): As a group Owner, you can prevent any new project membership for all projects in a group, allowing tighter control over project membership.\n1. [Users and permissions report](https://docs.gitlab.com/ee/administration/admin_area.html#user-permission-export): An administrator can export user permissions for all users in the GitLab instance from the Admin Area's Users page.\n1. [Advanced search](https://docs.gitlab.com/ee/user/search/advanced_search.html): You can use advanced search for faster, more efficient search across the entire GitLab instance.\n1. [Group DevOps Adoption](https://docs.gitlab.com/ee/user/group/devops_adoption/index.html): DevOps Adoption shows you how groups in your organization adopt and use the most essential features of GitLab.\n1. [Сross-project pipelines with artifacts dependencies](https://docs.gitlab.com/ee/ci/yaml/index.html#needsproject): Use `needs:project` to download artifacts from up to five jobs in other pipelines.\n1. [Feature flag related issues](https://docs.gitlab.com/ee/operations/feature_flags.html#feature-flag-related-issues): You can link related issues to a feature flag.\n1. [Merged results pipelines](https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipelines.html): A merged results pipeline is a type of [merge request pipeline](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html). It is a pipeline that runs against the results of the source and target branches merged together.\n1. [GitLab CI/CD for external repositories](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html): GitLab CI/CD can be used with [GitHub](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html), [Bitbucket Cloud](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/bitbucket_integration.html), or any other Git server, though there are some [limitations](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html#limitations).\n1. [Using GitLab CI/CD with a GitHub repository](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html): GitLab CI/CD can be used with GitHub.com and GitHub Enterprise by creating a [CI/CD project](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html) to connect your GitHub repository to GitLab.\n\nThe above 16 features join the eight features already available to the registration tier in GitLab 16.0 and [prior releases](https://about.gitlab.com/blog/expanded-registration-features-program/).\n\n## How to to participate in the Registration Features program\n\nIf you are interested in participating as a free self-managed user running GitLab Enterprise Edition, you can learn how from our documentation [how to turn on Service Ping](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#enable-or-disable-usage-statistics).",[109,794,14,838],{"slug":2130,"featured":6,"template":674},"registration-features-program-expands-by-16-free-features","content:en-us:blog:registration-features-program-expands-by-16-free-features.yml","Registration Features Program Expands By 16 Free Features","en-us/blog/registration-features-program-expands-by-16-free-features.yml","en-us/blog/registration-features-program-expands-by-16-free-features",{"_path":2136,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2137,"content":2143,"config":2148,"_id":2150,"_type":16,"title":2151,"_source":17,"_file":2152,"_stem":2153,"_extension":20},"/en-us/blog/gitlab-package-roadmap-for-2024",{"title":2138,"description":2139,"ogTitle":2138,"ogDescription":2139,"noIndex":6,"ogImage":2140,"ogUrl":2141,"ogSiteName":784,"ogType":785,"canonicalUrls":2141,"schema":2142},"GitLab Package roadmap for 2024","GitLab is launching new package and container registry features to help enterprise customers consolidate on GitLab for artifact management.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669103/Blog/Hero%20Images/AdobeStock_243118595.jpg","https://about.gitlab.com/blog/gitlab-package-roadmap-for-2024","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Package roadmap for 2024\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-01-16\",\n      }",{"title":2138,"description":2139,"authors":2144,"heroImage":2140,"date":2145,"body":2146,"category":14,"tags":2147},[748],"2024-01-16","_TLDR; In 2024, GitLab will deliver a dependency proxy for Maven, npm, PyPI, and NuGet (stretch). In addition, we'll expand the dependency proxy for containers to work with any external container registry, not just public Docker Hub accounts._\n\n2023 is nearly over. I'd like to take a minute to share some features for [GitLab Package](https://about.gitlab.com/stages-devops-lifecycle/package/) to look forward to in 2024. These new features will enable enterprise customers to consolidate on GitLab for artifact management, and help save money on licensing costs for JFrog/Sonatype and improve the developer experience.\n\n## Package registry\n\nAs the product manager for the Package stage, I have spent the past four years talking to customers and prospects about how they can replace their Artifactory or Sonatype instance with GitLab Package. Although we have helped many smaller organizations to consolidate on GitLab, it's been a challenge to help larger, more complex organizations to do so. Why? Because larger organizations typically need to pull packages from multiple repositories. Artifactory and Nexus offer a feature called virtual registries, which act as a single access point to download, install, or deploy artifacts in the same format from one or more upstream repositories.\n\nThis functionality can:\n- make pipelines faster\n- make pipelines more reliable\n- reduce the cost of data transfer because over time most packages will be pulled from the cache\n\nEach dependency proxy format will give users the ability to add/configure one external repository. \n\nOnce added, when a user tries to install a package using their project-level endpoint, GitLab will first look for the package in the project and, if it's not found, attempt to pull the package from the external repository.\n\nWhen a package is pulled from the external repository, it will be imported into the GitLab project so that the next time that particular package/version is pulled it's pulled from GitLab and not the external repository.\n\nIf the package is not found in their GitLab project or the external repository, GitLab will return an error.\n\n- This feature and all future dependency proxy formats will be in the Premium tier.\n- Project owners will be able to configure this via a project's settings (API or UI).\n- We will support external repositories that require authentication, such as Artifactory or Sonatype.\n\nTo support this theme, we will also likely need to invest in related features, such as those listed in the issues below, which focus on the performance of the registry or giving more fine-grained access control to customers:\n- [Add a dependency proxy scope for GitLab tokens](https://gitlab.com/gitlab-org/gitlab/-/issues/336800)\n- [Improve Package Registry metadata generation](https://gitlab.com/groups/gitlab-org/-/epics/9835)\n- [Package registry authentication token](https://gitlab.com/gitlab-org/gitlab/-/issues/328765)\n\n## Container registry\nToday, GitLab.com is supported by the next-generation container registry and we've seen many performance and reliability improvements.\n\nIn 2024, we will focus on:\n- Getting the [container registry to GA for self-managed customers](https://gitlab.com/groups/gitlab-org/-/epics/5521)\n- [Improving the UI/UX of the container registry](https://gitlab.com/groups/gitlab-org/-/epics/3211)\n- Adding support for [granular access protection for container registries](https://gitlab.com/groups/gitlab-org/-/epics/9825) and [immutable container image tags](https://gitlab.com/gitlab-org/container-registry/-/issues/82)\n- Adding an integration with Google Cloud Platform's Artifact Registry to help [make deploying container images from GitLab to GCP easy](https://gitlab.com/groups/gitlab-org/-/epics/11443)\n\nThis functionality will:\n- help customers to reduce their storage costs\n- make the container registry more performant and reliable\n- make the GitLab team more efficient (by avoiding maintaining two codebases)\n\nWe have exciting plans for 2024! Please follow along as we make the package and container registries more useful, easier to use, and more secure.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post 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 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._",[14,838,794,710],{"slug":2149,"featured":6,"template":674},"gitlab-package-roadmap-for-2024","content:en-us:blog:gitlab-package-roadmap-for-2024.yml","Gitlab Package Roadmap For 2024","en-us/blog/gitlab-package-roadmap-for-2024.yml","en-us/blog/gitlab-package-roadmap-for-2024",{"_path":2155,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2156,"content":2162,"config":2166,"_id":2169,"_type":16,"title":2170,"_source":17,"_file":2171,"_stem":2172,"_extension":20},"/en-us/blog/gitlab-16-7-release",{"title":2157,"description":2158,"ogTitle":2157,"ogDescription":2158,"noIndex":91,"ogImage":2159,"ogUrl":2160,"ogSiteName":784,"ogType":785,"canonicalUrls":2160,"schema":2161},"GitLab 16.7 Release","GitLab 16.7 released with general availability of GitLab Duo Code Suggestions and CI/CD Catalog in Beta.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683626/Blog/Hero%20Images/16_7-cover-image.png","https://about.gitlab.com/blog/gitlab-16-7-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 16.7 Release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jocelyn Eillis\"}],\n        \"datePublished\": \"2023-12-21\",\n      }",{"title":2157,"description":2158,"authors":2163,"heroImage":2159,"date":2164,"body":2165,"category":14},[2106],"2023-12-21","GitLab 16.7 released",{"slug":2167,"featured":91,"template":674,"externalUrl":2168},"gitlab-16-7-release","https://about.gitlab.com/releases/2023/12/21/gitlab-16-7-released/","content:en-us:blog:gitlab-16-7-release.yml","Gitlab 16 7 Release","en-us/blog/gitlab-16-7-release.yml","en-us/blog/gitlab-16-7-release",{"_path":2174,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2175,"content":2181,"config":2187,"_id":2189,"_type":16,"title":2190,"_source":17,"_file":2191,"_stem":2192,"_extension":20},"/en-us/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":2176,"description":2177,"ogTitle":2176,"ogDescription":2177,"noIndex":6,"ogImage":2178,"ogUrl":2179,"ogSiteName":784,"ogType":785,"canonicalUrls":2179,"schema":2180},"Tutorial: Automate releases and release notes with GitLab","With the GitLab Changelog API, you can automate the generation of release artifacts, release notes, and a comprehensive changelog detailing all user-centric software modifications.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Automate releases and release notes with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\",\n      }",{"title":2176,"description":2177,"authors":2182,"heroImage":2178,"date":2184,"body":2185,"category":14,"tags":2186,"updatedDate":813},[2183],"Ben Ridley","2023-11-01","***2025 update** - The Changelog API has continued to evolve and now has some great new capabilities we don’t cover in this blog, such as the ability to provide custom changelogs with templated values from your commit history. [Discover more in the official Changelogs docs.](https://docs.gitlab.com/user/project/changelogs/)*\n\nWhen you develop software that users rely on, effective communication about changes with each release is essential. By keeping users informed about new features and any modifications or removals, you ensure they maximize the software's benefits and avoid encountering unpleasant surprises during upgrades.\n\nHistorically, creating release notes and maintaining a changelog has been a laborious task, requiring developers to monitor changes externally or release managers to sift through merge histories. With the GitLab Changelog API, you can use the rich history provided in our git repository to easily create release notes and maintain a changelog.\n\nIn this tutorial, we'll delve into automating releases with GitLab, covering the generation of release artifacts, release notes, and a comprehensive changelog detailing all user-centric software modifications.\n\n## Releases in GitLab\nFirst, let's explore how releases work in GitLab.\n\nIn GitLab, a release is a specific version of your code, identified by a git tag, that includes details about changes since the last release (and release notes) and any related artifacts built from that version of the code, such as Docker images, installation packages, and documentation.\n\nYou can create and track releases in GitLab using the UI by calling our Release API or by defining a special `release` job inside a CI pipeline. In this tutorial, we'll use the `release` job in a CI/CD pipeline, which allows us to extend the automation we're using in our pipelines for testing, code scanning, etc. to also perform automated releases.\n\nTo automate our releases, we first need to answer this question: Where are we going to get the information on changes made for our release notes and our changelog? The answer: Our git repository, which provides us with a rich history of development activity through commit messages and merge commit history. Let's see if we can leverage this rich history to automatically create our notes and changelogs.\n\n## Introducing commit trailers\n[Commit trailers](https://git-scm.com/docs/git-interpret-trailers) are structured entries in your git commits, created by adding simple `\u003CHEADER>:\u003CBODY>` format messages to the end of your commit. The `git` CLI tool can then parse and extract these for use in other systems. An example you might have already used is `git commit --sign-off` to sign off on a commit. This is implemented by adding a `Signed-off-by: \u003CYour Name>` trailer to the commit. We can add any arbitrary structured data here, which makes it a great place to store information that could be useful for our changelog.\n\nIn fact, if we use a `Changelog: \u003Cadded/changed/removed>` trailer in our commits, the GitLab Changelog API will parse these and use them to create a changelog for us automatically!\n\nLet's see this in action by making some changes to a real codebase and performing a release, and generating release notes and changelog entries.\n\n## Our example project\nFor the purposes of this blog, I'm using a simple Python web app repository. Let's pretend Version 1.0.0 of the application was just released and is the current version of the code. I've also created a 1.0.0 release in GitLab, which I did manually because we haven't created our automated release pipeline yet:\n\n![A screenshot of the GitLab UI showing a release for Version 1.0.0](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n## Making our changes\nWe're in rapid development mode, so we're going to be working on releasing Version 2.0.0 of our application today. As part of our 2.0.0 release, we're going to be adding a new feature to our app: A chatbot! And we're also going to be removing the quantum blockchain feature, because we only needed that for our first venture capital funding round. Also, we're going to be adding an automated release job to our CI/CD pipeline for our 2.0.0 release.\n\nFirst, let's remove unneeded features. I've created a merge request that contains the necessary removals. Importantly, we need to ensure we have a commit message that includes the `Changelog: removed` trailer. There's a few ways to do this, such as including it directly in a commit, or performing an interactive rebase and adding it using the CLI. But I think the easiest way in our situation is to leave it until the end and then use the `Edit commit message` button in GitLab to add the trailer to the merge commit like so:\n\n![A screenshot the GitLab UI showing a merge request removing unused features](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\nIf you use this method, you can also change the merge commit title to something more succinct. I've changed the title of my merge commit to 'Remove Unused Features', as this is what will appear in the changelog entry.\n\nNext, let's add some new functionality for the 2.0.0 release. Again, all we need to do is open another merge request that includes our new features and then edit the merge commit to include the `Changelog: added` trailer and edit the commit title to be more succinct:\n\n![A screenshot of the GitLab UI showing a merge request to add new functionality](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png)\n\nNow we're pretty much ready to release 2.0.0. But we don't want to create our release manually this time. So before our release we're going to add some jobs to our `.gitlab-ci.yml` file that will perform the release for us automatically, and generate the respective release notes and changelog entries, when we tag our code with a new version like `2.0.0`.\n\n**Note:** If you want to enforce changelog trailers, consider using something like [Danger to perform automated checks for MR conventions](https://docs.gitlab.com/ee/development/dangerbot.html).\n\n## Building an automated release pipeline\nFor our pipeline to work, we need to create a project access token that will allow us to call GitLab's API to generate changelog entries. [Create a project access token with the API scope](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token), and then [store the token as a CI/CD variable](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui) called `CI_API_TOKEN`. We'll reference this variable to authenticate to the API.\n\nNext, we're going to add two new jobs to our `gitlab-ci.yml` file:\n```yaml\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\nIn the above configuration, the `prepare_job` uses `curl` and `jq` to call the GitLab Changelog API endpoint and then passes this to our `release_job` to actually create the release. To break it down further:\n- We use the project access token created earlier to call the GitLab Changelog API, which performs the generation of the release notes and we store this as an artifact.\n- We're using the `$CI_COMMIT_TAG` variable as the version. For this to work, we need to be using semantic versioning for our tags (something like `2.0.0` for example), so you'll notice I've also restricted the release job using a `rules` section that checks for a semantic version tag.\n\t- Semantic versioning is required for the GitLab Changelog API to work. It uses this format to find the most recent release to compare to our current release.\n- We use the official `release-cli` image from GitLab. The release-cli is required to use the `release` keyword in a job.\n- We use the `release` keyword to create a release in GitLab. This is a special job keyword reserved for creating a release and populating the required fields.\n- We can pass a file as an argument to the `description` of the release. In our case, it's the file we generated in the `prepare_job`, which was passed to this job as an artifact.\n- We've also included our container image that is being built earlier in the pipeline as a release asset. You can attach any assets you'd like from your build process, such as binaries or documentation by providing a URL to wherever you've uploaded them earlier in the pipeline.\n\n## Performing an automated release\nWith this setup, all we need to do to perform a release is push a tag to our repository that follows our versioning scheme. You can simply push a tag using the CLI, this example uses GitLab's UI to create a tag on the main branch. Create a tag by selecting Code -> Tags -> New Tag on the sidebar:\n![A screenshot of the GitLab UI illustrating how to create a tag](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\nOn creation, our pipelines will start to execute. The GitLab Changelog API will automatically generate release notes for us as markdown, which contains all the changes between this release and the previous release. Here's the resulting markdown generated in our example:\n\n```md\n## 2.0.0 (2023-08-25)\n\n### added (1 change)\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n### removed (1 change)\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n```\n\nAs you can see, GitLab has extracted the entries for our release notes automatically using our git commit trailers. In addition, it's helpfully provided links back to the merge request so readers can see more details and discussion around the changes.\n\nAnd now, our final release:\n![The GitLab release UI showing a release for version 2.0.0](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n## Creating the changelog\nNext, we want to update our changelog (which is basically a collated history of all your release notes). You can use a `POST` request to the changelog API endpoint we used earlier to do this.\n\nYou can do this as part of your release pipeline if you like, for example by adding this to the `script` section of your prepare job:\n```sh\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n```\n\n**Note that this will actually modify the repository.** It will create a commit to add the latest notes to a `CHANGELOG.md` file:\n![A screenshot of the repository which shows a commit updating the changelog file](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\nAnd we are done! By utilizing the rich history provided by `git` with some handy commit trailers, we can leverage GitLab's powerful API and CI/CD pipelines to automate our release process and generate release notes for us.\n\n> If you’d like to explore the project we used for this article, [you can find the project at this link](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo).\n",[671,859,109,1781,710,711],{"slug":2188,"featured":6,"template":674},"tutorial-automated-release-and-release-notes-with-gitlab","content:en-us:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","en-us/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","en-us/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":2194,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2195,"content":2201,"config":2207,"_id":2209,"_type":16,"title":2210,"_source":17,"_file":2211,"_stem":2212,"_extension":20},"/en-us/blog/contributions-to-git-2-42-release",{"title":2196,"description":2197,"ogTitle":2196,"ogDescription":2197,"noIndex":6,"ogImage":2198,"ogUrl":2199,"ogSiteName":784,"ogType":785,"canonicalUrls":2199,"schema":2200},"Git 2.42 release: Here are four of our contributions in detail","Find out how GitLab's Git team helped improve Git 2.42.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667792/Blog/Hero%20Images/git-241.jpg","https://about.gitlab.com/blog/contributions-to-git-2-42-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git 2.42 release: Here are four of our contributions in detail\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2023-10-12\",\n      }",{"title":2196,"description":2197,"authors":2202,"heroImage":2198,"date":2204,"body":2205,"category":14,"tags":2206},[2203],"Christian Couder","2023-10-12","\n\n[Git 2.42](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.42.0.txt)\nwas officially released on August 21, 2023, and included some\nimprovements from GitLab's Git team. Git is the foundation of\nrepository data at GitLab. GitLab's Git team works on new features, performance improvements, documentation improvements,\nand growing the Git community. Often our contributions to Git have a\nlot to do with the way we integrate Git into our services at\nGitLab.\n\nWe previously shared [some of our improvements that were included in the Git 2.41 release](https://about.gitlab.com/blog/contributions-to-latest-git-release/). Here are some highlights from the Git 2.42 release, and a\nwindow into how we use Git on the server side at GitLab.\n\n## 1. Prevent certain refs from being packed\n\n### Write-ahead logging\nIn [Gitaly](https://docs.gitlab.com/ee/administration/gitaly/), we\nwant to use a [write-ahead log](https://gitlab.com/groups/gitlab-org/-/epics/8911)\nto replicate Git operations on different machines.\n\nThis means that the Git objects and references that should be changed\nby a Git operation are first kept in a log entry. Then, when all the\nmachines have agreed that the operation should proceed, the log entry\nis applied so the corresponding Git objects and references are\nactually added to the repositories on all the machines.\n\n### Need for temporary references\nBetween the time when a specific log entry is first written and when\nit is applied, other log entries could be applied which could remove\nsome objects and references. It could happen that these objects and\nreferences are needed to apply the specific log entry though.\n\nSo when we log an entry, we have to make sure that all the objects and\nreferences that it needs to be properly applied will not be removed\nuntil that entry is either actually applied or discarded.\n\nThe best way to make sure things are kept in Git is to create new Git\nreferences pointing to these things. So we decided to use temporary\nreferences for that purpose. They would be created when a log entry is\nwritten, and then deleted when that entry is either applied or\ndiscarded.\n\n### Packed-refs performance\nGit can store references in \"loose\" files, with one reference per\nfile, or in the `packed-refs` file, which contains many of them. The\n`git pack-refs` command is used to pack some references from \"loose\"\nfiles into the `packed-refs` file.\n\nFor reading a lot of references, the `packed-refs` file is very\nefficient, but for writing or deleting a single reference, it is not\nso efficient as rewriting the whole `packed-refs` file is required.\n\nAs temporary references are to be created and then deleted soon after,\nstoring them in the `packed-refs` file would not be efficient. It\nwould be better to store them in \"loose\" files.\n\nThe `git pack-refs` command had no way to be told precisely which refs\nshould be packed or not though. By default it would repack all the\ntags (which are refs in `refs/tags/`) and all the refs that are\nalready packed. With the `--all` option one could tell it to repack\nall the refs except the hidden refs, broken refs, and symbolic refs,\nbut that was the only thing that could be controlled.\n\n### Improving `git pack-refs`\nWe decided to improve `git pack-refs` by adding two new options to it:\n  - `--include \u003Cpattern>` which can be used to specify which refs should be packed\n  - `--exclude \u003Cpattern>` which can be used to specify which refs should not be packed\n\n[John Cai](https://gitlab.com/jcaigitlab), Gitaly:Git team engineering manager, implemented these options.\n\nFor example, if the refs managed by the write-ahead log are in\n`refs/wal/`, it's now possible the exclude them from being moved into\nthe `packed-refs` file by using:\n\n```\n$ git pack-refs --exclude \"refs/wal/*\"\n```\n\nDetails of the patch series, including discussions, can be found\n[here](https://lore.kernel.org/git/pull.1501.git.git.1683215331910.gitgitgadget@gmail.com/).\n\n## 2. Get machine-readable output from `git cat-file --batch`\n\n### Efficiently retrieving Git object information\nIn GitLab, we often retrieve Git object information. For example, when a\nuser navigates into the files and directories in a repository, we need\nto get the content of the corresponding Git blobs and trees so that\nwe can show it.\n\nIn Gitaly, we use `git cat-file` to retrieve Git object information\nfrom a Git repository. As it's a frequent operation, it needs to be\nperformed efficiently, so we use the batch modes of `git cat-file`\navailable through the `--batch`, `--batch-check` and `--batch-command`\noptions.\n\nIn these modes, a pointer to a Git object can be repeatedly sent to\nthe standard input, called 'stdin', of a `git cat-file` command, while\nthe corresponding object information is read from the standard ouput,\ncalled 'stdout' of the command. This way we don't need to launch a\nnew `git cat-file` command for each object.\n\nGitLab can keep, for example, a `git cat-file --batch-command` process\nrunning in the background while feeding it commands like\n`info \u003Cobject>` or `contents \u003Cobject>` through its stdin to\nget either information about an object or its content.\n\n### Newlines in stdin, stdout, and filenames\nThe commands or pointers to Git objects that are sent through stdin\nshould be delimited using newline characters, and in the same way `git\ncat-file` will use newline characters to delimit the information from\ndifferent Git objects in its output. This is a common shell practice\nto make it easy to chain commands together. For example, one can\neasily get the size (in bytes) of the last three commits on the current\nbranch using the following:\n\n```\n$ git log -3 --format='%H' | git cat-file --batch-check='%(objectsize)'\n285\n646\n428\n```\n\nSometimes, though, the pointer to a Git object can contain a filename\nor a directory name, as such a pointer is allowed to be in the form\n`\u003Cbranch>:\u003Cpath>`. For example `HEAD:Documentation` is a valid\npointer to the blob or the tree corresponding to the `Documentation`\npath on the current branch.\n\nThis used to be an issue because on some systems newline characters\nare allowed in file or directory names. So the `-z` option was\nintroduced last year in Git 2.38 to allow users to change the input\ndelimiter in batch modes to the NUL character.\n\n### Error output\nWhen the `-z` option was introduced, it wasn't considered useful to\nchange the output delimiter to be also the NUL character. This is\nbecause only tree objects can contain paths and the internal format\nof tree objects already uses NUL characters to delimit paths.\n\nUnfortunately, it was overlooked that in case of an error the pointer\nto the object is displayed in the error message:\n\n```\n$ echo 'HEAD:does-not-exist' | git cat-file --batch\nHEAD:does-not-exist missing\n```\n\nAs the error messages are printed along with the regular ouput of the\ncommand on stdout, passing in an invalid pointer with a number of\nnewline characters in it could make it very difficult to parse the\noutput.\n\n### -Z comes to the rescue\n[Toon Claes](https://gitlab.com/toon), Gitaly senior engineer, initially worked on a\npatch to just quote the pointer in the error message, but it was\ndecided in the Git mailing list discussions related to the patch that\nit would be better to just create a new `-Z` option. This option would\nchange both the input and the output delimiter to the NUL character,\nwhile the old `-z` option would be deprecated over time.\n\nSo [Patrick Steinhardt](https://gitlab.com/pks-gitlab), Gitaly staff engineer, implemented that new `-Z` option.\n\nDetails of the patch series, including discussions, can be found\n[here](https://lore.kernel.org/git/20221209150048.2400648-1-toon@iotcl.com/)\nand [here](https://lore.kernel.org/git/cover.1685710884.git.ps@pks.im/).\n\n## 3. Pass pseudo-options to `git rev-list --stdin`\n\n### Computing sizes\nIn GitLab, we need to have different ways to compute the size of Git\nrelated content. For example, we need to know:\n  - how much disk space a repository is using\n  - how big a specific Git object is\n  - how much additional space on a repository is required by a\n    specific set of revisions (and the objects they reference)\n\nKnowing \"how much disk space a repository is using\" is useful to\nenforce repository-related quotas and is easy to get using regular\nshell and OS features.\n\nSize information about a specific Git object is useful to enforce\nquotas related to maximum file size. It can be obtained using, for\nexample, `git cat-file -s \u003Cobject>` or\n`echo \u003Cobject> | git cat-file --batch-check='%(objectsize)'`\nas already seen above.\n\nComputing the space required by a set of revisions is useful, too, as\nforks can share Git content in what we call\n\"[pool repositories](https://docs.gitlab.com/ee/development/git_object_deduplication.html),\"\nand we want to discriminate how much content belongs to each forked\nrepository. Fortunately, `git rev-list` has a `--disk-usage` option\nfor this purpose.\n\n### Passing arguments to `git rev-list`\n`git rev-list` can take a number of different arguments and has a lot\nof different options. It's a fundamental command to traverse commit\ngraphs, and it should be flexible enough to fulfill a lot of different\nuser needs.\n\nWhen repositories grow, they often store a lot of references and a lot\nof files and directories, so there is often the need to pass a big\nnumber of references or paths as arguments to the\ncommand. References and paths can be quite long though.\n\nTo avoid hitting platform limits related to command line length, long\nago, a `--stdin` mode was added that allowed users to pass revisions\nand paths through stdin, instead of as command line\narguments. However, when that was implemented, it was not considered\nnecessary to allow options or pseudo-options, like `--not`,\n`--glob=...`, or `--all` to be passed through stdin.\n\nThis appeared to be a problem for GitLab, as for computing sizes for\nforked repositories we needed some of the pseudo-options, and it would\nhave been intricate and possibly buggy to pass some of them and their\narguments as arguments on the command line while others were passed\nthrough stdin.\n\n### Allowing pseudo-options\nTo fix this issue, Patrick Steinhardt implemented a small patch series to\nallow pseudo-options through stdin.\n\nWith it, in Git 2.42, one can now pass pseudo-options, like `--not`,\n`--glob=...`, or `--all` through stdin when the `--stdin` mode is used.\n\nDetails of the patch series, including discussions, can be found\n[here](https://lore.kernel.org/git/cover.1686744685.git.ps@pks.im/).\n\n## 4. Code and test improvements\nWhile looking at some Git code, we are often tempted to modify nearby\ncode, either to change only its style when the code is ancient and it\nwould look better using Git's current code style, or to refactor it to\nmake it cleaner. This is why we sometimes send small patch series that\ndon't have a real GitLab related purpose.\n\nIn Git 2.42, examples of style code improvements we made are the\n[part1](https://lore.kernel.org/git/pull.1513.git.git.1684440205.gitgitgadget@gmail.com/)\nand\n[part2](https://lore.kernel.org/git/pull.1514.git.git.1684599239.gitgitgadget@gmail.com/)\ntest code modernization patches from John Cai.\n\nAnd [here](https://lore.kernel.org/git/cover.1684324059.git.ps@pks.im/) is\nan example of a refactoring to cleanup some code by Patrick Steinhardt.\n",[711,838,672,267],{"slug":2208,"featured":6,"template":674},"contributions-to-git-2-42-release","content:en-us:blog:contributions-to-git-2-42-release.yml","Contributions To Git 2 42 Release","en-us/blog/contributions-to-git-2-42-release.yml","en-us/blog/contributions-to-git-2-42-release",{"_path":2214,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2215,"content":2221,"config":2228,"_id":2230,"_type":16,"title":2231,"_source":17,"_file":2232,"_stem":2233,"_extension":20},"/en-us/blog/browser-based-dast-feature-announcement",{"title":2216,"description":2217,"ogTitle":2216,"ogDescription":2217,"noIndex":6,"ogImage":2218,"ogUrl":2219,"ogSiteName":784,"ogType":785,"canonicalUrls":2219,"schema":2220},"Introducing browser-based DAST and integrated passive checks","We're working hard on reducing noise. Here's what you need to know about the status of our browser-based DAST offering today.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682466/Blog/Hero%20Images/vek-labs-e8ofKlNHdsg-unsplash.jpg","https://about.gitlab.com/blog/browser-based-dast-feature-announcement","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing browser-based DAST and integrated passive checks\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Isaac Dawson\"}],\n        \"datePublished\": \"2022-10-19\",\n      }",{"title":2216,"description":2217,"authors":2222,"heroImage":2218,"date":2224,"body":2225,"category":14,"tags":2226},[2223],"Isaac Dawson","2022-10-19","\n\nThe [DAST](/direction/secure/dynamic-analysis/dast/) and [Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/) teams at GitLab are excited to announce we have fully [integrated passive checks](/releases/2022/08/22/gitlab-15-3-released/#browser-based-dast-passive-check-milestone) into our new [browser-based DAST analyzer](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html). Passive checks work by monitoring the network traffic to target applications while the web site is automatically crawled. This allows us to identify weaknesses that may exist without sending potentially disruptive network requests. This continues our effort to fully switch over to our browser-based analyzer for DAST in the coming months. If you are interested in using our new DAST analyzer please see our [documentation on how to configure a browser-based DAST scan](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html).\n\n## History of DAST at GitLab\n\nDAST was [officially launched](/releases/2018/01/22/gitlab-10-4-released/) as a part of the GitLab 10.4 release in January 2018. By utilizing the powerful OWASP [Zed Attack Proxy](https://www.zaproxy.org/) we were able to give our customers the ability to dynamically scan\ntheir web applications. From that initial minimal viable product, we have grown to the point where we are now running over a million scans a month.\n\nScanning web applications in the CI/CD context comes with challenges. Unlike [SAST](/direction/secure/static-analysis/sast/), which is relatively fast, dynamically scanning an application can take a significant amount of time. DAST is resource intensive as it needs to process each request and response to the target application. To ensure smooth operations for the majority of our customers we have to run under the assumption that our memory and CPU footprints should be as small as possible. Finally, and most likely the biggest pain point, is the disconnect that often occurs when trying to visualize or understand how a web application should be analyzed when one can not physically see any of the interactions between the scanner and the target application.\n\nZAP was originally built as a desktop application, meaning auditors could use it to see the target application while conducting their testing. Only by utilizing ZAP's scripting API could we make DAST scans viable in a CI/CD context. This surfaced some challenges: what is easy to configure in the UI may or may not be straightforward to adjust from a configuration file or a command line option. \n\nWhen reviewing our support tickets however, a very clear picture began to surface. Users were having the most problem with configuring authentication for their applications. This makes sense, as it is where the user interacts with the scanner the most. Modern applications almost require a browser to authenticate, due to relying on browser features like local or session storage. These features are commonly used for handling JSON Web Token (JWT) based authentication and authorization. \n\nIt should be noted that ZAP does have a browser based crawler extension, called AJAX Spider. This extension uses [Crawljax](https://github.com/crawljax/crawljax). GitLab provides this feature by supplying the correct CI/CD variable, but it is no longer recommended. AJAX Spider is however, only an extension, and does not represent a tight integration between the browser and the DAST tool. \n\n## A path forward\n\nWe needed a system where we could have full control over a browser to allow us to instrument interactions between a website and the DAST tool. A DAST tool which does not tightly integrate with a browser will be limited in its ability to fully interact with today's demanding web applications. Just some of the challenges of this are:\n\n- Single Page Applications (SPAs)\n- Complex, multi-step sign in features\n- Complex front-end frameworks  \n- Utilization of built-in browser features (e.g. usage of localStorage or sessionStorage) \n\nA new DAST tool based completely off instrumenting a browser and written in Go would give GitLab a lot more control going forward. What started as a side project during nights and weekends began to show some promise. The Vulnerability Research and DAST teams worked together to assess the viability of building out this DAST analyzer. To allow us to take advantage of new features without having to implement the entire engine, we opted to continue to use ZAP as the proxy. This means our analyzer is forwarding all the browser traffic through ZAP, but processing logic of crawling and passive checks are now done in our engine. While we've been relatively quiet on our progress, we've been incrementally rolling out new features with almost every release. The end goal is to completely replace ZAP with our own engine.\n\n## Where we are today\n\nOf course the biggest announcement is that we have fully switched over to using our own vulnerability check system for passive checks. These checks replace ZAP's \"passive\" checks. The Vulnerability Research team invested a lot of time looking over how each ZAP plugin worked and determined whether it was worth implementing, or if it should be implemented differently. Alert fatigue is a real concern we share with our customers. By reducing the noise (false positives) in our DAST offering, we hope to reduce the chance of our customers ignoring real findings. As such, our goal is to significantly reduce the noise that is usually associated with DAST scan results, and this is achieved through three different methods:\n\n1. Not implementing certain checks\n2. Reducing false positives (incorrect findings) \n3. Aggregating true positives (real findings)\n\nPoint one is worth expanding upon. DAST vulnerabilities are unique in that in some cases the fix for a vulnerability is reliant on the browser or user-agent being modified, and not  the target application. Browsers increase their security directly or have it increased by deprecating features that were used in attacks. Browsers deciding to disable Flash is a good example of this – what was a vulnerability yesterday may no longer be a vulnerability today. \n\nZAP's check for [Charset mis-match](https://www.zaproxy.org/docs/alerts/90011/) is another case in point. After [researching](https://gitlab.com/gitlab-org/gitlab/-/issues/331218) what was possible in 2022, it turns out this is no longer an issue worth reporting. Other DAST tools report similar issues that are no longer realistically exploitable or worth reporting, so this is not just an issue with ZAP. \n\nReducing false positives is another major initiative, and one that led us to create a rather unique system for creating new vulnerability checks. Traditionally, DAST tools use a plugin architecture of hardcoded vulnerability checks. While quick to implement, they can have the downside of being difficult to understand or error prone. They are also harder to implement in a standardized way. At GitLab we opted to use a configuration-file-based check system, much like today's SAST tools. \n\nFinally, aggregating true positives allows us to merge similar issues into a single finding. These types of issues are usually fixed by a single configuration change, such as adding a security header.\n\nOur passive checks are almost entirely written in YAML, using a custom specification that allows us to define a check as text. Where this is not feasible, reusable components are written that can be referenced by various checks. Below is an example check that looks for the `X-Content-Type-Options` header in HTTP response headers and reports if it is missing the `nosniff` value.\n\n```yaml\n",[2227,794,1659],"testing",{"slug":2229,"featured":6,"template":674},"browser-based-dast-feature-announcement","content:en-us:blog:browser-based-dast-feature-announcement.yml","Browser Based Dast Feature Announcement","en-us/blog/browser-based-dast-feature-announcement.yml","en-us/blog/browser-based-dast-feature-announcement",{"_path":2235,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2236,"content":2242,"config":2247,"_id":2249,"_type":16,"title":2250,"_source":17,"_file":2251,"_stem":2252,"_extension":20},"/en-us/blog/new-machine-types-for-gitlab-saas-runners",{"title":2237,"description":2238,"ogTitle":2237,"ogDescription":2238,"noIndex":6,"ogImage":2239,"ogUrl":2240,"ogSiteName":784,"ogType":785,"canonicalUrls":2240,"schema":2241},"GitLab introduces new machine types for GitLab SaaS Linux Runners","GitLab SaaS now offers larger machine types for running CI jobs on Linux.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672836/Blog/Hero%20Images/multiple-machine-types-cover.png","https://about.gitlab.com/blog/new-machine-types-for-gitlab-saas-runners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab introduces new machine types for GitLab SaaS Linux Runners\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Eastman\"}],\n        \"datePublished\": \"2022-09-22\",\n      }",{"title":2237,"description":2238,"authors":2243,"heroImage":2239,"date":2244,"body":2245,"category":14,"tags":2246},[1943],"2022-09-22","\nOur GitLab SaaS vision is to provide a solution where you can easily choose and use the correct type of public cloud-hosted compute resources for your CI/CD jobs. In this first iteration towards achieving that vision, we are pleased to announce that two larger compute machines are generally available for GitLab SaaS Runners on Linux.\n\nWith these two machine types, you can now access more choices for your GitLab SaaS CI/CD jobs. And with 100% job isolation on an ephemeral virtual machine, and security and autoscaling fully managed by GitLab, you can confidently run your critical [CI/CD](/topics/ci-cd/) jobs on GitLab SaaS.\n\n## New machine type details\n\nThe new [SaaS Runners on Linux](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html) are a 2 vCPU, 8GB RAM (`saas-linux-medium-amd64`), and a 4 vCPU, 16GB RAM (`saas-linux-large-amd64`) machine type. These machine types, powered by the latest generation of Google Compute N2D virtual machines, deliver significant performance improvements for general-purpose CI workloads. The medium machine type, `saas-linux-medium-amd64`,  is available to all subscriptions (Free, Premium, Ultimate). The large machine type, `saas-linux-large-amd64` is only available to paid plans (Premium and Ultimate) and GitLab for Open Source program members.\n\nNote: If you are in a Free plan and tag a CI job with the large machine type, `saas-linux-large-amd64`, you will get an error at the job level and the job will not run.\n\n```\nThis job is stuck because of one of the following problems. There are no active runners online, no runners for the protected branch, or no runners that match all of the job's tags: saas-linux-large-amd64\n\n```\n\n## Are the new machine types right for my CI job?\n\nThe answer is that it depends. If the CI job is compute-intensive, you will likely see a performance improvement measured by reduced build times. We ran a series of  [Linux kernel](https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-stress/linux-kernel) builds on the medium machine type to test the potential performance gains for compute-intensive CI jobs.\n\n![Linux kernel build CI job execution time benchmark](https://about.gitlab.com/images/blogimages/new-machine-types-gitlab-saas-linux/linux-kernel-build-runner-saas-benchmark_2022-09-22.png)\n\nOur testing found an average 41% reduction in CI job execution time for the medium machine types compared to the baseline small machine type. We recommend you experiment with the new machine types for your CI jobs to determine the right choice based on your build workflows.\n\n## Getting started\n\nTo get started with the new machine types, simply add a tag to your CI file. Without the tag, a job in your pipeline will automatically run on the small machine type.\n\n### Example pipeline configuration\n\nIn this example pipeline configuration, `job_001` will run on the default Linux SaaS Runner as no machine type tag is defined. The subsequent job, `job_002`, in the build stage will run on the medium machine type, and `job_003` will run on the large machine type. So you have flexibility within a GitLab CI/CD pipeline to choose the right machine type for each job.\n\n```\nstages:\n  - Prebuild\n  - Build\n  - Unit Test\n\njob_001:\n stage: Prebuild\n script:\n  - echo \"this job runs on the default (small) machine type\"\n\njob_002:\n tags: [ saas-linux-medium-amd64 ]\n stage: Build\n script:\n  - echo \"this job runs on the medium machine type\"\n\njob_003:\n tags: [ saas-linux-large-amd64 ]\n stage: Unit Test\n script:\n  - echo \"this job runs on the large machine type\"\n\n```\n\n## Understanding the new machine types and cost factors\n\nYou can start using the new machine types now with the CI minutes currently available in your plan. The new machine types will consume your CI minutes at a different rate than the default (small) machine type based on an applied cost factor. If you are a GitLab for Open Source program member, then refer to the [cost factor documentation page](https://docs.gitlab.com/ee/ci/pipelines/cicd_minutes.html#cost-factor) for details on how cost factors are applied to your CI/CD jobs.\n\n|  | saas-linux-small-amd64 |saas-linux-medium-amd64 |saas-linux-large-amd64 |\n| ------ | ------ |------ |------ |\n| CI minutes consumed per 1 minute of build time| 1 |2|3|\n\nToday your CI minutes usage report on GitLab SaaS will be an aggregate of all of the CI minutes consumed across all the machine types you select in your jobs. In this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/356076), we are working towards adding visibility into usage by each Runner type. So you will soon have more granular reporting of use across the various Runner classes (Linux, Windows, macOS) and machine types we plan to offer.\n\n## Feedback\n\nAt GitLab, we value your input and use it as a critical sensing mechanism in planning roadmap investments. To provide feedback on the machine types you need on GitLab SaaS Runners on Linux, add a comment to the respective comment thread in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/373196)\n\nCover image by [Julian Hochgesang](https://unsplash.com/@julianhochgesang) on [Unsplash](https://unsplash.com)\n{: .note}\n",[859,860,2069,14],{"slug":2248,"featured":6,"template":674},"new-machine-types-for-gitlab-saas-runners","content:en-us:blog:new-machine-types-for-gitlab-saas-runners.yml","New Machine Types For Gitlab Saas Runners","en-us/blog/new-machine-types-for-gitlab-saas-runners.yml","en-us/blog/new-machine-types-for-gitlab-saas-runners",{"_path":2254,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2255,"content":2261,"config":2268,"_id":2270,"_type":16,"title":2271,"_source":17,"_file":2272,"_stem":2273,"_extension":20},"/en-us/blog/three-faces-of-user-calls",{"title":2256,"description":2257,"ogTitle":2256,"ogDescription":2257,"noIndex":6,"ogImage":2258,"ogUrl":2259,"ogSiteName":784,"ogType":785,"canonicalUrls":2259,"schema":2260},"How product managers can get more out of user calls","There are 3 types of user calls. Here's how GitLab product managers approach them and how we leverage our transparency value to better understand our users.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682372/Blog/Hero%20Images/michal-czyz-ALM7RNZuDH8-unsplash.jpg","https://about.gitlab.com/blog/three-faces-of-user-calls","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How product managers can get more out of user calls\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n        \"datePublished\": \"2022-07-20\",\n      }",{"title":2256,"description":2257,"authors":2262,"heroImage":2258,"date":2263,"body":2264,"category":14,"tags":2265},[1358],"2022-07-20","\n\nOne of the core jobs of product managers is to speak with users to better understand their needs, pain points and the context in which they operate and use our products. But not all user calls are the same. \n\nThere are 3 prominent types of user calls:\n\n- Discovery or problem validation calls\n- Roadmap discussions\n- Solution validation calls\n\nHere's an in-depth look at how we approach the three types of user calls at GitLab.\n\n## Discovery calls\n\nDiscovery or problem validation calls are product managers' most crucial conversations with users. Discovery calls are typically set up to learn about our users in a targeted way. These calls help build a better understanding of users' pain points. \n\nFor discovery, we need a recipe for repeatable, comparable user calls. For this reason, we should create an interview script and follow that script on all the user calls. This does not mean these calls are robotic and devoid of improvisation, not at all! The script should provide the backbone of the discussions. We can adjust it either during the call or in advance based on prior knowledge about the user. Good discovery calls typically take the form of a deep-dive conversation: we know the script by heart and can run back and forth around it, always asking the questions that fit the conversation. \n\nFinding the right users is one of the most challenging parts of discovery calls. Thankfully, with GitLab, this is relatively easy. We can always reach out to the most active users on issues and invite them to a call. Another technique I employ is to find users in the [Cloud Native Computing Foundation](https://www.cncf.io) and Kubernetes communities' Slack channels and articles on [Medium](https://medium.com). This way, I can also find non-GitLab users, a set of people likely more valuable to interview than existing users. Finally, we can recruit users with the support of the account managers. They are always helpful in connecting PMs with users. Asking the users about their needs shows them that we genuinely care about them.\n\nThere are at least two distinct discovery calls: PM-led or UX-led. UX research typically works on projects with a strict scope. For PM-driven calls, a great framework is [\"Continuous discovery\" calls by Teresa Torres](https://www.producttalk.org/continuous-discovery/). With continuous discovery, we build a deep understanding of our users and get well-understood opportunities. The technique allows us to get a broad view and to dive deep into specific aspects of our problem space when needed.\n\n## Roadmap discussions\n\nRoadmap discussion calls are typically initiated by sales or account management teams. Product managers are asked to join the prospect/customer call to strengthen our positions and show how much we care for the customer. \n\nTo prepare for roadmap discussions, PMs should have an effective way to present the roadmap. This typically happens in the form of slides. A diligent PM might even prepare something specifically for the client.\n\nDuring these calls, the user/customer/prospect will typically ask the questions, and the PMs respond. Our role in these calls is to represent the truth. We might be tempted to paint a rosier picture about the current or expected state of the product than is actually true, and we should avoid making time-bound promises.\n\nWhat are the expected outcomes of roadmap discussions? They can help strengthen our position with the user. Remember that these calls primarily cater to our customers/users and customer-facing teams. As such, they are unlikely to provide deep learning about our users. \n\nIf we approach these calls with the intention to prove that our roadmap is correct, we will likely fall victim to both response and confirmation biases. There are techniques to validate a roadmap, but they are more aligned with problem validation than roadmap discussion calls. For example, UX researchers should be able to help validate a roadmap as a UX research project.\n\n## Solution validation calls\n\nLast but not least, we have solution validation calls. These calls serve our learning but are way more focused than discovery calls. Solution validation calls require some form of a prototype for a specific problem we want to test and get feedback on from our users.\n\nAt GitLab, the prototypes are typically built by product design or engineering. The product manager might miss some of these calls in an empowered and autonomous team. But, as these calls are great learning experiences, we should aim to be there to support and learn if we can.\n\nA solution validation call might be started with a concise roadmap discussion. Unlike in sales calls, our aim is not to influence the user but to set the scene for solution validation. The central part of the call should be around the proposed solution. We should provide the least amount of guidance to our users since there are no humans available to direct our users when they are working with the actual product. If much guidance is required, that is a sign that we might want to rethink our UX approach.\n\nFinding suitable interview candidates for a solution validation call might be tricky. For GitLab, we often use the shortcut of inviting users based on their activity on relevant issues. Sometimes, when our issues provide enough context, we might get some solution validation asynchronously as users give their feedback directly in the issue.\n\n## How many calls?\n\nHow often does a good PM have all these calls? For discovery calls, I aim to have 3 calls per week. Above this, I don’t mind taking 1 sales call. While I prefer the product designer to run solution validation calls, I try to participate there too. Not every solution requires dedicated validation, so having a target number for solution validation calls is unrealistic. The better the discovery calls are, the fewer solution validation calls you might need. Still, even the best discovery cannot and should not answer all the questions of a solution validation. Often there are different (and totally valid) approaches to the same problem, and we need to pick the one that is the easiest for users to understand.\n\nI think we need to speak to our users every day. Working at GitLab, sometimes this might take the form of issue comments, but face-to-face calls are a must. In any case, during these discussions we should aim to learn from our users, not just answer their questions. A handy question in issues is to ask for more context from our users. The response might highlight unknown use cases or edge cases we missed previously.\n\n## Take the calls\n\nIt is helpful to remember all the user call types we practice as PMs. As mentioned, I think the most crucial user calls for PMs are the discovery calls. If we don’t make discovery calls, nobody will; also, PMs might not be needed in the other calls. That said, a product manager's job is to also help the business be viable. So we should be able to support sales and always have a deck ready for roadmap calls. Lastly, we should work continuously with our team on solution validation so that everyone is confident in our solution.\n\n",[1781,2266,2267],"customers","contributors",{"slug":2269,"featured":6,"template":674},"three-faces-of-user-calls","content:en-us:blog:three-faces-of-user-calls.yml","Three Faces Of User Calls","en-us/blog/three-faces-of-user-calls.yml","en-us/blog/three-faces-of-user-calls",{"_path":2275,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2276,"content":2282,"config":2289,"_id":2291,"_type":16,"title":2292,"_source":17,"_file":2293,"_stem":2294,"_extension":20},"/en-us/blog/gitlab-ux-2020-year-in-review",{"title":2277,"description":2278,"ogTitle":2277,"ogDescription":2278,"noIndex":6,"ogImage":2279,"ogUrl":2280,"ogSiteName":784,"ogType":785,"canonicalUrls":2280,"schema":2281},"GitLab UX 2020 Year in Review","2020 was a difficult but productive year. Let's take a look back.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/gitlab-ux-2020-year-in-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab UX 2020 Year in Review\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2020-11-20\",\n      }",{"title":2277,"description":2278,"authors":2283,"heroImage":2279,"date":2285,"body":2286,"category":14,"tags":2287},[2284],"Christie Lenneville","2020-11-20","\nA global pandemic and broad social unrest have made this year difficult for everyone. When times are as tough as 2020 has proven to be, it's easy to focus on the negative and forget about the many good things that happened along the way. But our product designers, user researchers, and technical writers spend every day doing great work, and we can't let that slip by unnoticed. \n\nIn this post, I want to be intentional about celebrating our successes during a year when many of us wanted to just curl up under a comfy blanket and wait for the turmoil to pass. So, let's take a moment to reflect on some of the things we can feel really proud to have achieved.\n\n## Usability is now a key consideration in our category maturity model\n\nHistorically, we rated the [maturity](https://about.gitlab.com/direction/maturity/) of our product areas fairly subjectively and based almost entirely on feature availability. This year, that changed when we introduced [Category Maturity Scorecards](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) that are based on user research. Now, we start by considering the Job to be Done (JTBD) that our users need to accomplish, and we gather user feedback to rate the entire experience -- not just functionality, but usability, too. \n\nWe've learned some amazing things through this new approach, and those learnings have enabled us to make [valuable recommendations](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name%5B%5D=cm-scorecard-rec) to improve our product experience in areas like Code Review, Logging, and Issue Management. We have several additional scorecard initiatives underway, which means that our focus on creating an exceptional experience will only continue to grow. \n\nSo often, UX departments complain that they have to fight for executives to acknowledge the importance of usability on business outcomes. In this case, refining category maturity started as an idea from [Sid](https://gitlab.com/sytses), our CEO. This is honestly amazing! It's the kind of user-centered focus that UX teams get really excited about.\n\nAs the person who leads UX at GitLab, it was awesome for me to watch our cross-functional team immediately get on board. Because measuring product maturity isn't an industry standard, through our value of [Iteration](https://handbook.gitlab.com/handbook/values/#iteration) it took us some time (and a false start) to determine the right approach. Fortunately, Product leadership was both enthusiastic and patient, UX Researchers were persistent in taking feedback and making methodological refinements, and Product Designers were courageous in trying something they've never done before. Even better: Technical Writing has been involved, too, as we've identified documentation improvements that will refine our product maturity. \n\nThis was truly a team effort, and I appreciate everyone who participated. 🤝\n\n## Our design system evolved from an idea into reality\n\nWhen I joined GitLab in early 2019, our design system, [Pajamas](https://design.gitlab.com/), was a scrappy project that the design team was working hard to get off the ground. We had designed a set of 28 single-source-of-truth components and were working hard to build them into [GitLab UI](https://gitlab.com/gitlab-org/gitlab-ui), our Vue-based component library.\nWe now have a robust design library that's implemented in Figma, and a large collection of SSOT Vue components are available to use in the product, too. Even more exciting: We're just finishing with implementing our 8 most impactful components across the entire product UI (buttons, alerts, dropdowns, modals, tabs, popovers, and tooltips), which will result in better performance and consistency when we're done. (We're so close!)\n\nMost amazing to me was watching product designers and technical writers jump in to do much of this component migration work themselves. This was no small feat, because frontend development is not something that many of us are deeply skilled at. But, apparently we're both tenacious and brave, because we did the work anyway (with lots of help from our Frontend Engineers and the awesome documentation that our UX Foundations team created). In the process, we've gotten to know both our product features (which are complex) and our code base (which is also complex) even better, which makes us more effective in our day-to-day jobs.\n\nSpeaking of our UX Foundations team, this is another related success. At the beginning of 2020, we got the budgetary support to create a team that is dedicated solely to maintaining our design system and tooling. The team may be small, but its impact certainly isn't. They've already made some big improvements to things like:\n\n* **Improving tooling for designers:** The move to Figma allows for greater collaboration, as well as community contributions. Sketch is only available on Mac platforms and there are no real-time collaboration features. Figma allows us to provide a UI Kit that is available across platforms, while being available for community contributors to use for free. It also promotes collaboration through its use of real-time editing capabilities and version history. We were able to streamline developer handoff by simply linking to the design file, reducing the need for additional plugins such as Sketch Measure.\n* **Making our color palette consistent and accessible:** We addressed color contrast for accessibility and normalized the palette across hues, so that we can better systematize variable use throughout the UI.\n* **Improving consistency in our icons:** With the creation of our own [SVG Library](http://gitlab-org.gitlab.io/gitlab-svgs/), we've been working to [deprecate our use of Font Awesome](https://gitlab.com/groups/gitlab-org/-/epics/2331) throughout the year. With the help of the Frontend department, we've closed out 156 out of 168 issues related to this effort.\n* **Moving towards more accessible workflows:** Near the end of the year, we've started focusing more on building accessibility standards into our workflows. We are currently auditing and updating our [voluntary product accessibility template](https://design.gitlab.com/accessibility/vpat), as well as [incorporating accessibility audit guides](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2158) into Pajamas.\n\n## Actionable insights\n\nUser research is so incredibly valuable... when you take action on it. But it can be a challenge for research teams to condense their powerful findings into small but compelling insights and then track those insights to determine whether they actually make it into the product.\n\nIn the second half of this year, our user research team made two big strides in this area. First, we started using [Dovetail](https://dovetailapp.com/) to help us more easily analyze research data to find meangingful insights and share it collaboratively with Product Managers and Product Designers (and anyone else who may be interested). But, they took this a step farther by also beginning to [track actionable insights](https://about.gitlab.com/handbook/product/ux/performance-indicators/#actionable-insights) as a performance indicator.\n\nThe considerable effort it took to get both of these programs in place will be worth it as we watch our research efforts result in an even better product.\n\n## Beautifying our docs\n\nComplex products like GitLab require high-quality documentation. Some things you just can't (and shouldn't) communicate through the UI, so users rely on great docs to get their daily jobs done.\n\nOur Technical Writing team (many of whom have been with GitLab less than a year) worked hard to improve our docs site during 2020, including:\n\n- Several UX research projects to discover - and fix! - problems users encounter when using the docs site.\n- A \"Beautification\" effort that focused on an updated visual design. Our 2020 GitLab Contribute event included many rapid improvements to the docs site, and we made many more afterward. (Did you notice?)\n- Ongoing content improvements, including making our docs more consistent, findable, detailed, and easier to read.\n- Adding (a lot of) metadata information to product docs to help connect content contributors with Technical Writers.\n- Coding innovations for automation, such as grammar checking with Vale, a linter, to automatically catch errors before they’re merged.\n\nWe’ve also completed work on a Docs Strategy roadmap to drive even more improvements in the upcoming months.  \n\n## And so much more...\n\n* GitLab Design Talks: In this fun video series, watch designers, technical writers, researchers, and product managers talk about [Iteration](https://www.youtube.com/playlist?list=PL05JrBw4t0KpgzLWbRCXf8o7iap-uoe7o) and [Collaboration](https://www.youtube.com/playlist?list=PL05JrBw4t0KrER807JktsL-addVZa4N0-) at GitLab. (Special thanks to host [Nick Post](https://gitlab.com/npost)!)\n* UX Showcase: See [100+ videos](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz) highlighting exciting UX work happening across GitLab. I learn something new everytime I watch one of these.\n* Blog posts: Read about a variety of topics we were thinking about in 2020, including:\n    * [Designing in an all-remote company](https://about.gitlab.com/blog/designing-in-an-all-remote-company/)\n    * [Running an asynchronous sketching workshop for UX](https://about.gitlab.com/blog/async-sketching/)\n    * [Synchronous collaboration as a remote designer at GitLab](https://about.gitlab.com/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab/)\n    * [A tale of two file editors](https://about.gitlab.com/blog/a-tale-of-two-editors/)\n    * [How holistic UX design increased GitLab.com free trial signups](https://about.gitlab.com/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups/)\n    * [Improving iteration and collaboration with user stories](https://about.gitlab.com/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool/)\n    * [Designing incident management from scratch](https://about.gitlab.com/blog/designing-alerts-and-incidents/) \n    * [Why GitLab is the right design collaboration tool for the entire team ](https://about.gitlab.com/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team/)\n\nAgain, the GitLab UX team does amazing work every single day, and there is no way to capture all of that effort in a single blog post. As this year wraps up, I hope you personally take time to think about your own successes and the impact they had on our fast-moving company. \n\nI also hope you know that we value every one of you. You are appreciated. 💜\n\n{::options parse_block_html=\"true\" /}\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n  \u003Cp class=\"panel-heading\">\u003Cstrong>One more thing...\u003C/strong>\u003C/p>\n\u003Cdiv class=\"panel-body\">\n\n\u003Cp>The final 2020 highlight I wanted to ensure is here was Christie Lenneville's own promotion to be GitLab's first \u003Cstrong>Vice President of User Experience (UX)\u003C/strong>. I knew that as both the author of this article, and as a humble (and great) leader she'd be hesitant to add this herself. But it's not only a recognition of her achievements and her potential. VP-level leadership of UX at GitLab should \u003Ci>also\u003C/i> be a signal of how important UX is to our organization and to our community. And it should indicate that usability is an important differentiator for GitLab, and a critical part of our company's strategy. Congratulations again, Christie!\u003C/p>\n\n— Eric Johnson, Chief Technology Officer\n\n\u003C/div>\n\u003C/div>\n\n{::options parse_block_html=\"false\" /}\n",[1220,1219,2288,837],"inside GitLab",{"slug":2290,"featured":6,"template":674},"gitlab-ux-2020-year-in-review","content:en-us:blog:gitlab-ux-2020-year-in-review.yml","Gitlab Ux 2020 Year In Review","en-us/blog/gitlab-ux-2020-year-in-review.yml","en-us/blog/gitlab-ux-2020-year-in-review",9,[681,700,720,739,760,777,801,823,845],1751548582820]