[{"data":1,"prerenderedAt":1924},["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. Join us June 24.",{"text":437,"config":438},"Register 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":1922,"initialPosts":1923},{"_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/reduce-the-load-on-gitlab-gitaly-with-bundle-uri",{"noIndex":6,"title":662,"description":663},"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":662,"description":663,"heroImage":665,"date":666,"body":667,"category":14,"tags":668,"authors":671},"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,669,670],"DevSecOps","git",[672],"Olivier Campeau",{"featured":6,"template":674,"slug":675},"BlogPost","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",[681,700,721,745,768,790,812,835,855,876,896,916,935,954,976,997,1016,1037,1058,1076,1096,1115,1135,1155,1174,1195,1215,1236,1254,1275,1294,1314,1333,1354,1373,1394,1414,1434,1454,1474,1494,1515,1536,1556,1577,1598,1619,1638,1659,1678,1698,1719,1740,1758,1777,1796,1816,1837,1858,1878,1899],{"_path":682,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":683,"content":686,"config":694,"_id":696,"_type":16,"title":697,"_source":17,"_file":698,"_stem":699,"_extension":20},"/en-us/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":684,"title":685},"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":685,"description":684,"body":687,"category":14,"tags":688,"authors":689,"heroImage":692,"date":693},"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,669],[690,691],"Mike Flouton","Andy Bradfield","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png","2025-06-23",{"featured":91,"template":674,"slug":695},"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":701,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":702,"content":705,"config":714,"_id":717,"_type":16,"title":718,"_source":17,"_file":719,"_stem":720,"_extension":20},"/en-us/blog/gitlab-18-1-released",{"noIndex":6,"title":703,"description":704},"GitLab 18.1 released","This release includes Maven virtual registry (beta), Duo Code Review, compromised password detection, and SLSA level 1 with components.",{"heroImage":706,"title":703,"description":707,"authors":708,"date":710,"body":711,"category":14,"tags":712},"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.",[709],"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/).",[713,14],"releases",{"featured":91,"template":674,"slug":715,"externalUrl":716},"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":722,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":723,"content":731,"config":739,"_id":741,"_type":16,"title":742,"_source":17,"_file":743,"_stem":744,"_extension":20},"/en-us/blog/ai-native-gitlab-premium-transform-higher-education-software-development",{"title":724,"description":725,"ogTitle":724,"ogDescription":725,"noIndex":6,"ogImage":726,"ogUrl":727,"ogSiteName":728,"ogType":729,"canonicalUrls":727,"schema":730},"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":724,"description":725,"authors":732,"heroImage":726,"date":735,"body":736,"category":14,"tags":737},[733,734],"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,738,184],"features",{"slug":740,"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":746,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":747,"content":753,"config":762,"_id":764,"_type":16,"title":765,"_source":17,"_file":766,"_stem":767,"_extension":20},"/en-us/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"title":748,"description":749,"ogTitle":748,"ogDescription":749,"noIndex":6,"ogImage":750,"ogUrl":751,"ogSiteName":728,"ogType":729,"canonicalUrls":751,"schema":752},"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":748,"description":749,"authors":754,"heroImage":750,"date":757,"body":758,"category":14,"tags":759},[755,756],"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,760,738,761],"tutorial","embedded DevOps",{"slug":763,"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":769,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":770,"content":776,"config":784,"_id":786,"_type":16,"title":787,"_source":17,"_file":788,"_stem":789,"_extension":20},"/en-us/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"title":771,"description":772,"ogTitle":771,"ogDescription":772,"noIndex":6,"ogImage":773,"ogUrl":774,"ogSiteName":728,"ogType":729,"canonicalUrls":774,"schema":775},"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":771,"description":772,"authors":777,"heroImage":773,"date":779,"body":780,"category":14,"tags":781},[778],"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/).*",[782,14,783,475],"research","news",{"slug":785,"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":791,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":792,"content":798,"config":806,"_id":808,"_type":16,"title":809,"_source":17,"_file":810,"_stem":811,"_extension":20},"/en-us/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"title":793,"description":794,"ogTitle":793,"ogDescription":794,"noIndex":6,"ogImage":795,"ogUrl":796,"ogSiteName":728,"ogType":729,"canonicalUrls":796,"schema":797},"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":793,"description":794,"authors":799,"heroImage":795,"date":801,"body":802,"category":14,"tags":803},[800],"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,760,804,805,109,738],"CI","CD",{"slug":807,"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":813,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":814,"content":820,"config":828,"_id":831,"_type":16,"title":832,"_source":17,"_file":833,"_stem":834,"_extension":20},"/en-us/blog/gitlab-patch-release-18-0-1-17-11-3-17-10-7",{"title":815,"description":816,"ogTitle":815,"ogDescription":816,"noIndex":6,"ogImage":817,"ogUrl":818,"ogSiteName":728,"ogType":729,"canonicalUrls":818,"schema":819},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","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":815,"description":816,"authors":821,"heroImage":817,"date":823,"body":824,"category":14,"tags":825},[822]," Rohit Shambhuni","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",[826,827],"security releases","patch releases",{"slug":829,"featured":6,"template":674,"externalUrl":830},"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":836,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":837,"content":843,"config":849,"_id":851,"_type":16,"title":852,"_source":17,"_file":853,"_stem":854,"_extension":20},"/en-us/blog/gitlab-dedicated-for-government-now-fedramp-authorized",{"title":838,"description":839,"ogTitle":838,"ogDescription":839,"noIndex":6,"ogImage":840,"ogUrl":841,"ogSiteName":728,"ogType":729,"canonicalUrls":841,"schema":842},"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":838,"description":839,"authors":844,"heroImage":840,"date":846,"body":847,"category":14,"tags":848},[845,734],"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,738,783,14,184],{"slug":850,"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":856,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":857,"content":863,"config":869,"_id":872,"_type":16,"title":873,"_source":17,"_file":874,"_stem":875,"_extension":20},"/en-us/blog/gitlab-18-released",{"title":858,"description":859,"ogTitle":858,"ogDescription":859,"noIndex":6,"ogImage":860,"ogUrl":861,"ogSiteName":728,"ogType":729,"canonicalUrls":861,"schema":862},"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":858,"description":859,"authors":864,"heroImage":860,"date":866,"body":867,"category":14,"tags":868},[865],"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/).",[713,14],{"slug":870,"featured":6,"template":674,"externalUrl":871},"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":877,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":878,"content":884,"config":890,"_id":892,"_type":16,"title":893,"_source":17,"_file":894,"_stem":895,"_extension":20},"/en-us/blog/gitlab-premium-with-duo",{"title":879,"description":880,"ogTitle":879,"ogDescription":880,"noIndex":6,"ogImage":881,"ogUrl":882,"ogSiteName":728,"ogType":729,"canonicalUrls":882,"schema":883},"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":879,"description":880,"authors":885,"heroImage":881,"date":866,"body":887,"category":14,"tags":888},[886],"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",[889,475,783,738,14],"AI/ML",{"slug":891,"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":897,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":898,"content":903,"config":909,"_id":912,"_type":16,"title":913,"_source":17,"_file":914,"_stem":915,"_extension":20},"/en-us/blog/gitlab-patch-release-17-11-2-17-10-6-17-9-8",{"title":899,"description":900,"ogTitle":899,"ogDescription":900,"noIndex":6,"ogImage":817,"ogUrl":901,"ogSiteName":728,"ogType":729,"canonicalUrls":901,"schema":902},"GitLab Patch Release: 17.11.2, 17.10.6, 17.9.8","Learn more about this patch release for GitLab Community Edition (CE) and Enterprise Edition (EE).","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":899,"description":900,"authors":904,"heroImage":817,"date":906,"body":907,"category":14,"tags":908},[905],"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/).",[827,826],{"slug":910,"featured":6,"template":674,"externalUrl":911},"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":917,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":918,"content":923,"config":929,"_id":931,"_type":16,"title":932,"_source":17,"_file":933,"_stem":934,"_extension":20},"/en-us/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":919,"description":920,"ogTitle":919,"ogDescription":920,"noIndex":6,"ogImage":795,"ogUrl":921,"ogSiteName":728,"ogType":729,"canonicalUrls":921,"schema":922},"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":919,"description":920,"authors":924,"heroImage":795,"date":926,"body":927,"category":14,"tags":928},[925],"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,804,805,475,14,760],{"slug":930,"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":936,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":937,"content":941,"config":947,"_id":950,"_type":16,"title":951,"_source":17,"_file":952,"_stem":953,"_extension":20},"/en-us/blog/gitlab-patch-release-17-11-1-17-10-5-17-9-7",{"title":938,"description":900,"ogTitle":938,"ogDescription":900,"noIndex":6,"ogImage":817,"ogUrl":939,"ogSiteName":728,"ogType":729,"canonicalUrls":939,"schema":940},"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":938,"description":900,"authors":942,"heroImage":817,"date":944,"body":945,"category":14,"tags":946},[943]," 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).",[827],{"slug":948,"featured":6,"template":674,"externalUrl":949},"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":955,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":956,"content":962,"config":970,"_id":972,"_type":16,"title":973,"_source":17,"_file":974,"_stem":975,"_extension":20},"/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"title":957,"description":958,"ogTitle":957,"ogDescription":958,"noIndex":6,"ogImage":959,"ogUrl":960,"ogSiteName":728,"ogType":729,"canonicalUrls":960,"schema":961},"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":957,"description":958,"authors":963,"heroImage":959,"date":967,"body":968,"category":14,"tags":969},[964,965,966],"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":971,"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":977,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":978,"content":984,"config":990,"_id":993,"_type":16,"title":994,"_source":17,"_file":995,"_stem":996,"_extension":20},"/en-us/blog/gitlab-17-11-released",{"title":979,"description":980,"ogTitle":979,"ogDescription":980,"noIndex":6,"ogImage":981,"ogUrl":982,"ogSiteName":728,"ogType":729,"canonicalUrls":982,"schema":983},"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":979,"description":980,"authors":985,"heroImage":981,"date":987,"body":988,"category":14,"tags":989},[986],"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/).",[713],{"slug":991,"featured":6,"template":674,"externalUrl":992},"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":998,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":999,"content":1003,"config":1009,"_id":1012,"_type":16,"title":1013,"_source":17,"_file":1014,"_stem":1015,"_extension":20},"/en-us/blog/gitlab-patch-release-17-10-4-17-9-6-17-8-7",{"title":1000,"description":900,"ogTitle":1000,"ogDescription":900,"noIndex":6,"ogImage":817,"ogUrl":1001,"ogSiteName":728,"ogType":729,"canonicalUrls":1001,"schema":1002},"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":1000,"description":900,"authors":1004,"heroImage":817,"date":1006,"body":1007,"category":14,"tags":1008},[1005],"Costel Maxim","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).",[826,827],{"slug":1010,"featured":6,"template":674,"externalUrl":1011},"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":1017,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1018,"content":1024,"config":1030,"_id":1033,"_type":16,"title":1034,"_source":17,"_file":1035,"_stem":1036,"_extension":20},"/en-us/blog/gitlab-patch-release-17-9-5",{"title":1019,"description":1020,"ogTitle":1019,"ogDescription":1020,"noIndex":6,"ogImage":1021,"ogUrl":1022,"ogSiteName":728,"ogType":729,"canonicalUrls":1022,"schema":1023},"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":1019,"description":1020,"authors":1025,"heroImage":1021,"date":1027,"body":1028,"category":14,"tags":1029},[1026],"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.",[827],{"slug":1031,"featured":6,"template":674,"externalUrl":1032},"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":1038,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1039,"content":1045,"config":1052,"_id":1054,"_type":16,"title":1055,"_source":17,"_file":1056,"_stem":1057,"_extension":20},"/en-us/blog/improving-oauth-ropc-security-on-gitlab-com",{"title":1040,"description":1041,"ogTitle":1040,"ogDescription":1041,"noIndex":6,"ogImage":1042,"ogUrl":1043,"ogSiteName":728,"ogType":729,"canonicalUrls":1043,"schema":1044},"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":1040,"description":1041,"authors":1046,"heroImage":1042,"date":1048,"body":1049,"category":14,"tags":1050},[1047],"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,1051,475],"security",{"slug":1053,"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":1059,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1060,"content":1064,"config":1069,"_id":1072,"_type":16,"title":1073,"_source":17,"_file":1074,"_stem":1075,"_extension":20},"/en-us/blog/gitlab-patch-release-17-10-1-17-9-3-17-8-6",{"title":1061,"description":900,"ogTitle":1061,"ogDescription":900,"noIndex":6,"ogImage":817,"ogUrl":1062,"ogSiteName":728,"ogType":729,"canonicalUrls":1062,"schema":1063},"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":1061,"description":900,"authors":1065,"heroImage":817,"date":1066,"body":1067,"category":14,"tags":1068},[943],"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.",[826],{"slug":1070,"featured":6,"template":674,"externalUrl":1071},"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":1077,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1078,"content":1084,"config":1089,"_id":1092,"_type":16,"title":1093,"_source":17,"_file":1094,"_stem":1095,"_extension":20},"/en-us/blog/gitlab-17-10-released",{"title":1079,"description":1080,"ogTitle":1079,"ogDescription":1080,"noIndex":6,"ogImage":1081,"ogUrl":1082,"ogSiteName":728,"ogType":729,"canonicalUrls":1082,"schema":1083},"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":1079,"description":1080,"authors":1085,"heroImage":1081,"date":1086,"body":1087,"category":14,"tags":1088},[709],"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/).",[713],{"slug":1090,"featured":91,"template":674,"externalUrl":1091},"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":1097,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1098,"content":1103,"config":1109,"_id":1111,"_type":16,"title":1112,"_source":17,"_file":1113,"_stem":1114,"_extension":20},"/en-us/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"title":1099,"description":1100,"ogTitle":1099,"ogDescription":1100,"noIndex":6,"ogImage":795,"ogUrl":1101,"ogSiteName":728,"ogType":729,"canonicalUrls":1101,"schema":1102},"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":1099,"description":1100,"authors":1104,"heroImage":795,"date":1105,"body":1106,"category":14,"tags":1107},[925],"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,760,14,1108,109],"agile",{"slug":1110,"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":1116,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1117,"content":1122,"config":1128,"_id":1131,"_type":16,"title":1132,"_source":17,"_file":1133,"_stem":1134,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-17-9-2-17-8-5-17-7-7",{"title":1118,"description":1119,"ogTitle":1118,"ogDescription":1119,"noIndex":6,"ogImage":817,"ogUrl":1120,"ogSiteName":728,"ogType":729,"canonicalUrls":1120,"schema":1121},"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":1118,"description":1119,"authors":1123,"heroImage":817,"date":1125,"body":1126,"category":14,"tags":1127},[1124],"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/).",[826],{"slug":1129,"featured":6,"template":674,"externalUrl":1130},"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":1136,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1137,"content":1143,"config":1149,"_id":1151,"_type":16,"title":1152,"_source":17,"_file":1153,"_stem":1154,"_extension":20},"/en-us/blog/build-and-run-containers-in-remote-development-workspaces",{"title":1138,"description":1139,"ogTitle":1138,"ogDescription":1139,"noIndex":6,"ogImage":1140,"ogUrl":1141,"ogSiteName":728,"ogType":729,"canonicalUrls":1141,"schema":1142},"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":1138,"description":1139,"authors":1144,"heroImage":1140,"date":1146,"body":1147,"category":14,"tags":1148},[1145],"Vishal Tak","2025-03-03","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",[760,475,738,14],{"slug":1150,"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":1156,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1157,"content":1162,"config":1167,"_id":1170,"_type":16,"title":1171,"_source":17,"_file":1172,"_stem":1173,"_extension":20},"/en-us/blog/gitlab-patch-release-17-9-1-17-8-4-17-7-6",{"title":1158,"description":1159,"ogTitle":1158,"ogDescription":1159,"noIndex":6,"ogImage":817,"ogUrl":1160,"ogSiteName":728,"ogType":729,"canonicalUrls":1160,"schema":1161},"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":1158,"description":1159,"authors":1163,"heroImage":817,"date":1164,"body":1165,"category":14,"tags":1166},[1005],"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",[826],{"slug":1168,"featured":6,"template":674,"externalUrl":1169},"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":1175,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1176,"content":1182,"config":1188,"_id":1191,"_type":16,"title":1192,"_source":17,"_file":1193,"_stem":1194,"_extension":20},"/en-us/blog/gitlab-17-9-released",{"title":1177,"description":1178,"ogTitle":1177,"ogDescription":1178,"noIndex":6,"ogImage":1179,"ogUrl":1180,"ogSiteName":728,"ogType":729,"canonicalUrls":1180,"schema":1181},"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":1177,"description":1178,"authors":1183,"heroImage":1179,"date":1185,"body":1186,"category":14,"tags":1187},[1184],"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/).",[713],{"slug":1189,"featured":91,"template":674,"externalUrl":1190},"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":1196,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1197,"content":1203,"config":1209,"_id":1211,"_type":16,"title":1212,"_source":17,"_file":1213,"_stem":1214,"_extension":20},"/en-us/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":1198,"description":1199,"ogTitle":1198,"ogDescription":1199,"noIndex":6,"ogImage":1200,"ogUrl":1201,"ogSiteName":728,"ogType":729,"canonicalUrls":1201,"schema":1202},"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":1198,"description":1199,"authors":1204,"heroImage":1200,"date":1205,"body":1206,"category":14,"tags":1207},[709],"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",[669,760,1208],"solutions architecture",{"slug":1210,"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":1216,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1217,"content":1223,"config":1230,"_id":1232,"_type":16,"title":1233,"_source":17,"_file":1234,"_stem":1235,"_extension":20},"/en-us/blog/certificate-based-kubernetes-integration-sunsetting-on-gitlab-com",{"title":1218,"description":1219,"ogTitle":1218,"ogDescription":1219,"noIndex":6,"ogImage":1220,"ogUrl":1221,"ogSiteName":728,"ogType":729,"canonicalUrls":1221,"schema":1222},"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":1218,"description":1219,"authors":1224,"heroImage":1220,"date":1226,"body":1227,"category":14,"tags":1228,"updatedDate":967},[1225],"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,1229,14,475],"kubernetes",{"slug":1231,"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":1237,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1238,"content":1242,"config":1247,"_id":1250,"_type":16,"title":1251,"_source":17,"_file":1252,"_stem":1253,"_extension":20},"/en-us/blog/gitlab-patch-release-17-8-2-17-7-4-17-6-5",{"title":1239,"description":1159,"ogTitle":1239,"ogDescription":1159,"noIndex":6,"ogImage":817,"ogUrl":1240,"ogSiteName":728,"ogType":729,"canonicalUrls":1240,"schema":1241},"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":1239,"description":1159,"authors":1243,"heroImage":817,"date":1244,"body":1245,"category":14,"tags":1246},[822],"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/).",[713,826],{"slug":1248,"featured":6,"template":674,"externalUrl":1249},"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":1255,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1256,"content":1262,"config":1269,"_id":1271,"_type":16,"title":1272,"_source":17,"_file":1273,"_stem":1274,"_extension":20},"/en-us/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"title":1257,"description":1258,"ogTitle":1257,"ogDescription":1258,"noIndex":6,"ogImage":1259,"ogUrl":1260,"ogSiteName":728,"ogType":729,"canonicalUrls":1260,"schema":1261},"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":1257,"description":1258,"authors":1263,"heroImage":1259,"date":1266,"body":1267,"category":14,"tags":1268},[1264,1265],"Benjamin Skierlak","James Wormwell","2025-01-28","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.",[805,109,738,14,760],{"slug":1270,"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":1276,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1277,"content":1283,"config":1288,"_id":1290,"_type":16,"title":1291,"_source":17,"_file":1292,"_stem":1293,"_extension":20},"/en-us/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features",{"title":1278,"description":1279,"ogTitle":1278,"ogDescription":1279,"noIndex":6,"ogImage":1280,"ogUrl":1281,"ogSiteName":728,"ogType":729,"canonicalUrls":1281,"schema":1282},"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":1278,"description":1279,"authors":1284,"heroImage":1280,"date":1285,"body":1286,"category":14,"tags":1287},[733],"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/blog/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",[669,475,738,14,1051],{"slug":1289,"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":1295,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1296,"content":1302,"config":1308,"_id":1310,"_type":16,"title":1311,"_source":17,"_file":1312,"_stem":1313,"_extension":20},"/en-us/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability",{"title":1297,"description":1298,"ogTitle":1297,"ogDescription":1298,"noIndex":6,"ogImage":1299,"ogUrl":1300,"ogSiteName":728,"ogType":729,"canonicalUrls":1300,"schema":1301},"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":1297,"description":1298,"authors":1303,"heroImage":1299,"date":1305,"body":1306,"category":14,"tags":1307},[1304],"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",[669,475,738,783,109,184],{"slug":1309,"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":1315,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1316,"content":1320,"config":1326,"_id":1329,"_type":16,"title":1330,"_source":17,"_file":1331,"_stem":1332,"_extension":20},"/en-us/blog/gitlab-patch-release-17-8-1-17-7-3-17-6-4",{"title":1317,"description":900,"ogTitle":1317,"ogDescription":900,"noIndex":6,"ogImage":817,"ogUrl":1318,"ogSiteName":728,"ogType":729,"canonicalUrls":1318,"schema":1319},"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":1317,"description":900,"authors":1321,"heroImage":817,"date":1323,"body":1324,"category":14,"tags":1325},[1322],"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/).",[826,827],{"slug":1327,"featured":6,"template":674,"externalUrl":1328},"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":1334,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1335,"content":1341,"config":1347,"_id":1350,"_type":16,"title":1351,"_source":17,"_file":1352,"_stem":1353,"_extension":20},"/en-us/blog/gitlab-17-8-released",{"title":1336,"description":1337,"ogTitle":1336,"ogDescription":1337,"noIndex":6,"ogImage":1338,"ogUrl":1339,"ogSiteName":728,"ogType":729,"canonicalUrls":1339,"schema":1340},"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":1336,"description":1337,"authors":1342,"heroImage":1338,"date":1344,"body":1345,"category":14,"tags":1346},[1343],"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/).",[713,14],{"slug":1348,"featured":91,"template":674,"externalUrl":1349},"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":1355,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1356,"content":1361,"config":1366,"_id":1369,"_type":16,"title":1370,"_source":17,"_file":1371,"_stem":1372,"_extension":20},"/en-us/blog/gitlab-patch-release-17-7-2",{"title":1357,"description":1358,"ogTitle":1357,"ogDescription":1358,"noIndex":6,"ogImage":1021,"ogUrl":1359,"ogSiteName":728,"ogType":729,"canonicalUrls":1359,"schema":1360},"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":1357,"description":1358,"authors":1362,"heroImage":1021,"date":1363,"body":1364,"category":14,"tags":1365},[925],"2025-01-15","This is the post for Patch Release 17.7.2 for GitLab Community Edition and Enterprise Edition.",[827],{"slug":1367,"featured":6,"template":674,"externalUrl":1368},"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":1374,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1375,"content":1381,"config":1387,"_id":1390,"_type":16,"title":1391,"_source":17,"_file":1392,"_stem":1393,"_extension":20},"/en-us/blog/gitlab-17-7-released",{"title":1376,"description":1377,"ogTitle":1376,"ogDescription":1377,"noIndex":6,"ogImage":1378,"ogUrl":1379,"ogSiteName":728,"ogType":729,"canonicalUrls":1379,"schema":1380},"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":1376,"description":1377,"authors":1382,"heroImage":1378,"date":1384,"body":1385,"category":14,"tags":1386},[1383],"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/).",[713,14,475],{"slug":1388,"featured":91,"template":674,"externalUrl":1389},"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":1395,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1396,"content":1402,"config":1408,"_id":1410,"_type":16,"title":1411,"_source":17,"_file":1412,"_stem":1413,"_extension":20},"/en-us/blog/5-gitlab-premium-features-to-help-your-team-scale",{"title":1397,"description":1398,"ogTitle":1397,"ogDescription":1398,"noIndex":6,"ogImage":1399,"ogUrl":1400,"ogSiteName":728,"ogType":729,"canonicalUrls":1400,"schema":1401},"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":1397,"description":1398,"authors":1403,"heroImage":1399,"date":1405,"body":1406,"category":14,"tags":1407},[1404],"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,738],{"slug":1409,"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":1415,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1416,"content":1422,"config":1428,"_id":1430,"_type":16,"title":1431,"_source":17,"_file":1432,"_stem":1433,"_extension":20},"/en-us/blog/transform-code-quality-and-compliance-with-automated-processes",{"title":1417,"description":1418,"ogTitle":1417,"ogDescription":1418,"noIndex":6,"ogImage":1419,"ogUrl":1420,"ogSiteName":728,"ogType":729,"canonicalUrls":1420,"schema":1421},"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":1417,"description":1418,"authors":1423,"heroImage":1419,"date":1424,"body":1425,"category":14,"tags":1426},[733],"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/).",[804,1427,475,14,1051,738],"code review",{"slug":1429,"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":1435,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1436,"content":1442,"config":1448,"_id":1450,"_type":16,"title":1451,"_source":17,"_file":1452,"_stem":1453,"_extension":20},"/en-us/blog/streamline-migrations-with-user-contribution-and-membership-mapping",{"title":1437,"description":1438,"ogTitle":1437,"ogDescription":1438,"noIndex":6,"ogImage":1439,"ogUrl":1440,"ogSiteName":728,"ogType":729,"canonicalUrls":1440,"schema":1441},"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":1437,"description":1438,"authors":1443,"heroImage":1439,"date":1445,"body":1446,"category":14,"tags":1447},[1444],"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,738,14],{"slug":1449,"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":1455,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1456,"content":1462,"config":1467,"_id":1470,"_type":16,"title":1471,"_source":17,"_file":1472,"_stem":1473,"_extension":20},"/en-us/blog/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta",{"title":1457,"description":1458,"ogTitle":1457,"ogDescription":1458,"noIndex":6,"ogImage":1459,"ogUrl":1460,"ogSiteName":728,"ogType":729,"canonicalUrls":1460,"schema":1461},"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":1457,"description":1458,"authors":1463,"heroImage":1459,"date":1464,"body":1465,"category":14,"tags":1466},[1444],"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,713],{"slug":1468,"featured":91,"template":674,"externalUrl":1469},"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":1475,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1476,"content":1482,"config":1488,"_id":1490,"_type":16,"title":1491,"_source":17,"_file":1492,"_stem":1493,"_extension":20},"/en-us/blog/3-gitlab-features-to-level-up-devsecops-workflows",{"title":1477,"description":1478,"ogTitle":1477,"ogDescription":1478,"noIndex":6,"ogImage":1479,"ogUrl":1480,"ogSiteName":728,"ogType":729,"canonicalUrls":1480,"schema":1481},"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":1477,"description":1478,"authors":1483,"heroImage":1479,"date":1485,"body":1486,"category":14,"tags":1487},[1484],"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/blog/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,738,669,1051,109],{"slug":1489,"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":1495,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1496,"content":1502,"config":1508,"_id":1511,"_type":16,"title":1512,"_source":17,"_file":1513,"_stem":1514,"_extension":20},"/en-us/blog/gitlab-17-5-release",{"title":1497,"description":1498,"ogTitle":1497,"ogDescription":1498,"noIndex":6,"ogImage":1499,"ogUrl":1500,"ogSiteName":728,"ogType":729,"canonicalUrls":1500,"schema":1501},"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":1497,"description":1498,"authors":1503,"heroImage":1499,"date":1505,"body":1506,"category":14,"tags":1507},[1504],"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/).",[713],{"slug":1509,"featured":6,"template":674,"externalUrl":1510},"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":1516,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1517,"content":1523,"config":1530,"_id":1532,"_type":16,"title":1533,"_source":17,"_file":1534,"_stem":1535,"_extension":20},"/en-us/blog/how-to-include-file-references-in-your-ci-cd-components",{"title":1518,"description":1519,"ogTitle":1518,"ogDescription":1519,"noIndex":6,"ogImage":1520,"ogUrl":1521,"ogSiteName":728,"ogType":729,"canonicalUrls":1521,"schema":1522},"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":1518,"description":1519,"authors":1524,"heroImage":1520,"date":1526,"body":1527,"category":14,"tags":1528},[1525],"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,1529,738,14],"DevOps",{"slug":1531,"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":1537,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1538,"content":1544,"config":1550,"_id":1552,"_type":16,"title":1553,"_source":17,"_file":1554,"_stem":1555,"_extension":20},"/en-us/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems",{"title":1539,"description":1540,"ogTitle":1539,"ogDescription":1540,"noIndex":6,"ogImage":1541,"ogUrl":1542,"ogSiteName":728,"ogType":729,"canonicalUrls":1542,"schema":1543},"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":1539,"description":1540,"authors":1545,"heroImage":1541,"date":1547,"body":1548,"category":14,"tags":1549},[1546],"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",[760,14,738,109],{"slug":1551,"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":1557,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1558,"content":1564,"config":1571,"_id":1573,"_type":16,"title":1574,"_source":17,"_file":1575,"_stem":1576,"_extension":20},"/en-us/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment",{"title":1559,"description":1560,"ogTitle":1559,"ogDescription":1560,"noIndex":6,"ogImage":1561,"ogUrl":1562,"ogSiteName":728,"ogType":729,"canonicalUrls":1562,"schema":1563},"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":1559,"description":1560,"authors":1565,"heroImage":1561,"date":1568,"body":1569,"category":14,"tags":1570,"updatedDate":1006},[1566,1567],"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",[1108,109,669,738,14,760],{"slug":1572,"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":1578,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1579,"content":1585,"config":1591,"_id":1594,"_type":16,"title":1595,"_source":17,"_file":1596,"_stem":1597,"_extension":20},"/en-us/blog/gitlab-17-4-release",{"title":1580,"description":1581,"ogTitle":1580,"ogDescription":1581,"noIndex":6,"ogImage":1582,"ogUrl":1583,"ogSiteName":728,"ogType":729,"canonicalUrls":1583,"schema":1584},"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":1580,"description":1581,"authors":1586,"heroImage":1582,"date":1588,"body":1589,"category":14,"tags":1590},[1587],"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/).",[713,14,475,783],{"slug":1592,"featured":6,"template":674,"externalUrl":1593},"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":1599,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1600,"content":1606,"config":1612,"_id":1615,"_type":16,"title":1616,"_source":17,"_file":1617,"_stem":1618,"_extension":20},"/en-us/blog/gitlab-17-3-release",{"title":1601,"description":1602,"ogTitle":1601,"ogDescription":1602,"noIndex":6,"ogImage":1603,"ogUrl":1604,"ogSiteName":728,"ogType":729,"canonicalUrls":1604,"schema":1605},"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":1601,"description":1602,"authors":1607,"heroImage":1603,"date":1609,"body":1610,"category":14,"tags":1611},[1608],"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/).",[713,14],{"slug":1613,"featured":6,"template":674,"externalUrl":1614},"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":1620,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1621,"content":1626,"config":1632,"_id":1634,"_type":16,"title":1635,"_source":17,"_file":1636,"_stem":1637,"_extension":20},"/en-us/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation",{"title":1622,"description":1623,"ogTitle":1622,"ogDescription":1623,"noIndex":6,"ogImage":1399,"ogUrl":1624,"ogSiteName":728,"ogType":729,"canonicalUrls":1624,"schema":1625},"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":1622,"description":1623,"authors":1627,"heroImage":1399,"date":1629,"body":1630,"category":14,"tags":1631},[1628],"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,805,804,738],{"slug":1633,"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":1639,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1640,"content":1646,"config":1652,"_id":1655,"_type":16,"title":1656,"_source":17,"_file":1657,"_stem":1658,"_extension":20},"/en-us/blog/gitlab-patch-release-17-2-1-17-1-3-17-0-5",{"title":1641,"description":1642,"ogTitle":1641,"ogDescription":1642,"noIndex":6,"ogImage":1643,"ogUrl":1644,"ogSiteName":728,"ogType":729,"canonicalUrls":1644,"schema":1645},"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":1641,"description":1642,"authors":1647,"heroImage":1643,"date":1649,"body":1650,"category":14,"tags":1651},[1648],"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/).",[713,826],{"slug":1653,"featured":6,"template":674,"externalUrl":1654},"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":1660,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1661,"content":1666,"config":1672,"_id":1674,"_type":16,"title":1675,"_source":17,"_file":1676,"_stem":1677,"_extension":20},"/en-us/blog/next-generation-gitlab-container-registry-goes-ga",{"title":1662,"description":1663,"ogTitle":1662,"ogDescription":1663,"noIndex":6,"ogImage":1200,"ogUrl":1664,"ogSiteName":728,"ogType":729,"canonicalUrls":1664,"schema":1665},"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":1662,"description":1663,"authors":1667,"heroImage":1200,"date":1668,"body":1669,"category":14,"tags":1670},[709],"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,738,1671,14],"cloud native",{"slug":1673,"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":1679,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1680,"content":1686,"config":1691,"_id":1694,"_type":16,"title":1695,"_source":17,"_file":1696,"_stem":1697,"_extension":20},"/en-us/blog/gitlab-17-2-release",{"title":1681,"description":1682,"ogTitle":1681,"ogDescription":1682,"noIndex":6,"ogImage":1683,"ogUrl":1684,"ogSiteName":728,"ogType":729,"canonicalUrls":1684,"schema":1685},"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":1681,"description":1682,"authors":1687,"heroImage":1683,"date":1688,"body":1689,"category":14,"tags":1690},[1225],"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/).",[713,14,475],{"slug":1692,"featured":91,"template":674,"externalUrl":1693},"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":1699,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1700,"content":1706,"config":1713,"_id":1715,"_type":16,"title":1716,"_source":17,"_file":1717,"_stem":1718,"_extension":20},"/en-us/blog/introducing-gitlab-dedicated-for-government",{"title":1701,"description":1702,"ogTitle":1701,"ogDescription":1702,"noIndex":6,"ogImage":1703,"ogUrl":1704,"ogSiteName":728,"ogType":729,"canonicalUrls":1704,"schema":1705},"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":1701,"description":1702,"authors":1707,"heroImage":1703,"date":1710,"body":1711,"category":14,"tags":1712},[1708,1709],"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,1051,783,475,14],{"slug":1714,"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":1720,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1721,"content":1727,"config":1733,"_id":1736,"_type":16,"title":1737,"_source":17,"_file":1738,"_stem":1739,"_extension":20},"/en-us/blog/gitlab-16-8-release",{"title":1722,"description":1723,"ogTitle":1722,"ogDescription":1723,"noIndex":6,"ogImage":1724,"ogUrl":1725,"ogSiteName":728,"ogType":729,"canonicalUrls":1725,"schema":1726},"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":1722,"description":1723,"authors":1728,"heroImage":1724,"date":1730,"body":1731,"category":14,"tags":1732},[1729],"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/).",[713],{"slug":1734,"featured":6,"template":674,"externalUrl":1735},"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":1741,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1742,"content":1747,"config":1752,"_id":1754,"_type":16,"title":1755,"_source":17,"_file":1756,"_stem":1757,"_extension":20},"/en-us/blog/registration-features-program-expands-by-16-free-features",{"title":1743,"description":1744,"ogTitle":1743,"ogDescription":1744,"noIndex":6,"ogImage":959,"ogUrl":1745,"ogSiteName":728,"ogType":729,"canonicalUrls":1745,"schema":1746},"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":1743,"description":1744,"authors":1748,"heroImage":959,"date":1730,"body":1750,"category":14,"tags":1751},[1749],"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,738,14,783],{"slug":1753,"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":1759,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1760,"content":1766,"config":1771,"_id":1773,"_type":16,"title":1774,"_source":17,"_file":1775,"_stem":1776,"_extension":20},"/en-us/blog/gitlab-package-roadmap-for-2024",{"title":1761,"description":1762,"ogTitle":1761,"ogDescription":1762,"noIndex":6,"ogImage":1763,"ogUrl":1764,"ogSiteName":728,"ogType":729,"canonicalUrls":1764,"schema":1765},"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":1761,"description":1762,"authors":1767,"heroImage":1763,"date":1768,"body":1769,"category":14,"tags":1770},[709],"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,783,738,669],{"slug":1772,"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":1778,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1779,"content":1785,"config":1789,"_id":1792,"_type":16,"title":1793,"_source":17,"_file":1794,"_stem":1795,"_extension":20},"/en-us/blog/gitlab-16-7-release",{"title":1780,"description":1781,"ogTitle":1780,"ogDescription":1781,"noIndex":6,"ogImage":1782,"ogUrl":1783,"ogSiteName":728,"ogType":729,"canonicalUrls":1783,"schema":1784},"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":1780,"description":1781,"authors":1786,"heroImage":1782,"date":1787,"body":1788,"category":14},[1729],"2023-12-21","GitLab 16.7 released",{"slug":1790,"featured":91,"template":674,"externalUrl":1791},"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":1797,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1798,"content":1804,"config":1810,"_id":1812,"_type":16,"title":1813,"_source":17,"_file":1814,"_stem":1815,"_extension":20},"/en-us/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":1799,"description":1800,"ogTitle":1799,"ogDescription":1800,"noIndex":6,"ogImage":1801,"ogUrl":1802,"ogSiteName":728,"ogType":729,"canonicalUrls":1802,"schema":1803},"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":1799,"description":1800,"authors":1805,"heroImage":1801,"date":1807,"body":1808,"category":14,"tags":1809,"updatedDate":757},[1806],"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",[760,804,109,1529,669,670],{"slug":1811,"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":1817,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1818,"content":1824,"config":1831,"_id":1833,"_type":16,"title":1834,"_source":17,"_file":1835,"_stem":1836,"_extension":20},"/en-us/blog/contributions-to-git-2-42-release",{"title":1819,"description":1820,"ogTitle":1819,"ogDescription":1820,"noIndex":6,"ogImage":1821,"ogUrl":1822,"ogSiteName":728,"ogType":729,"canonicalUrls":1822,"schema":1823},"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":1819,"description":1820,"authors":1825,"heroImage":1821,"date":1827,"body":1828,"category":14,"tags":1829},[1826],"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",[670,783,1830,267],"open source",{"slug":1832,"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":1838,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1839,"content":1845,"config":1852,"_id":1854,"_type":16,"title":1855,"_source":17,"_file":1856,"_stem":1857,"_extension":20},"/en-us/blog/browser-based-dast-feature-announcement",{"title":1840,"description":1841,"ogTitle":1840,"ogDescription":1841,"noIndex":6,"ogImage":1842,"ogUrl":1843,"ogSiteName":728,"ogType":729,"canonicalUrls":1843,"schema":1844},"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":1840,"description":1841,"authors":1846,"heroImage":1842,"date":1848,"body":1849,"category":14,"tags":1850},[1847],"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",[1851,738,1427],"testing",{"slug":1853,"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":1859,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1860,"content":1866,"config":1872,"_id":1874,"_type":16,"title":1875,"_source":17,"_file":1876,"_stem":1877,"_extension":20},"/en-us/blog/new-machine-types-for-gitlab-saas-runners",{"title":1861,"description":1862,"ogTitle":1861,"ogDescription":1862,"noIndex":6,"ogImage":1863,"ogUrl":1864,"ogSiteName":728,"ogType":729,"canonicalUrls":1864,"schema":1865},"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":1861,"description":1862,"authors":1867,"heroImage":1863,"date":1868,"body":1869,"category":14,"tags":1870},[1628],"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",[804,805,1871,14],"performance",{"slug":1873,"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":1879,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1880,"content":1886,"config":1893,"_id":1895,"_type":16,"title":1896,"_source":17,"_file":1897,"_stem":1898,"_extension":20},"/en-us/blog/three-faces-of-user-calls",{"title":1881,"description":1882,"ogTitle":1881,"ogDescription":1882,"noIndex":6,"ogImage":1883,"ogUrl":1884,"ogSiteName":728,"ogType":729,"canonicalUrls":1884,"schema":1885},"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":1881,"description":1882,"authors":1887,"heroImage":1883,"date":1888,"body":1889,"category":14,"tags":1890},[1225],"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",[1529,1891,1892],"customers","contributors",{"slug":1894,"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":1900,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1901,"content":1907,"config":1916,"_id":1918,"_type":16,"title":1919,"_source":17,"_file":1920,"_stem":1921,"_extension":20},"/en-us/blog/gitlab-ux-2020-year-in-review",{"title":1902,"description":1903,"ogTitle":1902,"ogDescription":1903,"noIndex":6,"ogImage":1904,"ogUrl":1905,"ogSiteName":728,"ogType":729,"canonicalUrls":1905,"schema":1906},"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":1902,"description":1903,"authors":1908,"heroImage":1904,"date":1910,"body":1911,"category":14,"tags":1912},[1909],"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",[1913,1914,1915,782],"UX","design","inside GitLab",{"slug":1917,"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",7,[681,700,721,745,768,790,812,835,855],1751484543047]