[{"data":1,"prerenderedAt":1816},["ShallowReactive",2],{"/en-us/blog/tags/releases/":3,"navigation-en-us":19,"banner-en-us":449,"footer-en-us":466,"releases-tag-page-en-us":676},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/releases","tags",false,"",{"tag":9,"tagSlug":9},"releases",{"template":11},"BlogTag","content:en-us:blog:tags:releases.yml","yaml","Releases","content","en-us/blog/tags/releases.yml","en-us/blog/tags/releases","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":445,"_type":13,"title":446,"_source":15,"_file":447,"_stem":448,"_extension":18},"/shared/en-us/main-navigation","en-us",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":376,"minimal":407,"duo":426,"pricingDeployment":435},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/","gitlab logo","header",{"text":29,"config":30},"Get free trial",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"Talk to sales",{"href":36,"dataGaName":37,"dataGaLocation":27},"/sales/","sales",{"text":39,"config":40},"Sign in",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,186,191,297,357],{"text":45,"config":46,"cards":48,"footer":71},"Platform",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"The most comprehensive AI-powered DevSecOps Platform",{"text":52,"config":53},"Explore our Platform",{"href":54,"dataGaName":47,"dataGaLocation":27},"/platform/",{"title":56,"description":57,"link":58},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":59,"config":60},"Meet GitLab Duo",{"href":61,"dataGaName":62,"dataGaLocation":27},"/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":67,"config":68},"Learn more",{"href":69,"dataGaName":70,"dataGaLocation":27},"/why-gitlab/","why gitlab",{"title":72,"items":73},"Get started with",[74,79,84],{"text":75,"config":76},"Platform Engineering",{"href":77,"dataGaName":78,"dataGaLocation":27},"/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"Developer Experience",{"href":82,"dataGaName":83,"dataGaLocation":27},"/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":168},"Product",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":27},"/solutions/",[98,123,147],{"title":99,"description":100,"link":101,"items":106},"Automation","CI/CD and automation to accelerate deployment",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,111,115,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/solutions/continuous-integration/",{"text":112,"config":113},"AI-Assisted Development",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":27,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":104,"dataGaLocation":27,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":27,"icon":130},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[132,137,142],{"text":133,"config":134},"Application Security Testing",{"href":135,"dataGaName":136,"dataGaLocation":27},"/solutions/application-security-testing/","Application security testing",{"text":138,"config":139},"Software Supply Chain Security",{"href":140,"dataGaLocation":27,"dataGaName":141},"/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"Software Compliance",{"href":145,"dataGaName":146,"dataGaLocation":27},"/solutions/software-compliance/","software compliance",{"title":148,"link":149,"items":154},"Measurement",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":27},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[155,159,163],{"text":156,"config":157},"Visibility & Measurement",{"href":152,"dataGaLocation":27,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Value Stream Management",{"href":162,"dataGaLocation":27,"dataGaName":160},"/solutions/value-stream-management/",{"text":164,"config":165},"Analytics & Insights",{"href":166,"dataGaLocation":27,"dataGaName":167},"/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLab for",[171,176,181],{"text":172,"config":173},"Enterprise",{"href":174,"dataGaLocation":27,"dataGaName":175},"/enterprise/","enterprise",{"text":177,"config":178},"Small Business",{"href":179,"dataGaLocation":27,"dataGaName":180},"/small-business/","small business",{"text":182,"config":183},"Public Sector",{"href":184,"dataGaLocation":27,"dataGaName":185},"/solutions/public-sector/","public sector",{"text":187,"config":188},"Pricing",{"href":189,"dataGaName":190,"dataGaLocation":27,"dataNavLevelOne":190},"/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":284},"Resources",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"View all resources",{"href":198,"dataGaName":194,"dataGaLocation":27},"/resources/",[200,233,256],{"title":201,"items":202},"Getting started",[203,208,213,218,223,228],{"text":204,"config":205},"Install",{"href":206,"dataGaName":207,"dataGaLocation":27},"/install/","install",{"text":209,"config":210},"Quick start guides",{"href":211,"dataGaName":212,"dataGaLocation":27},"/get-started/","quick setup checklists",{"text":214,"config":215},"Learn",{"href":216,"dataGaLocation":27,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Product documentation",{"href":221,"dataGaName":222,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best practice videos",{"href":226,"dataGaName":227,"dataGaLocation":27},"/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrations",{"href":231,"dataGaName":232,"dataGaLocation":27},"/integrations/","integrations",{"title":234,"items":235},"Discover",[236,241,246,251],{"text":237,"config":238},"Customer success stories",{"href":239,"dataGaName":240,"dataGaLocation":27},"/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":27},"/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":252,"config":253},"TeamOps",{"href":254,"dataGaName":255,"dataGaLocation":27},"/teamops/","teamops",{"title":257,"items":258},"Connect",[259,264,269,274,279],{"text":260,"config":261},"GitLab Services",{"href":262,"dataGaName":263,"dataGaLocation":27},"/services/","services",{"text":265,"config":266},"Community",{"href":267,"dataGaName":268,"dataGaLocation":27},"/community/","community",{"text":270,"config":271},"Forum",{"href":272,"dataGaName":273,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":275,"config":276},"Events",{"href":277,"dataGaName":278,"dataGaLocation":27},"/events/","events",{"text":280,"config":281},"Partners",{"href":282,"dataGaName":283,"dataGaLocation":27},"/partners/","partners",{"backgroundColor":285,"textColor":286,"text":287,"image":288,"link":292},"#2f2a6b","#fff","Insights for the future of software development",{"altText":289,"config":290},"the source promo card",{"src":291},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":293,"config":294},"Read the latest",{"href":295,"dataGaName":296,"dataGaLocation":27},"/the-source/","the source",{"text":298,"config":299,"lists":301},"Company",{"dataNavLevelOne":300},"company",[302],{"items":303},[304,309,315,317,322,327,332,337,342,347,352],{"text":305,"config":306},"About",{"href":307,"dataGaName":308,"dataGaLocation":27},"/company/","about",{"text":310,"config":311,"footerGa":314},"Jobs",{"href":312,"dataGaName":313,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":313},{"text":275,"config":316},{"href":277,"dataGaName":278,"dataGaLocation":27},{"text":318,"config":319},"Leadership",{"href":320,"dataGaName":321,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":323,"config":324},"Team",{"href":325,"dataGaName":326,"dataGaLocation":27},"/company/team/","team",{"text":328,"config":329},"Handbook",{"href":330,"dataGaName":331,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":333,"config":334},"Investor relations",{"href":335,"dataGaName":336,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":338,"config":339},"Trust Center",{"href":340,"dataGaName":341,"dataGaLocation":27},"/security/","trust center",{"text":343,"config":344},"AI Transparency Center",{"href":345,"dataGaName":346,"dataGaLocation":27},"/ai-transparency-center/","ai transparency center",{"text":348,"config":349},"Newsletter",{"href":350,"dataGaName":351,"dataGaLocation":27},"/company/contact/","newsletter",{"text":353,"config":354},"Press",{"href":355,"dataGaName":356,"dataGaLocation":27},"/press/","press",{"text":358,"config":359,"lists":360},"Contact us",{"dataNavLevelOne":300},[361],{"items":362},[363,366,371],{"text":34,"config":364},{"href":36,"dataGaName":365,"dataGaLocation":27},"talk to sales",{"text":367,"config":368},"Get help",{"href":369,"dataGaName":370,"dataGaLocation":27},"/support/","get help",{"text":372,"config":373},"Customer portal",{"href":374,"dataGaName":375,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"Close",{"text":379,"link":380},"To search repositories and projects, login to",{"text":381,"config":382},"gitlab.com",{"href":41,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"Suggestions",[388,390,394,396,400,404],{"text":56,"config":389},{"href":61,"dataGaName":56,"dataGaLocation":384},{"text":391,"config":392},"Code Suggestions (AI)",{"href":393,"dataGaName":391,"dataGaLocation":384},"/solutions/code-suggestions/",{"text":108,"config":395},{"href":110,"dataGaName":108,"dataGaLocation":384},{"text":397,"config":398},"GitLab on AWS",{"href":399,"dataGaName":397,"dataGaLocation":384},"/partners/technology-partners/aws/",{"text":401,"config":402},"GitLab on Google Cloud",{"href":403,"dataGaName":401,"dataGaLocation":384},"/partners/technology-partners/google-cloud-platform/",{"text":405,"config":406},"Why GitLab?",{"href":69,"dataGaName":405,"dataGaLocation":384},{"freeTrial":408,"mobileIcon":413,"desktopIcon":418,"secondaryButton":421},{"text":409,"config":410},"Start free trial",{"href":411,"dataGaName":32,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"Gitlab Icon",{"src":416,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":422,"config":423},"Get Started",{"href":424,"dataGaName":425,"dataGaLocation":412},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"Learn more about GitLab Duo",{"href":61,"dataGaName":430,"dataGaLocation":412},"gitlab duo",{"altText":414,"config":432},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":434},{"src":420,"dataGaName":417,"dataGaLocation":412},{"freeTrial":436,"mobileIcon":441,"desktopIcon":443},{"text":437,"config":438},"Back to pricing",{"href":189,"dataGaName":439,"dataGaLocation":412,"icon":440},"back to pricing","GoBack",{"altText":414,"config":442},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":444},{"src":420,"dataGaName":417,"dataGaLocation":412},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":450,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":451,"button":452,"image":457,"config":461,"_id":463,"_type":13,"_source":15,"_file":464,"_stem":465,"_extension":18},"/shared/en-us/banner","is now in public beta!",{"text":453,"config":454},"Try the Beta",{"href":455,"dataGaName":456,"dataGaLocation":27},"/gitlab-duo/agent-platform/","duo banner",{"altText":458,"config":459},"GitLab Duo Agent Platform",{"src":460},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":462},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":467,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":468,"_id":672,"_type":13,"title":673,"_source":15,"_file":674,"_stem":675,"_extension":18},"/shared/en-us/main-footer",{"text":469,"source":470,"edit":476,"contribute":481,"config":486,"items":491,"minimal":664},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":471,"config":472},"View page source",{"href":473,"dataGaName":474,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":477,"config":478},"Edit this page",{"href":479,"dataGaName":480,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":482,"config":483},"Please contribute",{"href":484,"dataGaName":485,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":487,"facebook":488,"youtube":489,"linkedin":490},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[492,515,571,600,634],{"title":45,"links":493,"subMenu":498},[494],{"text":495,"config":496},"DevSecOps platform",{"href":54,"dataGaName":497,"dataGaLocation":475},"devsecops platform",[499],{"title":187,"links":500},[501,505,510],{"text":502,"config":503},"View plans",{"href":189,"dataGaName":504,"dataGaLocation":475},"view plans",{"text":506,"config":507},"Why Premium?",{"href":508,"dataGaName":509,"dataGaLocation":475},"/pricing/premium/","why premium",{"text":511,"config":512},"Why Ultimate?",{"href":513,"dataGaName":514,"dataGaLocation":475},"/pricing/ultimate/","why ultimate",{"title":516,"links":517},"Solutions",[518,523,525,527,532,537,541,544,548,553,555,558,561,566],{"text":519,"config":520},"Digital transformation",{"href":521,"dataGaName":522,"dataGaLocation":475},"/topics/digital-transformation/","digital transformation",{"text":133,"config":524},{"href":135,"dataGaName":133,"dataGaLocation":475},{"text":122,"config":526},{"href":104,"dataGaName":105,"dataGaLocation":475},{"text":528,"config":529},"Agile development",{"href":530,"dataGaName":531,"dataGaLocation":475},"/solutions/agile-delivery/","agile delivery",{"text":533,"config":534},"Cloud transformation",{"href":535,"dataGaName":536,"dataGaLocation":475},"/topics/cloud-native/","cloud transformation",{"text":538,"config":539},"SCM",{"href":118,"dataGaName":540,"dataGaLocation":475},"source code management",{"text":108,"config":542},{"href":110,"dataGaName":543,"dataGaLocation":475},"continuous integration & delivery",{"text":545,"config":546},"Value stream management",{"href":162,"dataGaName":547,"dataGaLocation":475},"value stream management",{"text":549,"config":550},"GitOps",{"href":551,"dataGaName":552,"dataGaLocation":475},"/solutions/gitops/","gitops",{"text":172,"config":554},{"href":174,"dataGaName":175,"dataGaLocation":475},{"text":556,"config":557},"Small business",{"href":179,"dataGaName":180,"dataGaLocation":475},{"text":559,"config":560},"Public sector",{"href":184,"dataGaName":185,"dataGaLocation":475},{"text":562,"config":563},"Education",{"href":564,"dataGaName":565,"dataGaLocation":475},"/solutions/education/","education",{"text":567,"config":568},"Financial services",{"href":569,"dataGaName":570,"dataGaLocation":475},"/solutions/finance/","financial services",{"title":192,"links":572},[573,575,577,579,582,584,586,588,590,592,594,596,598],{"text":204,"config":574},{"href":206,"dataGaName":207,"dataGaLocation":475},{"text":209,"config":576},{"href":211,"dataGaName":212,"dataGaLocation":475},{"text":214,"config":578},{"href":216,"dataGaName":217,"dataGaLocation":475},{"text":219,"config":580},{"href":221,"dataGaName":581,"dataGaLocation":475},"docs",{"text":242,"config":583},{"href":244,"dataGaName":245,"dataGaLocation":475},{"text":237,"config":585},{"href":239,"dataGaName":240,"dataGaLocation":475},{"text":247,"config":587},{"href":249,"dataGaName":250,"dataGaLocation":475},{"text":260,"config":589},{"href":262,"dataGaName":263,"dataGaLocation":475},{"text":252,"config":591},{"href":254,"dataGaName":255,"dataGaLocation":475},{"text":265,"config":593},{"href":267,"dataGaName":268,"dataGaLocation":475},{"text":270,"config":595},{"href":272,"dataGaName":273,"dataGaLocation":475},{"text":275,"config":597},{"href":277,"dataGaName":278,"dataGaLocation":475},{"text":280,"config":599},{"href":282,"dataGaName":283,"dataGaLocation":475},{"title":298,"links":601},[602,604,606,608,610,612,614,618,623,625,627,629],{"text":305,"config":603},{"href":307,"dataGaName":300,"dataGaLocation":475},{"text":310,"config":605},{"href":312,"dataGaName":313,"dataGaLocation":475},{"text":318,"config":607},{"href":320,"dataGaName":321,"dataGaLocation":475},{"text":323,"config":609},{"href":325,"dataGaName":326,"dataGaLocation":475},{"text":328,"config":611},{"href":330,"dataGaName":331,"dataGaLocation":475},{"text":333,"config":613},{"href":335,"dataGaName":336,"dataGaLocation":475},{"text":615,"config":616},"Sustainability",{"href":617,"dataGaName":615,"dataGaLocation":475},"/sustainability/",{"text":619,"config":620},"Diversity, inclusion and belonging (DIB)",{"href":621,"dataGaName":622,"dataGaLocation":475},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":338,"config":624},{"href":340,"dataGaName":341,"dataGaLocation":475},{"text":348,"config":626},{"href":350,"dataGaName":351,"dataGaLocation":475},{"text":353,"config":628},{"href":355,"dataGaName":356,"dataGaLocation":475},{"text":630,"config":631},"Modern Slavery Transparency Statement",{"href":632,"dataGaName":633,"dataGaLocation":475},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":635,"links":636},"Contact Us",[637,640,642,644,649,654,659],{"text":638,"config":639},"Contact an expert",{"href":36,"dataGaName":37,"dataGaLocation":475},{"text":367,"config":641},{"href":369,"dataGaName":370,"dataGaLocation":475},{"text":372,"config":643},{"href":374,"dataGaName":375,"dataGaLocation":475},{"text":645,"config":646},"Status",{"href":647,"dataGaName":648,"dataGaLocation":475},"https://status.gitlab.com/","status",{"text":650,"config":651},"Terms of use",{"href":652,"dataGaName":653,"dataGaLocation":475},"/terms/","terms of use",{"text":655,"config":656},"Privacy statement",{"href":657,"dataGaName":658,"dataGaLocation":475},"/privacy/","privacy statement",{"text":660,"config":661},"Cookie preferences",{"dataGaName":662,"dataGaLocation":475,"id":663,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":665},[666,668,670],{"text":650,"config":667},{"href":652,"dataGaName":653,"dataGaLocation":475},{"text":655,"config":669},{"href":657,"dataGaName":658,"dataGaLocation":475},{"text":660,"config":671},{"dataGaName":662,"dataGaLocation":475,"id":663,"isOneTrustButton":90},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":677,"featuredPost":1793,"totalPagesCount":1814,"initialPosts":1815},[678,704,729,749,768,790,812,832,854,873,896,917,936,956,978,997,1017,1037,1058,1077,1098,1118,1139,1159,1178,1197,1217,1238,1258,1277,1296,1315,1334,1355,1375,1396,1417,1432,1446,1460,1474,1488,1502,1516,1530,1544,1558,1572,1586,1600,1614,1628,1642,1656,1670,1684,1698,1712,1726,1740,1753,1767,1780],{"_path":679,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":680,"content":688,"config":697,"_id":700,"_type":13,"title":701,"_source":15,"_file":702,"_stem":703,"_extension":18},"/en-us/blog/advanced-search-data-migrations",{"title":681,"description":682,"ogTitle":681,"ogDescription":682,"noIndex":6,"ogImage":683,"ogUrl":684,"ogSiteName":685,"ogType":686,"canonicalUrls":684,"schema":687},"GitLab's data migration process for Advanced Search","We needed a more streamlined data migration process for Advanced search.\nHere's what we did.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682017/Blog/Hero%20Images/advanced-search-migrations.jpg","https://about.gitlab.com/blog/advanced-search-data-migrations","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's data migration process for Advanced Search\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dmitry Gruzd\"}],\n        \"datePublished\": \"2021-06-01\",\n      }",{"title":681,"description":682,"authors":689,"heroImage":683,"date":691,"body":692,"category":693,"tags":694},[690],"Dmitry Gruzd","2021-06-01","For some time now, GitLab has been working on enabling the Elasticsearch\n\nintegration on GitLab.com to allow as many GitLab.com users as possible\naccess\n\nto the [Advanced Global\nSearch](https://docs.gitlab.com/ee/user/search/advanced_search.html)\n\nfeatures. Last year, after enabling Advanced Search for all licensed\ncustomers on\n\nGitLab.com we were thinking how to simplify the rollout of some Advanced\nSearch\n\nfeatures that require changing the data in Elasticsearch.\n\n\n(If you're interested in the lessons we learned on our road to Enabling\n\nElasticsearch for GitLab.com, you can read [all about\nit](/blog/elasticsearch-update/).\n\n\n## The data migration process problem \n\n\nSometimes we need to change mappings of an index or backfill a field, and\n\nreindexing everything from scratch or using [Zero downtime\nreindexing](https://docs.gitlab.com/ee/integration/elasticsearch.html#zero-downtime-reindexing)\n\nmight seem like an obvious solution. However, this is not a scalable option\nfor\n\nbig GitLab instances. GitLab.com is the largest known installation of GitLab\nand\n\nas such has a lot of projects, code, issues, merge requests and other things\nthat\n\nneed to be indexed. For example, at the moment our Elasticsearch cluster has\n\nalmost 1 billion documents in it. It would take many weeks or even months to\n\nreindex everything and for all that time indexing would need to remain\npaused, therefore\n\nsearch results would quickly become outdated.\n\n\n## Original plan for multi-version support\n\n\nOriginally, we were planning to introduce multi-version support using an\napproach\n\nthat is fully reliant on GitLab to manage both indices, reading from the old\none\n\nand writing to both until the migration is finished. You can read more\ninformation at\n\n[!18254](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18254) and\n\n[&1769](https://gitlab.com/groups/gitlab-org/-/epics/1769). As of writing\nthis,\n\nmost of the code for this approach still exists in GitLab in a\nhalf-implemented form.\n\n\nThere were 2 primary concerns with this approach:\n\n\n1. Reindexing would require the GitLab application to read every single\ndocument\n\nfrom the storage and send it to Elasticsearch again. Doing so\n\nwould put a big strain on different parts of the application, such as\ndatabase,\n\nGitaly, and Sidekiq.\n\n1. Reindexing everything from GitLab to the cluster again may be very\nwasteful on\n\noccasions where you only need to change a small part of the index. For\nexample, if\n\nwe want to add epics to the index, it is very wasteful to reindex every\ndocument\n\nin the index when we could very quickly just index all the epics. There are\nmany\n\nsituations where we will be trying to perform some migration that can be\ndone more\n\nefficiently using a targeted approach (e.g. adding a new field to a document\ntype\n\nonly requires reindexing all the documents that actually have that field).\n\n\nFor these reasons we've decided to create a different data migration\nprocess.\n\n\n## Our revised data migration process\n\n\nWe took inspiration from the [Rails DB\nmigrations](https://guides.rubyonrails.org/active_record_migrations.html).\n\nWe wanted to apply the best practices from it without having to re-architect\nwhat\n\nthe Rails team has already implemented.\n\n\nFor example, we've decided that we would have a special directory with\ntime-stamped\n\nmigration files. We wanted to achieve a strict execution order so that many\n\nmigrations might be shipped simultaneously. A special background processing\nworker\n\nwill be checking this folder on schedule. This is slightly different to\nrails background migrations where the operator is required to manually run\nthe migration. We decided to make it fully automated and run it in the\nbackground to avoid the need for self-managed customers to add extra steps\nto the migration process. This would have likely made it much more difficult\nfor everyone involved as there are many ways to run GitLab. This extra\nconstraint also forces us to always think of migrations as possibly\nincomplete at any point in the code which is essential for zero-downtime.\n\n\nAt first, we wanted to store the migration state in the Postgresql database,\nbut\n\ndecided against it since this may not be perfect for the situation where a\nuser\n\nwants to connect a new Elasticsearch cluster to GitLab. It's better to store\nthe\n\nmigrations themselves in the Elasticsearch cluster itself so they're more\nlikely to be in\n\nsync with the data.\n\n\nYou can see your new migration index in your Elasticsearch cluster. It's\ncalled\n\n`gitlab-production-migrations`. GitLab stores a few fields there. We use the\n\nversion number as the document id. This is an example document:\n\n\n```\n\n{\n    \"_id\": \"20210510143200\",\n    \"_source\": {\n        \"completed\": true,\n        \"state\": {\n        },\n        \"started_at\": \"2021-05-12T07:19:08.884Z\",\n        \"completed_at\": \"2021-05-12T07:19:08.884Z\"\n    }\n}\n\n```\n\n\nThe state field is used to store data that's required to run batched\nmigrations.\n\nFor example, for batched migrations we store a slice number and a task id\nfor\n\ncurrent Elasticsearch reindex operation and we update the state after every\nrun.\n\n\nThis is how an example migration looks:\n\n\n```ruby\n\nclass MigrationName \u003C Elastic::Migration\n  def migrate\n    # Migrate the data here\n  end\n\n  def completed?\n    # Return true if completed, otherwise return false\n  end\nend\n\n```\n\n\nThis looks a lot like [Rails DB\nmigrations](https://guides.rubyonrails.org/active_record_migrations.html),\n\nwhich was our goal from the beginning. The main difference is that it has an\nadditional method to\n\ncheck if a migration is completed. We've added that method because we need\nto\n\nexecute asynchronous tasks quite often and we want to check if it's\ncompleted\n\nlater in a different worker process.\n\n\n## Migration framework logic\n\n\nThis is a simple flow chart to demonstrate the high level logic of the new\nmigration framework.\n\n\n```mermaid\n\ngraph TD\n    CRON(cron every 30 minutes) --> |executes| WORKER[MigrationWorker]\n    WORKER --> B(an uncompleted migration is found)\n    B --> HALT(it's halted)\n    B --> UN(it's uncompleted)\n    B --> COMP(it's finished)\n    HALT --> WARN(show warning in the admin UI)\n    WARN --> EX(exit)\n    UN --> PREF(migration preflight checks)\n    PREF --> RUN(execute the migration code)\n    COMP --> MARK(mark it as finished)\n    MARK --> EX\n```\n\n\nAs you can see above, there are multiple different states of a migration.\nFor example,\n\nthe framework allows it to be halted when it has too many failed attempts.\nIn\n\nthat case, the warning will be shown in the admin UI with a button for\nrestarting\n\nthe migration.\n\n\n![How the warning looks\nlike](https://about.gitlab.com/images/blogimages/advanced_search/halted_warning.png)\n\n\n## Configuration options\n\n\nWe've introduced many useful configuration options into the framework, such\nas:\n\n\n- `batched!` - Allows the migration to run in batches. If set, the worker\nwill\n\nre-enqueue itself with a delay which is set using the `throttle_delay`\noption\n\ndescribed below. We use this option to reduce the load and ensure that the\n\nmigration won't time out.\n\n\n- `throttle_delay` - Sets the wait time in between batch runs. This time\nshould be\n\nset high enough to allow each migration batch enough time to finish.\n\n\n- `pause_indexing!` - Pauses indexing while the migration runs. This setting\nwill\n\nrecord the indexing setting before the migration runs and set it back to\nthat\n\nvalue when the migration is completed. GitLab only uses this option when\n\nabsolutely necessary since we attempt to minimize the downtime as much as\npossible.\n\n\n- `space_requirements!` - Verifies that enough free space is available in\nthe\n\ncluster when the migration is running. This setting will halt the migration\nif the\n\nstorage required is not available. This option is used to\n\nprevent situations when your cluster runs out of space when attempting to\nexecute\n\na migration.\n\n\nYou can see the up-to-date list of options in this development\n[documentation\nsection](https://docs.gitlab.com/ee/development/elasticsearch.html#migration-options-supported-by-the-elasticmigrationworker).\n\n\n## Data migration process results\n\n\nWe implemented the Advanced Search migration framework in the 13.6 release\nand\n\nhave been improving it since. You can see some details in the original issue\n\n[#234046](https://gitlab.com/gitlab-org/gitlab/-/issues/234046). The only\n\nrequirement for this new feature is that you should create your index using\nat\n\nleast version 13.0. We have that requirement since we're heavily utilizing\n\naliases, which were introduced in 13.0. As you might know, over the last few\n\nreleases we've been working on separating different document types into\ntheir own\n\nindices. This migration framework has been a tremendous help for our\ninitiative.\n\nWe've already completed the migration of issues (in 13.8), comments (in\n13.11),\n\nand merge requests (in 13.12) with a noticeable performance improvement.\n\n\nSince we've accumulated so many different migrations over the last few\nreleases\n\nand they require us to support multiple code paths for a long period of\ntime,\n\nwe've decided to remove older migrations that were added prior to the 13.12\n\nrelease. You can see some details in this\n[issue](https://gitlab.com/gitlab-org/gitlab/-/issues/329952).\n\nWe plan to continue the same strategy in the future, which is one of the\nreasons\n\nwhy you should always upgrade to the latest minor version before migrating\nto a\n\nmajor release.\n\n\nIf you're interested in contributing to features that require Advanced\nSearch\n\nmigrations, we have a dedicated [documentation\nsection](https://docs.gitlab.com/ee/development/elasticsearch.html#creating-a-new-advanced-search-migration)\n\nthat explains how to create one and lists all available options for it.","engineering",[695,9,696],"features","workflow",{"slug":698,"featured":6,"template":699},"advanced-search-data-migrations","BlogPost","content:en-us:blog:advanced-search-data-migrations.yml","Advanced Search Data Migrations","en-us/blog/advanced-search-data-migrations.yml","en-us/blog/advanced-search-data-migrations",{"_path":705,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":706,"content":712,"config":723,"_id":725,"_type":13,"title":726,"_source":15,"_file":727,"_stem":728,"_extension":18},"/en-us/blog/amazon-linux-2-support-and-distro-specific-packages",{"title":707,"description":708,"ogTitle":707,"ogDescription":708,"noIndex":6,"ogImage":709,"ogUrl":710,"ogSiteName":685,"ogType":686,"canonicalUrls":710,"schema":711},"Amazon Linux 2 support and distro-specific packages for GitLab","Learn how to do early testing as well as how to peg your automation to the EL 7 packages until you are able to properly integrate the changes into your automation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682299/Blog/Hero%20Images/gitlab-blog-banner.png","https://about.gitlab.com/blog/amazon-linux-2-support-and-distro-specific-packages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Amazon Linux 2 support and distro-specific packages for GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2022-05-02\",\n      }",{"title":707,"description":708,"authors":713,"heroImage":709,"date":715,"body":716,"category":717,"tags":718},[714],"Darwin Sanoy","2022-05-02","GitLab’s Distribution Engineering team has been hard at work getting Amazon\nLinux 2 distro-specific packages ready in preparation for GitLab’s official\nsupport of Amazon Linux 2. Starting with Version 15.0 of GitLab, Amazon\nLinux 2 is a supported distro and packages are available for both x86 and\nGraviton ARM architectures.\n\n\n## What is Amazon Linux 2?\n\n\nAmazon Linux 2 is the next-generation Amazon Linux operating system that\nprovides a modern application environment with the most recent enhancements\nfrom the Linux community alongside long-term support. Amazon Linux 2 is\naccessible as a virtual machine image for on-premises development and\ntesting. This lets you easily develop, test, and certify your applications\nright from your local development environment. \n\n\nAccording to the AWS FAQ page for Amazon Linux 2, the primary elements of\nthis latest version of the operating system include:\n\n\n1. A Linux kernel tuned for performance on Amazon EC2.\n\n\n2. A set of core packages including systemd, GCC 7.3, Glibc 2.26, Binutils\n2.29.1 that receive Long Term Support (LTS) from\n[AWS](/blog/deploy-aws/).\n\n\n3. An extras channel for rapidly evolving technologies that are likely to be\nupdated frequently and outside the Long Term Support (LTS) model.\n\n\nAmazon Linux 2 has a support lifespan through June 20, 2024, to allow enough\ntime for users to migrate to Amazon Linux 2022.\n\n\n\n## Safely moving forward to Amazon Linux 2 packages from EL7\n\n\nWhile Amazon Linux 2 has not been officially supported before 15.0, as a\nconvenience to customers who wanted to use yum and RPM packages to install\nthe EL7 packages, GitLab configured a workaround in our packaging services\nto direct Amazon Linux 2 yum requests to the EL7 packages. If you’ve been\nusing GitLab’s yum repo registration script, you many not know that you were\nusing EL7 packages and not distro-specific packages.\n\n\nThis workaround will be deprecated and requests from Amazon Linux 2 will get\nthe distro-specific packages with the release of GitLab 15.3.0 on August 22,\n2022.\n\n\nAs a convenience for those of you who have automation that depends directly\non this workaround, we wanted to provide you with information on how to do\nearly testing as well as how to peg your automation to the EL 7 packages\nuntil you are able to properly integrate the changes into your automation.\n\n\nGitLab documentation demonstrates how to call our managed yum repository\nsetup scripts by downloading the latest copy and running it directly in [the\ninstructions for installing\ninstances](https://about.gitlab.com/install/#centos-7) and [the instructions\nfor installing\nrunners](https://docs.gitlab.com/runner/install/linux-repository.html).\n\n\nAny organization using GitLab’s EL 7 packages for Amazon Linux 2 will want\nto test with - and update to - the distro-specific packages as soon as\npossible as GitLab will only be testing Amazon Linux 2 with the Amazon Linux\n2 specific packages going forward.\n\n\nWe also understand that the timing of the testing and migration to these\npackages must be done in a coordinated cutover so that the package type does\nnot change in your existing stacks without you having made any changes. This\ncan be more important if a GitLab stack has undergone platform qualification\nfor compliance purposes.\n\n\nAmazon Linux 2 specific packages are only available for GitLab 14.9.0 and\nlater. If your automation depends directly on GitLab’s repo configuration\nscript and it is still pegged to a GitLab version prior to 14.9.0 when this\nchange becomes GA, then action must be taken to prevent breaking that\nautomation. We have devised an idempotent two-line script solution that you\ncan put in place now to prevent disruption if you are still on a pre-14.9.0\nversion at the time the new behavior of `script.rpm.sh` becomes GA on August\n22, 2022 with the release of GitLab 15.3.0.\n\n\nGitLab rake-based backup and restore will continue to work seamlessly across\nthe distro-specific package changes if you have to restore to your Amazon\nLinux 2 built stack from an EL7 backup. If you are using third-party backup,\nyou may wish to trigger a new backup immediately after transitioning to the\nnew distro packages to avoid the scenario altogether.\n\n\n## Amazon Linux 2 packages for building GitLab instances before 15.3.0\n\n\nThe following code inserts two lines of code between those originally\noutlined in [the instructions for installing using RPM\npackages](/install/#centos-7). The first one (starts with `sed`) splices in\nthe Amazon Linux 2 yum repo endpoint edits into the repository configuration\nfile created by script.rpm.sh. The second one (starts with `if yum`) cleans\nthe yum cache if the package was already installed so that the new location\nwill be used.\n\n\n> Sudo note: If you are using these commands interactively under the default\nSSH or SSM session manager user, then using `sudo su` before running this\ncode is necessary. If you are using these commands in Infrastructure as Code\n(e.g. CloudFormation userdata scripts), then sudo may cause ‘command not\nfound’ errors when the user running automation is already root equivalent.\nBe mindful about using interactively tested commands directly in your\nautomation.\n\n\n```bash\n\n#Existing packaging script from https://about.gitlab.com/install/#centos-7\n\ncurl\nhttps://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh\n| sudo bash\n\n\n#Patch to preview and/or peg Amazon Linux 2 specific packages\n\nsed -i \"s/\\/el\\/7/\\/amazon\\/2/g\" /etc/yum.repos.d/gitlab_gitlab*.repo\n\n\n#Reset the cache if the package was previously installed (not needed for\ninstalls onto a clean machine)\n\nif yum list installed gitlab-ee; then yum clean all ; yum makecache; fi\n\n\n#Existing install command (remove \"-y\" to validate package and arch mapping\nbefore install)\n\nyum install gitlab-ee -y\n\n```\n\n\n> Notice in this output that the **Version** ends in `.amazon2`. In this\ncase the **Arch** is `aarch64` - indicating 64-bit Graviton ARM.\n\n\n![Resolved GitLab\nDependencies](https://about.gitlab.com/images/blogimages/2022-04-amazon-linux-2/gl-instance-dependencies-resolved.png)\n\n\n### Moving to Amazon Linux 2 packages early for a seamless post-GA\ntransition\n\n\nWhen the script.rpm.sh script is cut over to always point Amazon Linux 2 to\nthe new distro-specific packages, the sed command will no longer be\nnecessary. However, sed is also idempotent and will not make edits if the\nsearch text is not found. This means you can use the sed command to switch\nover early, but not have to worry about a breaking change when the\n`script.rpm.sh` is updated.\n\n\n### Pegging EL 7 and/or a GitLab version prior to 14.9.0 for a seamless\npost-GA transition\n\n\nIf your automation is pegged to an earlier version of GitLab, you will need\nto keep using EL7 packages, and, in fact, after the cutover you would need\nto implement the opposite command (which is also idempotent to be\nimplemented now).\n\n\n```bash\n\n#Patch to peg GitLab Version to EL 7 Packages (only does something after GA\nof gitlab repo script)\n\nsed -i \"s/\\/amazon\\/2/\\/el\\/7/g\" /etc/yum.repos.d/gitlab_gitlab*.repo\n\n\n#Reset the cache if the package was previously installed (not needed for\ninstalls onto a clean machine)\n\nif yum list installed gitlab-ee; then yum clean all ; yum makecache; fi\n\n```\n\n\nJust like the sed command for taking distro-specific packages early, this\ncommand can be implemented immediately with no bad effects - which will\nseamlessly keeping your automation pegged to the EL 7 packages when\n`script.rpm.sh` is updated.\n\n\n## Amazon Linux 2 package for building GitLab Runners before 15.3.0\n\n\nThe following code inserts two lines of code between those originally\n[outlined in the\ninstructions](https://docs.gitlab.com/runner/install/linux-repository.html).\nThe first one (starts with `sed`) splices in the Amazon Linux 2 yum repo\nendpoint edits into the repository configuration file created by\nscript.rpm.sh. The second one (starts with `if yum`) cleans the yum cache if\nthe package was already installed so that the new location will be used.\n\n\n> Sudo note: If you are using these commands interactively under the default\nSSH or SSM session manager user, then using `sudo su` before running this\ncode is necessary. If you are using these commands in Infrastructure as Code\n(e.g. CloudFormation userdata scripts), then sudo may cause ‘command not\nfound’ errors when the user running automation is already root equivalent.\nBe mindful about using interactively tested commands directly in your\nautomation.\n\n\n```bash\n\n#Existing packaging script from\nhttps://docs.gitlab.com/runner/install/linux-repository.html\n\ncurl -L\n\"https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh\"\n| sudo bash\n\n\n#Patch to test or peg Amazon Linux 2 specific packages\n\nsed -i \"s/\\/el\\/7/\\/amazon\\/2/g\" /etc/yum.repos.d/runner_gitlab*.repo\n\n\n#Reset the cache if the package was previously installed (not needed for\ninstalls onto a clean machine)\n\nif yum list installed gitlab-runner; then yum clean all ; yum makecache; fi\n\n\n#Existing install command (remove \"-y\" to validate package and arch mapping\nbefore install)\n\nyum install gitlab-runner -y\n\n```\n\n\n> Notice in this output that **Version** is not distro-specific. In this\ncase the **Arch** is `aarch64` - indicating 64-bit Graviton ARM.\n\n\n![Resolved GitLab Runner\nDependencies](https://about.gitlab.com/images/blogimages/2022-04-amazon-linux-2/gl-runner-dependencies-resolved.png)\n\n\n## Pegging to EL 7 and/or a GitLab Runner version prior to 14.9.1 for a\nseamless post-GA transition\n\n\nThe underlying package for EL 7 and Amazon Linux 2 is literally a copy of\nthe same package. However, the Amazon Linux 2 endpoint for Runner RPM\npackages have only been uploaded from GitLab Runner 14.9.1 and later, so if\nyou have runners that need to be on an earlier version, you would need to\nstay pointed at EL 7 for those packages to continue to resolve as available.\nThe following code shows how to do that for GitLab Runner.\n\n\n```bash\n\n#Patch to peg GitLab Version to EL 7 Packages (only does something after GA\nof gitlab repo script)\n\nsed -i \"s/\\/amazon\\/2/\\/el\\/7/g\" /etc/yum.repos.d/runner_gitlab*.repo\n\n\n#Reset the cache if the package was previously installed (not needed for\ninstalls onto a clean machine)\n\nif yum list installed gitlab-runner; then yum clean all ; yum makecache; fi\n\n```\n\n\n## Need-to-know takeaways\n\n\n- Amazon Linux 2 is a supported distro for GitLab instances and runner as of\nthe release of version 15.0 on May 22, 2022.\n\n- Amazon Linux 2 packages are available for x86 and ARM for GitLab Version\n14.9.0 and higher. (Prior to 14.9.0 the EL7 packages must be used as they\nhave a long version history).\n\n- This is the first availability of ARM RPM packages of GitLab for Amazon\nLinux 2.\n\n- In 15.3 (August 22, 2022), the script.rpm.sh will automatically start\ndirecting to the Amazon Linux 2 packages where it had previously directed\nAmazon Linux 2 yum requests to the EL7 packages.\n\n- It is common to have taken a dependency directly on the latest version of\nthis GitLab script in other automation.\n\n- Before the GA cutover date of August 22, 2022 (15.3.0 GitLab Release), for\nthese scripts, you have the opportunity to pre-test these packages and\ndetermine whether they create any issues with your automation or GitLab\nconfiguration.\n\n- You can also peg to the Amazon Linux 2 packages early or peg to the EL7\npackages in advance if you find problems that you need more time to resolve.\nBoth of these pegging types are idempotent, meaning the code changes do not\ndo anything that causes problems after the change over happens.\n\n- Existing Amazon Linux 2 installations that were installed using the EL7\npackages can use a regular yum upgrade command to start using the new Amazon\nLinux 2 packages. This operation may also be an upgrade of the product\nversion at the same time. For existing installations you will need to patch\nthe yum repo files as explained in this article in order to upgrade directly\nto Amazon Linux 2 from EL7 using packages. \n\n\n> **Note**\n\n> This blog post and linked pages contain information related to upcoming\nproducts, features, and functionality. It is important to note that the\ninformation presented is for informational purposes only. Please do not rely\non this information for purchasing or planning purposes. As with all\nprojects, the items mentioned in this blog post and linked pages are subject\nto change or delay. The development, release, and timing of any products,\nfeatures, or functionality remain at the sole discretion of GitLab Inc.\n\n\n![AWS Partner\nLogo](https://about.gitlab.com/images/blogimages/2022-04-amazon-linux-2/awsgravitonready.png){:\n.right}\n","news",[9,719,720,721,722],"CI","CD","tutorial","AWS",{"slug":724,"featured":6,"template":699},"amazon-linux-2-support-and-distro-specific-packages","content:en-us:blog:amazon-linux-2-support-and-distro-specific-packages.yml","Amazon Linux 2 Support And Distro Specific Packages","en-us/blog/amazon-linux-2-support-and-distro-specific-packages.yml","en-us/blog/amazon-linux-2-support-and-distro-specific-packages",{"_path":730,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":731,"content":737,"config":743,"_id":745,"_type":13,"title":746,"_source":15,"_file":747,"_stem":748,"_extension":18},"/en-us/blog/api-v3-removal-impending",{"title":732,"description":733,"ogTitle":732,"ogDescription":733,"noIndex":6,"ogImage":734,"ogUrl":735,"ogSiteName":685,"ogType":686,"canonicalUrls":735,"schema":736},"Breaking change: Support for API v3 will be removed June 4","With the removal of deprecated GitLab API v3 in GitLab 11.0, requests to the API v3 will fail.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/api-v3-removal-impending","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Breaking change: Support for API v3 will be removed June 4\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"James Ramsay\"}],\n        \"datePublished\": \"2018-06-01\",\n      }",{"title":732,"description":733,"authors":738,"heroImage":734,"date":740,"body":741,"category":300,"tags":742},[739],"James Ramsay","2018-06-01","\nOn June 4, 2018 integrations using API v3 connected to GitLab.com will stop\nworking. With the release of GitLab 11 on June 22, 2018 the API v3 will be\nremoved completely. **Update all integrations before June 4 to avoid downtime.**\n\n\u003C!-- more -->\n\nIn the GitLab 8.17 release post, we announced the [deprecation of API v3](/releases/2017/02/22/gitlab-8-17-released/), and that support for API\nv3 would be dropped in a future release.\n\nPlease ensure that you upgrade any integrations to API v4 to avoid any\ndowntime. Documentation is available for [upgrading from v3 to v4](https://docs.gitlab.com/ee/update/).\n\n## When will this happen?\n\nThe API v3 will be removed in GitLab 11.0 on 22 June, 2018.\nPlease consider that integrations using API v3 connected to GitLab.com will\nstop working as soon as the first RC is deployed to production, and this will\nhappen around 4 June, 2018. **Update all integrations before this date**.\n",[717,9,232],{"slug":744,"featured":6,"template":699},"api-v3-removal-impending","content:en-us:blog:api-v3-removal-impending.yml","Api V3 Removal Impending","en-us/blog/api-v3-removal-impending.yml","en-us/blog/api-v3-removal-impending",{"_path":750,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":751,"content":756,"config":762,"_id":764,"_type":13,"title":765,"_source":15,"_file":766,"_stem":767,"_extension":18},"/en-us/blog/auto-devops-enabled-by-default",{"title":752,"description":753,"ogTitle":752,"ogDescription":753,"noIndex":6,"ogImage":734,"ogUrl":754,"ogSiteName":685,"ogType":686,"canonicalUrls":754,"schema":755},"Auto DevOps will be enabled by default as part of GitLab’s 11.3 release","GitLab 11.3 will bring the power of Auto DevOps to every user","https://about.gitlab.com/blog/auto-devops-enabled-by-default","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Auto DevOps will be enabled by default as part of GitLab’s 11.3 release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Gruesso\"}],\n        \"datePublished\": \"2018-09-10\",\n      }",{"title":752,"description":753,"authors":757,"heroImage":734,"date":759,"body":760,"category":300,"tags":761},[758],"Daniel Gruesso","2018-09-10","\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) was made generally available in GitLab’s 11.0 release and, while it has had great adoption,\nwe want all of GitLab's users to take advantage of its great features. From Auto Build to Auto Monitoring,\nAuto DevOps brings valuable benefits out of the box.\n\nAt GitLab, one of our product values is to [default to on](https://handbook.gitlab.com/handbook/product/product-principles/#configuration-principles).\nWhen we introduce a new configurable feature we know to be of great value, we will default to ON so that everyone can\nbenefit from it. While Auto DevOps supports projects using the most popular programming languages, there may be some\nspecialized projects for which additional configuration is required. Therefore, before we\nenable it for everyone, we want to ensure we will not be running Auto DevOps pipelines for projects\nthat are not supported. To that end, we will [disable auto devops automatically](https://gitlab.com/gitlab-org/gitlab-ce/issues/39923)\nif a pipeline fails. GitLab will notify the project owner of this attempt so they can make the necessary configuration\nchanges to work with auto devops if desired.\n\nWe will initially enable this feature gradually on gitlab.com and monitor its performance. Barring any\nissues, we will enable it as part of our 11.3 release for self-managed customers on September 22nd, 2018.\n\nWe hope that everyone will benefit from the great features Auto DevOps brings. You can read more\nabout [Auto DevOps here](https://docs.gitlab.com/ee/topics/autodevops).\n",[695,717,9],{"slug":763,"featured":6,"template":699},"auto-devops-enabled-by-default","content:en-us:blog:auto-devops-enabled-by-default.yml","Auto Devops Enabled By Default","en-us/blog/auto-devops-enabled-by-default.yml","en-us/blog/auto-devops-enabled-by-default",{"_path":769,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":770,"content":775,"config":785,"_id":787,"_type":13,"title":771,"_source":15,"_file":788,"_stem":789,"_extension":18},"/en-us/blog/being-a-better-ally",{"title":771,"description":771,"ogTitle":771,"ogDescription":771,"noIndex":6,"ogImage":772,"ogUrl":773,"ogSiteName":685,"ogType":686,"canonicalUrls":773,"schema":774},"Being A Better Ally","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679611/Blog/Hero%20Images/cook-county-blog-unsplash.jpg","https://about.gitlab.com/blog/being-a-better-ally","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Being A Better Ally\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2020-09-09\",\n      }",{"title":771,"description":771,"authors":776,"heroImage":772,"date":778,"body":779,"category":780,"tags":781},[777],"David O'Regan","2020-09-09","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nI’ve been at GitLab five months now - with every merge request committed and milestone met, GitLab team members collaborate on innovative and efficient methods of delivering some of the world's best software. Besides this, I’ve also noticed that GitLab team members do a superb job of creating an environment that allows each of our peers to contribute, be heard, and bring their whole selves to work. Once you’ve gotten a taste of being part of that kind of community you get to see how much it matters in writing good code - talented and inclusive teams are more creative, efficient, and happier in the workplace.\n\nThe Gitlab Handbook offers amazing explanations about our values and resources for living them to your best ability. One of our values ‘Diversity, Inclusion, and Belonging’ has the following note on this value that I really appreciate:\n\n> “... Diversity is having a seat at the table, Inclusion is having a voice and feeling empowered to use it, and Belonging is acknowledgement of your voice being heard along with creating an environment where team members feel secure to be themselves...”\n\nAnyone can, and everyone should strive to nurture these values. For myself, as a person with intersecting levels of privilege who is not a member of an underrepresented group, allyship is a fantastic way to help build a better working environment. Though, being honest, if you asked me 6 months ago what allyship meant, I couldn't have told you. Going over the Handbook was a great start and I highly encourage it, as was working through my own [diversity training](https://gitlab.com/gitlab-com/diversity-and-inclusion/-/issues/127) but I also wanted to put together a small piece for anyone else getting started on their journey in allyship. Something my old bodybuilding coach [Blue Shinners](https://www.independent.ie/lifestyle/big-and-beautiful-26331156.html) used to tell me came to mind when I started the learning process;\n\n> It's not complicated, but that doesn't make it easy - Blue Shinners\n\nFor context on this piece, I want to let you know the following:\nI am a white, cisgender male (pronouns: he|him|his). I also have a lot of privilege along other lines of intersectionality (e.g. heterosexual, neurotypical, a citizen of an affluent, peaceful nation, etc).\n\nI am far from an expert in the field of allyship or building inclusive work environments, so I’m relying on my lived experiences and what I’ve learned from reading and listening to others. Regarding scope, I am committed to using my position within GitLab to help foster an inclusive and diverse environment aligned with GitLab’s core values.\n\nI’ve got to say - for me, becoming a better ally looks a lot more like a patchwork of small bursts of reading, learning little bits in social interactions, being corrected here and there, apologizing, and using what I’ve learned to do better. It isn’t always tidy, but if I were to lay my journey out in general steps, it would look a little something like this:\nGetting excited about learning and listening, making space, and making spaces inclusive. Contributing to a better culture, where and how you can. If you see something, (and it’s safe for you to do so,) say something. Though most of all accept that you will make mistakes, and strive for course correction.\n\nI personally make a lot of mistakes. The uncomfortable truth about making mistakes is they are part of lifeand more part of living honestly. Alan Watts very famously said that you do not know where your choices come from when you live honestly, and this can cause you to fumble as you explore like a toddler taking their first steps. One of the most difficult things I have ever done is to honestly level the question at myself;\n\n> If you make mistakes in all other areas of life, is it possible you also make mistakes in this area?\n\nThe natural instinct is to pull back in ~~anger~~(fear), claiming you are a good person and would never intentionally set out to treat people differently based on something as shallow as how they look or present themseleves. Regardless of how you feel, making mistakes is inevitable purely due to the fact that without a well thought out dose of empathy, you simply cannot assume someone else's situation nor experience.\n\n### Getting excited about learning and listening\n\nSearch for answers - you don’t have to know everything about the historical and cultural basis of social injustice, but I know that even a few articles or YouTube videos here and there have made the difference in giving me a better foundation for understanding, open-mindedness, kindness, and better conduct.\n\nListen to your peers, partners, and colleagues when they share their experiences or important pieces of news with you - and be willing to share yours, if asked.\n\nKnow your [‘-isms’](https://en.wikipedia.org/wiki/-ism) and learn about unconscious biases - especially your own. If you haven’t experienced certain kinds of prejudice or discrimination it may be while until you learn about them or how you unconsciously maintain them. Knowing about them lets you make an active choice in reducing toxic behaviors in shared spaces.\n\nIf you can’t find what you’re looking for in your research, don’t be afraid to ask for help. When possible, ask the appropriate person for help, like your team supervisor, or even ask in the GitLab diversity slack channel (I personally learn a lot from this channel each day).\n\nWhen the context is more specific, ask your peers - but leave room for individuals to say no or for groups to leave anonymous feedback.\n\nKnowledge is necessary to good allyship. And it’s sufficient when paired with inclusive, affirming actions. Like with any good piece of code, go for the minimum viable product - learn more, incorporate it into your daily actions, be willing to keep adding to that knowledge base and growing.\n\n### Making space, and making spaces inclusive\n\nLearn about the space you’re in and space you occupy - for myself, this journey meant coming through the understanding that software companies are overwhelmingly composed of people that look just like me. Learning more about how and why some groups are underrepresented, even in companies like GitLab, is another important step in allyship.\n\nLooking at GitLab’s values, we’re encouraged to see others succeed and help where we can. Good allyship is about doing my best to ensure that underrepresented voices are given at least as much space as my own, both by letting people know you want their contribution with affirming and inclusive language and by showing your appreciation for those contributions by giving credit and offering praise centered on their hard work.\n\nUse common sense and be kind in your interactions with your colleagues. Don’t make assumptions. Be flexible and open-minded. Be respectful of others’ privacy and get excited about what they’re willing to share with you, from their quirks to their life story and family album. These interactions create the bond GitLab team memebers share and makes this all-remote team that you love to work with.\n\n### Contribute to a better culture, where and how you can\n\nImproving the work we do at GitLab is often about your contributions, but it’s also about how good a job we do as allies to ensure that all of our ideas and contributions receive time, consideration, and credit. As a good ally, this means remembering to uplift and make space for the most marginal voices.\n\nCelebrate intersectional as well as cross-functional collaboration by considering paired-programming or mentorship with someone new. The benefit of working at GitLab is that it is teeming with talented developers from all backgrounds. When you issue or consider a request for paired programming or mentorship, center the goals and timeline to confirm you both have the time and skills to get it all in. Be willing to meet the other person where they’re at: be flexible, respectful, and accommodating of their needs in the workplace, ask them about their experiences, be willing to share yours.\n\nShare your time and your love of code with your local community - hundreds of cities worldwide have organizations and education programs that promote programming for marginalized groups and youth. Even if it’s during traditional working hours, at GitLab, we have the flexibility of working things out with our supervisor to support the events and people that won’t wait until ‘after work’. A great example of this is the [Vue Vixens](https://www.vuevixens.org/) which are one of my personal favorites.\n\nDonate to an organization or cause that is able to do the work you can’t on your own. Did you know that GitLab has a pretty great [donation matching program proposal in the makes?](https://gitlab.com/gitlab-com/diversity-and-inclusion/-/issues/91) It’s nice to know they’ll back you up on the causes you support.\n\nIf you see something (and it’s safe for you to do so), say something. Call out discrimination - address the behavior, without labeling the person. This comes back to empathy in the workplace. Be in the shoes of the person or group experiencing the discriminatory behaviour, and be in the shoes of the person behind the behaviour. Support the marginalized person or group, to reinforce the equal value of everyone of GitLab. Addressing someone’s discriminatory behaviour and holding them accountable gives them an opportunity to adopt, adapt, and improve.\n\nWe have a lot of options in how we respond to discriminatory behavior. I go into all interactions with my team assuming good intent, and keep in mind that we are each more than our work or individual actions. I also keep in mind that while discriminatory behavior can be addressed directly and in the moment or context, it can also be addressed indirectly, or in a 1-on-1 afterwards, which can offer a more approachable context for difficult feedback.\n\nI recognize that in an ideal world, everyone would feel comfortable calling out discriminatory behavior, but it isn’t always safe for everyone to do so - especially members of the groups being discriminated against. That’s where ally’s like myself come in - inclusive spaces are about shared work, and I have more opportunities than many to help build that.\n\nAccept that you will make mistakes, and strive for course correction in all areas.\n\n“Many would-be allies fear making mistakes that could have them labeled as “-ist” or “-ic” (racist, sexist, transphobic, homophobic, etc). But as an ally, you’re also affected by a system of oppression. This means that as an ally, there is much to unlearn and learn—mistakes are expected. You need to own this as fact and should be willing to embrace the daily work of doing better.”\n\nI’ve mentioned before that this is a core takeaway for developers and team leaders alike. Whether we’re creating a merge request, bringing our true selves to work, or becoming a better ally, we should do so with a low sense of shame and no ego.\n\nYou will make mistakes. I promise. We all will. But when it comes to allyship, it won’t just be a blow to the ego. It will be to the part of ourselves that loves GitLab for the people we get to work with every day and hates the idea of hurting anyone here.\n\nSo here are some notes for getting through those sticky occasions, and iterating better when someone calls out that you haven’t been the best ally:\n\n> In simple terms: say thank you, say sorry, iterate and do better.\n\nDon't:\n\n- center around yourself\n- prioritize your intention above the impact of your actions\n- deny the other person’s lived experience, derail or deflect from the issue in your apology\n- avoid arguing semantics on how the issue was brought to your attention\n- ask that person to accept inequality or microaggressions as a fact of life\n- blame them or their actions for what happened\n- retaliate against the person either actively or passively\n\nDo:\n\n- ask if they’re okay and center their experience\n- listen to what they have to say, acknowledge what happened and your role in it\n- apologize as gracefully as possible\n- understand and learn from what happened, do your homework\n- stop the behavior and modify the pattern that led to it.\n\nKeep in mind that it’s okay to ask for the person’s feedback on what you can do to be a better ally or for a clarification on what happened was problematic, but remember to center their experience and leave the other person space to refuse (fixing the behaviour is contribution you make to a more inclusive space going forward). Where I come from, it’s mandatory to add that your owe the person a pint of Guiness down at the pub after a workplace chat... maybe a coffee chat is a better call for an all-remote company though.\n\nRemember that we are more than our work or our individual behaviors. But over time, we do become associated with a track record comprising both of those things. When our colleagues do code review or call us out, it’s an opportunity for us to grow and build better habits. And as long as we continue to iterate better, our contributions to GitLab will be more meaningful and people will see us in the light of the changes we’ve made (not the small slips along the way).\n\nTL;DR\n\nBeing an ally is an ongoing journey where we have many opportunities to contribute, collaborate, learn, get feedback, and iterate better... so pretty much the same as everything else we do at GitLab. And with this one, we grow better interactions with some of the most talented developers we’ll ever get to work with.\n\nAs with every other post, this is also a collaboration... so whether it’s further resources, suggested additions, punctuation edits, or even a few callouts that I should look out for, it’s all very welcome. It's how we all grow, it’s how I hope I am becoming a better ally.\n\nCover image by [Element5 Digital](https://unsplash.com/@element5digital) on [Unsplash](https://unsplash.com)\n{: .note}\n\n[Join us](/jobs/) at GitLab! Or consider [trying us out](/free-trial/) for free.\n\n","unfiltered",[549,782,783,9,784],"security","design","agile",{"slug":786,"featured":6,"template":699},"being-a-better-ally","content:en-us:blog:being-a-better-ally.yml","en-us/blog/being-a-better-ally.yml","en-us/blog/being-a-better-ally",{"_path":791,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":792,"content":798,"config":806,"_id":808,"_type":13,"title":809,"_source":15,"_file":810,"_stem":811,"_extension":18},"/en-us/blog/boring-solutions-faster-iteration",{"title":793,"description":794,"ogTitle":793,"ogDescription":794,"noIndex":6,"ogImage":795,"ogUrl":796,"ogSiteName":685,"ogType":686,"canonicalUrls":796,"schema":797},"Want to iterate faster? Choose boring solutions","We’ve released 106 times in 106 months, proof that boring solutions do work when it comes to software development. Here are some of our favorites.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681499/Blog/Hero%20Images/pencils2.jpg","https://about.gitlab.com/blog/boring-solutions-faster-iteration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Want to iterate faster? Choose boring solutions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-08-18\",\n      }",{"title":793,"description":794,"authors":799,"heroImage":795,"date":801,"body":802,"category":803,"tags":804},[800],"Valerie Silverthorne","2020-08-18","\n\n*bor-ing* | *bȯr-iŋ*\n\n_Definition of boring: causing weariness and restlessness through lack of interest : causing boredom : tiresome_ –– Merriam-Webster\n\nAt GitLab we’re boring and we’re proud of it. \"Use the simplest and most boring solutions for a problem, and remember that 'boring' should not be conflated with 'bad' or technical debt,\" our [handbook](https://handbook.gitlab.com/handbook/) says. \"The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors.\"\n\nAlthough this may seem like counterintuitive behavior at a fast moving software startup, boring solutions are actually grounded in both science and history. [Boyd’s Law of Iteration](https://blog.codinghorror.com/boyds-law-of-iteration/) proves that faster iteration is superior to the quality of iteration. We feel like our history of releasing 106 times in 106 months also proves this point. We’ve managed [to iterate so quickly month after month](/blog/observations-on-how-to-iterate-faster/) *because* we’ve chosen the boring solution.\n\nIf this isn’t enough to convince your team to choose the boring solution more often, we’ve rounded up a slew of boring choices we’ve made to help you make the case (and maybe speed up your software delivery).\n\n## Issue labels\n\nAn early boring solution was the choice to use issue labels to power lists on issue boards. Instead of creating a new system, the boring solution was to use what we had to make a small iteration and get entirely new functionality. (Candidly - this design decision has become a huge pain point, but it’s still a great example of a boring solution) –– [William Chia](/company/team/#williamchia), senior product marketing manager, cloud native & [GitOps](/solutions/gitops/)\n\n## Skip the new UI\nWe created documentation around using [curl](https://curl.haxx.se) against API endpoints instead of creating a new user interface. –– [Nicholas Klick](/company/team/#nicholasklick), backend engineering manager, Configure\n\nWe chose to use a JSON Web Token to authenticate with Vault vs. building out a new UI or CLI. –– [Jackie Meshell](/company/team/#jmeshell), senior product manager, Release:Release Management\n\n## Embrace a small change\nWe recently added awareness [if a security scanner isn’t enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/214392) from the project-level security dashboard. Previously there was no way to know this without going to the Configuration page. While it’s a small change, we’ve received good feedback so far, and hopefully encourages customers to take more advantage of our Gold/ Ultimate offering (and keep their applications safer!) –– [Becka Lippert](/company/team/#beckalippert), product designer, Secure\n\n## Boring = less confusing\nWe spent some time and research deciding among multi-select dropdowns, single-select dropdowns, and plain dropdowns. It was a simple but effective process and prompted team member [Austin Regnery](/company/team/#aregnery), product designer, Manage:Compliance, to comment, “Before joining GitLab I remember reading [this issue](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/443) and being really impressed by both the boring solution and data-driven decision making.\n\n## Boring can also make work easier\nWe made it easier to read the title of an issue without having to scroll back to the top of the page. We initially proposed only the title would stick, but then we did a quick solution validation and found out the MVC was to include the issue status. We paired the first iteration back from a solution that would include other objects (like MRs, epics, etc.) and chose to scope it down just to issues. We also pushed back on making other elements sticky (like the tab nav) [in the first iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/216880). –– [Mike Long](/company/team/#mikelong), product design manager, Plan & Manage\n\n## If boring doesn’t work, abandon it\nIn GitLab’s early days, we used [Gitolite](https://gitolite.com/gitolite/index.html) and the SSH key list. They were boring solutions. They were not elegant but allowed us to focus on adding value. When it no longer worked, we [changed it](/blog/gitlab-without-gitolite/). –– [Sid Sijbrandij](/company/team/#sytses), CEO\n\n## Who needs fancy?\n\nAnd if there’s any doubt that we won’t reach for something shiny when something simple will do, we’ll leave you with these two anecdotes.\n\nWe use SQL for the CI job queue. –– [Stan Hu](/company/team/#stanhu), engineering fellow\n\nAnd, when we made the decision to move from Azure to GCP, we used the most boring solution ever – a checklist (no, really, a checklist) to help us make the process seamless. We made 140 changes to that checklist, all told, but after that careful process, [we were able to migrate from Azure to GCP with no serious issues](/blog/gitlab-journey-from-azure-to-gcp/).\n\n*Read more about faster software delivery:*\n\nPro tips for a faster [CI/CD pipeline](/blog/effective-ci-cd-pipelines/)\n\nKeep your [Kubernetes runners moving](/blog/best-practices-for-kubernetes-runners/)\n\nGet [faster and more flexible pipelines](/blog/directed-acyclic-graph/)\n\nCover image by [Frank Vessia](https://unsplash.com/@frankvex?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n","insights",[805,9,695],"inside GitLab",{"slug":807,"featured":6,"template":699},"boring-solutions-faster-iteration","content:en-us:blog:boring-solutions-faster-iteration.yml","Boring Solutions Faster Iteration","en-us/blog/boring-solutions-faster-iteration.yml","en-us/blog/boring-solutions-faster-iteration",{"_path":813,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":814,"content":820,"config":826,"_id":828,"_type":13,"title":829,"_source":15,"_file":830,"_stem":831,"_extension":18},"/en-us/blog/changes-coming-to-url-structure-follow-deprecations-redirects",{"title":815,"description":816,"ogTitle":815,"ogDescription":816,"noIndex":6,"ogImage":817,"ogUrl":818,"ogSiteName":685,"ogType":686,"canonicalUrls":818,"schema":819},"Bookmark these changes: URL structure updates coming in GitLab 17.0","An overview of project and user settings URL changes, including deprecations and redirects, that will happen in 17.0.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","https://about.gitlab.com/blog/changes-coming-to-url-structure-follow-deprecations-redirects","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bookmark these changes: URL structure updates coming in GitLab 17.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christen Dybenko\"}],\n        \"datePublished\": \"2023-08-30\",\n      }",{"title":815,"description":816,"authors":821,"heroImage":817,"date":823,"body":824,"category":717,"tags":825},[822],"Christen Dybenko","2023-08-30","\nOver the next few releases GitLab will be making some changes to our URL structure. They mainly affect settings pages, but we're cleaning up a few other URLs as well. The URL structure represents the site map, and it should be both predictable and consistent.\nOver the years, page titles have begun to deviate from their original designation and these changes aim to rectify that.\nYou can see the full effect of these changes in the tables below.\n\nWe will be adding these as 301 redirects over the next few months, with a plan to remove the old routes entirely in our 17.0 release in May 2024. If you have any of these pages bookmarked, or rely on these URLs, they will continue to work up until the removal in 17.0.\n\nPlease share your feedback on this change in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/420675).\n\n## Page URL updates\nHere are the page URL updates for projects and user settings.\n\n### Project\n\n| Sidebar | Current Path | New Path |\n|---------|------|-------------|\n| Analyze / **Contributor statistics** | /-/\u003Cspan style=\"background: #fdd4cd;\">graphs\u003C/span>/{default branch name} | /-/\u003Cspan style=\"background: #c3e6cd;\">contributor_statistics\u003C/span>/{default branch name} |\n| Code / **Repository graph** | /-/\u003Cspan style=\"background: #fdd4cd;\">network\u003C/span>/{default branch name} | /-/\u003Cspan style=\"background: #c3e6cd;\">repository_graph\u003C/span>/{default branch name} |\n| Code / **Locked files** | /\u003Cspan style=\"background: #fdd4cd;\">path_locks\u003C/span> | \u003Cspan style=\"background: #c3e6cd;\">/-/locked_files\u003C/span> |\n| Monitor / **Alerts** | /-/\u003Cspan style=\"background: #fdd4cd;\">alert_management\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">alerts\u003C/span> | \n| Settings / **Webhooks** | /-/\u003Cspan style=\"background: #fdd4cd;\">hooks\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">settings/webhooks\u003C/span> | \n| Settings / **Monitor** | /-/settings/\u003Cspan style=\"background: #fdd4cd;\">operations\u003C/span> | /-/settings/\u003Cspan style=\"background: #c3e6cd;\">monitor\u003C/span> | \n\n### User settings\n\n| Sidebar | Current Path | New Path |\n|---------|------|---------|\n| User settings \u003Cbr>↳ Profile | /-/profile | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/profile | \n| User settings \u003Cbr>↳ Account | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/account | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/account |\n| User settings \u003Cbr>↳ Applications | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/applications | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/applications | \n| User settings \u003Cbr>↳ Chat | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/chat\u003Cspan style=\"background: #fdd4cd;\">\\_names\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/chat | \n| User settings \u003Cbr>↳ Personal access tokens | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/personal_access_tokens | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/personal_access_tokens | \n| User settings \u003Cbr>↳ Emails | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/emails | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/emails | \n| User settings \u003Cbr>↳ Password | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/password/edit | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/password/edit | \n| User settings \u003Cbr>↳ Notifications | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/notifications | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/notifications | \n| User settings \u003Cbr>↳ SSH keys | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/keys | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/\u003Cspan style=\"background: #c3e6cd;\">ssh\u003C/span>\\_keys | \n| User settings \u003Cbr>↳ GPG keys | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/gpg_keys | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/gpg_keys | \n| User settings \u003Cbr>↳ Preferences | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/preferences | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/preferences | \n| User settings \u003Cbr>↳ Active sessions | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/active_sessions | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/active_sessions | \n| User settings \u003Cbr>↳ Authentication log | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/\u003Cspan style=\"background: #fdd4cd;\">audit_log\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/\u003Cspan style=\"background: #c3e6cd;\">authentication_log\u003C/span> | \n| User settings \u003Cbr>↳ Usage quotas | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/usage_quotas | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/usage_quotas |\n",[717,695,9,495],{"slug":827,"featured":6,"template":699},"changes-coming-to-url-structure-follow-deprecations-redirects","content:en-us:blog:changes-coming-to-url-structure-follow-deprecations-redirects.yml","Changes Coming To Url Structure Follow Deprecations Redirects","en-us/blog/changes-coming-to-url-structure-follow-deprecations-redirects.yml","en-us/blog/changes-coming-to-url-structure-follow-deprecations-redirects",{"_path":833,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":834,"content":840,"config":848,"_id":850,"_type":13,"title":851,"_source":15,"_file":852,"_stem":853,"_extension":18},"/en-us/blog/cicd-tunnel-impersonation",{"title":835,"description":836,"ogTitle":835,"ogDescription":836,"noIndex":6,"ogImage":837,"ogUrl":838,"ogSiteName":685,"ogType":686,"canonicalUrls":838,"schema":839},"Fine-grained permissions with impersonation in CI/CD tunnel","Learn how to use use fine-grained permissions via generic impersonation in CI/CD Tunnel","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667435/Blog/Hero%20Images/tunnel.jpg","https://about.gitlab.com/blog/cicd-tunnel-impersonation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use fine-grained permissions via generic impersonation in CI/CD Tunnel\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2022-02-01\",\n      }",{"title":841,"description":836,"authors":842,"heroImage":837,"date":844,"body":845,"category":693,"tags":846},"How to use fine-grained permissions via generic impersonation in CI/CD Tunnel",[843],"Cesar Saavedra","2022-02-01","\nThe [CI/CD Tunnel](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html), which leverages the [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/), enables users to access Kubernetes clusters from GitLab CI/CD jobs. In this blog post, we review how you can securely access your clusters from your CI/CD pipelines by using generic impersonation. In addition, we will briefly cover the activity list of the GitLab Agent for Kubernetes, a capability recently introduced by GitLab, that can help you detect and troubleshoot faulty events.\n\n## Using impersonation with your CI/CD tunnel\n\nThe CI/CD Tunnel leverages the GitLab Agent for Kubernetes, which permits the secure connectivity between GitLab and your Kubernetes cluster without the need to expose your cluster to the internet and outside your firewall. The CI/CD Tunnel allows you to connect to your Kubernetes cluster from your CI/CD jobs/pipelines.\n\nBy default, the CI/CD Tunnel inherits all the permissions from the service account used to install the Agent in the cluster. However, fine-grained permissions can be used in conjunction with the CI/CD Tunnel to restrict and manage access to your cluster resources.\n\nFine-grained permissions control with the CI/CD tunnel via impersonation:\n\n- Allows you to leverage your K8s authorization capabilities to limit the permissions of what can be done with the CI/CD tunnel on your running cluster\n\n- Lowers the risk of providing unlimited access to your K8s cluster with the CI/CD tunnel\n\n- Segments fine-grained permissions with the CI/CD tunnel at the project or group level\n\n- Controls permissions with the CI/CD tunnel at the username or service account\n\nTo restrict access to your cluster, you can use impersonation. To specify impersonations, use the access_as attribute in your Agent's configuration file and use Kubernetes RBAC rules to manage impersonated account permissions.\n\nYou can impersonate:\n- The Agent itself (default)\n= The CI job that accesses the cluster\n- A specific user or system account defined within the cluster\n\n## Steps to exercise impersonation with the CI/CD Tunnel\n\nLet's go through the steps on how you can exercise impersonation with the CI/CD Tunnel.\n\n### Creating your Kubernetes cluster\n\nIn order to exercise the capabilities described above, we need a Kubernetes cluster. Although, you can use any Kubernetes distribution, for this example, we create a GKE Standard Kubernetes cluster and name it \"csaavedra-ga4k-cluster\". We select the zone and version 1.21 of Kubernetes and ensure that our cluster will have three nodes. We leave the security and metadata screens with their defaulted values and click on the create button:\n\n![Creating a GKE cluster](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/0-gke-creation.png){: .shadow.medium.center.wrap-text}\nCreating a GKE cluster\n{: .note.text-center}\n\n### Sample projects to be used\n\nLet's proceed now to this [top-level group](https://gitlab.com/tech-marketing/sandbox/gl-14-5-cs-demos), which contains three projects, which we will use to show impersonation with the CI/CD tunnel. You can do this at the project or group level. In this example, we will show setting impersonation at the project level:\n\n![Project structure in GitLab](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/1-project-struct.png){: .shadow.medium.center.wrap-text}\nProject structure in GitLab\n{: .note.text-center}\n\nProject \"ga4k\" will configure the GitLab Agent for Kubernetes and also set impersonations with the CI/CD tunnel. Project \"sample-application\" will use the CI/CD tunnel, managed by the agent, to connect to the Kubernetes cluster and execute a pipeline using different impersonations. Project \"cluster-management\" will also use the CI/CD tunnel to connect to the cluster and install the Ingress application on it.\n\nNot only does the CI/CD tunnel streamline the deployment, management, and monitoring of Kubernetes-native applications, but it also does it securely and safely by using impersonations that leverage your Kubernetes cluster's RBAC rules.\n\nProject \"ga4k\" contains and manages the configuration for the GitLab Agent for K8s called \"csaavedra-agentk\". Looking at its \"config.yaml\" file, we see that the agent points to itself for manifest projects, but most importantly, it provides CI/CD tunnel access to two projects: \"sample-application\" and \"cluster-management\". This means that these two projects' CI/CD pipelines will have access to the K8s cluster that the agent is securely connected to:\n\n![The GitLab Agent for K8s configuration](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/2-agent-config.png){: .shadow.medium.center.wrap-text}\nThe GitLab Agent for K8s configuration\n{: .note.text-center}\n\nProject \"sample-application\" has a pipeline, which we will later execute under different impersonations. And project \"cluster-management\" has a pipeline that will install only the Ingress application on the Kubernetes cluster, as configured in its helmfile.yaml file:\n\n![Deployable applications in cluster-management project](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/3-cluster-mgmt-helmfile.png){: .shadow.medium.center.wrap-text}\nDeployable applications in cluster-management project\n{: .note.text-center}\n\n### Connecting the Agent to your Kubernetes cluster\n\nLet's head back to project \"ga4k\" and connect to the Kubernetes cluster via the agent. We select agent \"csaavedra-agentk\" to register with GitLab:\n\n![List of defined agents](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/4-agents-popdown.png){: .shadow.medium.center.wrap-text}\nList of defined agents\n{: .note.text-center}\n\nThis step generates a token that we can use to install the agent on the cluster. We copy the Docker command to our local desktop for later use. Notice that the command includes the generated token, which you can also copy:\n\n![Docker command to deploy agent to your K8s cluster](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/5-docker-cmd.png){: .shadow.medium.center.wrap-text}\nDocker command to deploy agent to your K8s cluster\n{: .note.text-center}\n\nFrom a local command window, we ensure that our connectivity parameters to GCP are correct:\n\n![Checking your GCP connectivity parameters](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/6-gcp-connectivity.png){: .shadow.medium.center.wrap-text}\nChecking your GCP connectivity parameters\n{: .note.text-center}\n\nWe then add the credentials to our kubeconfig file to connect to our newly created Kubernetes cluster \"csaavedra-ga4k-cluster\" and verify that our context is set to it:\n\n![Adding your cluster credentials to your kubeconfig](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/7-adding-creds.png){: .shadow.medium.center.wrap-text}\nAdding the credentials of your cluster to your kubeconfig\n{: .note.text-center}\n\nOnce this is done, we can list all the pods that are up and running on the cluster by entering `kubectl get pods –all-namespaces`:\n\n![Listing the pods in your running cluster](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/8-listing-pods.png){: .shadow.medium.center.wrap-text}\nListing the pods in your running cluster\n{: .note.text-center}\n\nFinally, we paste the docker command that will install the GitLab Agent for Kubernetes to this cluster making sure that its namespace is \"ga4k-agent\":\n\n![Deploying the agent to your K8s cluster](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/9-pasted-docker-cmd.png){: .shadow.medium.center.wrap-text}\nDeploying the agent to your K8s cluster\n{: .note.text-center}\n\nWe list the pods one more time to check that the agent pod is up and running on the cluster:\n\n![Agent up and running on your K8s cluster](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/10-agent-up.png){: .shadow.medium.center.wrap-text}\nAgent up and running on your K8s cluster\n{: .note.text-center}\n\nThe screen will refresh and show our Kubernetes cluster connected via the agent:\n\n![Agent connected to your K8s cluster](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/11-agent-connected.png){: .shadow.large.center.wrap-text}\nAgent connected to your K8s cluster\n{: .note.text-center}\n\n### The Agent's Activity Information page\n\nClicking on the agent name takes us to the Agent's Activity Information page, which lists agent events in real time. This information can help monitor your cluster's activity and detect and troubleshoot faulty events from your cluster. Connection and token information is currently listed with more events coming in future releases:\n\n![Agent activity information page](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/12-agent-activity.png){: .shadow.small.center.wrap-text}\nAgent activity information page\n{: .note.text-center}\n\n### Deploying Ingress to your Kubernetes cluster using default impersonation\n\nBy default, the CI/CD Tunnel inherits all the permissions from the service account used to install the agent in the cluster. Per the agent's configuration, the CI/CD pipelines of the \"cluster-management\" project will have access to the K8s cluster that the agent is securely connected to. Let's leverage this connectivity to deploy the Ingress application to the Kubernetes cluster from project \"cluster-management\". Let's make a small update to the project pipeline to launch it. Once the pipeline launches, we navigate to its detail view to track its completion:\n\n![Project \"cluster-management\" pipeline completed](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/13-cluster-mgmt-pipeline.png){: .shadow.small.center.wrap-text}\nProject \"cluster-management\" pipeline completed\n{: .note.text-center}\n\nand check the log of its **apply** job to verify that it was able to switch to the agent's context and successfully ran all the installation steps:\n\n![Ingress deployed to your cluster via CI/CD Tunnel using default impersonation](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/14-apply-job-log.png){: .shadow.medium.center.wrap-text}\nIngress deployed to your cluster via CI/CD Tunnel using default impersonation\n{: .note.text-center}\n\nFor further verification, we list the pods in the cluster and check that the ingress pods are up and running:\n\n![Ingress pods up and running](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/15-ingress-pods-up.png){: .shadow.medium.center.wrap-text}\nIngress pods up and running on your cluster\n{: .note.text-center}\n\n### Start trailing the agent's log file to watch updates\n\nBefore we start the impersonation use cases, let's start trailing the agent's log file from a command window:\n\n![Trailing agent log from the command line](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/16-trail-agent-log.png){: .shadow.medium.center.wrap-text}\nTrailing agent log from the command line\n{: .note.text-center}\n\nAnd also let's increase its logging to debug:\n\n![Increasing the agent log level to debug](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/17-agent-logging-level.png){: .shadow.medium.center.wrap-text}\nIncreasing the agent log level to debug\n{: .note.text-center}\n\n### Running impersonation using access_as:ci_job\n\nLet's now impersonate the CI job that accesses the cluster. For this, we modify the agent's configuration and add the \"access_as\" attribute with the \"ci_job\" tag under it:\n\n![Impersonating the CI job](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/18-ci-job-impersonation.png){: .shadow.medium.center.wrap-text}\nImpersonating the CI job\n{: .note.text-center}\n\nAs we save the updated configuration, we verify in the log output that the update has taken place in the running agent:\n\n![Agent updated with CI job impersonation](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/19-agent-conf-updated.png){: .shadow.large.center.wrap-text}\nAgent updated with CI job impersonation\n{: .note.text-center}\n\nNotice that the pipeline of the \"sample-application\" project has a test stage and a test job. It sets the variable KUBE_CONTEXT first, loads an image with the version of kubectl that matches the version of the K8s cluster, and executes two kubectl commands that access the remote cluster via the agent:\n\n![Project \"sample-application\" pipeline](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/20-sample-application-pipeline.png){: .shadow.medium.center.wrap-text}\nProject \"sample-application\" pipeline\n{: .note.text-center}\n\nWe manually execute the pipeline of the \"sample-application\" project and verify in the job log output that the context switch was successful and that the kubectl commands executed correctly:\n\n![Job log output with CI impersonation](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/21-ci-impersonation-job-log.png){: .shadow.medium.center.wrap-text}\nJob log output with CI impersonation\n{: .note.text-center}\n\n### Running impersonation using access_as:impersonate:username\n\nThe last use case is the impersonation of a specific user or system account defined within the cluster. I have pre-created a service account called \"jane\" on the Kubernetes cluster under the \"default\" namespace. And \"jane\" has been given the permission to do a \"get\", \"list\", and \"watch\" on the cluster pods as you can see by the output in the command window:\n\n![Jane user with permission to list pods](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/22-jane-and-perms.png){: .shadow.medium.center.wrap-text}\nJane user with permission to list pods\n{: .note.text-center}\n\nRemember that the service account \"gitlab-agent\" under namespace \"ga4k-agent\" was created earlier when we installed the agent by running the Docker command. In order for the agent to be able to impersonate another service account or user, it needs to have the permissions to do so. We do this by creating a clusterrole \"impersonate\" for impersonating users, groups, and service accounts, and then create a clusterrolebinding \"allowimpersonator\" to give these permissions for the \"default\" namespace to the agent \"gitlab-agent\" in the \"ga4k-agent\" namespace:\n\n![Giving impersonation permission to agent](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/23-clusterrole-perm-to-agent.png){: .shadow.large.center.wrap-text}\nGiving impersonation permission to agent\n{: .note.text-center}\n\nWe then edit the agent's configuration and add the \"impersonate\" attribute and provide the service account for \"jane\" as the parameter for the \"username\" tag:\n\n![Impersonating a specific user](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/24-user-impersonation.png){: .shadow.medium.center.wrap-text}\nImpersonating a specific user called jane\n{: .note.text-center}\n\nAs we commit the changes, we check the log output to verify that the update has taken place in the running agent:\n\n![Agent updated with user impersonation](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/25-agent-conf-updated.png){: .shadow.large.center.wrap-text}\nAgent updated with user impersonation\n{: .note.text-center}\n\nSince we know that \"jane\" has the permission to list the running pods in the cluster, let's head to the project \"sample-application\" pipeline and add the command \"kubectl get pods –all-namespaces\" to it:\n\n![Adding get pods command that jane is allowed to run](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/26-adding-get-pods-cmd.png){: .shadow.medium.center.wrap-text}\nAdding get pods command that jane is allowed to run\n{: .note.text-center}\n\nWe commit the update and head over to the running pipeline and drill into the \"test\" job log output to see that the context switch was successful and that the kubectl commands executed correctly, including the listing of the running pods in the cluster:\n\n![Job output for pipeline impersonation jane](https://about.gitlab.com/images/blogimages/cicd-tunnel-impersonate/27-user-impersonation-job-log.png){: .shadow.medium.center.wrap-text}\nJob output for pipeline impersonation jane\n{: .note.text-center}\n\n## Conclusion\n\nIn this blog post, we reviewed how you can securely access your Kubernetes clusters from your CI/CD pipelines by using generic impersonation.  In addition, we showed the activity list of the GitLab Agent for Kubernetes, which can help you detect and troubleshoot faulty events from your cluster.\n\nTo see these capabilities in action, check out the following video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/j8SJuHd7Zsw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by Jakob Søby on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[9,719,720,847],"kubernetes",{"slug":849,"featured":6,"template":699},"cicd-tunnel-impersonation","content:en-us:blog:cicd-tunnel-impersonation.yml","Cicd Tunnel Impersonation","en-us/blog/cicd-tunnel-impersonation.yml","en-us/blog/cicd-tunnel-impersonation",{"_path":855,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":856,"content":861,"config":867,"_id":869,"_type":13,"title":870,"_source":15,"_file":871,"_stem":872,"_extension":18},"/en-us/blog/composition-analysis-group-deprecations",{"title":857,"description":858,"ogTitle":857,"ogDescription":858,"noIndex":6,"ogImage":734,"ogUrl":859,"ogSiteName":685,"ogType":686,"canonicalUrls":859,"schema":860},"Announcing 14.6 Composition Analysis deprecations and behavior changes","Upcoming deprecations and behavior changes for the Dependency Scanning and License Compliance features.","https://about.gitlab.com/blog/composition-analysis-group-deprecations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Announcing 14.6 Composition Analysis deprecations and behavior changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nicole Schwartz\"}],\n        \"datePublished\": \"2021-12-13\",\n      }",{"title":857,"description":858,"authors":862,"heroImage":734,"date":864,"body":865,"category":717,"tags":866},[863],"Nicole Schwartz","2021-12-13","\n\nThe Composition Analysis group would like to announce two deprecations and one change in a variable's behavior with the 14.6 and December 22, 2021, release.\n\n- Variable DS_EXCLUDED_PATHS behavior changed so that it now pre-filters.\n- Dependency Scanning is deprecating bundler-audit.\n- License Compliance is deprecating “approved” and “blacklisted” from the `managed_licenses` API.\n\n## Variable DS_EXCLUDED_PATHS behavior now pre-filters\n\nFor users of the Dependency Scanning variable DS_EXCLUDED_PATHS, it will now pre-filter. Dependency Scanning now considers DS_EXCLUDED_PATHS when searching for supported projects and will pre-filter out those that match. Pre-filtering prevents the analyzer from logging warnings or failing when processing dependency files that have been explicitly excluded using DS_EXCLUDED_PATHS. This enables users to skip dependency files and build files if desired, and can lead to a performance increase in some cases. \n\nThis change was made December 2, 2021, for Gemnasium; December 6, 2021, for gemnasium-python; and December 7, 2021, for gemnasium-maven. This change applies to all versions as the change is backported. \n\nYou should not need to take any action. However, if you were expecting this post-filtering behavior, and wrote custom tooling to handle that, you will need to adjust your custom tools. For example, before this change, you may have needed to manually, or using a script, delete specific files to avoid a warning or error occurring.\n\nThe previous behavior was causing failures and unexpected errors for users and, after discussions, we found that this, pre-filter as opposed to post filter, was the more expected and desired behavior.\n\n[Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/292457)\n\n[Configuration Documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-dependency-scanning) \n\n## Deprecation of bundler-audit Dependency Scanning tool\n\nAs of 14.6, bundler-audit is being deprecated from Dependency Scanning. It will continue to be in our CI/CD template while deprecated. We are removing bundler-audit from Dependency Scanning on May 22, 2022, in 15.0. After this removal Ruby scanning functionality will not be affected as it is still being covered by Gemnasium.\n\nIf you have explicitly excluded bundler-audit using DS_EXCLUDED_ANALYZERS, you will need to clean up (remove the reference) in 15.0. If you have customized your pipeline's Dependency Scanning configuration – for example, to edit the `bundler-audit-dependency_scanning` job – you will want to switch to gemnasium-dependency_scanning before removal in 15.0, to prevent your pipeline from failing. If you have not used the DS_EXCLUDED_ANALYZERS to reference bundler-audit, or customized your template specifically for bundler-audit, you will not need to take action.\n\n[Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/289832) \n\nSee all upcoming deprecations on our [Deprecation Page](https://docs.gitlab.com/ee/update/deprecations) \n\n## Deprecate legacy approval status names from the License Compliance API\n\nWe deprecated legacy names for approval status of license policy (blacklisted, approved) in the `managed_licenses` API but they are still used in our API queries and responses. They will be removed in 15.0. \n\nIf you are using our License Compliance API, you should stop using the “approved” and “blacklisted” query parameters. They are now “allowed” and “denied\". In 15.0, the responses will also stop using “approved” and “blacklisted”. You will want to adjust any of your custom tools to be able to use the old and new values so they do not break with the 15.0 release. \n\n[Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/335707) \n\nSee all upcoming deprecations on our [Deprecation Page](https://docs.gitlab.com/ee/update/deprecations)\n",[695,9],{"slug":868,"featured":6,"template":699},"composition-analysis-group-deprecations","content:en-us:blog:composition-analysis-group-deprecations.yml","Composition Analysis Group Deprecations","en-us/blog/composition-analysis-group-deprecations.yml","en-us/blog/composition-analysis-group-deprecations",{"_path":874,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":875,"content":881,"config":890,"_id":892,"_type":13,"title":893,"_source":15,"_file":894,"_stem":895,"_extension":18},"/en-us/blog/creationline-post",{"title":876,"description":877,"ogTitle":876,"ogDescription":877,"noIndex":6,"ogImage":878,"ogUrl":879,"ogSiteName":685,"ogType":686,"canonicalUrls":879,"schema":880},"Meet Creationline team members who contribute to GitLab","Creationline contributes to GitLab as a reseller. Three team members explain how it works.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673096/Blog/Hero%20Images/contributors-cover.png","https://about.gitlab.com/blog/creationline-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet Creationline team members who contribute to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-11-27\",\n      }",{"title":876,"description":877,"authors":882,"heroImage":878,"date":884,"body":885,"category":886,"tags":887},[883],"Ray Paik","2019-11-27","\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm\nexcited to introduce Creationline, which is a [GitLab reseller in Japan](/resellers/creationline/). As you read this blog post, you will find Creationline is not a typical reseller. Their team were able to help both their customers and the GitLab community through their contributions. Here's what three Creationline employees had to share with us.\n\n## Decision to partner with Gitlab and contributing as a reseller\n#### [Jean-Baptiste Vasseur](https://gitlab.com/jvasseur), Agile Coach and DevOps Consultant\n\nWhen we explored the [DevOps](/topics/devops/) landscape about 3 years ago, we accidentally came across [GitLab’s handbook](https://handbook.gitlab.com/handbook/). This was a revelation for us! Pushing transparency to a point where job applicants know how GitLab members are expected to behave with candidates, a company culture where people are not afraid to communicate their failures, published company business targets and how the team is planning to achieve them, and of course how an open source software philosophy applied to every aspect of GitLab. We felt connected to so many aspects of GitLab’s company culture that I wanted to find a way to work together.\n\nAs [Creationline](http://www.creationline.com/gitlab) was already reselling licenses for other cloud and DevOps companies, and as GitLab was looking for more partners in different countries at that time, we felt confident we had a very good match and started distributing GitLab licenses in June, 2017.\n\nI usually invest a lot of my time prospecting clients, providing technical and value chain consulting, and contributing to the local community by co-organizing meetups and delivering CI/CD workshops. While I also love writing code – I come from an engineering background – it's a challenge to find the time to make open source contributions. However, while I was consulting for a large IT firm that was developing an internal DevOps package built around GitLab, I had an opportunity to make a valuable contribution to GitLab on the company's behalf. The team had a lot of passion for the project and loved working with the GitLab product, but they got blocked by a missing API and were not comfortable enough with their English to open a merge request.\n\nAs consultants, we did not have the responsibility of adding features or fixing issues on GitLab, but I really wanted to help our client. I explored the source code, figured out the pattern/coding style, and opened my first [merge request](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22296). Review happened almost immediately, and GitLab team members were very nice and also challenged me to apply some refactoring, which helped me learn even more about the source code.\n\n![Open Source Summit Japan, 2019](https://about.gitlab.com/images/blogimages/creationline-blogpost/Creationline-OSS-Japan.jpg){: .shadow.medium.center}\nCreationline and GitLab team members at Open Source Summit-Japan\n{: .note.text-center}\n\n## Journey from an end user to a regular contributor to an evangelist\n#### [Hiroyuki Sato](https://gitlab.com/hiroponz), GitLab Evangelist\n\nI started to contribute to GitLab back in 2012. At that time I was already using GitLab at work, and I wanted to fix a bug that I was facing. This issue was preventing the source code diff from being displayed on the screen, but it was only occurring when using Japanese. As this issue was not seen in other languages, this was not a high priority bug, but it was impacting us severely. I found it very natural to fix it myself and to open a [merge request](https://github.com/gitlabhq/gitlabhq/pull/2100). In order to solve this, I also had to first fix the gem ‘grit_ext’ that GitLab was using, and created [another merge request](https://github.com/gitlabhq/grit_ext/pull/1).\n\nBoth merge requests got reviewed and merged within three days! This experience was so exciting that I started to contribute more and created [multiple merge requests](https://github.com/gitlabhq/gitlabhq/pulls?q=is%3Apr+author%3Ahiroponz+is%3Aclosed), and eventually I was awarded the [MVP](https://about.gitlab.com/community/mvp/) for GitLab's 5.1 release.\n\nLater on, as I really loved GitLab as a product, I started to explore if there was a way for me to work more closely with GitLab. This is when I met Creationline, which had just become the exclusive reseller in Japan and I decided to join them in April, 2018.\n\nNow, I am involved in pre-sales, marketing, customer support, and I also offer trainings on how to get the best out of GitLab. Of course, I still invest a part of my time to [contribute to GitLab](https://gitlab.com/groups/gitlab-org/-/merge_requests?%0Ascope=all&utf8=%E2%9C%93&state=merged&author_username=hiroponz) to help customers overcome issues/challenges, and this is one of my favorite parts of the job!\n\n## Dogfooding at Creationline\n#### [Yuko Takano](https://gitlab.com/takano_cl), Customer Success Manager\n\nAs a reseller team, we wanted to have more opportunities to use GitLab on a daily basis so we can support our customers better. We also wanted to experience the continuous server side operations, and set up our own instance so that we can capitalize on this experience.\n\nWe started using GitLab inside the GitLab reseller team, and then expanded it to various business functions within our organization. We now use a lot of GitLab features in order to manage source code, visualize our sales and marketing workflow, track translation work, organize OKRs with epics, and we continue to look for other areas to explore.\n\n![GitLab CI workshop](https://about.gitlab.com/images/blogimages/creationline-blogpost/Creationlin-GitLab-workshop.jpg){: .shadow.medium.center}\nCreationline team running the GitLab CI Workshop\n{: .note.text-center}\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can\nlearn how you can contribute to GitLab's code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n","open-source",[268,888,889,9],"open source","contributors",{"slug":891,"featured":6,"template":699},"creationline-post","content:en-us:blog:creationline-post.yml","Creationline Post","en-us/blog/creationline-post.yml","en-us/blog/creationline-post",{"_path":897,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":898,"content":904,"config":911,"_id":913,"_type":13,"title":914,"_source":15,"_file":915,"_stem":916,"_extension":18},"/en-us/blog/deprecating-the-cert-based-kubernetes-integration",{"title":899,"description":900,"ogTitle":899,"ogDescription":900,"noIndex":6,"ogImage":901,"ogUrl":902,"ogSiteName":685,"ogType":686,"canonicalUrls":902,"schema":903},"Deprecating cert-based Kubernetes integration in GitLab 14.5","Understand why we're deprecating this integration, how it might affect you, and get a closer look at GitLab Agent for Kubernetes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670635/Blog/Hero%20Images/kubernetesterms.jpg","https://about.gitlab.com/blog/deprecating-the-cert-based-kubernetes-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We are deprecating the certificate-based integration with Kubernetes in GitLab 14.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n        \"datePublished\": \"2021-11-15\",\n      }",{"title":905,"description":900,"authors":906,"heroImage":901,"date":908,"body":909,"category":717,"tags":910},"We are deprecating the certificate-based integration with Kubernetes in GitLab 14.5",[907],"Viktor Nagy","2021-11-15","\n\nWe are deprecating the certificate-based Kubernetes integration with GitLab and all the features that\nrely on it. This is the legacy integration, [introduced](/releases/2018/01/22/gitlab-10-4-released/#gitlab-clusters-now-generally-available) early in 2018, in GitLab 10.4.\n\nIn September 2020, we started to build a more robust, secure, forthcoming, and reliable integration\nwith Kubernetes and released the [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/),\nwhich is the recommended methodology to connect clusters with GitLab.\n\nIn this post, we explain the reasons for the change of path, what to expect, and how this\naffects the features that rely on the certificate-based integration with Kubernetes.\n\n## What to expect\n\nThe deprecation of the certificate-based Kubernetes integration affects all the features\nthat require a cluster connected to GitLab through cluster certificates. All those features are deprecated. The certificate-based integrations will be switched off on gitlab.com starting with the GitLab 15.0 release. Self-managed users will be able to switch the features back until their final removal. [The final removal will happen](https://gitlab.com/gitlab-org/configure/general/-/issues/199) once all the collected, critical use-cases are supported with the agent and enough time was given for our users to migrate to the agent.\n\nIn regards to the existing features that rely on the certificate-based integration:\n\n- Some of the features will be migrated to use the GitLab Agent and we will\nprovide you with migration guides to help you follow along. We will communicate them\nthrough the following releases in our release posts, as usual.\n- If you already use features that depend on cluster certificates, you can keep using\nthem. But note that you might need to take extras steps in the future to migrate them\nto the Agent. However, we **do not** guarantee that we will migrate all the existing\ncertificate-based features to the Agent.\n- Existing users should not expect new functionality except for the developments required to support more recent Kubernetes versions, security and critical fixes, and community contributions. \n- If you currently do not use a deprecated feature and regardless decide to use it anyway,\nunderstand that there's a risk of having to migrate it to the Agent later, or, in the\nworst-case scenario, you might have to stop using the feature in the future.\n\nSee the updated list of the [affected features](https://docs.gitlab.com/ee/user/infrastructure/clusters/#deprecated-features) on the docs.\n\n## What this deprecation means\n\nThe deprecation means that we will not build more features on top of the existing features\nthat depend on cluster certificates. It doesn't mean that the features will stop working right now.\n\nNew features for Kubernetes clusters will be built on top of the connection between GitLab and\nyour cluster through the Agent rather than on top of the certificate-based connection.\n\nWe have [dedicated documentation](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html) to support you migrating from the certificate-based connections to agent-based connections.\n\n## What should you do for clusters not connected to GitLab yet\n\nTo connect new clusters with GitLab, use the [Agent](https://docs.gitlab.com/ee/user/clusters/agent/)\nso that you don't have to take extra steps to use the Agent later on.\n\n## Why we deprecated the certificate-based integration with Kubernetes\n\nThere were several reasons why we decided to rethink our approach to Kubernetes:\n\n- The certificate-based integration's biggest shortcoming is that it relies on direct\naccess to the Kubernetes API. Its exposure often comes with unacceptably high risk, especially for GitLab\nSaaS users.\n- The most valuable features within the integration required elevated privileges, often\nrequiring you to give cluster-admin rights to GitLab. At the same time, features that did\nnot need these privileges could not be restricted with more limited access. This means\nthat you had to grant full access to a rather simple feature, which could turn out as a liability.\n- Feedback from users implied that many of the features were never ready for production and\ncould be used only in limited situations.\n- The industry progressed, and pull-based deployments started to gain ground. And this approach\nwas mostly unknown when we built the integration.\n\nWe decided to address all these shortcomings with the GitLab Agent.\n\n## The advantages of the GitLab Agent\n\nThe integration with Kubernetes through the Agent provides many benefits compared to the\ncertificate-based integration, such as:\n\n- Security\n- Reliability\n- Scalability\n- Speed\n- Functionality\n\nCompared to the certificate-based integration, the Agent offers the following functionalities:\n\n- Configure your cluster through code. This enables a clear separation of duties and you can use well-known merge request workflows and approvals.\n- An agent can be configured using regular Kubernetes RBAC rules, maintaining access\nto your cluster safe.\n- Scaling to multiple environments is trivial as each agent connects to one environment.\n- An agent's connection to a cluster can be shared by other groups and projects to simplify\ncoordination and maintenance.\n- The Agent supports pull-based deployments, enabling modern GitOps approaches.\n- The Agent supports push-based deployments, enabling existing GitLab CI/CD workflows to\nremain functional.\n- Having a bi-directional channel between GitLab and the cluster enables a new set of integrations,\nlike surfacing container network security policy alerts and container scan results into GitLab.\n\n## What is next on the roadmap of the GitLab Agent\n\nWe identified a few high-value features on the list of deprecated features. Moreover, we know\nthat having some level of observability around the resources managed by the Agent is\nits biggest shortcoming. As a result, we are going to focus on the following three items first:\n\n- Provide [observability features for cluster resources](https://gitlab.com/groups/gitlab-org/-/epics/2493) so you can track your metrics and logs directly from GitLab.\n- [Auto DevOps and especially Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy) can already by used on top of an Agent-based connection, but the setup is not easy. We will provide you with a solution soon.\n- [GitLab-Managed Clusters](https://docs.gitlab.com/ee/user/project/clusters/gitlab_managed_clusters.html#gitlab-managed-clusters-deprecated) are expected to work as they do today until we ship an equivalent or superior functionality\nbuilt around the Agent. Together with shipping this functionality, we will provide a migration guide if necessary.\n\n## We are listening\n\nPlease help us to help you. We need your feedback to help us prioritize the migration of the\ncurrent features to the Agent and to build new features based on the Agent. We are especially seeking\nfeed back around real-world, high-scale usage of the features built for using Kubernetes clusters with GitLab.\n\nIf you would be open to sharing your feedback, please start a new thread in [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8). Feel free to mention `@nagyv-gitlab` in your comment to make sure that your comment is read and the information won't be missed.\n",[847,232,9],{"slug":912,"featured":6,"template":699},"deprecating-the-cert-based-kubernetes-integration","content:en-us:blog:deprecating-the-cert-based-kubernetes-integration.yml","Deprecating The Cert Based Kubernetes Integration","en-us/blog/deprecating-the-cert-based-kubernetes-integration.yml","en-us/blog/deprecating-the-cert-based-kubernetes-integration",{"_path":918,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":919,"content":924,"config":930,"_id":932,"_type":13,"title":933,"_source":15,"_file":934,"_stem":935,"_extension":18},"/en-us/blog/docker-in-docker-with-docker-19-dot-03",{"title":920,"description":921,"ogTitle":920,"ogDescription":921,"noIndex":6,"ogImage":734,"ogUrl":922,"ogSiteName":685,"ogType":686,"canonicalUrls":922,"schema":923},"Update: Changes to GitLab CI/CD and Docker in Docker with Docker 19.03","If you are using the Docker in Docker workflow you may need to enable TLS or explicitly turn it off.","https://about.gitlab.com/blog/docker-in-docker-with-docker-19-dot-03","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Update: Changes to GitLab CI/CD and Docker in Docker with Docker 19.03\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Steve Azzopardi\"}],\n        \"datePublished\": \"2019-07-31\",\n      }",{"title":920,"description":921,"authors":925,"heroImage":734,"date":927,"body":928,"category":717,"tags":929},[926],"Steve Azzopardi","2019-07-31","\n\nLast week Docker released a new version,\n[19.03](https://docs.docker.com/engine/release-notes/#19030), which\nbrings a few exciting features with it.\n\nOne of the features affects GitLab CI/CD when using the [Docker in Docker\nworkflow](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-executor).\nAs of version 19.03, [`docker:dind`](https://hub.docker.com/_/docker)\nwill automatically generate TLS certificates and require using them for\ncommunication. This is from [Docker's official\ndocumentation](https://hub.docker.com/_/docker#tls):\n\n> Starting in 18.09+, the dind variants of this image will automatically generate TLS certificates in the directory specified by the DOCKER_TLS_CERTDIR environment variable.\n> Warning: in 18.09, this behavior is disabled by default (for compatibility). If you use --network=host, shared network namespaces (as in Kubernetes pods), or otherwise have network access to the container (including containers started within the dind instance via their gateway interface), this is a potential security issue (which can lead to access to the host system, for example). It is recommended to enable TLS by setting the variable to an appropriate value (-e DOCKER_TLS_CERTDIR=/certs or similar). In 19.03+, this behavior is enabled by default.\n\nWhen you upgrade to 19.03 (which is done automatically if using\n`docker:dind`) you may start seeing an issue like:\n\n```\ndocker: Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?.\n```\n\nTo fix the problem above you have two options:\n\n1. Configure [GitLab Runner](https://docs.gitlab.com/runner/) to use TLS.\n1. Explicitly turn off TLS.\n\nThe shared Runners available on GitLab.com support both workflows, which\nare described in detail below.\n\nYou may notice that we are now also suggesting a specific version such as\n`docker:19.03.0-dind` and not `docker:dind`. This is to help prevent users'\njobs randomly failing when a new update comes out.\n\n## Configure TLS\n\nSince the service `docker:dind` will create the certificates, we need to\nhave the certificate shared between the service and the job container.\nTo do this we have to add a mount inside of the\n[volumes](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersdocker-section)\nunder the `[runners.docker]` section.\n\nFor example:\n\n```toml\n[[runners]]\n  name = \"My Docker Runner\"\n  url = \"http://gitlab.com\"\n  token = \"\"\n  executor = \"docker\"\n  [runners.custom_build_dir]\n  [runners.docker]\n    privileged = true\n    volumes = [\"/certs/client\", \"/cache\"]\n    shm_size = 0\n```\n\nIf you're a GitLab.com user, we've already done the config change above for you on the\nShared Runners.\n\nAlso, update `.gitlab-ci.yml` accordingly to specify the\n`DOCKER_TLS_CERTDIR`\n\n```yml\nimage: docker:19.03.0\n\nvariables:\n  DOCKER_DRIVER: overlay2\n  # Create the certificates inside this directory for both the server\n  # and client. The certificates used by the client will be created in\n  # /certs/client so we only need to share this directory with the\n  # volume mount in `config.toml`.\n  DOCKER_TLS_CERTDIR: \"/certs\"\n\nservices:\n  - docker:19.03.0-dind\n\nbefore_script:\n  - docker info\n\nbuild:\n  stage: build\n  script:\n    - docker build -t my-docker-image .\n    - docker run my-docker-image /script/to/run/tests\n```\n\n## Disable TLS\n\nYou might not have access to update the volume mounting inside of the\n`config.toml`, so the only option is to disable TLS. You can do this by\nsetting the environment variable `DOCKER_TLS_CERTDIR` to an empty value.\n\nFor GitLab.com Shared Runners users this is done already using the\n[environment settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section),\nwhich works the same way.\n\n```yml\nimage: docker:19.03.0\n\nvariables:\n  DOCKER_DRIVER: overlay2\n  DOCKER_TLS_CERTDIR: \"\"\n\nservices:\n  - docker:19.03.0-dind\n\nbefore_script:\n  - docker info\n\nbuild:\n  stage: build\n  script:\n    - docker build -t my-docker-image .\n    - docker run my-docker-image /script/to/run/tests\n```\n\nWe would like to thank the rest of the community with all the feedback\nand help throughout\n[#4501](https://gitlab.com/gitlab-org/gitlab-runner/issues/4501).\n\n",[9,108],{"slug":931,"featured":6,"template":699},"docker-in-docker-with-docker-19-dot-03","content:en-us:blog:docker-in-docker-with-docker-19-dot-03.yml","Docker In Docker With Docker 19 Dot 03","en-us/blog/docker-in-docker-with-docker-19-dot-03.yml","en-us/blog/docker-in-docker-with-docker-19-dot-03",{"_path":937,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":938,"content":943,"config":950,"_id":952,"_type":13,"title":953,"_source":15,"_file":954,"_stem":955,"_extension":18},"/en-us/blog/git-protocol-v2-enabled-for-ssh-on-gitlab-dot-com",{"title":939,"description":940,"ogTitle":939,"ogDescription":940,"noIndex":6,"ogImage":734,"ogUrl":941,"ogSiteName":685,"ogType":686,"canonicalUrls":941,"schema":942},"Git Protocol v2 now enabled for SSH on GitLab.com","Fetch faster using Git Protocol v2 – here's how.","https://about.gitlab.com/blog/git-protocol-v2-enabled-for-ssh-on-gitlab-dot-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git Protocol v2 now enabled for SSH on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"James Ramsay\"}],\n        \"datePublished\": \"2018-12-10\",\n      }",{"title":939,"description":940,"authors":944,"heroImage":734,"date":945,"body":946,"category":693,"tags":947},[739],"2018-12-10","GitLab added support for [Git Protocol v2 over HTTP and SSH in GitLab\n11.4](/releases/2018/10/22/gitlab-11-4-released/#git-protocol-v2), and\nenabled Protocol v2 over HTTP on GitLab.com, but not for SSH. On Nov. 23, we\nenabled [Git Protocol v2 over SSH on\nGitLab.com](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5244).\nYou can view Git Protocol usage on our [public\ndashboard](https://dashboards.gitlab.com/d/pqlQq0xik/git-protocol-versions?refresh=5m&orgId=1).\n\n\nGit Protocol v2 is supported from Git v2.18.0 and is opt-in. To enable\nglobally, run `git config --global protocol.version 2`.\n\n\n## What Git Protocol v2 means for you\n\n\nGit 2.18 introduced support for Protocol v2, which defines how clones,\nfetches, and pushes are communicated between the client (your computer) and\nthe server (GitLab). The new [wire\nprotocol](https://www.kernel.org/pub/software/scm/git/docs/technical/pack-protocol.html)\nimproves the performance of fetch commands and enables future protocol\nimprovements. [Read more about Protocol\nv2](https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html)\nin the release post by the author of the change.\n\n\nTo see the reduction in network traffic with Protocol v2 you can run the\ncommands below:\n\n\n```\n\n# Original Git wire protocol\n\nGIT_TRACE_PACKET=1 git -c protocol.version=0 ls-remote\ngit@gitlab.com:gitlab-org/gitlab-ce.git master\n\n\n# New Git wire protocol v2\n\nGIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote\ngit@gitlab.com:gitlab-org/gitlab-ce.git master\n\n```\n\n\nIn moving from Protocol v0 to v2, on this repo the number of lines\n(\"packets\") sent behind the scenes drops from over 36,000 to fewer than 30.\n",[948,949,9],"git","production",{"slug":951,"featured":6,"template":699},"git-protocol-v2-enabled-for-ssh-on-gitlab-dot-com","content:en-us:blog:git-protocol-v2-enabled-for-ssh-on-gitlab-dot-com.yml","Git Protocol V2 Enabled For Ssh On Gitlab Dot Com","en-us/blog/git-protocol-v2-enabled-for-ssh-on-gitlab-dot-com.yml","en-us/blog/git-protocol-v2-enabled-for-ssh-on-gitlab-dot-com",{"_path":957,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":958,"content":964,"config":972,"_id":974,"_type":13,"title":975,"_source":15,"_file":976,"_stem":977,"_extension":18},"/en-us/blog/gitlab-16-ai-and-security-take-center-stage",{"title":959,"description":960,"ogTitle":959,"ogDescription":960,"noIndex":6,"ogImage":961,"ogUrl":962,"ogSiteName":685,"ogType":686,"canonicalUrls":962,"schema":963},"GitLab 16: AI and security take center stage","Our GitLab 16 launch event showcased our AI-powered workflows that drive usability improvements, security enhancements, and observability advancements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671793/Blog/Hero%20Images/16_0-cover-image.png","https://about.gitlab.com/blog/gitlab-16-ai-and-security-take-center-stage","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 16: AI and security take center stage\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2023-06-30\",\n      }",{"title":959,"description":960,"authors":965,"heroImage":961,"date":967,"body":968,"category":969,"tags":970},[966],"David DeSanto, Chief Product Officer, GitLab","2023-06-30","\nThe new era of DevSecOps is here – and its focus is on improving everyone’s experience through AI-powered workflows that drive usability improvements, security enhancements, and observability advancements.\n\nAt our recent GitLab 16 launch event, we highlighted how our platform has evolved to fuel productivity and efficiency, which are top of mind in 2023, according to GitLab’s [2023 Global DevSecOps Report: Productivity & Efficiency Within Reach](https://about.gitlab.com/developer-survey/).\n\n> If you missed the GitLab 16 event, it’s [available on demand](https://about.gitlab.com/sixteen/), so it’s not too late.\n\nWhat I find most exciting about the launch of [GitLab 16](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/) is that it marks a significant milestone for our customers, as well as for GitLab, and heralds the era of AI-powered DevSecOps. We’ve built upon the nearly 500 new capabilities we introduced with GitLab 15 and have continued that upward trajectory. \n\nThe GitLab 16 event showcased amazing new capabilities across our entire DevSecOps platform, which is reinforced by our significant investments in critical areas: \n\n1. Building a world-class DevSecOps experience that includes significant usability improvements, additional collaboration capabilities, and [AI-assisted workflows](https://about.gitlab.com/blog/ai-ml-in-devsecops-series/). \n2. Providing advanced security and compliance, deepening our capabilities, and bringing [software supply chain security](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/) to the forefront of software development.\n3. Bringing observability, analytics, and feedback into our DevSecOps platform, [empowering organizations to close the SDLC loop](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html) with user data.\n4. Offering GitLab for data science workloads to enable data scientists and data engineers to benefit from all the value our DevSecOps Platform provides, including collaboration, reproducibility, and streamlined deployment into production.\n\n## Introducing GitLab Duo\nAs part of GitLab 16, we [unveiled GitLab Duo](https://about.gitlab.com/blog/meet-gitlab-duo-the-suite-of-ai-capabilities/), our suite of enterprise-grade AI capabilities powering DevSecOps workflows. GitLab Duo is integrated directly into the DevSecOps platform, enabling you to write better code faster and more efficiently. And GitLab Duo goes well beyond code creation to deliver AI-assisted workflows at all stages of the software development lifecycle, such as security testing and analysis, observability, and proactive vulnerability detection. Our goal is to help you achieve a 10x improvement in workflow efficiency by tapping into all of the DevSecOps platform’s AI capabilities. \n\nGitLab Duo includes Code Suggestions, Explain this Code, Explain this Vulnerability, Summarize Issue Comments, Chat, and more.\n\nLearn about the [powerful features of GitLab Duo](https://about.gitlab.com/gitlab-duo/).\n\n## Joining forces with Google Cloud\nAt the launch June Yang, VP of Cloud AI and Industry Solutions at Google Cloud, discussed our partnership with [Google Cloud](https://about.gitlab.com/partners/technology-partners/google-cloud-platform/), (as recently [announced in May](https://about.gitlab.com/press/releases/2023-05-02-gitlab-and-google-cloud-partner-to-expand-ai-assisted-capabilities/)) in which we’re building several joint solutions that will help enterprise customers to improve the efficiency, effectiveness, and quality of their software development processes.\n\nBoth GitLab and Google Cloud are committed to developing new AI-powered solutions that help businesses improve their software development processes and protect their data.\n\nGitLab's vision for generative AI is grounded in privacy, security, and transparency. The partnership with Google Cloud enables GitLab to offer private and secure AI-powered features, while ensuring customer intellectual property (i.e., their source code) stays theirs and will not be used for training and fine-tuning of AI models. \n\n## CARFAX’s DevSecOps results\nMark Portofe, Director of Platform Engineering at CARFAX, also joined us for our GItLab 16 launch. It was enlightening to hear how CARFAX has been using GitLab since 2017 to make them more productive and more secure. Mark shared how CARFAX can now [create CI/CD pipelines](https://about.gitlab.com/solutions/continuous-integration/) in hours instead of the days or even weeks it took before – freeing up their developers’ time to focus on getting code to production. As a result, their number of production deployments has increased by 20% year over year.\n\n## GitLab Dedicated\nAs part of our GitLab 16 event, we also shared that [GitLab Dedicated](https://about.gitlab.com/dedicated/), our single-tenant SaaS offering of GitLab’s DevSecOps platform designed to address the needs of customers with stringent compliance requirements, is now generally available. \n\nWith GitLab Dedicated, organizations can access all of the benefits of the DevSecOps platform delivered as a SaaS offering – including faster releases, better security, and more productive developers – while satisfying compliance requirements such as data residency, isolation, and private networking.\n\n## Value Stream Analytics and Dashboards\nWhen it comes to observability, analytics, and feedback, our single application shines by providing end-to-end metrics and insights. We see this being very much native to our DevSecOps platform.\n\nWe’ve made great strides with [Value Streams Dashboards](https://www.youtube.com/watch?v=EA9Sbks27g4), a  popular feature with our customers. These dashboards combine DORA 4 metrics with GitLab-specific metrics to give organizations insights into the health of their software delivery, identifying areas of efficiency and areas for improvement. \n\nWe are also introducing [Product Analytics](https://about.gitlab.com/blog/introducing-product-analytics-in-gitlab/) in GitLab 16 to close the DevSecOps loop with user metrics and feedback from the applications that organizations are building with GitLab, which they can incorporate into their planning efforts. \n\n## Watch the GitLab 16 launch event\nI’m really proud of the work our teams put into GitLab 16 to make it a reality. To hear more and dig deeper into the amazing capabilities of GitLab 16, check out the [launch event](https://about.gitlab.com/sixteen/).\n","ai-ml",[971,495,9,782],"AI/ML",{"slug":973,"featured":6,"template":699},"gitlab-16-ai-and-security-take-center-stage","content:en-us:blog:gitlab-16-ai-and-security-take-center-stage.yml","Gitlab 16 Ai And Security Take Center Stage","en-us/blog/gitlab-16-ai-and-security-take-center-stage.yml","en-us/blog/gitlab-16-ai-and-security-take-center-stage",{"_path":979,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":980,"content":985,"config":991,"_id":993,"_type":13,"title":994,"_source":15,"_file":995,"_stem":996,"_extension":18},"/en-us/blog/gitlab-com-13-0-breaking-changes",{"title":981,"description":982,"ogTitle":981,"ogDescription":982,"noIndex":6,"ogImage":734,"ogUrl":983,"ogSiteName":685,"ogType":686,"canonicalUrls":983,"schema":984},"GitLab.com is moving to 13.0, with narrow breaking changes","Our next release, 13.0, will include narrow breaking changes. Find out how this could affect you and what you need to do.","https://about.gitlab.com/blog/gitlab-com-13-0-breaking-changes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab.com is moving to 13.0, with narrow breaking changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joshua Lambert\"}],\n        \"datePublished\": \"2020-05-06\",\n      }\n                  ",{"title":981,"description":982,"authors":986,"heroImage":734,"date":988,"body":989,"category":717,"tags":990},[987],"Joshua Lambert","2020-05-06","\n\nGitLab 13.0 is coming on May 22, 2020 to GitLab.com. Along with the\n[exciting new features](https://www.youtube.com/playlist?list=PL05JrBw4t0KqWysAAKFYYIE2Tf9IZB5bv), it also includes\n[planned deprecations](https://about.gitlab.com/releases/2020/04/22/gitlab-12-10-released/#release-deprecations) because it is this year's major version release. We try to minimize these changes, but some are important enough to warrant the change in functionality.\n\nThese changes will be going live on GitLab.com over the next few days, through our [daily deployments](https://about.gitlab.com/handbook/engineering/infrastructure/library/scheduled-daily-deployments/), leading up to the official release of 13.0 on May 22nd. Keep reading to learn more about these important changes.\n\n## Auto DevOps default PostgreSQL chart version changing to 8.2.1\n\nAs part of updating Auto DevOps to support Kubernetes 1.16, the default PostgreSQL chart version is changing from 0.7.1 to 8.2.1.\n\nTo migrate your existing 0.7.1 PostgreSQL database to the newer 8.2.1-based database,\nfollow the [upgrade guide](https://docs.gitlab.com/ee/topics/autodevops/upgrading_postgresql.html)\nto backup your database, install the new version of PostgreSQL, and restore your database.\n\nTo remain on the old default, you will need to explicitly set the\n`AUTO_DEVOPS_POSTGRES_CHANNEL` CI variable to `1`.\n\n## Auto DevOps Auto Deploy default setting for `deploymentApiVersion` changing\n\nBecause several APIs [were removed](https://kubernetes.io/blog/api-deprecations-in-1-16/)\nin Kubernetes 1.16, the `deploymentApiVersion` setting is changing to a new default\nof `apps/v1` in [GitLab 13.0](https://gitlab.com/gitlab-org/charts/auto-deploy-app/issues/47). \n\nIf you are using Kubernetes 1.9 and below, you will need to upgrade your Kubernetes\ncluster to get `apps/v1` version support. For Auto DevOps,\n[GitLab requires](https://docs.gitlab.com/ee/topics/autodevops/#requirements) Kubernetes 1.12+.\n\n## Auto DevOps and Secure Configuration templates are changing to `rules` instead of `only/except`\n\nThe use of [`only` and `except`](https://docs.gitlab.com/ee/ci/yaml/#only--except) is\ndiscouraged in favor of [`rules`](https://docs.gitlab.com/ee/ci/yaml/#rules).\n`rules` provides more verbose and expressive job execution  logic that is less\ncomplex to evaluate and understand. \n\nAuto DevOps and Secure [configuration templates](https://docs.gitlab.com/ee/ci/yaml/#includetemplate)\nthat use `only` and `except` are changing to `rules`. Users who have customized\njob templates will need to transition as these two configuration options cannot\nbe used together. We have [documentation available for help migrating your templates](https://docs.gitlab.com/ee/user/application_security/#transitioning-your-onlyexcept-syntax-to-rules).\n\nThis change will affect the following job configuration templates: \n\n- `Build.gitlab-ci.yml`\n- `Test.gitlab-ci.yml`\n- `Deploy.gitlab-ci.yml`\n- [Secure vendored `.gitlab-ci.yml` templates](https://gitlab.com/groups/gitlab-org/-/epics/2300)\n  - `Container-scanning.gitlab-ci.yml`\n  - `DAST.gitlab-ci.yml`\n  - `Dependency-Scanning.gitlab-ci.yml`\n  - `License-Management.gitlab-ci.yml`\n  - `License-Scanning.gitlab-ci.yml`\n  - `SAST.gitlab-ci.yml`\n\nAny customization to these templates using `only` and `except` must be changed to\nthe [`rules`](https://docs.gitlab.com/ee/ci/yaml/#rules) syntax. `only/except` can’t be used in \ncombination with `rules` since it’s intended to be replaced by that functionality.\nPlease see [our troubleshooting doc](https://docs.gitlab.com/ee/user/application_security/#getting-error-message-sast-job-config-key-may-not-be-used-with-rules-onlyexcept)\nfor guidance on transition your rules or pinning to the previous version.\n\nWe would love to hear more about these cases in [this `rules` improvement issue](https://gitlab.com/groups/gitlab-org/-/epics/2783).\n\nRelevant issues: \n\n- [Moving Auto DevOps jobs syntax to `rules`](https://gitlab.com/gitlab-org/gitlab/-/issues/213336)\n- [Transition to rules syntax for Secure's vendored templates](https://gitlab.com/groups/gitlab-org/-/epics/2300)\n\n## Offset pagination limit of 50,000 for `/projects` endpoint\n\nAn offset-based pagination limit of `50,000` is being applied to the `/projects`\nAPI endpoint on GitLab.com. Integrations that make API calls with offsets above\n`50,000` must switch to [keyset-based pagination](https://docs.gitlab.com/ee/api/#keyset-based-pagination),\nwhich will offer significantly improved response times and reduced load on the\nGitLab server. Self-managed instances can customize the limit to a desired value.\n\nTo optimize performance, keyset-based pagination only offers ordering based on\nproject `id`. Use cases that require more flexible ordering options can continue\nto use offset-based pagination, provided the offsets remain below the limit.\nIf use cases require flexible ordering options with deep offsets, we recommend\nsorting client-side.\n\n## Removing GitLab Snippets content from search\n\nAs we continue to work towards [version control for Snippets](https://gitlab.com/groups/gitlab-org/-/epics/239),\nwe are making a change to search for Snippets in the UI and API that removes snippet\n**Content** from search results. **Title** and **Description** will still be\naccessible via search and API.\n\n## Introducing a new `id` field which replaces the deprecated `cve` field in the JSON common security report\n\nAs we add (and encourage third-party vendors to add) more security integrations,\nwe're working to improve our current JSON common report format. The primary field\n`cve` property is confusing, as it does not contain CVE data and should therefore\nbe removed. We are introducing the `id` field, which is automatically calculated\nfor GitLab scanners and required for third-party partner scanners. The `id` field\nwill eventually replace `cve` as a unique identifier. Anyone leveraging the `cve`\nproperty in security reports, with custom scripts or as an integrator into our\nSecure features, will eventually need to stop using the `cve` property and instead\nshould start using the new `id` property. Please be aware that today `id` and\n`cve` are both required fields.\n\n- [Container Scanning - Reports JSON format](https://docs.gitlab.com/ee/user/application_security/container_scanning/#reports-json-format)\n- [Dependency Scanning - Reports JSON format](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#reports-json-format)\n- [Static Application Security Testing (SAST) - Reports JSON format](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format)\n\n## Removal of `token` attribute in Runner's details API\n\nWe are removing the `token` attribute from the Runners API endpoint that gets details\nof a Runner by its ID. You can provide feedback in \n[the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214322) or your\nusual support channels.\n\n## Removal of deprecated project paths\n\nWith the introduction of [subgroups](https://docs.gitlab.com/user/group/subgroups/), GitLab's URL path structure became more complex. We've been [introducing a separator](https://gitlab.com/gitlab-org/gitlab/-/issues/214217), `/-/`, to improve clarity between groups, projects, and pages within a project. For example, `https://gitlab.com/gitlab-org/gitlab/issues` is now `https://gitlab.com/gitlab-org/gitlab/-/issues`. These changes result in improved performance, stability, and simplicity. \n\nAs we introduce the separator to additional pages, we automatically redirect requests to the old paths to the new ones. With GitLab 13.0, we are [removing this redirect](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26808) for pages which have had the separator since GitLab 12.0.\n\nRegular usage of GitLab will not be impacted by this change. However bookmarks or scripting created over a year ago, utilizing an affected path, will need to be updated to utilize the new path.\n\n## GitLab Runner 13.0 breaking changes\n\n- [Windows Batch `cmd` for the shell executor](https://gitlab.com/gitlab-org/gitlab-runner/issues/6099): In GitLab 11.11, we deprecated the use of Windows Batch executor for the GitLab Runner in favor of PowerShell. In 13.0 we will deprecate the use of Windows batch (cmd) from the Runner shell executor.  When a user registers a new runner shell executor it will now default to `powershell`. The Cmd shell remains included in future versions of GitLab Runner. However, any new Runner feature is to be tested and supported only for use with PowerShell.\n- [debug/jobs/list?v=1 endpoint](https://gitlab.com/gitlab-org/gitlab-runner/issues/6361): In 13.0, the `/debug/jobs/list?v=1` endpoint used for monitoring is replaced with the `/debug/jobs/list?v=2` endpoint.\n- [Docker services flag on register command](https://gitlab.com/gitlab-org/gitlab-runner/issues/6404): In GitLab Runner 12.7 we introduced the ability to allow a service alias from `config` in the Docker executor. In 13.0, the old structure, `--docker-services` will also be removed. This means that the following option `gitlab-runner register --docker-services postgres` will no longer set the service as the configuration is no longer an array of strings. For users with automation that relies on the `--docker-services` flag, click here for a [migration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6404#migration) example.\n- [Legacy build directory caching feature flag](https://gitlab.com/gitlab-org/gitlab-runner/issues/4180): In GitLab Runner 13.0 we will remove the legacy build directory caching feature flag that was introduced in 11.10. We highly recommend that users do not store anything in the `Builds Directory`. Refer to the [Build Directory](https://docs.gitlab.com/runner/best_practice/#build-directory) section of the best practices documentation page for additional details.\n- [Windows 1803 support end of life](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6553): In GitLab Runner 13.0, Windows 1803 is no longer supported.\n- [Fedora 29 support end of life](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/16158): In GitLab Runner 13.0, Fedora 29 is no longer supported.\n\n## To utilize License Compliance you must use the new License Scanning template\n\nAs of GitLab 13.0 for self-managed, and this week for GitLab.com users, we have removed the License-Management.gitlab.ci.yml template (deprecated since GitLab 12.8). You must replace it with the License-Scanning.gitlab-ci.yml template instead. For more details visit [the documentation](https://docs.gitlab.com/ee/user/compliance/license_compliance/#migration-from-license_management-to-license_scanning).\n\nIf you are directly referencing the results of the License Scan running as part of License Compliance, you also need to use the new report type artifacts:reports:license_scanning instead of artifacts:reports:license_management. This is optional with the release of GitLab 12.8 through GitLab 12.10, but mandatory with the release of GitLab 13.0. This will not apply to users of versions GitLab 12.7 and earlier.\n\nThis change was made because GitLab License Management is now renamed to GitLab License Compliance. After review with users and analysts, we determined that this new name better indicates what the feature is for, aligns with existing market terminology, and reduces confusion with GitLab subscription licensing features. You can find the research and work on this issue in the epic Rename License Management to License Compliance. The analyses of your projects done as a part of License Compliance will be called License Scanning.\n",[717,949,9],{"slug":992,"featured":6,"template":699},"gitlab-com-13-0-breaking-changes","content:en-us:blog:gitlab-com-13-0-breaking-changes.yml","Gitlab Com 13 0 Breaking Changes","en-us/blog/gitlab-com-13-0-breaking-changes.yml","en-us/blog/gitlab-com-13-0-breaking-changes",{"_path":998,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":999,"content":1004,"config":1011,"_id":1013,"_type":13,"title":1014,"_source":15,"_file":1015,"_stem":1016,"_extension":18},"/en-us/blog/gitlab-com-13-4-breaking-changes",{"title":1000,"description":1001,"ogTitle":1000,"ogDescription":1001,"noIndex":6,"ogImage":734,"ogUrl":1002,"ogSiteName":685,"ogType":686,"canonicalUrls":1002,"schema":1003},"Upcoming Breaking Changes to Secure Analyzers in GitLab 13.4","Our next release, 13.4, will include narrow breaking changes for our Secure scanning features. Find out how this could affect you and what you need to do.","https://about.gitlab.com/blog/gitlab-com-13-4-breaking-changes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Upcoming GitLab.com narrow breaking changes to Secure Analyzers in GitLab 13.4\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2020-08-19\",\n      }",{"title":1005,"description":1001,"authors":1006,"heroImage":734,"date":1008,"body":1009,"category":782,"tags":1010},"Upcoming GitLab.com narrow breaking changes to Secure Analyzers in GitLab 13.4",[1007],"Taylor McCaslin","2020-08-19","\n\nWe've spent the first few releases of GitLab 13 with several user-focused improvements to our Static [Application Security Testing (SAST)](/topics/devsecops/) capabilities: \n\n* We made our open-source based SAST analyzers free to use for every GitLab user on all tiers [covering 18 languages/frameworks](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). \n* We released a new [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) scan type and a managed CI template. This also added new capabilities like [full history secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#full-history-secret-scan). \n\nWith these changes we've modernized and simplified the way our Security scans work, requiring the deprecation and removal of a few configuration options to improve the security, stability, and speed of our analyzers. \n\nWith these removals, there are a few changes that you should make to your Secure scan configurations to ensure you continue enjoying those capabilities. All of these removals were previously announced as deprecations in the past few release blog posts.  \n\n**These changes will release to GitLab.com as early as August 27th and will be released to self-managed customers with GitLab 13.4 on September 22.** If you have questions or feedback, you can [let us know in this feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/235816).\n\n\n## Removal of Secret Detection Job in SAST CI Template (High Impact)\n\nSince [GitLab 13.1](/releases/2020/06/22/gitlab-13-1-released/#deprecation-of-secret-detection-job-in-sast-configuration), the [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) CI/CD configuration settings moved to a separate GitLab-provided template and run as a new Secure scan type. This new Secret Detection template is also now [included in Auto DevOps](https://docs.gitlab.com/ee/user/application_security/#security-scanning-with-auto-devops). \n\nIn 13.4 we will remove the [old SAST `secrets-sast` job definition](https://gitlab.com/gitlab-org/gitlab/-/blob/67e235bd5826c160db47bbb8c0dc87e6b9cd7b43/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L171) and if you have not switched to the [new Secret Detection template](https://docs.gitlab.com/ee/user/application_security/secret_detection/#configuration) you will not continue to scan for secrets. You can easily transition by adding the new template.\n\nBefore upgrading to GitLab 13.4 we recommend you [add the new Secret Detection template](https://docs.gitlab.com/ee/user/application_security/secret_detection/#configuration) to your `gitlab-ci.yml` file, and then remove the [old SAST `secrets-sast` job definition](https://gitlab.com/gitlab-org/gitlab/-/blob/67e235bd5826c160db47bbb8c0dc87e6b9cd7b43/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L171) from the [SAST configuration template](https://docs.gitlab.com/ee/user/application_security/sast/#configuration) in `SAST.gitlab-ci.yml` file. We have made a [video to guide you through the process of transitioning](https://www.youtube.com/watch?v=W2tjcQreDwQ&feature=emb_title) to this new template. \n\n- You can follow [this implementation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/234011) for further details.\n- [Initial deprecation announced in 13.1 (6/22)](/releases/2020/06/22/gitlab-13-1-released/#deprecation-of-secret-detection-job-in-sast-configuration)\n\n\n## Removal of DinD (Medium impact)\n\nTo increase the security and reduce complexity of scans, use of Docker-in-Docker (DinD) in GitLab Secure scanners was [deprecated in 13.0](/releases/2020/05/22/gitlab-13-0-released/#deprecation-of-docker-in-docker-(dind)-for-security-scanners) and is **scheduled for removal in 13.4**. GitLab security products started to use non-DinD mode by default in vendor templates in GitLab 13.0. We encourage customers to update their vendor CI templates to use this new behavior. If you override or use custom [Secure CI templates](https://gitlab.com/gitlab-org/gitlab-foss/-/tree/master/lib/gitlab/ci/templates/Security), you can follow the guides below to disable Docker in Docker (DinD) from your existing job templates: \n \n* [Disabling Docker in Docker for Dependency Scanning (12.10 Documentation)](https://docs.gitlab.com/12.10/ee/user/application_security/dependency_scanning/index.html#disabling-docker-in-docker-for-dependency-scanning)\n* [Disabling Docker in Docker for SAST (12.10 Documentation)](https://docs.gitlab.com/12.10/ee/user/application_security/sast/#disabling-docker-in-docker-for-sast)\n* [Initial deprecation announced in 13.0 (5/22)](/releases/2020/05/22/gitlab-13-0-released/#deprecation-of-docker-in-docker-(dind)-for-security-scanners)\n\n\n## Transition of Secure Analyzers to Linux Alpine image (Low impact)\n\nTo [simplify and modernize](/direction/secure/static-analysis/sast/#whats-next--why) our [GitLab Secure SAST Analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), we will transition the [GitLab Bandit Python Analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) image from Debian Buster to [Alpine Linux](https://alpinelinux.org/about/). This transition will reduce the image size and increase both the speed and security of our analyzer.\n\n    This transition will be backward incompatible though we expect limited impact. If you use a `before_script` to pre-build dependencies for your Python project, you should test this change before upgrading to GitLab 13.4. We will add a new section in the [SAST troubleshooting documentation](https://docs.gitlab.com/ee/user/application_security/sast/#troubleshooting) with more information about this change as we approach 13.4.\n\n- [Initial deprecation annouced in 13.2 (7/22)](/releases/2020/07/22/gitlab-13-2-released/#transitioning-gitlab-bandit-secure-analyzer-os-image)\n\n\n## Transition of TSLint Job to ESLint (Low impact)\n\nThe [recent update of our ESLint Secure analyzer](/releases/2020/07/22/gitlab-13-2-released/#javascript--typescript-sast-analyzer-available-for-all) includes new support for TypeScript which is actively maintained. Since 2019 the [TSLint project has been deprecated](https://palantir.github.io/tslint/) in favor of ESLint. We have now unified these analyzers in [GitLab's ESLint analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/eslint), which renders our TSLint analyzer obsolete. \n      \nIn 13.2 we deprecated the [TSLint Secure analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/tslint) and have removed the [TSLint job definition from the SAST template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml). If you leverage [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) or `include` the [GitLab Secure SAST Template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml) no action is required, as this transition happened automatically when you updated to GitLab 13.2. We recommend that anyone using the TSLint SAST job in a customized CI template to migrate to the [newly updated ESLint Job](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L85).\n\nThe next time the SAST job runs after this transition you may see previously present TSLint vulnerabilities being marked as \"resolved\" and new TypeScript vulnerabilities from ESLint. This behavior is expected due to the new unique vulnerability signatures from ESLint which are different from old TSLint job scan vulnerability signatures.\n\n- [Initial deprecation annouced in 13.2 (7/22)](/releases/2020/07/22/gitlab-13-2-released/#deprecation-and-planned-removal-of-tslint-secure-analyzer)\n\n\n## Looking towards the future\n\nWe are always working to improve the security, efficiency, and quality of our Security scanning tools. These deprecations and removals help us rapidly improve our solution and allow us to deliver on our [Secure product vision](/direction/secure/). We appreciate your understanding of these changes, and if you have questions about these deprecations and removals please [let us know in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/235816).\n",[9,108,782],{"slug":1012,"featured":6,"template":699},"gitlab-com-13-4-breaking-changes","content:en-us:blog:gitlab-com-13-4-breaking-changes.yml","Gitlab Com 13 4 Breaking Changes","en-us/blog/gitlab-com-13-4-breaking-changes.yml","en-us/blog/gitlab-com-13-4-breaking-changes",{"_path":1018,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1019,"content":1025,"config":1031,"_id":1033,"_type":13,"title":1034,"_source":15,"_file":1035,"_stem":1036,"_extension":18},"/en-us/blog/gitlab-moving-to-14-breaking-changes",{"title":1020,"description":1021,"ogTitle":1020,"ogDescription":1021,"noIndex":6,"ogImage":1022,"ogUrl":1023,"ogSiteName":685,"ogType":686,"canonicalUrls":1023,"schema":1024},"GitLab.com is moving to 14.0 with a few breaking changes","These are the features that will be deprecated in GitLab 14.0.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667351/Blog/Hero%20Images/14_0_breaking_changes.jpg","https://about.gitlab.com/blog/gitlab-moving-to-14-breaking-changes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab.com is moving to 14.0 with a few breaking changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Orit Golowinski\"}],\n        \"datePublished\": \"2021-06-04\",\n      }",{"title":1020,"description":1021,"authors":1026,"heroImage":1022,"date":1028,"body":1029,"category":300,"tags":1030},[1027],"Orit Golowinski","2021-06-04","\n## GitLab 14.0: Our annual major release\n\nGitLab 14.0 is coming to GitLab.com. Along with the [exciting new features](https://www.youtube.com/embed/Z1FqGH0pNvo), it also includes [planned deprecations](/releases/2021/05/22/gitlab-13-12-released/#release-deprecations) because it is the major version release for 2021. We try to minimize breaking changes, but some changes are needed to improve workflows, performance, scalability, and more.\n\nThese changes will go live on GitLab.com sometime between May 23 – June 22, through our [daily deployments](/handbook/engineering/infrastructure/library/scheduled-daily-deployments/), leading up to the official release of 14.0 on June 22. Keep reading to learn more about these important changes.\n\nGitLab 14.0 for self-managed users will also be released on June 22, [read on for more information about deprecations and removals for self-managed instances](/releases/2021/05/22/gitlab-13-12-released/#release-deprecations).\n\n## Plan\n\n### Removed deprecated GraphQL fields\n\nIn accordance with our [GraphQL deprecation process](https://docs.gitlab.com/ee/api/graphql/#deprecation-process), the following fields, enum names, and mutation aliases that were deprecated on or before GitLab version 13.6 are [permanently removed from our GraphQL API in 14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/267966).\n\nFields:\n\n- `Mutations::Todos::MarkAllDone` - `updated_ids`\n- `Mutations::Todos::RestoreMany` - `updated_ids`\n- `Mutations::DastScannerProfiles::Create` - `global_id`\n- `TimeFrameArguments (concern*)` - `start_date`\n- `TimeFrameArguments (concern*)` - `end_date`\n- `Types::SnippetType` - `blob`\n- `Types::DastScannerProfileType` - `global_id`\n- `EE::Types::GroupType` - `vulnerabilities_count_by_day_and_severity`\n- `EE::Types::QueryType` - `vulnerabilities_count_by_day_and_severity`\n\nEnums (each replaced by the upper-case version, such as `updated_desc` -> `UPDATED_DESC`):\n\n- `Types::SortEnum` - `updated_desc`\n- `Types::SortEnum` - `updated_asc`\n- `Types::SortEnum` - `created_desc`\n- `Types::SortEnum` - `updated_asc`\n\nMutation aliases:\n\n- `DeprecatedMutations (concern**)` - `AddAwardEmoji`\n- `DeprecatedMutations (concern**)` - `RemoveAwardEmoji`\n- `DeprecatedMutations (concern**)` - `ToggleAwardEmoji`\n- `EE::Types::DeprecatedMutations (concern***)` - `Mutations::Pipelines::RunDastScan`\n- `EE::Types::DeprecatedMutations (concern***)` - `Mutations::Vulnerabilities::Dismiss`\n- `EE::Types::DeprecatedMutations (concern***)` - `Mutations::Vulnerabilities::RevertToDetected`\n\nFor mutation aliases, the concern name isn't as important as the name of the mutation itself. While you can't use **this particular name** anymore, we provide alternatives in our GraphQL documentation.\n\n## Create\n\n### Name change of default branch in Git\n\nEvery Git repository has an initial branch, which is the first branch that is automatically generated when you create a new repository. By default, this initial branch is named `master`. In Git version 2.31.0 – released [March 15th, 2021](https://www.google.com/calendar/event?eid=NG03dTF0YWU4cnMyMmc5bzJoMjVyYTZwcXEgamZnYmwybXJsaXBwNHBiNmllaWgwcXIzc29AZw&ctz=America/Los_Angeles) – the default Git branch name changed to `main`. In coordination with the Git project and the broader community, GitLab is changing the default branch name for new projects on both our [SaaS](/pricing/feature-comparison/) (GitLab.com) and self-managed offerings, starting with GitLab 14.0.\n\nFor more information, see the related [epic](https://gitlab.com/groups/gitlab-org/-/epics/3600), [documentation](https://docs.gitlab.com/ee/user/project/repository/branches/default.html), and the Git [mailing list discussion](https://lore.kernel.org/git/xmqqa6vf437i.fsf@gitster.c.googlers.com/T/#t).\n\n### Deprecated legacy Gitaly cluster primary electors\n\nNow that Praefect supports a [`per_repository` primary election strategy](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#repository-specific-primary-nodes), GitLab 14.0 removes the legacy strategies deprecated in GitLab 13.12:\n\n- The `local` elector is not supported in production, and should not affect production instances.\n- The `sql` elector is incompatible with the [variable replication factor](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#configure-replication-factor) feature.\n\nIf you use the `local` or `sql` primary electors, we recommend you update to the `per_repository` election strategy as soon as possible. Read the [migration documentation](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#migrate-to-repository-specific-primary-gitaly-nodes) to learn more.\n\n### WIP merge requests renamed \"draft merge requests\"\n\n[WIP (work in progress) status](/blog/feature-highlight-wip/) for merge requests provide a clear signal to reviewers that the merge request in question is not ready to be merged. The WIP feature for merge requests has been renamed to \"Draft\", a more inclusive and self-explanatory term. \"Draft\" clearly communicates the merge request in question isn't ready for review, and makes no assumptions about the progress being made toward it. \"Draft\" also reduces the cognitive load for new users, non-English speakers, and anyone unfamiliar with the WIP acronym.\n\nWIP merge requests were deprecated in favor of **draft** merge requests, and are [removed entirely](https://gitlab.com/gitlab-org/gitlab/-/issues/228685) in GitLab 14.0.\n\n## Manage\n\n### Deprecated GitLab OAuth implicit grants\n\nGitLab 14.0 deprecates the [OAuth 2 implicit grant flow](https://docs.gitlab.com/ee/api/oauth2.html#implicit-grant-flow), as it has been removed for [OAuth 2.1](https://oauth.net/2.1/).\n\nBeginning in GitLab 14.0, you can't create new applications with the OAuth 2 implicit grant flow. Existing OAuth implicit grant flows will become unsupported in GitLab 14.4. Migrate existing applications to other supported [OAuth2 flows](https://docs.gitlab.com/ee/api/oauth2.html#supported-oauth2-flows) before GitLab 14.4.\n\n### Removed `CI_PROJECT_CONFIG_PATH` predefined project variable\n\nThe `CI_PROJECT_CONFIG_PATH` predefined project variable is removed in favor of the `CI_CONFIG_PATH` variable, which is functionally the same. If you are using `CI_PROJECT_CONFIG_PATH` in your pipeline configurations update to use `CI_CONFIG_PATH` instead.\n\n### Expired SSH keys disabled by default\n\nStarting in GitLab 14.0, expired [SSH keys added to GitLab](https://docs.gitlab.com/ee/user/ssh.html) are disabled by default. This changes the current behavior, which allows expired SSH keys to be used unless explicitly disabled by an administrator. Administrators can still allow the use of expired keys in the same way as they can [override expiration settings](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#optional-non-enforcement-of-personal-access-token-expiration) for personal access tokens.\n\n## Verify\n\n### Changes to Code Quality Rubocop support\n\nCurrently, by default, the Code Quality feature doesn't provide support for Ruby 2.6+ if you're using the Code Quality template.\n\nTo better support the latest versions of Ruby, we are changing the default Rubocop version to add support for Ruby 2.4 through 3.0. Support for Ruby 2.1, 2.2, and 2.3 is dropped as a result of this change. To enable support for older versions, [customize your configuration](https://docs.gitlab.com/ee/ci/testing/code_quality.html). Read the relevant issue [\"Default `codeclimate-rubocop` engine does not support Ruby 2.6+\"\"](https://gitlab.com/gitlab-org/ci-cd/codequality/-/issues/28) to learn more about this change.\n\n### Renamed default Browser Performance Testing job\n\nBrowser Performance Testing currently runs in a job named `performance` by default. This name can be confused with [Load Performance Testing](https://docs.gitlab.com/ee/ci/testing/load_performance_testing.html), introduced in GitLab 13.2. To make clear which job is running Browser Performance Testing, GitLab 14.0 renames the default job name from `performance` to `browser_performance` in the template. Read the relevant issue [\"Rename default Browser Performance Testing job\"](https://gitlab.com/gitlab-org/gitlab/-/issues/225914) to learn more about this change.\n\n### Ruby version changing in `Ruby.gitlab-ci.yml`\n\nThe `Ruby.gitlab-ci.yml` template contains changes to better support new versions of Ruby. Previously, the `Ruby.gitlab-ci.yml` file included Ruby 2.5. To better support the latest versions of Ruby, the template now uses `ruby:latest`, which is currently Ruby 3.0. Read the [ruby-lang.org release announcement](https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/) to learn more about the changes to Ruby, and explore our relevant issue, [\"Updates Ruby version 2.5 to 3.0\"](https://gitlab.com/gitlab-org/gitlab/-/issues/329160) to learn more about the change.\n\n### GitLab Runner: Package installation ignores `skel` directory during installation\n\nIn GitLab Runner 14.0, the installation process ignores the `skel` directory by default when creating the user's home directory. For more details about this breaking change, read the [deprecation issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4845).\n\n### GitLab Runner: PowerShell Core as default shell for newly registered Runners on Windows\n\nBeginning in GitLab Runner 14.0, newly registered Windows Runners default to adding PowerShell Core (`pwsh`) as the default shell in the `config.toml` file, instead of the legacy Windows PowerShell (`powershell`).\n\n### GitLab Runner: Remove support for Windows Server 1909 image\n\nMicrosoft ended support for Windows Server version 1909 on May 11, 2021. In keeping with our [support policy](https://docs.gitlab.com/runner/install/windows.html) for Windows Server, GitLab 14.0 removes Windows 1909 support from GitLab Runner. If you are still using Windows Server 1909, then `docker-windows` on GitLab Runner 14.0 or higher will no longer work. For additional details regarding this breaking change, read the [deprecation issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27899).\n\n## Release\n\n### Renewed template for Auto DevOps: Stable Auto Deploy\n\nGitLab 14.0 renews the [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy) CI template to the latest version. This includes new features, bug fixes, and performance improvements with a dependency on the `v2` [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image). This latest template is opt-in, meaning, unless you specifically customize Auto DevOps in your project, it uses the stable template with a dependency on the `v1` auto-deploy-image.\n\nThe `v1` and `v2` versions are not backward compatible, so your project might encounter an unexpected failure if you already have a deployed application. Please follow the [upgrade guide](https://docs.gitlab.com/ee/topics/autodevops/upgrading_auto_deploy_dependencies.html#upgrade-guide) to upgrade your environments. You can also start using the latest template today by following the [early adoption guide](https://docs.gitlab.com/ee/topics/autodevops/upgrading_auto_deploy_dependencies.html#early-adopters).\n\n### Deprecated release description in the Tags API\n\nGitLab 14.0 removes support for the release description in the Tags API. You can no longer add a release description when [creating a new tag](https://docs.gitlab.com/ee/api/tags.html#create-a-new-tag). You also can't [create](https://docs.gitlab.com/ee/api/tags.html#create-a-new-release) or [update](https://docs.gitlab.com/ee/api/tags.html#update-a-release) a release through the Tags API. You should migrate to the [Releases API](https://docs.gitlab.com/ee/api/releases/#create-a-release) instead.\n\n### Deprecated `disk` source configuration for GitLab Pages\n\nGitLab Pages [API-based configuration](https://docs.gitlab.com/ee/administration/pages/#gitlab-api-based-configuration) has been available since GitLab 13.0, and will replace the `disk` source configuration which GitLab 14.0 removes. We recommend that you stop using `disk` source configuration, since it is no longer supported and cannot be selected. Use `gitlab` for an API-based configuration instead. To migrate away from the `disk` source configuration, set `gitlab_pages['domain_config_source'] = \"gitlab\"` in your `gitlab.rb/etc/gitlab/gitlab.rb` file. We recommend that you do this before GitLab 14.0 so you can find and troubleshoot any potential problems ahead of time.\n\n### Deprecated legacy feature flags\n\nLegacy feature flags became read-only in GitLab 13.4, and GitLab 14.0 removes support for them. You must [migrate your legacy feature flags](https://docs.gitlab.com/ee/operations/feature_flags.html#legacy-feature-flag-migration) to the new version, as described in the [documentation](https://docs.gitlab.com/ee/operations/feature_flags.html). Watch the video tutorial below for help with the migration:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/CAJY2IGep7Y\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Package\n\n### Empty container registries will have the cleanup policies turned off\n\nThe [cleanup policy](https://docs.gitlab.com/ee/user/packages/container_registry/#cleanup-policy) is a scheduled job you can use to remove or preserve tags from the Container Registry. In GitLab 14.0, we will make an update that will turn the cleanup policy feature off for projects that have no container images in their registry. Moving forward, a recurring job will regularly run to ensure that projects with no container images do not have the cleanup policy feature turned on.\n\nThis change significantly improves the performance and reliability of the feature and allows us to prioritize exciting usability features like a preview-run, as proposed in the issue, [\"Expiration policy dry-run and forced run\"](https://gitlab.com/gitlab-org/gitlab/-/issues/223732).\n\nIf this change affects you, you can easily [enable the feature again](https://docs.gitlab.com/ee/user/packages/container_registry/#create-a-cleanup-policy) by following the steps in the documentation.\n\n## Configure\n\n### Removed one-click GitLab Managed Apps\n\nGitLab 13.7 deprecated the one-click install of GitLab Managed Apps, and GitLab 14.0 removes them entirely. Although GitLab Managed Apps made it easy to start deploying to Kubernetes from GitLab, feedback from the community was that they were not flexible or customizable enough for real-world Kubernetes applications. Our new direction focuses on [installing apps on Kubernetes with GitLab CI/CD](https://docs.gitlab.com/ee/update/removals.html) to provide a better balance between ease-of-use and extensive customization.\n\nThis removal does not affect how existing managed applications run inside your cluster. However, you no longer can update or modify those applications in the GitLab UI.\n\nWe recommend cluster administrators to [migrate any existing managed applications to the project template](https://docs.gitlab.com/ee/user/clusters/migrating_from_gma_to_project_template.html).\n\n### New Terraform template version\n\nAs we continuously develop GitLab's Terraform integrations, to minimize customer disruption, we maintain two GitLab CI/CD templates for Terraform:\n\n- The [\"latest version\" template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.latest.gitlab-ci.yml), which is updated frequently between minor releases of GitLab (such as 13.10, 13.11, etc).\n- The [\"major version\" template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.gitlab-ci.yml), which is updated only at major releases (such as 13.0, 14.0, etc).([View the new \"major version\" template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.gitlab-ci.yml).)\n\nAt every major release of GitLab, the \"latest version\" template becomes the \"major version\" template, inheriting the \"latest template\" setup. As we have added many new features to the Terraform integration, the new setup for the \"major version\" template can be considered a breaking change.\n\nThe latest template supports the [Terraform Merge Request widget](https://docs.gitlab.com/ee/user/infrastructure/iac/mr_integration.html) and doesn't need additional setup to work with the [GitLab managed Terraform state](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html).\n\n### Renewed template for Terraform\n\nGitLab 14.0 renews the Terraform CI/CD template to the latest version. The new template is set up for the GitLab Managed Terraform state. It includes a dependency on the GitLab `terraform-images` image to improve the user experience with GitLab's [Infrastructure as Code](https://docs.gitlab.com/ee/user/infrastructure/#quick-start) features.\n\nSince the current stable and latest templates are incompatible, and the latest template becomes the stable template GitLab 14.0, your Terraform pipeline might encounter an unexpected failure if you run a custom `init` job.\n\n### Auto Build uses Cloud Native Buildpacks by default\n\nIn GitLab 14.0, Auto Build now defaults to Cloud Native Buildpacks instead of Herokuish when no `Dockerfile` is present. Users depending on the `/bin/herokuish` binary provided by Herokuish should either change their deployments to use `/cnb/lifecycle/launcher` instead of `/bin/herokuish exec`, or opt-out of using Cloud Native Buildpacks, by setting the CI variable `AUTO_BUILD_IMAGE_CNB_ENABLED` to `false`.\n\n## Secure\n\n### Removals for SAST and Secret Detection\n\nThis release removes or migrates several variables:\n\n- [Removes the SAST Analyzer variable](/releases/2021/04/22/gitlab-13-11-released/#remove-sast-analyzer-sast_gosec_config-variable-in-favor-of-custom-rulesets) `SAST_GOSEC_CONFIG` in favor of custom rulesets for expanded configuration and consistency.\n- [Removes the global variable](/releases/2021/04/22/gitlab-13-11-released/#deprecating-global-%60sast_analyzer_image_tag%60-in-sast-ci-template) `SAST_ANALYZER_IMAGE_TAG` in favor of analyzer-specific variables to provide more granular control of versioning analyzers.\n- [Migrates the variable](/releases/2021/04/22/gitlab-13-11-released/#migrate-from-sast_default_analyzers-to-sast_excluded_analyzers) `SAST_DEFAULT_ANALYZERS` to `SAST_EXCLUDED_ANALYZERS` for better forward compatibility.\n\nThis release also removes the `secret_detection_default_branch` job in our managed `Secret-Detection.gitlab-ci.yml` template to reduce CI complexity.\n\nIf you override or maintain custom versions of `SAST.gitlab-ci.yml` or `Secret-Detection.gitlab-ci.yml`, update your CI templates. We strongly encourage you [inherit and override our managed CI templates](https://docs.gitlab.com/ee/user/application_security/secret_detection/#custom-settings-example) to future-proof your CI templates.\n\n### Removed the License-Management CI template\n\nIn 13.0, we deprecated the License-Management CI template and renamed it License-Scanning. GitLab 14.0 completely removes the License-Management CI template. We have been providing backward compatibility by warning users of the old template to switch. Read the change in the [relevant issue #216261](https://gitlab.com/gitlab-org/gitlab/-/issues/216261) or [blog post](/blog/composition-analysis-14-deprecations-and-removals/).\n\n### Deprecations for Dependency Scanning\n\nTo exclude a DS analyzer previously you needed to remove it from the default list of analyzers and use that to set the `DS_DEFAULT_ANALYZERS` variable in your project’s CI template. We determined it should be easier to avoid running a particular analyzer without losing the benefit of newly added analyzers. Now you should be able to migrate from `DS_DEFAULT_ANALYZERS` to `DS_EXCLUDED_ANALYZERS` as [described in the documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/analyzers.html#disable-specific-analyzers). Read more about the change in [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/287691), the [13.9 release post](/releases/2021/02/22/gitlab-13-9-released/#deprecations-for-dependency-scanning), and [the relevant blog post](/blog/composition-analysis-14-deprecations-and-removals/).\n\nTo prevent the Gemnasium analyzers to fetch the advisory database at runtime, you previously had to set the `GEMNASIUM_DB_UPDATE` variable. But this is not documented properly and its naming is inconsistent with the equivalent `BUNDLER_AUDIT_UPDATE_DISABLED` variable. You should migrate from `GEMNASIUM_DB_UPDATE` to `GEMNASIUM_UPDATE_DISABLED` when it is available. Read about the change in the [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/215483).\n\n### DAST environment variable renaming and removal\n\nGitLab 13.8 renamed multiple environment variables to support broader usage in different workflows. GitLab 14.0 permanently removes these variables, and they no longer work. If you use the old variables in your configuration it's time to update to the new variable names. Any scans using these variables in GitLab 14.0 and later will fail to be configured correctly:\n\n-  `DAST_AUTH_EXCLUDE_URLS` is now `DAST_EXCLUDE_URLS`.\n-  `AUTH_EXCLUDE_URLS` is now `DAST_EXCLUDE_URLS`.\n-  `AUTH_USERNAME` is now `DAST_USERNAME`.\n-  `AUTH_PASSWORD` is now `DAST_PASSWORD`.\n-  `AUTH_USERNAME_FIELD` is now `DAST_USERNAME_FIELD`.\n-  `AUTH_PASSWORD_FIELD` is now `DAST_PASSWORD_FIELD`.\n-  `DAST_ZAP_USE_AJAX_SPIDER` is now `DAST_USE_AJAX_SPIDER`.\n-  `DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED` is removed, as the feature is being removed.\n\n## Protect\n\n### Web Application Firewall (WAF) removal\n\nGitLab's Web Application Firewall (WAF) was deprecated in GitLab 13.6. GitLab 14.0 removes the WAF on June 22, 2021. GitLab's WAF had limitations inherent in the architectural design that made it difficult to meet the requirements traditionally expected of a WAF. By deprecating and removing the WAF, GitLab can focus on improving other areas in the product to provide more value to users.\n\nIf you currently rely on GitLab's WAF, we recommend you continue to use the free and open source [ModSecurity](https://www.modsecurity.org/) project, which is independent from GitLab. More details are available in the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/271276).\n\n### Container Scanning Engine Clair removal\n\nPrior to GitLab 14.0, GitLab used the open-source Clair engine for container scanning. Clair was deprecated in GitLab 13.9, and GitLab 14.0 replaces Clair with Trivy. If you use any GitLab 13.x release, you can continue to use Clair without making any changes to your CI files – however, GitLab will no longer update or maintain that scanning engine.\n\nBeginning in the 14.0 release Trivy becomes the new default scanner and receives regular updates and the latest features. You should review their CI files in advance of the 14.0 release and [follow these instructions](https://docs.gitlab.com/ee/user/application_security/container_scanning/#migrating-from-clair-to-trivy) to ensure your container scanning jobs continue to work. You can provide feedback and get additional details about the change to Trivy on our [open deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/321451).\n\n## Enablement\n\n### Remove old Advanced Search migrations in GitLab 14.0 release\n\n[Advanced Search migrations](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html) is a feature that helps you update your Elasticsearch index in the background when a GitLab version upgrade introduces changes to indexes. Advanced Search migrations add complexity that requires us to support multiple code paths. It's important to reduce this complexity while keeping it safe.\n\nGitLab 14.0 removes all migrations that were added before the GitLab 13.12 release. **Instances Running GitLab 13.11 or under must be upgraded to GitLab 13.12 before upgrading to GitLab 14.0**, otherwise you may need to recreate your Advanced Search index. You can find more information about the process of deleting migrations in our [Elasticsearch development documentation](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html).\n\n## API Changes\n\n### Enforce maximum attachment size on Project API uploads\n\nSome people use the [project API](https://docs.gitlab.com/ee/api/projects.html#upload-a-file) to upload large binaries to link in the Release pages. This API was originally intended only to share attachments in issues or merge requests, and should have been subject to the configured maximum attachment size (10 MB by default). GitLab 14.0 enforces the size limit, and uploads that exceed this limit now fail with a `413 Entity Too Large` error. Files that already uploaded remain downloadable.\n\n### Drop `updated_at` filter from Deployment API\n\nSome users are pulling data from the [`list project deployments`](https://docs.gitlab.com/ee/api/deployments.html#list-project-deployments) API endpoint to populate a custom-built dashboard. There is no way to restrict the API results to display only the latest changes. To overcome this, you must retrieve all records, check them one-by-one, and process only the records updated after the latest `updated_at` value in the last batch retrieved.\n\nGitLab 14.0 changes this API to make this process more efficient and performant:\n\n- `updated_after` is now `finished_after`.\n- `updated_before` is now `finished_before`.\n- Queries specifying the `updated_at` filter must set `order_by` to `updated_at`.\n\n### Limit projects returned in `GET /groups/:id/`\n\nTo improve performance, GitLab 14.0 limits the number of projects returned from the `GET /groups/:id/` API call to 100. You can still retrieve a complete list of projects with the `GET /groups/:id/projects` API call.\n\n### Remove `trace` parameter from `PUT /api/jobs/:id`\n\nGitLab Runner was previously updated to change how it communicates with GitLab. Some internal code is no longer in use, and GitLab 14.0 deprecates this unused code. Make sure your [GitLab Runner version matches your GitLab version](https://docs.gitlab.com/runner/#gitlab-runner-versions) to ensure consistent behavior.\n\n### Deprecate segments from DevOps Adoption API\n\nThe first release of the DevOps Adoption report had a concept of \"segments\". Segments were [quickly removed from the report](https://gitlab.com/groups/gitlab-org/-/epics/5251) because they introduced an additional layer of complexity on top of \"groups\" and \"projects\". Subsequent iterations of the DevOps Adoption report focuses on comparing adoption across groups rather than segments. GitLab 14.0 [removes all references to \"segments\" in the GraphQL API](https://gitlab.com/gitlab-org/gitlab/-/issues/324414) and replaces them with \"groups\".\n\nCover image by [PHOTOGRAPHER Silvia Brazzoduro](https://unsplash.com/photos/YSxcf6C_SEg) on [Unsplash](https://unsplash.com)\n{: .note}\n",[717,9,949],{"slug":1032,"featured":6,"template":699},"gitlab-moving-to-14-breaking-changes","content:en-us:blog:gitlab-moving-to-14-breaking-changes.yml","Gitlab Moving To 14 Breaking Changes","en-us/blog/gitlab-moving-to-14-breaking-changes.yml","en-us/blog/gitlab-moving-to-14-breaking-changes",{"_path":1038,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1039,"content":1044,"config":1052,"_id":1054,"_type":13,"title":1055,"_source":15,"_file":1056,"_stem":1057,"_extension":18},"/en-us/blog/gitlab-release-date-change",{"title":1040,"description":1041,"ogTitle":1040,"ogDescription":1041,"noIndex":6,"ogImage":817,"ogUrl":1042,"ogSiteName":685,"ogType":686,"canonicalUrls":1042,"schema":1043},"GitLab releases moving to the third Thursday of the month","This move will create more predictability for our customers in terms of the day of week for the release while continuing our monthly pace of self-managed releases.","https://about.gitlab.com/blog/gitlab-release-date-change","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab releases moving to the third Thursday of the month\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ian Pedowitz\"}],\n        \"datePublished\": \"2023-09-18\",\n      }",{"title":1040,"description":1041,"authors":1045,"heroImage":817,"date":1047,"body":1048,"category":717,"tags":1049},[1046],"Ian Pedowitz","2023-09-18","\n\nStarting with GitLab 16.6, which will be released on Nov. 16, 2023, **our monthly release date will change from the 22nd of every month to the third Thursday of every month**. This iteration in our release processes will ensure consistency and create more predictability for our customers in terms of the day of the week for the release while continuing our monthly pace of self-managed releases.\n\n## What does this change mean for you?\nIf you’re using GitLab.com SaaS, not much will change as GitLab.com SaaS will continue to deploy multiple times a day.\n\nIf you’re using GitLab self-managed, releases will happen on the third Thursday of every month. If you have any processes, tooling, or automation that is based around the GitLab self-managed release being the 22nd of the month, it will need to be updated to support this new schedule of the third Thursday of the month.\n\nA new rolling 12-month schedule has been added to the [releases page](https://about.gitlab.com/releases/) with more details about these changes, and can be added to your bookmarks. A machine-readable version is also available at [`data/releases.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/releases.yml).\n",[717,1050,1051,9],"collaboration","product",{"slug":1053,"featured":6,"template":699},"gitlab-release-date-change","content:en-us:blog:gitlab-release-date-change.yml","Gitlab Release Date Change","en-us/blog/gitlab-release-date-change.yml","en-us/blog/gitlab-release-date-change",{"_path":1059,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1060,"content":1065,"config":1071,"_id":1073,"_type":13,"title":1074,"_source":15,"_file":1075,"_stem":1076,"_extension":18},"/en-us/blog/gitlab-releases-15-breaking-changes",{"title":1061,"description":1062,"ogTitle":1061,"ogDescription":1062,"noIndex":6,"ogImage":1022,"ogUrl":1063,"ogSiteName":685,"ogType":686,"canonicalUrls":1063,"schema":1064},"GitLab.com is moving to 15.0 with a few breaking changes","These are the features that will be removed in GitLab 15.0.","https://about.gitlab.com/blog/gitlab-releases-15-breaking-changes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab.com is moving to 15.0 with a few breaking changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brian Rhea\"}],\n        \"datePublished\": \"2022-04-18\",\n      }",{"title":1061,"description":1062,"authors":1066,"heroImage":1022,"date":1068,"body":1069,"category":300,"tags":1070},[1067],"Brian Rhea","2022-04-18","\nNote: This post was updated on May 20, 2022, to reflect the release of GitLab 15.0.\n{: .note}\n\nGitLab 15.0 has arrived! Along with the [exciting new features](https://youtu.be/1a6-yv6UXsY), it also includes planned removals of [previously deprecated features](https://docs.gitlab.com/ee/update/deprecations.html). Some of these removals are [breaking changes](https://about.gitlab.com/handbook/product/gitlab-the-product/#breaking-changes-deprecations-and-removing-features), because this release is a major version release. We try to minimize such breaking changes but sometimes they are needed to improve workflows, performance, scalability, and more. Please keep reading to learn more about these important changes.\n\nTo see all removals in 15.0, visit [GitLab Docs](https://docs.gitlab.com/ee/update/deprecations.html). Jump to the list of breaking changes in each stage by clicking below:\n\n- [Manage](#manage)\n- [Plan](#plan)\n- [Create](#create)\n- [Verify](#verify)\n- [Package](#package)\n- [Secure](#secure)\n- [Configure](#configure)\n- [Monitor](#monitor)\n- [Protect](#protect)\n- [Enablement](#enablement)\n- [Ecosystem](#ecosystem)\n- [Platform](#platform)\n\n## Manage\n\n### Audit events for repository push events\n\nAnnounced in 14.3\n{: .note}\n\nAudit events for [repository events](https://docs.gitlab.com/ee/administration/audit_events.html#removed-events) are removed as of GitLab 15.0.\n\nAudit events for repository events were always disabled by default and had to be manually enabled with a feature flag.\nEnabling them could slow down GitLab instances by generating too many events. Therefore, they are removed.\n\nPlease note that we will add high-volume audit events in the future as part of [streaming audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html). An example of this is how we will send [Git fetch actions](https://gitlab.com/gitlab-org/gitlab/-/issues/343984) as a streaming audit event. If you would be interested in seeing repository push events or some other action as a streaming audit event, please reach out to us!\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/337993)\n\n### External status check API breaking changes\n\nAnnounced in 14.8\n{: .note}\n\nThe [external status check API](https://docs.gitlab.com/ee/api/status_checks.html) was originally implemented to\nsupport pass-by-default requests to mark a status check as passing. Pass-by-default requests are now removed.\nSpecifically, the following are removed:\n\n- Requests that do not contain the `status` field.\n- Requests that have the `status` field set to `approved`.\n\nFrom GitLab 15.0, status checks are only set to a passing state if the `status` field is both present\nand set to `passed`. Requests that:\n\n- Do not contain the `status` field will be rejected with a `400` error. For more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338827).\n- Contain any value other than `passed`, such as `approved`, cause the status check to fail. For more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/339039).\n\nTo align with this change, API calls to list external status checks also return the value of `passed` rather than\n`approved` for status checks that have passed.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/339039)\n\n### OAuth implicit grant\n\nAnnounced in 14.0\n{: .note}\n\nThe OAuth implicit grant authorization flow is no longer supported. Any applications that use OAuth implicit grant must switch to alternative [supported OAuth flows](https://docs.gitlab.com/ee/api/oauth2.html).\n\n### OAuth tokens without an expiration\n\nAnnounced in 14.3\n{: .note}\n\nGitLab no longer supports OAuth tokens [without an expiration](https://docs.gitlab.com/ee/integration/oauth_provider.html#expiring-access-tokens).\n\nAny existing token without an expiration has one automatically generated and applied.\n\n### Optional enforcement of SSH expiration\n\nAnnounced in 14.8\n{: .note}\n\nDisabling SSH expiration enforcement is unusual from a security perspective and could create unusual situations where an expired\nkey is unintentionally able to be used. Unexpected behavior in a security feature is inherently dangerous and so now we enforce\nexpiration on all SSH keys.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351963)\n\n### Optional enforcement of personal access token expiration\n\nAnnounced in 14.8\n{: .note}\n\nAllowing expired personal access tokens to be used is unusual from a security perspective and could create unusual situations where an\nexpired key is unintentionally able to be used. Unexpected behavior in a security feature is inherently dangerous and so we now do not let expired personal access tokens be used.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351962)\n\n### Required pipeline configurations in Premium tier\n\nAnnounced in 14.8\n{: .note}\n\n[Required pipeline configuration](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#required-pipeline-configuration) helps to define and mandate organization-wide pipeline configurations and is a requirement at an executive and organizational level. To align better with our [pricing philosophy](https://about.gitlab.com/company/pricing/#three-tiers), this feature is removed from the Premium tier in GitLab 15.0. This feature continues to be available in the GitLab Ultimate tier.\n\nWe recommend customers use [Compliance Pipelines](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration), also in GitLab Ultimate, as an alternative as it provides greater flexibility, allowing required pipelines to be assigned to specific compliance framework labels.\n\nThis change also helps GitLab remain consistent in our tiering strategy with the other related Ultimate-tier features:\n\n- [Security policies](https://docs.gitlab.com/ee/user/application_security/policies/).\n- [Compliance framework pipelines](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration).\n\n### `omniauth-kerberos` gem\n\nAnnounced in 14.3\n{: .note}\n\nThe `omniauth-kerberos` gem is no longer supported. This gem has not been maintained and has very little usage. Therefore, we\nremoved support for this authentication method and recommend using [SPNEGO](https://en.wikipedia.org/wiki/SPNEGO) instead. You can\nfollow the [upgrade instructions](https://docs.gitlab.com/ee/integration/kerberos.html#upgrading-from-password-based-to-ticket-based-kerberos-sign-ins)\nto upgrade from the removed integration to the new supported one.\n\nWe are not removing Kerberos SPNEGO integration. We are removing the old password-based Kerberos.\n\n---\n\n## Create\n\n### Feature flag PUSH_RULES_SUPERSEDE_CODE_OWNERS\n\nAnnounced in 14.8\n{: .note}\n\nThe feature flag `PUSH_RULES_SUPERSEDE_CODE_OWNERS` has been removed in GitLab 15.0. From now on, push rules will supersede CODEOWNERS. The CODEOWNERS feature is no longer available for access control.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/262019)\n\n### `defaultMergeCommitMessageWithDescription` GraphQL API field\n\nAnnounced in 14.5\n{: .note}\n\nThe GraphQL API field `defaultMergeCommitMessageWithDescription` has been removed in GitLab 15.0. For projects with a commit message template set, it will ignore the template.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345451)\n\n---\n\n## Verify\n\n### API: `stale` status returned instead of `offline` or `not_connected`\n\nAnnounced in 14.6\n{: .note}\n\nA breaking change was made to the Runner [API](https://docs.gitlab.com/ee/api/runners.html#runners-api) endpoints\nin 15.0.\n\nInstead of the GitLab Runner API endpoints returning `offline` and `not_connected` for runners that have not\ncontacted the GitLab instance in the past three months, the API endpoints now return the `stale` value,\nwhich was introduced in 14.6.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347303)\n\n### `artifacts:report:cobertura` keyword\n\nAnnounced in 14.8\n{: .note}\n\nAs of GitLab 15.0, the `artifacts:report:cobertura` keyword has been replaced by\n[`artifacts:reports:coverage_report`](https://gitlab.com/gitlab-org/gitlab/-/issues/344533). Cobertura is the only\nsupported report file, but this is the first step towards GitLab supporting other report types.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/348980)\n\n### Known host required for GitLab Runner SSH executor\n\nAnnounced in 14.5\n{: .note}\n\nIn [GitLab 14.3](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3074), we added a configuration setting in the GitLab Runner `config.toml`. This setting, [`[runners.ssh.disable_strict_host_key_checking]`](https://docs.gitlab.com/runner/executors/ssh.html#security), controls whether or not to use strict host key checking with the SSH executor.\n\nIn GitLab 15.0, the default value for this configuration option has changed from `true` to `false`. This means that strict host key checking will be enforced when using the GitLab Runner SSH executor.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28192)\n\n### Runner status `not_connected` API value\n\nAnnounced in 14.6\n{: .note}\n\nThe GitLab Runner REST and GraphQL [API](https://docs.gitlab.com/ee/api/runners.html#runners-api) endpoints\ndeprecated the `not_connected` status value in GitLab 14.6 and will start returning `never_contacted` in its place\nstarting in GitLab 15.0.\n\nRunners that have never contacted the GitLab instance will also return `stale` if created more than 3 months ago.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347305)\n\n### `type` and `types` keyword from CI/CD configuration\n\nAnnounced in 14.6\n{: .note}\n\nThe `type` and `types` CI/CD keywords is removed in GitLab 15.0, so pipelines that use these keywords fail with a syntax error. Switch to `stage` and `stages`, which have the same behavior.\n\n### Test coverage project CI/CD setting\n\nAnnounced in 14.8\n{: .note}\n\nTo specify a test coverage pattern, in GitLab 15.0 the\n[project setting for test coverage parsing](https://docs.gitlab.com/ee/ci/pipelines/settings.html#add-test-coverage-results-to-a-merge-request-removed)\nhas been removed.\n\nTo set test coverage parsing, use the project’s `.gitlab-ci.yml` file by providing a regular expression with the\n[`coverage` keyword](https://docs.gitlab.com/ee/ci/yaml/index.html#coverage).\n\n---\n\n## Package\n\n### Container registry authentication with htpasswd\n\nAnnounced in 14.9\n{: .note}\n\nThe Container Registry supports [authentication](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#auth) with `htpasswd`. It relies on an [Apache `htpasswd` file](https://httpd.apache.org/docs/2.4/programs/htpasswd.html), with passwords hashed using `bcrypt`.\n\nSince it isn't used in the context of GitLab (the product), `htpasswd` authentication will be deprecated in GitLab 14.9 and removed in GitLab 15.0.\n\n### GraphQL permissions change for Package settings\n\nAnnounced in 14.9\n{: .note}\n\nThe GitLab Package stage offers a Package Registry, Container Registry, and Dependency Proxy to help you manage all of your dependencies using GitLab. Each of these product categories has a variety of settings that can be adjusted using the API.\n\nThe permissions model for GraphQL is being updated. After 15.0, users with the Guest, Reporter, and Developer role can no longer update these settings:\n\n- [Package Registry settings](https://docs.gitlab.com/ee/api/graphql/reference/#packagesettings)\n- [Container Registry cleanup policy](https://docs.gitlab.com/ee/api/graphql/reference/#containerexpirationpolicy)\n- [Dependency Proxy time-to-live policy](https://docs.gitlab.com/ee/api/graphql/reference/#dependencyproxyimagettlgrouppolicy)\n- [Enabling the Dependency Proxy for your group](https://docs.gitlab.com/ee/api/graphql/reference/#dependencyproxysetting)\n\nThe issue for this removal is [GitLab-#350682](https://gitlab.com/gitlab-org/gitlab/-/issues/350682)\n\n### Versions from PackageType\n\nAnnounced in 14.5\n{: .note}\n\nAs part of the work to create a [Package Registry GraphQL API](https://gitlab.com/groups/gitlab-org/-/epics/6318), the Package group deprecated the `Version` type for the basic `PackageType` type and moved it to [`PackageDetailsType`](https://docs.gitlab.com/ee/api/graphql/reference/index.html#packagedetailstype).\n\nIn GitLab 15.0, we will completely remove `Version` from `PackageType`.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/327453)\n\n### dependency_proxy_for_private_groups feature flag\n\nAnnounced in 14.5\n{: .note}\n\nA feature flag was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11582) in GitLab 13.7 as part of the change to require authentication to use the Dependency Proxy. Before GitLab 13.7, you could use the Dependency Proxy without authentication.\n\nIn GitLab 15.0, we will remove the feature flag, and you must always authenticate when you use the Dependency Proxy.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/276777)\n\n### Pipelines field from the version field\n\nAnnounced in 14.5\n{: .note}\n\nIn GraphQL, there are two `pipelines` fields that you can use in a [`PackageDetailsType`](https://docs.gitlab.com/ee/api/graphql/reference/#packagedetailstype) to get the pipelines for package versions:\n\n- The `versions` field's `pipelines` field. This returns all the pipelines associated with all the package's versions, which can pull an unbounded number of objects in memory and create performance concerns.\n- The `pipelines` field of a specific `version`. This returns only the pipelines associated with that single package version.\n\nTo mitigate possible performance problems, we will remove the `versions` field's `pipelines` field in GitLab 15.0. Although you will no longer be able to get all pipelines for all versions of a package, you can still get the pipelines of a single version through the remaining `pipelines` field for that version.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342882)\n\n### Update to the Container Registry group-level API\n\nAnnounced in 14.5\n{: .note}\n\nIn GitLab 15.0, support for the `tags` and `tags_count` parameters will be removed from the Container Registry API that [gets registry repositories from a group](https://docs.gitlab.com/ee/api/container_registry.html#within-a-group).\n\nThe `GET /groups/:id/registry/repositories` endpoint will remain, but won't return any info about tags. To get the info about tags, you can use the existing `GET /registry/repositories/:id` endpoint, which will continue to support the `tags` and `tag_count` options as it does today. The latter must be called once per image repository.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336912)\n\n---\n\n## Secure\n\n### DS_DEFAULT_ANALYZERS environment variable\n\nAnnounced in 14.0\n{: .note}\n\nWe are removing the `DS_DEFAULT_ANALYZERS` environment variable from Dependency Scanning on May 22, 2022 in 15.0. After this removal, this variable's value will be ignored. To configure which analyzers to run with the default configuration, you should use the `DS_EXCLUDED_ANALYZERS` variable instead.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/333299)\n\n### Dependency Scanning default Java version changed to 17\n\nAnnounced in 14.10\n{: .note}\n\nFor Dependency Scanning, the default version of Java that the scanner expects will be updated from 11 to 17. Java 17 is [the most up-to-date Long Term Support (LTS) version](https://en.wikipedia.org/wiki/Java_version_history). Dependency Scanning continues to support the same [range of versions (8, 11, 13, 14, 15, 16, 17)](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers), only the default version is changing. If your project uses the previous default of Java 11, be sure to [set the `DS_JAVA_VERSION` variable to match](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-specific-analyzers-used-by-dependency-scanning). Please note that consequently the default version of Gradle is now 7.3.3.\n\n### End of support for Python 3.6 in Dependency Scanning\n\nAnnounced in 14.8\n{: .note}\n\nFor those using Dependency Scanning for Python projects, we are removing support for the default `gemnasium-python:2` image which uses Python 3.6, as well as the custom `gemnasium-python:2-python-3.9` image which uses Python 3.9. The new default image as of GitLab 15.0 will be for Python 3.9 as it is a [supported version](https://endoflife.date/python) and 3.6 [is no longer supported](https://endoflife.date/python).\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351503)\n\n### Retire-JS Dependency Scanning tool\n\nAnnounced in 14.8\n{: .note}\n\nWe have removed support for retire.js from Dependency Scanning as of May 22, 2022 in GitLab 15.0. JavaScript scanning functionality will not be affected as it is still being covered by Gemnasium.\n\nIf you have explicitly excluded retire.js using the `DS_EXCLUDED_ANALYZERS` variable, then you will be able to remove the reference to retire.js. If you have customized your pipeline’s Dependency Scanning configuration related to the `retire-js-dependency_scanning` job, then you will want to switch to `gemnasium-dependency_scanning`. If you have not used the `DS_EXCLUDED_ANALYZERS` to reference retire.js, or customized your template specifically for retire.js, you will not need to take any action.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/289830)\n\n### bundler-audit Dependency Scanning tool\n\nAnnounced in 14.8\n{: .note}\n\nWe are removing bundler-audit from Dependency Scanning on May 22, 2022 in 15.0. After this removal, Ruby scanning functionality will not be affected as it is still being covered by Gemnasium.\n\nIf you have explicitly excluded bundler-audit using the `DS_EXCLUDED_ANALYZERS` variable, then you will be able to remove the reference to bundler-audit. If you have customized your pipeline’s Dependency Scanning configuration related to the `bundler-audit-dependency_scanning` job, then you will want to switch to `gemnasium-dependency_scanning`. If you have not used the `DS_EXCLUDED_ANALYZERS` to reference bundler-audit or customized your template specifically for bundler-audit, you will not need to take any action.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347491)\n\n---\n\n## Configure\n\n### GitLab Serverless\n\nAnnounced in 14.3\n{: .note}\n\nAll functionality related to GitLab Serverless was deprecated in GitLab 14.3 and is scheduled for removal in GitLab 15.0. Users who need a replacement for this functionality are encouraged to explore using the following technologies with GitLab CI/CD:\n\n- [Serverless Framework](https://www.serverless.com)\n- [AWS Serverless Application Model](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/deploying-using-gitlab.html)\n\nFor additional context, or to provide feedback regarding this change, please reference our [deprecation issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/6).\n\n- [Issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/6)\n\n### `Managed-Cluster-Applications.gitlab-ci.yml`\n\nAnnounced in 14.0\n{: .note}\n\nThe `Managed-Cluster-Applications.gitlab-ci.yml` CI/CD template is being removed. If you need an  alternative, try the [Cluster Management project template](https://gitlab.com/gitlab-org/gitlab/-/issues/333610) instead. If your are not ready to move, you can copy the [last released version](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/v14.10.1/lib/gitlab/ci/templates/Managed-Cluster-Applications.gitlab-ci.yml) of the template into your project.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/333610)\n\n### Self-managed certificate-based integration with Kubernetes feature flagged\n\nAnnounced in 14.5\n{: .note}\n\nIn 15.0 the certificate-based integration with Kubernetes will be disabled by default.\n\nAfter 15.0, you should use the [agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) to connect Kubernetes clusters with GitLab. The agent for Kubernetes is a more robust, secure, and reliable integration with Kubernetes. [How do I migrate to the agent?](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)\n\nIf you need more time to migrate, you can enable the `certificate_based_clusters` [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html), which re-enables the certificate-based integration.\n\nIn GitLab 16.0, we will [remove the feature, its related code, and the feature flag](https://about.gitlab.com/blog/deprecating-the-cert-based-kubernetes-integration/). GitLab will continue to fix any security or critical issues until 16.0.\n\n- [Epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)\n\n---\n\n## Monitor\n\n### ELK stack logging\n\nAnnounced in 14.7\n{: .note}\n\nThe logging features in GitLab allow users to install the ELK stack (Elasticsearch, Logstash, and Kibana) to aggregate and manage application logs. Users could search for relevant logs in GitLab directly. However, since deprecating certificate-based integration with Kubernetes clusters and GitLab Managed Apps, this feature is no longer available. For more information on the future of logging and observability, you can follow the issue for [integrating Opstrace with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/346485)\n\n### Jaeger integration\n\nAnnounced in 14.7\n{: .note}\n\nTracing in GitLab is an integration with Jaeger, an open-source end-to-end distributed tracing system. GitLab users could previously navigate to their Jaeger instance to gain insight into the performance of a deployed application, tracking each function or microservice that handles a given request. Tracing in GitLab was deprecated in GitLab 14.7, and removed in 15.0. To track work on a possible replacement, see the issue for [Opstrace integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/346540)\n\n### Request profiling\n\nAnnounced in 14.8\n{: .note}\n\n[Request profiling](https://docs.gitlab.com/ee/administration/monitoring/performance/index.html) has been removed in GitLab 15.0.\n\nWe're working on [consolidating our profiling tools](https://gitlab.com/groups/gitlab-org/-/epics/7327) and making them more easily accessible.\nWe [evaluated](https://gitlab.com/gitlab-org/gitlab/-/issues/350152) the use of this feature and we found that it is not widely used.\nIt also depends on a few third-party gems that are not actively maintained anymore, have not been updated for the latest version of Ruby, or crash frequently when profiling heavy page loads.\n\nFor more information, check the [summary section of the deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352488#deprecation-summary).\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352488)\n\n---\n\n## Protect\n\n### Container Network and Host Security\n\nAnnounced in 14.8\n{: .note}\n\nAll functionality related to the Container Network Security and Container Host Security categories was deprecated in GitLab 14.8 and is scheduled for removal in GitLab 15.0. Users who need a replacement for this functionality are encouraged to evaluate the following open source projects as potential solutions that can be installed and managed outside of GitLab: [AppArmor](https://gitlab.com/apparmor/apparmor), [Cilium](https://github.com/cilium/cilium), [Falco](https://github.com/falcosecurity/falco), [FluentD](https://github.com/fluent/fluentd), [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/). To integrate these technologies with GitLab, add the desired Helm charts in your copy of the [Cluster Management Project Template](https://docs.gitlab.com/ee/user/clusters/management_project_template.html). Deploy these Helm charts in production by calling commands through GitLab [CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).\n\nAs part of this change, the following capabilities within GitLab are scheduled for removal in GitLab 15.0:\n\n- The **Security & Compliance > Threat Monitoring** page.\n- The Network Policy security policy type, as found on the **Security & Compliance > Policies** page.\n- The ability to manage integrations with the following technologies through GitLab: AppArmor, Cilium, Falco, FluentD, and Pod Security Policies.\n- All APIs related to the above functionality.\n\nFor additional context, or to provide feedback regarding this change, please reference our [deprecation issue](https://gitlab.com/groups/gitlab-org/-/epics/7476).\n\n- [Issue](https://gitlab.com/groups/gitlab-org/-/epics/7477)\n\n### Vulnerability Check\n\nAnnounced in 14.8\n{: .note}\n\nThe vulnerability check feature was deprecated in GitLab 14.8 and is scheduled for removal in GitLab 15.0. We encourage you to migrate to the new security approvals feature instead. You can do so by navigating to **Security & Compliance > Policies** and creating a new Scan Result Policy.\n\nThe new security approvals feature is similar to vulnerability check. For example, both can require approvals for MRs that contain security vulnerabilities. However, security approvals improve the previous experience in several ways:\n\n- Users can choose who is allowed to edit security approval rules. An independent security or compliance team can therefore manage rules in a way that prevents development project maintainers from modifying the rules.\n- Multiple rules can be created and chained together to allow for filtering on different severity thresholds for each scanner type.\n- A two-step approval process can be enforced for any desired changes to security approval rules.\n- A single set of security policies can be applied to multiple development projects to allow for ease in maintaining a single, centralized ruleset.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/357300)\n\n---\n\n## Enablement\n\n### Background upload for object storage\n\nAnnounced in 14.9\n{: .note}\n\nTo reduce the overall complexity and maintenance burden of GitLab's [object storage feature](https://docs.gitlab.com/ee/administration/object_storage.html), support for using `background_upload` has been removed in GitLab 15.0.\n\nThis impacts a small subset of object storage providers, including but not limited to:\n\n- **OpenStack** Customers using OpenStack need to change their configuration to use the S3 API instead of Swift.\n- **RackSpace** Customers using RackSpace-based object storage need to migrate data to a different provider.\n\nIf your object storage provider does not support `background_upload`, please [migrate objects to a supported object storage provider](https://docs.gitlab.com/ee/administration/object_storage.html#migrate-objects-to-a-different-object-storage-provider).\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/26600)\n\n### Elasticsearch 6.8.x in GitLab 15.0\n\nAnnounced in 14.8\n{: .note}\n\nElasticsearch 6.8 support has been removed in GitLab 15.0. Elasticsearch 6.8 has reached [end of life](https://www.elastic.co/support/eol).\nIf you use Elasticsearch 6.8, **you must upgrade your Elasticsearch version to 7.x** prior to upgrading to GitLab 15.0.\nYou should not upgrade to Elasticsearch 8 until you have completed the GitLab 15.0 upgrade.\n\nView the [version requirements](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html) for details.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/350275)\n\n### Gitaly nodes in virtual storage\n\nAnnounced in 13.12\n{: .note}\n\nConfiguring the Gitaly nodes directly in the virtual storage's root configuration object has been deprecated in GitLab 13.12 and is no longer supported in GitLab 15.0. You must move the Gitaly nodes under the `'nodes'` key as described in [the Praefect configuration](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#praefect).\n\n### Move Gitaly Cluster Praefect `database_host_no_proxy` and `database_port_no_proxy configs`\n\nAnnounced in 14.0\n{: .note}\n\nThe Gitaly Cluster configuration keys for `praefect['database_host_no_proxy']` and `praefect['database_port_no_proxy']` are replaced with `praefect['database_direct_host']` and `praefect['database_direct_port']`.\n\n- [Issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6150)\n\n### Move `custom_hooks_dir` setting from GitLab Shell to Gitaly\n\nAnnounced in 14.9\n{: .note}\n\nThe [`custom_hooks_dir`](https://docs.gitlab.com/ee/administration/server_hooks.html#create-a-global-server-hook-for-all-repositories) setting is now configured in Gitaly, and is removed from GitLab Shell in GitLab 15.0.\n\n- [Issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4208)\n\n### Pseudonymizer\n\nAnnounced in 14.7\n{: .note}\n\nThe Pseudonymizer feature is generally unused, can cause production issues with large databases, and can interfere with object storage development.\nIt was removed in GitLab 15.0.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/219952)\n\n### `promote-to-primary-node` command from `gitlab-ctl`\n\nAnnounced in 14.5\n{: .note}\n\nIn GitLab 14.5, we introduced the command `gitlab-ctl promote` to promote any Geo secondary node to a primary during a failover. This command replaces `gitlab-ctl promote-to-primary-node` which was only usable for single-node Geo sites. `gitlab-ctl promote-to-primary-node` has been removed in GitLab 15.0.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345207)\n\n### SUSE Linux Enterprise Server 12 SP2\n\nAnnounced in 14.5\n{: .note}\n\nLong term service and support (LTSS) for SUSE Linux Enterprise Server (SLES) 12 SP2 [ended on March 31, 2021](https://www.suse.com/lifecycle/). The CA certificates on SP2 include the expired DST root certificate, and it's not getting new CA certificate package updates. We have implemented some [workarounds](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/merge_requests/191), but we will not be able to continue to keep the build running properly.\n\n### Sidekiq configuration for metrics and health checks\n\nAnnounced in 14.7\n{: .note}\n\nIn GitLab 15.0, you can no longer serve Sidekiq metrics and health checks over a single address and port.\n\nTo improve stability, availability, and prevent data loss in edge cases, GitLab now serves\n[Sidekiq metrics and health checks from two separate servers](https://gitlab.com/groups/gitlab-org/-/epics/6409).\n\nWhen you use Omnibus or Helm charts, if GitLab is configured for both servers to bind to the same address,\na configuration error occurs.\nTo prevent this error, choose different ports for the metrics and health check servers:\n\n- [Configure Sidekiq health checks](https://docs.gitlab.com/ee/administration/sidekiq/index.html)\n- [Configure the Sidekiq metrics server](https://docs.gitlab.com/ee/administration/sidekiq/index.html)\n\nIf you installed GitLab from source, verify manually that both servers are configured to bind to separate addresses and ports.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/347509)\n\n### Support for `gitaly['internal_socket_dir']`\n\nAnnounced in 14.10\n{: .note}\n\nGitaly introduced a new directory that holds all runtime data Gitaly requires to operate correctly. This new directory replaces the old internal socket directory, and consequentially the usage of `gitaly['internal_socket_dir']` was deprecated in favor of `gitaly['runtime_dir']`.\n\n- [Issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6758)\n\n### Support for legacy format of `config/database.yml`\n\nAnnounced in 14.3\n{: .note}\n\nThe syntax of [GitLab's database](https://docs.gitlab.com/omnibus/settings/database.html)\nconfiguration located in `database.yml` has changed and the legacy format has been removed.\nThe legacy format supported a single PostgreSQL adapter, whereas the new format supports multiple databases.\nThe `main:` database needs to be defined as a first configuration item.\n\nThis change only impacts users compiling GitLab from source, all the other installation methods handle this configuration automatically.\nInstructions are available [in the source update documentation](https://docs.gitlab.com/ee/update/upgrading_from_source.html#new-configuration-options-for-databaseyml).\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338182)\n\n### The `promote-db` command is no longer available from `gitlab-ctl`\n\nAnnounced in 14.5\n{: .note}\n\nIn GitLab 14.5, we introduced the command `gitlab-ctl promote` to promote any Geo secondary node to a primary during a failover. This command replaces `gitlab-ctl promote-db` which is used to promote database nodes in multi-node Geo secondary sites. The `gitlab-ctl promote-db` command has been removed in GitLab 15.0.\n\n- [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345207)\n\n---\n",[717,9,949],{"slug":1072,"featured":6,"template":699},"gitlab-releases-15-breaking-changes","content:en-us:blog:gitlab-releases-15-breaking-changes.yml","Gitlab Releases 15 Breaking Changes","en-us/blog/gitlab-releases-15-breaking-changes.yml","en-us/blog/gitlab-releases-15-breaking-changes",{"_path":1078,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1079,"content":1085,"config":1092,"_id":1094,"_type":13,"title":1095,"_source":15,"_file":1096,"_stem":1097,"_extension":18},"/en-us/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast",{"title":1080,"description":1081,"ogTitle":1080,"ogDescription":1081,"noIndex":6,"ogImage":1082,"ogUrl":1083,"ogSiteName":685,"ogType":686,"canonicalUrls":1083,"schema":1084},"GitLab Runner update required to use SAST in Auto DevOps","Make sure you upgrade GitLab Runner to 11.5+ to coninue using SAST in Auto DevOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Runner update required to use SAST in Auto DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabio Busatto\"}],\n        \"datePublished\": \"2018-12-06\",\n      }",{"title":1080,"description":1081,"authors":1086,"heroImage":1082,"date":1088,"body":1089,"category":693,"tags":1090},[1087],"Fabio Busatto","2018-12-06","\n\nWe are introducing a major change for the [SAST] job definition for [Auto DevOps] with **GitLab 11.6**, shipping Dec. 22.\nAs a result, SAST jobs will fail after the upgrade to GitLab 11.6 if they are picked up by a version of [GitLab Runner]\nprior to 11.5. The jobs will fail, but they will not block pipelines. However, you won't see results\nfor SAST in the merge request or at the pipeline level anymore.\n\nThe same change will happen for [Dependency Scanning], [Container Scanning], [DAST], and [License Management] in future releases.\n\n## Why did this happen?\n\nThe [new job definition] uses the [`reports` syntax], which is necessary to show SAST results in the [Group Security Dashboard].\nUnfortunately, this syntax is not supported by GitLab Runner prior to 11.5.\n\n## Who is affected?\n\nYou are affected by this change if you meet **all** the requirements in the following list:\n1. You are using Auto DevOps **AND**\n1. you have at least one GitLab Runner 11.4 or older set up for your projects **AND**\n1. you are interested in security reports.\n\n## Who is not affected?\n\nYou are **not** affected by this change if you meet **at least one** of the requirements in the following list:\n1. You are not using Auto DevOps **OR**\n1. you are using only GitLab Runner 11.5 or newer **OR**\n1. you are using only shared runners on GitLab.com (we already upgraded them) **OR**\n1. you are not interested in security reports.\n\n## How to solve the problem\n\nIf you are not affected by the change, you don't need to take any action.\n\nIf you are affected, you should upgrade your GitLab Runners to version 11.5 or newer as soon as possible.\nIf you don't, you will not have new SAST reports until you do upgrade. If you upgrade your runners later, SAST will\nstart to work again correctly.\n\n## Which is the expected timeline?\n\nGitLab 11.6 will be released on **Dec. 22**.  This change may also be shipped in an early release\ncandidate (RC) version.\n\nIf you are using a **self-managed** GitLab instance, and you don't install RC versions, you will be affected when\nyou'll upgrade to GitLab 11.6.\n\nIf you are using **GitLab.com**, you will be affected as soon as the RC version with the change will be deployed.\n\nFeel free to reach out to us with any further questions!\n\n[SAST]: https://docs.gitlab.com/ee/user/application_security/sast/\n[Auto DevOps]: https://docs.gitlab.com/ee/topics/autodevops/\n[new job definition]: https://docs.gitlab.com/ee/user/application_security/sast/\n[`reports` syntax]: https://docs.gitlab.com/ee/ci/yaml/#artifactsreportssast-ultimate\n[Group Security Dashboard]: https://docs.gitlab.com/ee/user/application_security/security_dashboard/\n[GitLab Runner]: https://docs.gitlab.com/runner/\n[Dependency Scanning]: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/\n[Container Scanning]: https://docs.gitlab.com/ee/user/application_security/container_scanning/\n[DAST]: https://docs.gitlab.com/ee/user/application_security/dast/\n[License Management]: https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html\n",[719,1091,695,9,782],"DevOps",{"slug":1093,"featured":6,"template":699},"gitlab-runner-update-required-to-use-auto-devops-and-sast","content:en-us:blog:gitlab-runner-update-required-to-use-auto-devops-and-sast.yml","Gitlab Runner Update Required To Use Auto Devops And Sast","en-us/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast.yml","en-us/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast",{"_path":1099,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1100,"content":1106,"config":1112,"_id":1114,"_type":13,"title":1115,"_source":15,"_file":1116,"_stem":1117,"_extension":18},"/en-us/blog/gitlab-security-tools-and-the-hipaa-risk-analysis",{"title":1101,"description":1102,"ogTitle":1101,"ogDescription":1102,"noIndex":6,"ogImage":1103,"ogUrl":1104,"ogSiteName":685,"ogType":686,"canonicalUrls":1104,"schema":1105},"GitLab's security tools and the HIPAA risk analysis","A closer look at GitLab’s security scanning tools and the HIPAA risk analysis.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680548/Blog/Hero%20Images/gitlab-security-and-hipaa-risk-analysis.jpg","https://about.gitlab.com/blog/gitlab-security-tools-and-the-hipaa-risk-analysis","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's security tools and the HIPAA risk analysis\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Luka Trbojevic\"}],\n        \"datePublished\": \"2019-04-10\",\n      }",{"title":1101,"description":1102,"authors":1107,"heroImage":1103,"date":1109,"body":1110,"category":782,"tags":1111},[1108],"Luka Trbojevic","2019-04-10","\n\nThe importance of the HIPAA risk analysis (45 CFR § 164.308(a)(1)(ii)(A)) can’t be overstated.\nThe Office for Civil Rights (OCR) announced 2018 was an [all-time record year for HIPAA enforcement](https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/2018enforcement/index.html),\nand an incomplete risk analysis or inadequate follow-up on findings were cited in three of the major breaches.\n\nDigitization of healthcare is moving faster than ever. From patient portals to patient-reported\noutcomes platform, there’s an application for just about everything. But as we adjust our pace\nof building and innovating in this digital healthcare era, we must quickly recalibrate our pace\nof identifying risks and vulnerabilities in our software.\n\nYou may already know, GitLab is a single tool for the entire DevOps lifecycle, from project planning\nto deployment. But it’s also a powerful security tool that can add automated vulnerability scanning\nto your development process.\n\nLet’s take a closer look.\n\n## Using Static Application Security Testing to identify vulnerabilities in source code\n\nUsing [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/)\n(SAST), you can identify vulnerabilities in your source code. Setting up SAST is easy – you can\neither include the [SAST CI job](https://docs.gitlab.com/ee/user/application_security/sast/) or use\n[Auto SAST](https://docs.gitlab.com/ee/topics/autodevops/index.html#auto-sast).\nAfter that’s done, and every time the job is run, your source code will be scanned.\nWhen the scan is done, the results are [displayed right on the merge request](https://docs.gitlab.com/ee/user/application_security/sast/#how-it-works).\nAnd when you go to any pipeline with a SAST job, you’ll be shown a [security report](https://docs.gitlab.com/ee/user/application_security/sast/#security-report-under-pipelines) with the findings.\n\n## Using Dynamic Application Security Testing to identify vulnerabilities in web applications\n\nUnlike SAST, which scans source code for vulnerabilities, [Dynamic Application Security Testing](https://docs.gitlab.com/ee/user/application_security/dast/) (DAST) analyzes\nrunning web applications for vulnerabilities. It’s just as simple to set up as SAST – simply add\na DAST CI/CD job to your pipeline. DAST will also [display the findings directly in the merge request](https://docs.gitlab.com/ee/user/application_security/dast/#how-it-works)\nand create a [report artifact](https://docs.gitlab.com/ee/ci/yaml/#artifactsreportsdast).\n\n## Container Scanning\n\nIf you use Docker, you can use [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\nto scan your Docker images for vulnerabilities. This is again as simple as adding a [Container Scanning CI/CD job](https://docs.gitlab.com/ee/user/application_security/container_scanning/#configuring-with-templates) to your pipeline!\nThe scan will generate a [report artifact](https://docs.gitlab.com/ee/ci/yaml/#artifactsreportscontainer_scanning) you can download and review.\n\n## Secret Detection\n\nThe risk analysis standard requires both risks and vulnerabilities. One common risk is for secrets\n(API keys and passwords, for example) to be inadvertently leaked. To address that problem,\nwe’re working on [Secret Detection](https://gitlab.com/groups/gitlab-org/-/epics/675).\nIt’ll check files and configurations to identify potentially sensitive information, running every\ntime a commit is pushed to a branch.\n\n## Coming soon: Even more tools to assess risks and vulnerabilities\n\nIn the coming year we’ll be adding a number of product categories to our Secure stage to help\nimprove your application’s security and find more vulnerabilities. Here’s what you can look forward to:\n\n### Digging deeper for application vulnerabilities: Interactive Application Security Testing\n\n[Interactive Application Security Testing](https://gitlab.com/groups/gitlab-org/-/epics/344) (IAST)\nassesses an application’s response to an external security scan (like DAST) to identify vulnerabilities\nthat wouldn’t be caught by just the external scan. When this feature is complete, it’ll add yet\nanother layer of vulnerability detection to DAST.\n\n### Fuzzing\n\nAnother way to find application vulnerabilities is to generate random inputs and send them\nto the application. By doing this, you can find unintended behaviors in the application that\nmay result in a vulnerability. While fuzzing is often a niche technique, we’re\n[working on adding basic fuzzing capability straight into GitLab](https://gitlab.com/groups/gitlab-org/-/epics/818)!\n\n## Putting it all together\n\nToday, with GitLab, you can:\n\n* Identify vulnerabilities in your source code using SAST.\n* Identify vulnerabilities in your web application using DAST.\n* Identify vulnerabilities in your Docker containers using Container Scanning.\n* Scan for passwords, API keys, and other sensitive information with Secrets Detection.\n\nIn the near future, with GitLab, you’ll be able to:\n\n* Identify vulnerabilities in your application using IAST.\n* Identify vulnerabilities in your application with fuzzing.\n\n## Closing thoughts\n\nWhether you’re a four-person startup making the next groundbreaking healthcare analytics platform,\nor an academic medical center developing health applications, having security visibility where\nit didn’t exist previously is a good thing. And having that visibility incorporated directly into\nyour development process with minimal work and seamless integration is even better.\n\nWith GitLab’s security features you can incorporate automated vulnerability detection straight\ninto your development process. While the risk analysis requirement goes beyond just the software\nyou’re writing, as you write more code faster, automating part of the software security portion can only help.\n\n### Disclaimer\n\nTHE INFORMATION PROVIDED ON THIS WEBSITE IS TO BE USED FOR INFORMATIONAL PURPOSES ONLY. THE INFORMATION SHOULD NOT BE RELIED UPON OR CONSTRUED AS LEGAL OR COMPLIANCE ADVICE OR OPINIONS. THE INFORMATION IS NOT COMPREHENSIVE AND WILL NOT GUARANTEE COMPLIANCE WITH ANY REGULATION OR INDUSTRY STANDARD. YOU MUST NOT RELY ON THE INFORMATION FOUND ON THIS WEBSITE AS AN ALTERNATIVE TO SEEKING PROFESSIONAL ADVICE FROM YOUR ATTORNEY AND/OR COMPLIANCE PROFESSIONAL.\n{: .note}\n\nCover image by [rawpixel.com](https://www.pexels.com/@rawpixel?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/clinician-writing-medical-report-1919236/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n",[782,9,696],{"slug":1113,"featured":6,"template":699},"gitlab-security-tools-and-the-hipaa-risk-analysis","content:en-us:blog:gitlab-security-tools-and-the-hipaa-risk-analysis.yml","Gitlab Security Tools And The Hipaa Risk Analysis","en-us/blog/gitlab-security-tools-and-the-hipaa-risk-analysis.yml","en-us/blog/gitlab-security-tools-and-the-hipaa-risk-analysis",{"_path":1119,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1120,"content":1126,"config":1133,"_id":1135,"_type":13,"title":1136,"_source":15,"_file":1137,"_stem":1138,"_extension":18},"/en-us/blog/gitlab-tls1011-discontinued-update",{"title":1121,"description":1122,"ogTitle":1121,"ogDescription":1122,"noIndex":6,"ogImage":1123,"ogUrl":1124,"ogSiteName":685,"ogType":686,"canonicalUrls":1124,"schema":1125},"TLS 1.0 and 1.1 support ended on GitLab.com and API","TLS 1.2 is now required for all clients that connect to GitLab.com and our GitLab API.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666816/Blog/Hero%20Images/security-cover.png","https://about.gitlab.com/blog/gitlab-tls1011-discontinued-update","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Support for TLS 1.0 and 1.1 discontinued on GitLab.com and GitLab API on 2018-12-15\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Melissa Farber\"}],\n        \"datePublished\": \"2018-12-17\",\n      }",{"title":1127,"description":1122,"authors":1128,"heroImage":1123,"date":1130,"body":1131,"category":300,"tags":1132},"Support for TLS 1.0 and 1.1 discontinued on GitLab.com and GitLab API on 2018-12-15",[1129],"Melissa Farber","2018-12-17","\n\nOur commitment to providing our users with an increasingly secure platform, supported by the [PCI Security Standards Council](https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls) mandate, required us to discontinue support of TLS 1.0 and 1.1 on GitLab.com and in our GitLab API on Dec. 15, 2018.\n\nTLS 1.2 is now required for all clients that connect to GitLab.com and our GitLab API.\n\nAs we announced in our [October](/blog/gitlab-to-deprecate-older-tls/) and [November](/blog/gitlab-tls-support-discontinue-update/) blog posts about this initiative, we are always working to evolve our security posture and part of that evolution was the discontinuation of support for these older versions of TLS, which have been rendered outdated or proven to be prone to attacks. The migration away from these weaker cryptographic standards was key to GitLab's compliance with the Payment Card Industry (PCI) DSS 3.1 mandate, which required the deprecation of Secure Sockets Layer (SSL) 3.0, TLS 1.0, and some ciphers supported by TLS 1.1 from protocols supporting strong cryptography.\n\n### The discontinuation of support for TLS 1.0 and 1.1 is only for GitLab.com and our GitLab API\n\nThe changes required to discontinue TLS 1.0 and 1.1 support for self-managed installations are being tracked in [this public issue in the Omnibus project](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3875). These updates are currently being scheduled for major release 12.0, slated for Mar. 22, 2019.\n\nIf you have experienced any disruptions of service due to the discontinuation of support for TLS versions 1.0 and 1.1, please do not hesitate to reach out to [GitLab support](/support/#contact-support).\n\n## Identified client incompatibilities\n\nThe majority of traffic should be unaffected by the discontinuation of support for TLS versions 1.0 and 1.1. Currently, the vast majority of requests to GitLab.com are using up-to-date clients with support for TLS 1.2. While there are a few remaining clients that we believe will be affected (see below), most of these can be updated to work with TLS 1.2.\n\n### Git-Credential-Manager-for-Windows prior to 1.14.0\n\nVersions prior to 1.14.0 of Git-Credential-Manager-for-Windows do not support TLSv1.2. This can be addressed by updating to v1.14.0.\n\n### Git on Red Hat 5, \u003C 6.8, and \u003C 7.2\n\nUsers running Red Hat 5 are advised to upgrade to a newer version of the operating system as Red Hat does not have a point release planned for 5 that supports TLS 1.2. Git clients shipped with Red Hat 6 and 7 did not support TLSv1.2, which can be remediated by updating to versions 6.8 and 7.2 respectively.\n\n### JGit/Java releases \u003C JDK 8\n\nVersions of the JDK 6 and prior do not support TLSv1.2. We advise users of JDK \u003C= 6 to upgrade to a newer version of the JDK.\n\n### Visual Studio\n\nThe latest version of Visual Studio 2017 supports TLSv1.2. Users not running the latest version are advised to upgrade.\n\nIf you have any questions, please reach out to the Security team by emailing security@gitlab.com.\n",[9,782],{"slug":1134,"featured":6,"template":699},"gitlab-tls1011-discontinued-update","content:en-us:blog:gitlab-tls1011-discontinued-update.yml","Gitlab Tls1011 Discontinued Update","en-us/blog/gitlab-tls1011-discontinued-update.yml","en-us/blog/gitlab-tls1011-discontinued-update",{"_path":1140,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1141,"content":1146,"config":1153,"_id":1155,"_type":13,"title":1156,"_source":15,"_file":1157,"_stem":1158,"_extension":18},"/en-us/blog/introducing-markdown-live-preview",{"title":1142,"description":1143,"ogTitle":1142,"ogDescription":1143,"noIndex":6,"ogImage":734,"ogUrl":1144,"ogSiteName":685,"ogType":686,"canonicalUrls":1144,"schema":1145},"GitLab's realtime Preview Markdown is an editor for everyone","With GitLab's new realtime Preview Markdown, technical and non-technical team members can more easily work together. Here's everything you need to know.","https://about.gitlab.com/blog/introducing-markdown-live-preview","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's realtime Preview Markdown is an editor for everyone\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Parker Ennis\"}],\n        \"datePublished\": \"2021-09-21\",\n      }",{"title":1142,"description":1143,"authors":1147,"heroImage":734,"date":1149,"body":1150,"category":717,"tags":1151},[1148],"Parker Ennis","2021-09-21","\n\nFostering better, more meaningful collaboration is an integral part of DevOps and a key part of what GitLab, the complete DevOps Platform, unlocks for developers and their teams. While many developers or engineers feel more comfortable working locally on their machines and spend a majority of their time using a CLI to push code changes, with GitLab you can also use the [Web Editor](https://docs.gitlab.com/ee/user/project/repository/web_editor.html) or [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) to collaborate and edit content in a much easier, faster, and approachable way. \n\nStarting in [GitLab 14.2](https://about.gitlab.com/releases/2021/08/22/gitlab-14-2-released/), editing Markdown content in the Web Editor or Web IDE just got even better.\n\n### Introducing the real-time Preview Markdown editor\n\n[GitLab Flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html) automatically renders Markdown content in an easy-to-read and easy-to-write plain text language. Although Markdown is inherently more “human-readable” and versatile when writing rich web content, Markdown files can become tricky to work with as they become more verbose and complex. \n\nEasy-to-read and easy-to-write means different roles with varying degrees of technical experience can collaborate on content more efficiently and seamlessly. However, previewing the rendered output of Markdown content to validate the accuracy of any changes has not been as intuitive, requiring an extra step to switch out of the Web IDE or Web Editor where the raw source code lives in order to view the changes from the Preview tab. Frequent context-switching back and forth between tabs to validate changes leads to wasted time and can be disruptive to the creative process while writing content.\n\nIn GitLab 14.2, now both the Web IDE and Web Editor include [an option to preview Markdown in real-time, in a single window](/releases/2021/08/22/gitlab-14-2-released/#create-split-markdown-preview). A side-by-side preview panel will display when editing Markdown with a click of a button that will toggle a split view panel in the editor and render the content on the page you’re working on as the changes are being made. \n\nHere’s an example of what this new functionality looks like:\n\n![Example of real-time Markdown Preview side-by-side panels](https://about.gitlab.com/images/blogimages/markdown-live-preview.png){: .shadow.small}\n\n#### How do I use it?\n\nIt’s very straightforward to start using the side-by-side preview. When you are editing any Markdown file, even a newly created one, you can right-click the editor and select **Preview Markdown** or use `Command/Control + Shift + P` to toggle a split-screen live preview of your Markdown content. From there, all you need to do is start writing or editing content and you’ll see your changes in real time!\n\n![Example of the Preview Markdown button in the static editor](https://about.gitlab.com/images/blogimages/markdown-live-preview-hotkey.png){: .shadow.small}\n\n#### Everyone can contribute\n\nAt GitLab, [everyone can contribute](/company/mission/#everyone-can-contribute) and we welcome feedback in any form. As we usher in the [new DevOps Platform era ](/blog/welcome-to-the-devops-platform-era/) and wave goodbye to the all-too-familiar \"DIY\" style of DevOps, we're excited to iterate and improve with our wider community. \n\n## What is Markdown?\n \nMarkdown is a lightweight markup language for formatting text using a plain editor text. It was created by John Gruber and Aaron Swartz in 2004. It is now one of the most popular markup languages and is used mainly by writers and programmers to help them take notes, write quickly, and develop website content without figuring out how to use the formatting toolbar in text editors. A big part of its appeal is that you don't have to have any knowledge of HTML to use Markdown to write and create web pages.\n \nMarkdown is platform-independent and can be used to create websites, documents, notes, books, presentations, emails, and more. \n \nThere is some school of thought that Markdown is easier to write than HTML, and it's easier for most people to read Markdown source than HTML source. In fact, experts say you can learn Markdown in as little as 10 minutes.\n \n## What is Markdown used for?\n \nMarkdown can be used to format code in GitLab. Creating a markdown file in GitLab requires creating a new file with the .md extension. Once in the new file, the code can be written in Markdown syntax. When the code is finished, you can commit the file to your Git repository.\nWhile not as feature-laden as Microsoft Word, Markdown lets you create basic documents and use a Markdown document authoring app to export formatted documents to PDFs or HTML files.\n \nUsing Markdown is different than using a [WYSIWYG](https://en.wikipedia.org/wiki/WYSIWYG) editor. For example, in an application like Word, changes are visible immediately. Markdown is different. When a Markdown-formatted file is created, you add Markdown syntax to the text to indicate which words and phrases should look different.\n \n[For example,](https://www.markdownguide.org/getting-started/) to distinguish a heading, add a number sign before it (e.g., # Heading One). Or add two asterisks before and after a phrase to put it in bold (e.g., **this text is bold**). \nBolden and italicize text in Markdown without needing the WYSIWYG interface.\n\n",[1152,1091,9],"code review",{"slug":1154,"featured":6,"template":699},"introducing-markdown-live-preview","content:en-us:blog:introducing-markdown-live-preview.yml","Introducing Markdown Live Preview","en-us/blog/introducing-markdown-live-preview.yml","en-us/blog/introducing-markdown-live-preview",{"_path":1160,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1161,"content":1166,"config":1172,"_id":1174,"_type":13,"title":1175,"_source":15,"_file":1176,"_stem":1177,"_extension":18},"/en-us/blog/introducing-the-gitlab-kubernetes-agent",{"title":1162,"description":1163,"ogTitle":1162,"ogDescription":1163,"noIndex":6,"ogImage":1082,"ogUrl":1164,"ogSiteName":685,"ogType":686,"canonicalUrls":1164,"schema":1165},"Understand the new GitLab Agent for Kubernetes","Just released in 13.4, our brand new Kubernetes Agent provides a secure and K8s–friendly approach to integrating GitLab with your clusters.","https://about.gitlab.com/blog/introducing-the-gitlab-kubernetes-agent","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Understand the new GitLab Agent for Kubernetes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n        \"datePublished\": \"2020-09-22\",\n      }",{"title":1162,"description":1163,"authors":1167,"heroImage":1082,"date":1168,"body":1169,"category":693,"tags":1170},[907],"2020-09-22","\n\nWe are happy to share the first iteration of the GitLab Agent for Kubernetes with our users and community. The Agent is the foundation for the next generation of the integration between GitLab and Kubernetes. \n\n## A bit of history of the GitLab Kubernetes Integrations\n\nGitLab's current Kubernetes integrations were introduced more than three years ago. Their primary goal was to allow a simple setup of clusters and provide a smooth deployment experience to our users. These integrations served us well in the past years but at the same time its weaknesses were limiting for some important and crucial use cases. The biggest weaknesses we see with the current integration are:\n\n- the requirement to open up the cluster to the internet, especially to GitLab\n- the need for cluster admin rights to get the benefit of GitLab Managed Clusters\n- exclusive support for push-based deployments that might not suit some highly regulated industries\n\nA few months ago, the Configure Team at GitLab started going in a new direction to come up with an integration that could address these weaknesses and provide a cloud native tie-in between GitLab and Kubernetes. This new direction is built on the GitLab Agent for Kubernetes, which we released in [GitLab 13.4](/releases/2020/09/22/gitlab-13-4-released/).\n\n## Design goals\n\nWhen we sat down to solve for the above weaknesses, we came up with a few principles that we are seeking to follow.\n\nWe want to be good cloud native citizens, and work together with the community, instead of reinventing the wheel.\n\nWe primarily want to serve expert Kubernetes platform engineers. While the current GitLab Managed Clusters and cluster creation from within GitLab might serve many use cases, it's primarily aimed at simple cluster setup and is not flexible enough to be the basis for production clusters. We want to change this approach, and are focusing on the needs of expert Kubernetes engineers first. We think that coming up with sane defaults will provide the necessary simplicity for new Kubernetes users as well.\n\nWe want to offer a secure solution that allows cluster operators to restrict GitLab's rights in the cluster and does not require opening up the cluster to the Internet.\n\n## The Agent\n\nFollowing the above goals, we've started to develop the GitLab Agent for Kubernetes. The Agent provides a permanent communication channel between GitLab and the cluster. To follow industry best practices for [GitOps](/topics/gitops/) it is configured by code, instead of a UI.\n\nThe current version of the Agent allows for pull-based deployments. Its deployment machinery is built on the [`gitops-engine`](https://github.com/argoproj/gitops-engine), a project initiated by ArgoCD and Flux where GitLab engineers are actively contributing as well.\n\n### Setting up the GitLab Agent\n\nThe Agent needs to be set up first. This requires a few actions from the user:\n\n- create an Agent token for authentication with GitLab, and store it in your cluster as a secret\n- commit the necessary Agent configurations in one of your repositories\n- install the Agent to your cluster\n\n### Deployments with an Agent\n\nAs mentioned above, the Agent needs a configuration directory inside one of your repositories. This configuration describes the projects that the Agent syncs into your clusters. We call the synced projects the __manifest project__. The manifest project should contain Kubernetes manifest files. The __manifest project__ project might be either inside or separated from your application code.\n\nWe've set up a simple example that shows a __manifest project__ and an __application project__. In this example [GitLab CI/CD](/topics/ci-cd/) in the __application project__ is used to create a container image and update the __manifest project__. Then the Agent picks up the changes from the __manifest project__, and deploys the Kubernetes manifests stored there.\n\n### Limitations\n\nAs this is the initial release of the Agent, it has many known limitations. We don't support all the amazing features the previous GitLab Kubernetes integration does such as [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/), deploy boards, GitLab Managed Apps, etc. To start in GitLab 13.4 we limited our focus to supporting pull-based deployment for Helm-based GitLab installations. \n\nFollowing the current release, we will be focusing on:\n\n- [shipping the GitLab Agent for Kubernetes as part of the Official Linux Package](https://gitlab.com/groups/gitlab-org/-/epics/3834)\n- [supporting the deployment of private repositories](https://gitlab.com/gitlab-org/gitlab/-/issues/220912)\n\n## Further plans for GitLab Kubernetes Integrations\n\nThe Agent opens up many new opportunities for GitLab's Kubernetes integrations. Having an active component allows us to provide all the GitLab functionalities in locked down clusters as well. We're currently looking into the following areas to support with the agent:\n\n- integrate cluster-side dynamic container scanning with GitLab\n- use GitLab as an authentication and authorization provider for Kubernetes clusters\n- offer linters and checks for Kubernetes best practices on deployed resources\n- proxy cluster services easily through GitLab\n\nYou can see all our plans in the [Agent epic](https://gitlab.com/groups/gitlab-org/-/epics/3329) where we invite you to give us feedback and about this direction. \n\nYou can view a demo of how to install and use the GitLab Agent below:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://player.vimeo.com/video/505413162\" width=\"640\" height=\"480\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n",[847,9,1171,696],"cloud native",{"slug":1173,"featured":6,"template":699},"introducing-the-gitlab-kubernetes-agent","content:en-us:blog:introducing-the-gitlab-kubernetes-agent.yml","Introducing The Gitlab Kubernetes Agent","en-us/blog/introducing-the-gitlab-kubernetes-agent.yml","en-us/blog/introducing-the-gitlab-kubernetes-agent",{"_path":1179,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1180,"content":1185,"config":1191,"_id":1193,"_type":13,"title":1194,"_source":15,"_file":1195,"_stem":1196,"_extension":18},"/en-us/blog/job-artifact-meta-data-expiration-change",{"title":1181,"description":1182,"ogTitle":1181,"ogDescription":1182,"noIndex":6,"ogImage":1082,"ogUrl":1183,"ogSiteName":685,"ogType":686,"canonicalUrls":1183,"schema":1184},"Artifact and job meta data expiration settings are changing for GitLab.com","Default expiration dates for job meta data and artifacts will change on June 22, 2020. Find out how this benefits all users of GitLab.com","https://about.gitlab.com/blog/job-artifact-meta-data-expiration-change","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Artifact and job meta data expiration settings are changing for GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Parker Ennis\"}],\n        \"datePublished\": \"2020-06-18\",\n      }",{"title":1181,"description":1182,"authors":1186,"heroImage":1082,"date":1187,"body":1188,"category":717,"tags":1189},[1148],"2020-06-18","\n\nTo help maintain overall stability and performance for all GitLab users, some changes are coming to GitLab.com effective June 22, 2020. This will directly impact the default retention period for [older job metadata](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#archive-jobs) as well as enable a [default expiration policy](https://docs.gitlab.com/ee/user/gitlab_com/index.html#gitlab-cicd) for older job artifacts.\n\n## TL;DR\n\n### **Updating GitLab.com's Job Artifact Expiration Policy**\n\nWhat you need to know:\n* Starting June 22, 2020, new job artifacts will immediately default to a 30 day expiration upon initial creation.\n* Existing job artifacts without an expiration date that were created after October 22, 2019, but before June 22, 2020, will have their expiration date set to 1 year after the initial creation date.\n   * _For example, if the last pipeline job you created and ran successfully was on November 10th, 2019, then the job artifacts produced by that job upon completion would have a default expiration date automatically set to November 10th, 2020._\n* Existing job artifacts without an expiration date that were created before October 22, 2019, will have their expiration date set to April 22, 2021.\n   * _For example, if the last pipeline job you created and ran successfully was on July 10th, 2019, then the job artifacts produced by that job upon completion would have a default expiration date automatically set to April 22nd, 2021, unless you specify a different expiration date._\n\nFor additional details, please see our [GitLab.com CI/CD settings documentation](https://docs.gitlab.com/ee/user/gitlab_com/index.html#gitlab-cicd).\n\n### **Default archive of jobs on GitLab.com set to 3 months**\n\nWhat you need to know:\n* Starting June 22, 2020 jobs older than 12 months will be archived.\n* Starting August 6, 2020 jobs older than 6 months will be archived.\n* Starting September 22, 2020 jobs older than 3 months will be archived. This will be the default setting going forward on GitLab.com.\n* New build data will be archived 3 months after creation starting June 22, 2020.\n* New job metadata will be archived 3 months after creation starting June 22, 2020.\nFor additional details, please see our GitLab.com CI/CD settings documentation, linked above.\n\n## Additional context\n\n### What are we doing and why?\n\nThe functionality changes will set build artifacts to expire on GitLab.com after 30 days and archive [build metadata](/blog/building-build-images/) after 3 months. In most cases, you probably aren't utilizing old job artifacts that are sitting in storage and will be set to expire. This same concept applies to old metadata for jobs that aren't getting used and you may have even forgotten about.\n\n### When do the changes take effect?\n\nNew artifacts will have their expiration date set to 30 days by default starting June 22nd, 2020. Existing artifacts will automatically have their expiration dates set to the updated policy if they aren't already set by the aforementioned date. The last of those existing artifacts will have an expiration date of 12 months.\n\nAdditionally, build data older than 12 months will be archived on June 22, 2020 and any other data will be gradually set to expire within 3 months of the original creation date over the next 3 months.\n\n### What if I want to keep my artifacts and data? How can I do that?\n\nDon't worry! You can always override artifact expiration with the 'expire_in' keyword to keep a job artifact longer than 30 days. Additionally, artifacts from the [last successful job](https://gitlab.com/gitlab-org/gitlab/-/issues/16267) that were created after September 22, 2020, will not be archived after 30 days.\n\n### What's the benefit to end users?\n\nThese actions will result in improved performance and value for everyone using GitLab. By making these changes, we'll free up a significant amount of space in both the GitLab.com database and on disk, which results in better reliability/performance. It also reduces operational costs for GitLab, which aids us in continuing to provide all users with the smoothest possible user experience far into the future!\n\n",[1190,9,949],"performance",{"slug":1192,"featured":6,"template":699},"job-artifact-meta-data-expiration-change","content:en-us:blog:job-artifact-meta-data-expiration-change.yml","Job Artifact Meta Data Expiration Change","en-us/blog/job-artifact-meta-data-expiration-change.yml","en-us/blog/job-artifact-meta-data-expiration-change",{"_path":1198,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1199,"content":1205,"config":1211,"_id":1213,"_type":13,"title":1214,"_source":15,"_file":1215,"_stem":1216,"_extension":18},"/en-us/blog/live-from-commit-news",{"title":1200,"description":1201,"ogTitle":1200,"ogDescription":1201,"noIndex":6,"ogImage":1202,"ogUrl":1203,"ogSiteName":685,"ogType":686,"canonicalUrls":1203,"schema":1204},"At GitLab Commit, our product roadmap, new partners, and a new milestone","Live from GitLab Commit: what’s next for our product strategy, expanded partnerships, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664134/Blog/Hero%20Images/gitlabcommitbrooklyn.png","https://about.gitlab.com/blog/live-from-commit-news","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"At GitLab Commit, our product roadmap, new partners, and a new milestone\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-09-17\",\n      }",{"title":1200,"description":1201,"authors":1206,"heroImage":1202,"date":1207,"body":1208,"category":300,"tags":1209},[800],"2019-09-17","\nOur first ever user conference – GitLab Commit in Brooklyn – has only been under way for a few hours and we’ve already made a number of key announcements. Not only did we secure an additional [$268 million in Series E funding](/blog/gitlab-series-e-funding/) to power our DevOps journey forward, we’ve also strengthened key partnerships, hit new milestones, and released details about important new features in the product.\n\n## GitLab is for everyone\n\nIn the next few releases, look for GitLab to add advanced integration with the [Amazon Elastic Kubernetes](https://aws.amazon.com/eks/) service (EKS), something our CEO [Sid Sijbrandij](/company/team/#sytses) told the audience during his keynote at Commit. Sid also said the number of customers using GitLab with [Terraform by HashiCorp](/blog/gitlab-hashicorp-terraform-vault-pt-1/) is increasing at an exciting rate. This Ops-focused solution leverages GitLab’s CI/CD automated pipelines to better achieve infrastructure as code, a.k.a. GitOps. Lastly, later this year, look out for GitLab to integrate with HashiCorp’s very popular [Vault Project](https://www.vaultproject.io/docs/internals/security.html) that will protect secrets throughout the pipeline.\n\nMoving forward, Sid stressed that we believe everyone has a seat at the table. \"We will make our vision of a complete DevSecOps a reality for each and every one of you,\" says Sid.\n\nAnd for those who’ve been hoping for auto remediation, it’s coming, says [Mark Pundsack](/company/team/#markpundsack), vice president of product strategy, during his keynote. There is work to be done but the vision is clear: Necessary but repetitive security work will be automated in the near future.\n\nThat’s not the end, however. Mark outlined a future where operations and security teams have their own customized dashboards on GitLab, giving them access to the same information as developers. “A ton of people are involved with the development and delivery of software,” says Mark. “That is the ultimate GitLab vision: Where every knowledge worker involved with software development and delivery uses a single application so they are on the same page with the rest of their team members.” Ultimately GitLab will expand to the business side, bringing project managers, designers, legal, and executives into the mix. Mark’s final message: “GitLab is for everyone.”\n\n## GitLab & VMWare\n\n[GitLab and VMWare](https://www.globenewswire.com/news-release/2019/09/17/1916738/0/en/GitLab-to-Enable-Cloud-Native-Transformation-on-VMware-Cloud-Marketplace.html) announced a collaboration making [GitLab now available on the VMWare Cloud marketplace](https://about.gitlab.com/2019-09-17-gitlab-on-vmware-cloud-marketplace/). Development teams will be able to deploy and run [GitLab Enterprise (Core)](/pricing/) on their VMWare environments with just a few clicks. GitLab is packaged and supported by Bitnami which provides curated applications for the VMWare marketplace. GitLab also supports [“Continuous Verification”](https://thenewstack.io/how-continuous-security-can-solve-the-cloud-protection-conundrum/) by integrating with VMWare Secure State, Wavefront by VMWare, and CloudHealth.\n\n## KDE chooses GitLab\n\nKDE, an international technology community creating free and open source software for desktop and portable computing, [chose GitLab](https://www.globenewswire.com/news-release/2019/09/17/1916731/0/en/GitLab-Adopted-by-KDE-to-Foster-Open-Source-Contributions.html) for its developers. The KDE team wants to offer additional infrastructure support and thinks GitLab will help boost development momentum.\n\nThe KDE community is one of the largest free software communities with more than 2,600 contributors. Now they’ll have access to an even wider range of development and code review features with GitLab’s DevOps platform to complement their tools currently in use. The KDE community will have additional options for accessible infrastructure for contributors, code review integration with Git, streamlined infrastructure and tooling, and an open communication channel with the upstream GitLab community.\n\n## Forbes 2019 Cloud 100\n\nWe’re pretty excited to mention we’ve been named to the [Forbes 2019 Cloud 100](https://www.forbes.com/sites/mnunez/2019/09/11/a-truck-tracker-a-coder-toolbox-and-a-unicorn-from-down-under-inside-this-years-cloud-100/#6148bcad5653), the definitive ranking of the top 100 private cloud companies in the world, published by Forbes in partnership with Bessemer Venture Partners and Salesforce Ventures. We’re the only cloud-agnostic DevOps platform, and [we came in at number 32](https://about.gitlab.com/2019-09-11-gitlab-named-leader-in-forbes-cloud-100-list/)!\n\nIf you like what you’re hearing out of GitLab Commit Brooklyn, then join us at our next [GitLab Commit in London](/events/commit/#) on October 9.\n",[268,278,888,9,1210],"frontend",{"slug":1212,"featured":6,"template":699},"live-from-commit-news","content:en-us:blog:live-from-commit-news.yml","Live From Commit News","en-us/blog/live-from-commit-news.yml","en-us/blog/live-from-commit-news",{"_path":1218,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1219,"content":1225,"config":1232,"_id":1234,"_type":13,"title":1235,"_source":15,"_file":1236,"_stem":1237,"_extension":18},"/en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt",{"title":1220,"description":1221,"ogTitle":1220,"ogDescription":1221,"noIndex":6,"ogImage":1222,"ogUrl":1223,"ogSiteName":685,"ogType":686,"canonicalUrls":1223,"schema":1224},"How to manage your Snowflake spend with Periscope and dbt","The GitLab data team is open sourcing the dbt package they use to manage their Snowflake spend.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670255/Blog/Hero%20Images/data-servers.jpg","https://about.gitlab.com/blog/managing-your-snowflake-spend-with-periscope-and-dbt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to manage your Snowflake spend with Periscope and dbt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor Murphy\"},{\"@type\":\"Person\",\"name\":\"Emilie Schario\"}],\n        \"datePublished\": \"2019-08-26\",\n      }",{"title":1220,"description":1221,"authors":1226,"heroImage":1222,"date":1229,"body":1230,"category":886,"tags":1231},[1227,1228],"Taylor Murphy","Emilie Schario","2019-08-26","On the data team at GitLab, we are grateful to be empowered with best\nin-class tools that enable us to produce high-quality work. At the 2018\nDataEngConf (now Data Council), GitLab data engineer [Thomas La\nPiana](/company/team/#tlapiana) spoke about how a team of three was\nsupporting the data needs of a billion-dollar company. As he explains in\nthis talk, we focus a lot on processes and workflows.\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/eu623QBwakc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\n## Where are the existing gaps?\n\nToday, the data team has grown from three to seven: three engineers and four\nanalysts.\n\nSince we've more than doubled in the last six months, we've had to take a\nstep back and revisit our processes.\n\n\n![GitLab Team\nHeadcount](https://about.gitlab.com/images/blogimages/team_headcount.png){:\n.shadow.medium.center}\n\nThe GitLab team has grown significantly in the past few months.\n\n{: .note.text-center}\n\n\n### GitLab is growing fast\n\n\nDespite the significant jump in the data team's headcount, our growth has\nnot matched the exponential growth of the team supporting GitLab.\n\nAs GitLab grows, more folks aim to include more data in their\ndecision-making process.\n\nThis means we're iterating quickly, collecting feedback, and constantly\nimproving on the quality of the analyses we are producing for our business\nstakeholders.\n\nThe demand for more data means there is a lot more to accomplish – making\nnow an opportune time to review our processes and improve the data team's\nimpact across GitLab.\n\n\nFor example, a data team member pointed out that refinement isn't a part of\nour [milestone planning\nprocess](/handbook/business-technology/data-team/how-we-work/#milestone-planning).\n\nNo wonder our backlog wasn't moving anywhere! We identified the root of the\nproblem by asking our team, \"What is the problem we're trying to solve?\" and\nthen laid out a plan to address it.\n\n\n### Onboarding can be hard\n\n\nWe've made some great data analyst hires recently!\n\nWe don't require our new team members to be familiar with our existing data\nstack (Stitch/Singer - Snowflake - dbt - Periscope), but we do require them\nto have technical skills that match their role.\n\nThis usually includes Git, SQL, and Python (Pandas) at the bare minimum,\nthough we welcome R (tidyverse) as well.\n\nWhile onboarding at any company can be difficult, it's especially\nchallenging in an all-remote organization such as GitLab.\n\n\nIn addition to introducing candidates to our specific technologies, part of\nthe [data analyst\nonboarding](https://gitlab.com/gitlab-data/analytics/blob/master/.gitlab/issue_templates/data_onboarding.md)\nincludes a unit on resource consumption.\n\nWe spend time introducing the concepts of databases and warehouses in\nSnowflake, because storage and compute being separate are often novel ideas\nto folks joining GitLab from an on-premise data organization.\n\nIn some cases, we are teaching our new hires a new way to think about the\ndata-related problems they're solving, and introducing different resources\nto remedy these problems.\n\n\n### With great power comes great responsibility\n\n\nWe consume more resources as the data team headcount grows. I think about\nthis like folks using water in a household. If everyone is on vacation, the\nwater bill will be low, but if all the cousins come visit for a week, the\nbill will be high.\n\nSimilarly to why we encourage a big group of visiting relatives to take\nshorter showers to conserve water, on the data team we work to steward\nresources effectively. This means we must identify wasted resources to\nrecapture them.\n\nIt's important that our operating expenses not balloon with headcount.\n\n\n## Are you protected against a leak?\n\n\nAs a homeowner, I can share a myriad of appliance-gone-wrong stories, but\none tops them all: the time there was a leak in our front yard that we only\ndiscovered because of a $1,000 water bill.\n\nOften, homeowners can only measure water usage when the bill arrives, when\nit's always too late to fix it.\n\n\nLucky for our team and yours, Snowflake is much more generous than my water\ncompany.\n\nWe *can* monitor our costs as it accrues.\n\nAfter having this process in place for a bit now, we'd encourage you to\nimplement it in your stack.\n\n\n## Monitor your Snowflake spend with dbt and Periscope\n\n\nWe're excited to make our [Snowflake spend dbt\npackage](https://gitlab.com/gitlab-data/snowflake_spend) widely available\nfor use.\n\nDoing this is in line with our belief in the value of [open source\nanalytics](/blog/open-source-analytics/).\n\n\nTo get started, you'll need to grant access to the `snowflake` database to\nyour dbt-specific role with:\n\n```\n\nGRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE \u003Crole>;\n\n```\n\n\nThen you'll need to update the `packages.yml` file in your dbt project to\ninclude the following:\n\n```\n\npackages:\n  - git: https://gitlab.com/gitlab-data/snowflake_spend.git\n    revision: v1.0.0\n```\n\n\nToday, you can only install the package directly from Git.\n\nSince it doesn't depend on any other packages, you don't have to worry about\nversion management, so this should not cause any problems.\n\nYou can run `dbt deps` to ensure the package is installed correctly.\n\n\nYou will need a csv called `snowflake_contract_rates.csv` which has two\ncolumns: effective date and rate. The effective date is the day the new\ncontracted rate started and it should be in YYYY-MM-DD format. The rate is\nthe per credit price for the given time period. You can see how the data\nteam configures [their csv\nfile](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/data/snowflake_contract_rates.csv).\nYou will need to run `dbt seed` for the csv to be loaded as a table and for\nthe model to run succesfully.\n\n\nFinally, you will need to update your `dbt_project.yml` file to enable this\npackage with the following block.\n\n```\n\nmodels:\n  snowflake_spend:\n    enabled: true\n```\n\nYou can see [how the data team has configured the\npackage](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/dbt_project.yml#L68)\nin our `dbt_project.yml` file.\n\n\nRunning `dbt compile` will not only test that you've configured all of this\ncorrectly, but also will compile the files in the `analysis` directory.\nThese are the queries that we use to underlie the exact Periscope dashboard\nthat we have automatically posted in Slack every day.\n\n\n![GitLab's Periscope dashboard for managing Snowflake\nspend](https://about.gitlab.com/images/blogimages/periscope_snowflake_spend1.png){:\n.shadow.medium.center}\n\n![GitLab's Periscope dashboard for managing Snowflake\nspend](https://about.gitlab.com/images/blogimages/periscope_snowflake_spend2.png){:\n.shadow.medium.center}\n\n\nOnce you've set up this dashboard, you can configure it to auto-refresh\ndaily.\n\nThen use Slack's `/remind app.periscopedata.com/dashboardurl` to have it\nregularly publish in the channel of your choice.\n\n\nYou can see how our resource management initiatives have been effective.\n\nWe hope you'll find monitoring a key step to helping manage your own\nSnowflake spend.\n\n\nHave any thoughts, questions, or suggestions? [Create an\nissue](https://gitlab.com/gitlab-data/snowflake_spend/issues).\n\n\nPhoto by [Taylor Vick](https://unsplash.com/photos/M5tzZtFCOfs) on\n[Unsplash](https://unsplash.com/)\n\n{: .note}\n",[1050,268,888,9],{"slug":1233,"featured":6,"template":699},"managing-your-snowflake-spend-with-periscope-and-dbt","content:en-us:blog:managing-your-snowflake-spend-with-periscope-and-dbt.yml","Managing Your Snowflake Spend With Periscope And Dbt","en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt.yml","en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt",{"_path":1239,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1240,"content":1245,"config":1252,"_id":1254,"_type":13,"title":1255,"_source":15,"_file":1256,"_stem":1257,"_extension":18},"/en-us/blog/new-elasticsearch-version-requirements",{"title":1241,"description":1242,"ogTitle":1241,"ogDescription":1242,"noIndex":6,"ogImage":1082,"ogUrl":1243,"ogSiteName":685,"ogType":686,"canonicalUrls":1243,"schema":1244},"GitLab 11.5 adds Elasticsearch 6, removes ES 5.5 support","GitLab 11.5 will support Elasticsearch version 6 and 5.6, sunsetting support for versions 5.5 and earlier.","https://about.gitlab.com/blog/new-elasticsearch-version-requirements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 11.5 to support Elasticsearch 6, sunset support for Elasticsearch 5.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mario de la Ossa\"}],\n        \"datePublished\": \"2018-11-16\",\n      }",{"title":1246,"description":1242,"authors":1247,"heroImage":1082,"date":1249,"body":1250,"category":693,"tags":1251},"GitLab 11.5 to support Elasticsearch 6, sunset support for Elasticsearch 5.5",[1248],"Mario de la Ossa","2018-11-16","\nIn Gitlab 11.5 (to be released on Nov. 22, 2018), GitLab's [Elasticsearch integration](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html)\nwill support Elasticsearch version 6, and will no longer support versions 5.5 or earlier.\nPlease make plans to upgrade Elasticsearch to version 5.6 or 6.x immediately before upgrading to GitLab 11.5. After you upgrade GitLab, you will also need\nto perform a [reindex](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html),\nas the changes required to support these Elasticsearch versions are incompatible with the indexes of previous versions.\n\nIn summary, starting with 11.5, GitLab will support:\n- Elasticsearch version 5.6\n- Elasticsearch version 6.x\n\nIf you are using GitLab.com, this does not impact you in any way. This is only relevant\nfor [self-managed GitLab](/pricing/#self-managed).\n{: .alert .alert-info}\n\nGitLab uses Elasticsearch for [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_search.html)\nand [Advanced Syntax Search](https://docs.gitlab.com/ee/user/search/advanced_search.html).\n\n## Why are we doing this?\n\nElasticsearch version 6 brings with it two large changes that were incompatible with the way we currently index:\n\n- The [removal of mapping types](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/removal-of-types.html).\n- Parent-child relationships are now established via a [`join` datatype](https://www.elastic.co/guide/en/elasticsearch/reference/6.0/parent-join.html).\n\nWe'll go into some detail on how each of these changes affects GitLab.\n\n### Removal of mapping types\n\nIn Elasticsearch 6, all documents under the same index must be of the same 'type.' We need to keep all documents under the same index\nin order to be able to query based on project membership and permissions, so this change forced us to implement our own\n`type` field in order to still be able to query only a single type (for example, issues).\n\nThis removal of mapping types also affected [the way parent-child relationships work](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/removal-of-types.html#_parent_child_without_mapping_types).\n\n### `join` datatype\n\nWith the mapping type change comes a change to the way parent-child relationships\nare expressed. Elasticsearch 5.6 and 6.x have introduced a [`join` datatype](https://www.elastic.co/guide/en/elasticsearch/reference/6.0/parent-join.html)\nthat GitLab 11.5 puts to use. (As of 6.0, it is the required method for defining these relationships.)\n\nWhen using `join`, all insertions and deletions must be routed relative to their\nparent – which means we must send the parent's ID in the `routing` field. In 5.6,\nthis means that the `_parent` field is ignored, and in 6.x it is removed.\n\n### Why Elasticsearch 5.6 remains compatible\n\nAs noted in the [schedule for removal of mapping types](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/removal-of-types.html#_schedule_for_removal_of_mapping_types),\nversion 5.6 is the first Elasticsearch version where the `join` datatype is available, as well as the first version where `single_type`\nbehavior can be enabled.\n\nWe tested versions 5.5 and below, and unfortunately they have no support for `join` datatypes, so we need to end support for these versions as of GitLab 11.5.\n\nWe're especially looking forward to supporting Elasticsearch version 6 as it brings with it some great [improvements](https://www.elastic.co/blog/elasticsearch-6-0-0-released), including:\n\n- Major improvements for sparsely populated fields\n- Faster query times with sorted indices\n- Search scalability across shards\n",[695,9],{"slug":1253,"featured":6,"template":699},"new-elasticsearch-version-requirements","content:en-us:blog:new-elasticsearch-version-requirements.yml","New Elasticsearch Version Requirements","en-us/blog/new-elasticsearch-version-requirements.yml","en-us/blog/new-elasticsearch-version-requirements",{"_path":1259,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1260,"content":1265,"config":1271,"_id":1273,"_type":13,"title":1274,"_source":15,"_file":1275,"_stem":1276,"_extension":18},"/en-us/blog/old-runners-stop-working",{"title":1261,"description":1262,"ogTitle":1261,"ogDescription":1262,"noIndex":6,"ogImage":734,"ogUrl":1263,"ogSiteName":685,"ogType":686,"canonicalUrls":1263,"schema":1264},"Breaking change: Support ending for runners Prior to 9.0","With the removal of deprecated CI API v1, runners older than 9.0 will stop working with GitLab 10.0","https://about.gitlab.com/blog/old-runners-stop-working","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Breaking change: Support for Runners prior to 9.0 will be removed imminently\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabio Busatto\"}],\n        \"datePublished\": \"2017-09-04\",\n      }",{"title":1266,"description":1262,"authors":1267,"heroImage":734,"date":1268,"body":1269,"category":717,"tags":1270},"Breaking change: Support for Runners prior to 9.0 will be removed imminently",[1087],"2017-09-04","\n\nThis month, when we release GitLab 10.0, **deprecated runners will not be able to communicate with the system anymore**, since they rely on an old version of the API that will be removed.\nAll runners with version 9.0 or newer will continue to work as usual without any modification.\nWe encourage all of our users who still have old runners deployed to **upgrade them to the latest version as soon as possible** to avoid any downtime.\n\n\u003C!-- more -->\n\nIn the GitLab 9.0 release post, we announced that previous runners have been [officially deprecated](/releases/2017/03/22/gitlab-9-0-released/#gitlab-runner-deprecation), and the support for them would have been eventually dropped in a future release.\nWith another specific [blog post](/releases/2017/04/10/upcoming-runner-changes-for-gitlab-dot-com/) back in April, we also announced that we migrated our shared runners on GitLab.com, and which are the great benefits in upgrading to the latest version, and we started a process to dismiss support for any version prior to 9.0.\n\n## When will this happen?\n\nGitLab 10.0 will be released on September, 22nd. Please consider that old runners connected to GitLab.com will stop working as soon as the first RC gets deployed to production, and this will happen around September 8th.\n**Be sure that you upgrade all your runners before that date**.\n\n## Which versions are affected?\n\nAll runners with a version older than 9.0 will stop working with GitLab 10.0, as they rely on old API that will be removed in this release. This means that you can continue using your old runners with any GitLab version up to 9.5, even if it is not suggested. Upgrading GitLab to 10.0 or above will require upgrading the runners as well.\n\n## How can I check if I have old runners still active?\n\nIf you are an Admin of a GitLab instance, you can find the list of shared runners under **Admin area ➔ Overview ➔ Runners**. Check the **Version** column to find if you have runners older than 9.0.\n\nIf you are Owner or Master for a project, go to **Settings ➔ CI/CD** (or **Settings ➔ Pipelines** if you are using the old navigation) and click on each of the runners you may find under **Specific Runners** to see the version.\n\n## How can I upgrade an old runner?\n\nRunners can be upgraded to the latest version following [these instructions](https://docs.gitlab.com/runner/#install-gitlab-runner). After the update, the runner should start working again as before, even better!\n",[9,717,805],{"slug":1272,"featured":6,"template":699},"old-runners-stop-working","content:en-us:blog:old-runners-stop-working.yml","Old Runners Stop Working","en-us/blog/old-runners-stop-working.yml","en-us/blog/old-runners-stop-working",{"_path":1278,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1279,"content":1284,"config":1290,"_id":1292,"_type":13,"title":1293,"_source":15,"_file":1294,"_stem":1295,"_extension":18},"/en-us/blog/python-3-defailt-for-license-compliance",{"title":1280,"description":1281,"ogTitle":1280,"ogDescription":1281,"noIndex":6,"ogImage":734,"ogUrl":1282,"ogSiteName":685,"ogType":686,"canonicalUrls":1282,"schema":1283},"Python 3 becomes default for license compliance scanning","Python 3 will soon become the default version used by the Secure stage License Compliance feature.","https://about.gitlab.com/blog/python-3-defailt-for-license-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Upcoming breaking change: Python 3 will be the default version used in License Compliance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nicole Schwartz\"}],\n        \"datePublished\": \"2019-07-19\",\n      }",{"title":1285,"description":1281,"authors":1286,"heroImage":734,"date":1287,"body":1288,"category":717,"tags":1289},"Upcoming breaking change: Python 3 will be the default version used in License Compliance",[863],"2019-07-19","\n\nWith the release of GitLab 12.2 on August 22, Python 3 will become the default version used in the Secure\nstage License Compliance\u003Csup>1\u003C/sup> feature. GitLab.com users should expect to see the change at\nthe beginning of August.\n\n### What do I do if I use Python 2.0?\n\nGitLab self-managed users with Python 2 will need to set the CI variable `LM_PYTHON_VERSION` to \"2\" when\nthey start using GitLab 12.2. GitLab.com users will need to do so at the beginning of August.\n\nIn the GitLab 12.0 release post, [we announced License Compliance\u003Csup>1\u003C/sup> will change the\ndefault version of Python from version\n2 to version 3](/releases/2019/06/22/gitlab-12-0-released/#license-management-will-use-python-3-as-the-default-in-gitlab-12.2)\nin GitLab 12.2, and that support for Python 2 would be deprecated in a future release due\nto [Python 2.7 reaching the end of its life](https://pythonclock.org/) on Jan. 1, 2020.\n\n### What if I currently use Python 3?\n\nYou can change License Compliance\u003Csup>1\u003C/sup> to use Python 3 by setting the CI\nvariable `LM_PYTHON_VERSION` to \"3\" today. If you do not make this change before the default\nis changed, it will only begin to work starting with GitLab 12.2.\n\n##### \u003Csup>1\u003C/sup>What is License Compliance?\n\nLicense Compliance, formerly called License\nManagement, [is being renamed to better align with common industry vernacular starting in 12.2](/releases/2019/06/22/gitlab-12-0-released/#secure-license-management-renamed-to-license-compliance-in-gitlab-12.0).\nThe purpose of License Compliance is to track which licenses are used by third-party\ncomponents included in your project, like libraries and external dependencies, and to check that\nthey are compatible with your organizations licensing model. License Compliance is part of our\n[Secure Composition Analysis group](https://handbook.gitlab.com/handbook/product/categories/#composition-analysis-group).\n\nYou can view the [documentation for License Management here](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html).\n",[9,717,232],{"slug":1291,"featured":6,"template":699},"python-3-defailt-for-license-compliance","content:en-us:blog:python-3-defailt-for-license-compliance.yml","Python 3 Defailt For License Compliance","en-us/blog/python-3-defailt-for-license-compliance.yml","en-us/blog/python-3-defailt-for-license-compliance",{"_path":1297,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1298,"content":1303,"config":1309,"_id":1311,"_type":13,"title":1312,"_source":15,"_file":1313,"_stem":1314,"_extension":18},"/en-us/blog/removing-mysql-support",{"title":1299,"description":1300,"ogTitle":1299,"ogDescription":1300,"noIndex":6,"ogImage":734,"ogUrl":1301,"ogSiteName":685,"ogType":686,"canonicalUrls":1301,"schema":1302},"Why we're ending support for MySQL in 12.1","GitLab will be ending support for MySQL starting with our 12.1 release – here's why.","https://about.gitlab.com/blog/removing-mysql-support","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we're ending support for MySQL in 12.1\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kenny Johnston\"}],\n        \"datePublished\": \"2019-06-27\",\n      }",{"title":1299,"description":1300,"authors":1304,"heroImage":734,"date":1306,"body":1307,"category":300,"tags":1308},[1305],"Kenny Johnston","2019-06-27","\nIn July of 2017 [GitLab documented that we would be deprecating support for MySQL](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1756).\nWell, the 12.1 release marks the conclusion of our\ndeprecation period and it will [no longer support MySQL](https://gitlab.com/gitlab-org/gitlab-ce/issues/52442).\nIt wasn't an easy decision, but we wanted to share with you why we did it.\n\n## It wasn't great for our use case\n\nThere are lots of great use cases for MySQL, our specific needs just didn't seem to be a good fit. [Our use of MySQL\nhad a number of limitations](https://gitlab.com/gitlab-org/gitlab-ce/issues/51173#issues). In most cases, it wasn't\nas simple as adding support to MySQL, but that by bending MySQL we typically broke PostgreSQL. To name a few limitations:\n\n* We can't [support nested groups with MySQL in a performant way](https://gitlab.com/gitlab-org/gitlab-ce/issues/30472#note_27747600)\n* We have to use hacks to increase limits on columns and this can lead to [MySQL refusing to store data](https://gitlab.com/gitlab-org/gitlab-ce/issues/49583)\n* MySQL [can't add](https://gitlab.com/gitlab-org/gitlab-ce/issues/40168) `TEXT` type column without `length` specified\n* MySQL doesn't [support partial indexes](https://dba.stackexchange.com/questions/106589/to-have-postgresql-like-partial-index-in-mysql-5-5)\n* These limitations have already created a number of places where MySQL was already not supported (including with [Geo](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11914/diffs))\n\n## It made us slower\n\nIn order to work around some of the pain points above, we ended of creating a lot of [MySQL](https://gitlab.com/gitlab-org/gitlab-ee/blob/7ef7c604729c2627914bcc0ece3355786a9a3413/ee/db/migrate/20180831134049_allow_many_prometheus_alerts.rb#L30)-[specific](https://gitlab.com/gitlab-org/gitlab-ee/blob/7ef7c604729c2627914bcc0ece3355786a9a3413/db/migrate/prometheus_metrics_limits_to_mysql.rb)\ncode. In some cases this led to [merge requests that were twice as complex](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16793)\nbecause they had to support a second database backend. Creating and maintaining this code is a drain on our cycle time and velocity, and it puts a\ndampener on our value of iteration.\n\nIt also made us slower because our CI system would run our test suites twice, once on each backend. Removing support\nfor MySQL reduces the time for our CI jobs, and reduces the costs. [These costs ended up being considerable](/company/team/structure/working-groups/gitlab-com-cost/),\nand it was difficult to justify the expense with the small number of users choosing MySQL.\n\n## We couldn't take advantage of either backend\n\nBy providing support for both database backends (PostgreSQL and MySQL) we were unable to truly take advantage\nof either. Where we wanted to utilize specific performance and realiability capabilities unique to a backend,\nwe had to instead choose the lowest common denominator. As an example (there are [more](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/24987#note_186506464)), we wanted to use PostgreSQL's `LATERAL JOIN` for optimizing dashboards events, but [couldn't because it was not available in MySQL](https://gitlab.com/gitlab-org/gitlab-ce/issues/31806#note_32117488).\n\n## Most of our customers are on PostgreSQL\n\nUsing [Usage Ping](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#usage-ping) data we got a clear sense that the vast majority of our customers had already moved to PostgreSQL.\nWe've seen a steady migration to PostgreSQL and recently had less than 1200 GitLab instances reporting their usage of\nMySQL. At the time there were 110,000 instances using PostgreSQL. Of those still using MySQL the majority were using 11.0 or earlier.\n\nThis gave us a lot of confidence that GitLab users still on MySQL could migrate to the bundled PostgreSQL backend\nif they choose to upgrade to 12.1 and beyond, or remain on MySQL in older versions of GitLab.\n\nAs a side note – we don't use MySQL ourselves, and not doing so meant we weren't encountering issues BEFORE our users.\n\n## Need help migrating?\n\nIf you are one of those users, please check out our [migration docs](https://docs.gitlab.com/ee/update/index.html) for a guide on upgrading from MySQL to PostgreSQL.\n",[9],{"slug":1310,"featured":6,"template":699},"removing-mysql-support","content:en-us:blog:removing-mysql-support.yml","Removing Mysql Support","en-us/blog/removing-mysql-support.yml","en-us/blog/removing-mysql-support",{"_path":1316,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1317,"content":1323,"config":1328,"_id":1330,"_type":13,"title":1331,"_source":15,"_file":1332,"_stem":1333,"_extension":18},"/en-us/blog/safe-deploys",{"title":1318,"description":1319,"ogTitle":1318,"ogDescription":1319,"noIndex":6,"ogImage":1320,"ogUrl":1321,"ogSiteName":685,"ogType":686,"canonicalUrls":1321,"schema":1322},"GitLab's guide to safe deployment practices","It's important to safeguard your deployment process. Here's our best advice to protect your environments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678412/Blog/Hero%20Images/safe_deploy.jpg","https://about.gitlab.com/blog/safe-deploys","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's guide to safe deployment practices\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Orit Golowinski\"}],\n        \"datePublished\": \"2020-07-23\",\n      }",{"title":1318,"description":1319,"authors":1324,"heroImage":1320,"date":1325,"body":1326,"category":693,"tags":1327},[1027],"2020-07-23","\nHere at GitLab we understand the importance of safe deployment practices. \n\n[Progressive delivery](/direction/ops/#progressive-delivery) is continuous delivery with fine-grained control over who sees the change. This ensures that all code and configuration updates go through the [CI/CD stages](/topics/ci-cd/) to catch any regressions or bugs before they reach customers. If something does make it past those gates, progressive delivery makes sure any negative impact is as small as possible.\n\nWe have recently added several features that add safeguards to your deployment process, which we will review in this blog post.\n\n### Protected Environments\n\nIt is important that deploy jobs are restricted to only those who are authorized to deploy in that environment, and we call this restriction by roles \"protected\". While this feature has been around for a while, it is important to remember that this should be the first step to take when thinking about safe deployments. \n\nTake a deeper dive into [protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n### Sequential Deployment (or Safe Continuous Deployment)\n\nIf your project follows the Continuous Deployment practice that deploys the `master` branch to the production environment with GitLab CI/CD pipelines, you may encounter the following problems due to the asynchronous nature of pipeline jobs:\n\n- Multiple deployment jobs run concurrently, targeting the same environment. This can make the environment unstable because the deployment script could conflict and finish in an incomplete state.\n- An older deployment job could overwrite the latest deployment, resulting in an unintentional rollback. Some users could be exposed to old feature sets on the production website even though the pipeline shows that the latest deployment job successfully finished.\n- A pipeline might deploy to production at the worst time, such as on a holiday or over the weekend, when there is limited staff available to solve potential problems.\n\nTo address these problems, GitLab provides the following options:\n\n* [Limit job concurrency](https://docs.gitlab.com/ee/ci/yaml/#resource_group)\n* [Prevent deployment of old versions](https://docs.gitlab.com/ee/ci/pipelines/settings.html#skip-outdated-deployment-jobs)\n* [Deploy freeze](https://docs.gitlab.com/ee/user/project/releases/index.html#prevent-unintentional-releases-by-setting-a-deploy-freeze)\n\n## Limit job concurrency\n\nYou can limit deployment concurrency by adding a `resource_group` to any `.gitlab-ci.yml` jobs that should run one at a time. For example:\n\n* Pipeline-A starts running with SHA-A\n* Pipeline-B starts running with SHA-B (newer)\n* Pipeline-A starts a deployment\n* Pipeline-B waits for Pipeline-A's deployment to finish\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/m6eZb6U-M2A\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n### Prevent deployment of old versions\n\nThe execution order of pipeline jobs can vary from run to run, which could cause undesired behavior. For example, a deployment job in a newer pipeline could finish before a deployment job in an older pipeline. This creates a race condition where the older deployment finishes later, overwriting the \"newer\" deployment.\n\nYou can ensure that older deployment jobs are cancelled automatically when a newer deployment runs by enabling the [prevent deployment of old versions](https://docs.gitlab.com/ee/ci/pipelines/settings.html#skip-outdated-deployment-jobs) feature.\n\n* Pipeline-A starts running with SHA-A\n* Pipeline-B starts running with SHA-B (newer)\n* Pipeline-B finishes. Now SHA-B is on the production environment\n* Pipeline-A is canceled automatically because it was going to deploy SHA-A to production\n\n![Prevent deployment of old versions](https://about.gitlab.com/images/blogimages/older_job.png){: .shadow}\n\n## Deployment Freeze\n\nTo prevent deployments for a particular period, such as during a planned holiday when most employees are out, you can set up a deploy freeze. During a deploy freeze, no deployments can be executed. This is helpful to ensure that deployments do not happen unexpectedly.\n\nFind more detailed information about [deployment safety](https://docs.gitlab.com/ee/ci/environments/deployment_safety.html).\n\n**Read more about GitLab and safety:**\n\n* [Capitalize on GitLab security tools](https://docs.gitlab.com/ee/integration/jenkins.html)\n\n* How app sec engineers [can use GitLab to improve security](/blog/secure-stage-for-appsec/)\n\n* Wondering [how secure GitLab is?](/blog/soc2-compliance/)\n\nCover image by [Mathew Schwartz](https://unsplash.com/photos/qcpwU_oMyu8) on [Unsplash](https://unsplash.com)\n{: .note}\n",[108,9,782],{"slug":1329,"featured":6,"template":699},"safe-deploys","content:en-us:blog:safe-deploys.yml","Safe Deploys","en-us/blog/safe-deploys.yml","en-us/blog/safe-deploys",{"_path":1335,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1336,"content":1342,"config":1349,"_id":1351,"_type":13,"title":1352,"_source":15,"_file":1353,"_stem":1354,"_extension":18},"/en-us/blog/splitting-database-into-main-and-ci",{"title":1337,"description":1338,"ogTitle":1337,"ogDescription":1338,"noIndex":6,"ogImage":1339,"ogUrl":1340,"ogSiteName":685,"ogType":686,"canonicalUrls":1340,"schema":1341},"We are splitting our database into Main and CI","We are splitting our database into Main and CI to improve the scalability and reliability of GitLab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669673/Blog/Hero%20Images/engineering.png","https://about.gitlab.com/blog/splitting-database-into-main-and-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We are splitting our database into Main and CI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Douglas Alexandre\"}],\n        \"datePublished\": \"2022-06-02\",\n      }",{"title":1337,"description":1338,"authors":1343,"heroImage":1339,"date":1346,"body":1347,"category":300,"tags":1348},[1344,1345],"Fabian Zimmer","Douglas Alexandre","2022-06-02","\nImproving the performance and reliability of GitLab.com has always been a top priority for GitLab. While we continuously make iterative improvements to GitLab and our production architecture, we anticipate making a larger change to improve the scalability and reliability of GitLab.com: We are splitting our single PostgreSQL database into a `main` and a `ci` database.\n\nWe believe this process, also known as [functional decomposition](/company/team/structure/working-groups/database-scalability/#functional-decomposition-split), will increase GitLab's database capacity by roughly 2x and allows GitLab.com to continue to scale.\n\n## When will the split take place and what does this mean for users of GitLab.com?\n\nThis change is planned to take place between Saturday, 2022-07-02, 05:00am UTC and Saturday, 2022-07-02, 09:00am UTC. The implementation of this change is anticipated to include a **service downtime of up to 120 minutes** between Saturday, 2022-07-02, 06:00am to 08:00am UTC. During this time you will experience complete service disruption of GitLab.com.\n\nWe are taking downtime to ensure that the application works as expected following the split and to minimize the risk of any data integrity issues.\n\n## Background\n\nGitLab.com's [database architecture](/handbook/engineering/infrastructure/production/architecture/#database-architecture) uses a single PostgreSQL database cluster. This single cluster (let's call it `main`), consists of a single primary and multiple read-only replicas and stores the data generated by all GitLab features. Database reads can be scaled horizontally through read-only replicas, but writes cannot because PostgreSQL does not support active-active replication natively.\n\nA large portion of all writes are generated by features related to Continuous Integration (CI). So, to scale GitLab.com's database capacity, we are splitting the single PostgreSQL main cluster into two clusters:\n\n1. A Continuous Integration database cluster for all CI-related features (`ci`).\n1. A database cluster for all other features (`main`).\n\nAt a high level, GitLab.com's database architecture is changing like this:\n\n![Illustration of splitting into Main and CI](https://about.gitlab.com/images/blogimages/decomposition-illustration-blog.png){: .center}\n\nYou can learn more by visiting our public epic: [Decompose GitLab.com's database to improve scalability](https://gitlab.com/groups/gitlab-org/-/epics/6168).\n\n## Impact\n\nSplitting our database into `main` and `ci` initially will only impact GitLab.com. To ensure consistency, we plan to enable [decomposition for self-managed GitLab instances](https://gitlab.com/groups/gitlab-org/-/epics/7509) later. While this split is a significant architectural change that we believe will increase GitLab's database capacity by roughly 2x, there are other benefits as well.  \n\n### Increased performance\n\nBy running two separate database clusters, we believe we will increase the overall count of available database connections. This means we can serve more traffic. It also means that during peak hours there is more buffer, which reduces the likelihood of congestion that may cause performance and UX degradations.\n\nAnother significant advantage is that we anticipate we will be able to tune the `main` and `ci` databases independently, allowing us to optimize these different workloads.\n\n### Increased stability\n\nSplitting the database cluster into `main` and `ci` means that `ci` writes are shifting to the `ci` database cluster. We anticipate this will lead to reduced database saturation, which is a major cause of incidents. Consequently, we believe that the overall stability of GitLab.com may increase following the split.\n\nWe believe increased stability means that development teams can spend more time working on generating value through new features and other improvements and less time guarding against potential issues.\n\n### Shipping as fast as ever\n\nA primary objective of this project was to provide tooling to our development teams so that they can continue to develop features that use multiple databases. All of these tools, for example [loose foreign keys](https://docs.gitlab.com/ee/development/database/loose_foreign_keys.html) or new [data migrations for multiple databases](https://docs.gitlab.com/ee/development/database/migrations_for_multiple_databases.html), are available already and used in production.\n\nWith these tools in place, we expect that teams will be able to ship features as fast as before.\n\n### Tools and dashboards re-use\n\nThis change does introduce additional complexity. After all, we will run another database cluster. Given that the `ci` cluster is almost identical to the existing `main` cluster, our DBREs and SREs are able to re-use almost all tools (for example for backups) and dashboards. This reduces the overall risk introduced by this change.\n\n## How we are preparing for the split\n\nOver the last year, many teams at GitLab have worked to support running GitLab using multiple databases. In total, more than 600 merge requests made it into the product. Because we chose a [phased rollout approach](https://gitlab.com/groups/gitlab-org/-/epics/6160#roll-out-plan), almost all developed capabilities are already running on our production systems.\n\n- We've already provisioned a standby-cluster that [serves CI read-only data](https://gitlab.com/groups/gitlab-org/-/epics/6160#phase-3-serve-ci-reads-from-ci-standby-cluster) but, crucially, **not** writes on GitLab.com. This increases our confidence that this cluster is correctly provisioned and fully functional.\n- We've also split out all [CI write traffic into a separate connection](https://gitlab.com/groups/gitlab-org/-/epics/6160#phase-3-serve-ci-reads-from-ci-standby-cluster). From an application standpoint, it appears as if we are already using a `ci` and a `main` database. This gives us confidence that the application changes are working correctly.\n- Our CI pipelines also fully support running against multiple databases and all tests are passing.\n\nWhat is left is promoting the `ci` standby cluster so that all CI **reads and writes** are accepted on that cluster.\n\n## How we're working to ensure a smooth split\n\nThe [Pods group](/handbook/engineering/development/enablement/data_stores/pods/) is working closely with our SREs, DBREs and Quality to rehearse for the production change. These rehearsals include dry runs, executing the promotion of the `ci` database cluster, and testing our rollback strategies. All of these steps are tracked as part of a CI decomposition change template. This template is continuously improved to ensure that we capture all learnings from the rehearsals. The template is mirrored onto our Ops GitLab instance, which will remain available during the downtime window and forms the basis for executing the change.\n\nThe general process of the split can be described as follows:\n\n1. Running health checks\n1. Stopping all incoming traffic\n1. Promoting the CI database cluster to take reads and writes\n1. Running QA\n1. Allowing incoming traffic\n\nWe have developed and are extensively testing rollback plans.\n\nA [detailed timeline](https://gitlab.com/groups/gitlab-org/-/epics/7791#proposed-timeline) is available and we publish [daily asynchronous technical updates](https://gitlab.com/groups/gitlab-org/-/epics/7791#last-async-update) of our progress.\n",[695,695,9,268],{"slug":1350,"featured":6,"template":699},"splitting-database-into-main-and-ci","content:en-us:blog:splitting-database-into-main-and-ci.yml","Splitting Database Into Main And Ci","en-us/blog/splitting-database-into-main-and-ci.yml","en-us/blog/splitting-database-into-main-and-ci",{"_path":1356,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1357,"content":1363,"config":1369,"_id":1371,"_type":13,"title":1372,"_source":15,"_file":1373,"_stem":1374,"_extension":18},"/en-us/blog/take-advantage-of-git-rebase",{"title":1358,"description":1359,"ogTitle":1358,"ogDescription":1359,"noIndex":6,"ogImage":1360,"ogUrl":1361,"ogSiteName":685,"ogType":686,"canonicalUrls":1361,"schema":1362},"Take advantage of Git rebase","Tap into the Git rebase features to improve your workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665560/Blog/Hero%20Images/speedmonorepo.jpg","https://about.gitlab.com/blog/take-advantage-of-git-rebase","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Take advantage of Git rebase\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2022-10-06\",\n      }",{"title":1358,"description":1359,"authors":1364,"heroImage":1360,"date":1366,"body":1367,"category":693,"tags":1368},[1365],"Christian Couder","2022-10-06","These days, developers spend a lot of time reviewing merge requests\n\nand taking these reviews into account to improve the code. We'll discuss how\n\n[Git rebase](https://git-scm.com/docs/git-rebase) can help in\n\nspeeding up these review cycles. But first, let's take a look at some\n\nworkflow considerations.\n\n\n## Different ways to rework a merge request\n\n\nA developer who worked on some code changes and created a merge\n\nrequest with these changes will often have to rework them. Why does\n\nthis happen? Tests can fail, bugs are found, or reviewers suggest\n\nimprovements and find shortcomings.\n\n\n### Simple but messy method: add more commits\n\n\nOne way to rework the code changes is to make more changes in some new\n\ncommits on top of the branch that was used to create the merge\n\nrequest, and then push the branch again to update the merge\n\nrequest.\n\n\nWhen a number of commits have been added in this way, the merge\n\nrequest becomes problematic:\n\n\n- It's difficult to review by looking at all the changes together.\n\n- It's difficult to review the commits separately as they may contain\ndifferent unrelated changes, or even multiple reworks of the same code.\n\n\nReviewers find it easier to review changes split into a number of small,\n\nself-contained commits that can be reviewed individually.\n\n\n### Pro method: rebase!\n\n\nA better method to prepare or rework a merge request is to always\n\nensure that each commit contains small, self-contained, easy-to-review\n\nchanges.\n\n\nThis means that all the commits in the branch may need reworking\n\ninstead of stacking on yet more commits. This approach might seem much\n\nmore complex and tedious, but `git rebase` comes to the rescue!\n\n\n## Rework your commits with `git rebase`\n\n\nIf your goal is to build a merge request from a series of small,\n\nself-contained commits, your branch may need significant rework before its\n\ncommits are good enough. When the commits are ready, you can push the branch\n\nand update or create a merge request with this branch.\n\n\n### Start an interactive rebase\n\n\nIf your branch is based on `main`, the command to rework your branch\n\nis:\n\n\n```plaintext\n\ngit rebase -i main\n\n```\n\n\nI encourage you to create [a Git\nalias](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases),\n\nor a shell alias or function for this command right away, as you will\n\nuse it very often.\n\n\nThe `-i` option passed to `git rebase` is an alias for\n\n`--interactive`. It starts\n\n[an 'interactive'\nrebase](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---interactive)\n\nwhich will open your editor. In it, you will find a list of the\n\ncommits in your branch followed by commented-out lines beginning with\n\n`#`. The list of commits looks like this:\n\n\n```plaintext\n\npick 1aac632db2 first commit subject\n\npick a385014ad4 second commit subject\n\npick 6af12a88cf other commit subject\n\npick 5cd121e2a1 last commit subject\n\n```\n\n\nThese lines are instructions for how `git rebase` should handle these\n\ncommits. The commits are listed in chronological order, with the\n\noldest commit at the top. (This order is the opposite of the default\n\n`git log` order.) What do these lines contain?\n\n\n- An instruction (here, `pick`) that tells Git what action to take\n\n- An abbreviated commit ID\n\n- A commit subject to help you identify the commit contents\n\n\n### Edit the instruction list\n\n\nYou can edit these instructions! When you quit your text editor, `git\nrebase`\n\nreads the instructions you've just edited, and performs them\n\nin sequence to recreate your branch the way you want.\n\n\nAfter the instructions for all commits, a set of commented-out lines\n\nexplain how to edit the instruction lines, and how each instruction\n\nwill change your branch:\n\n\n- If you **delete a commit's entire instruction line** from the list,\n  that commit won't be recreated.\n- If you **reorder the instruction lines**, the commits will be\n  recreated in the order you specify.\n- If you **change the action** from `pick` to something else, such as\n  `squash` or `reword`, Git performs the action you specify on that\n  commit.\n- You can even **add new instruction lines** before, after, or between\n  existing lines.\n\nIf the comment lines aren't enough, more information about what you\n\ncan do and how it works is available in:\n\n\n- The [Git Tools - Rewriting\nHistory](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)\n  section of the \"Pro Git\" book\n- The [Interactive\nmode](https://git-scm.com/docs/git-rebase#_interactive_mode)\n  section of the `git rebase` documentation\n\n### Continue or abort the rebase\n\n\nAn interactive rebase can stop if there is a conflict (as a regular\n\nrebase would) or if you used an instruction like `edit` in the\n\ninstruction line. This allows you to make some changes, like splitting\n\nthe current commit into two commits, or fixing the rebase conflict if\n\nthere is one. You can then either:\n\n\n- Continue the interactive rebase with `git rebase --continue`.\n\n- Abort the rebase altogether with `git rebase --abort`.\n\n\n(These `git rebase` options also work when a regular, non-interactive\n\nrebase stops.)\n\n\n## Further tips and benefits\n\n\n### Try different instructions\n\n\nI recommend you try out the different instructions you can use in\n\neach instruction line, especially `reword`, `edit`, `squash`, and `fixup`.\nYou'll\n\nsoon want to use the abbreviated versions of these instructions: `r`,\n\n`e`, `s`, and `f`.\n\n\n### Run shell commands in your rebase\n\n\nYou might also have noticed an `exec \u003Ccommand>` instruction that\n\nallows you to run any shell command at any point in the interactive rebase.\n\nI've found it more useful for non-interactive rebases, such as:\n\n\n```plaintext\n\ngit rebase --exec 'make test' main\n\n```\n\n\n(It's not an interactive rebase because it doesn't contain the `-i` flag.)\n\n\nThe `--exec \u003Ccommand>` flag allows you to run any shell command after\n\neach rebased commit, stopping if the shell command fails (which is\n\nsignaled by a non zero exit code).\n\n\n### Test all your commits\n\n\nPassing a command to build your software and run its tests, like\n\n`make test`, to `--exec` will check that each commit in your branch\n\nbuilds correctly and passes your tests.\n\n\nIf `make test` fails, the rebase stops. You can then fix the current\n\ncommit right away, and continue the rebase to test the next\n\ncommits.\n\n\nChecking each commit builds cleanly and passes all the tests ensures\n\nyour code base is always in a good state. It's especially useful if\n\nyou want to take advantage of\n\n[Git bisect](https://git-scm.com/docs/git-bisect) when you encounter\n\nregressions.\n\n\n## Conclusion\n\n\nIn Git, a rebase is a very versatile and useful tool to rework\n\ncommits. Use it to achieve a workflow with high-quality changes\n\nproposed in high-quality commits and merge requests. It makes your\n\ndevelopers and reviewers more efficient. Code reviews and debugging also\nbecome easier and more effective.\n\n\n**EDIT:** Check out our [follow-up post on how you can apply this is real\nlife](/blog/rebase-in-real-life/).\n",[948,696,9,721],{"slug":1370,"featured":6,"template":699},"take-advantage-of-git-rebase","content:en-us:blog:take-advantage-of-git-rebase.yml","Take Advantage Of Git Rebase","en-us/blog/take-advantage-of-git-rebase.yml","en-us/blog/take-advantage-of-git-rebase",{"_path":1376,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1377,"content":1383,"config":1390,"_id":1392,"_type":13,"title":1393,"_source":15,"_file":1394,"_stem":1395,"_extension":18},"/en-us/blog/top-reasons-for-software-release-delays",{"title":1378,"description":1379,"ogTitle":1378,"ogDescription":1379,"noIndex":6,"ogImage":1380,"ogUrl":1381,"ogSiteName":685,"ogType":686,"canonicalUrls":1381,"schema":1382},"Top reasons for software release delays","In our 2022 Global DevSecOps survey, DevOps pros shared their frustrations with software releases, including security's shift left and complicated code reviews.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664070/Blog/Hero%20Images/cloudwatch-gitlab-incident-management-bg.jpg","https://about.gitlab.com/blog/top-reasons-for-software-release-delays","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top reasons for software release delays\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-08-30\",\n      }",{"title":1378,"description":1379,"authors":1384,"heroImage":1380,"date":1385,"body":1386,"category":1387,"tags":1388},[800],"2022-08-30","\n_What’s the most likely reason for a software release delay?_\n\nFrom 2019 through 2021, respondents to our Global DevSecOps Surveys _always_ blamed software testing. This year, however, was dramatically different.\n\nMore than 5,000 DevOps practitioners took our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/), and, for the first time, they offered five equally valid reasons why releases might be tardy: code development, code review, security analysis, test data management, and, of course, testing.\n\nProcesses and priorities are clearly changing in DevOps teams today, and they’re affecting release delays. Here’s how to understand the forces at work.\n\n> Join us at [GitLab Commit 2022](/events/commit/) and connect with the ideas, technologies, and people that are driving DevOps and digital transformation.\n\n## Code development and code review\n\nOver the past three years, code development and code review were the second- and third-ranked culprits for release delays. That’s to be expected: No one ever said code development was easy and code reviews have always been problematic.\n\nDevelopers report [a myriad of challenges with code review](/blog/the-code-review-struggle-is-real-heres-what-you-need-to-know/): It’s too labor intensive, no one is available to do it, and the culture often doesn’t support the process. But in this year’s survey, 76% of developers said they find code reviews “very” or “somewhat” valuable, and a majority said code review was one of the key steps in DevOps they wish they could do more of. All told, 27% of developers review code weekly while another 21% review it daily or with every commit.\n\nClearly, code review is important but [it takes work](/blog/tips-for-better-code-review/) to make them happen more efficiently. One up-and-coming solution that could help make code reviews easier is artificial intelligence. Our survey found 31% of DevOps teams use AI for code review today, more than double the percentage in 2021. GitLab is also excited about the possibilities found in AI’s close cousin machine learning – we’re using it to [improve the code review process](/blog/the-road-to-smarter-code-reviewer-recommendations/).\n\n## Keeping software secure\n\nCreating safe code requires security testing and the frustration around this step is both real and longstanding. Security has nearly always [been seen as a “blocker”](/blog/developer-security-divide/) when it comes to software development in general and software releases in particular. In our 2022 survey, though, priorities have changed. Security is now the top area DevOps teams plan to invest in this year, and a majority of developers report that the most difficult part of their job is keeping software secure. Here’s just a sample of what developers had to say about the challenges of their roles today:\n\n_We are trying to keep up with the latest tools and security for optimal performance and privacy._\n\n_We are trying to build applications that are secure and stable._\n\n_It is challenging to keep it secure and keep it updated._\n\n_Cyber security attacks are the biggest challenge facing us today._\n\n_Data security, data security, I repeat, data security._\n\nThe focus on security isn’t just talk, either. More than 50% of DevOps teams are running SAST, DAST, and container scans, all dramatic increases from 2021. But at the same time, this is the fourth year security pros have continued to blame developers for finding too few bugs too late in the process. Security is a developer performance metric for many teams, but sec team members say it is still very hard to get devs to actually fix bugs, a trend we’ve seen reflected over and over.\n\nIn other words, it’s complicated enough to make the potential of delays unsurprising.\n\n## Managing the test data\n\nToo much test data is one of those good and bad problems to have: 47% of DevOps teams we surveyed report full test automation, nearly double the percentage from last year, and more security scans are being run too. More than half of survey takers (53%) are testing their code as it’s being written, up 21% from last year.\n\nAll those tests result in a data management problem most teams aren’t actually set up to handle. Here’s one example: Less than one-third of teams are able to put DAST and SAST results into a developer’s workflow/IDE and those percentages remain stubbornly low year after year.\n\nTesting momentum and automation are growing by leaps and bounds, but teams now need better ways to evaluate, communicate, and act on the data.\n\n## The tricky nature of software testing\n\nSoftware testing has often worn the “DevOps scapegoat” mantle, and perhaps for good reason. Getting testing just right is critical, but it’s also elusive. There are so many kinds of tests teams can run, test automation requires a big process and culture investment, and test results are often seen as “flaky,” “noisy,” and “late” by busy developers not enthused about context switching or inaccurate results.\n\nBut there are a couple of promising signs: As we saw in 2021, developer respondents told us again this year that testing is high on their list of tasks they would like to do more of. And artificial intelligence is also making inroads: About 37% of teams are using AI/ML to test their code (a 23-point jump from 2021) and 20% more are planning to add it to their DevOps practice this year.\n\nWant to understand more about software release delays and DevOps best practices? Read our [2022 Global DevSecOps Survey](/developer-survey/).\n","devsecops",[1389,1152,9,1091],"developer survey",{"slug":1391,"featured":6,"template":699},"top-reasons-for-software-release-delays","content:en-us:blog:top-reasons-for-software-release-delays.yml","Top Reasons For Software Release Delays","en-us/blog/top-reasons-for-software-release-delays.yml","en-us/blog/top-reasons-for-software-release-delays",{"_path":1397,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1398,"content":1403,"config":1411,"_id":1413,"_type":13,"title":1414,"_source":15,"_file":1415,"_stem":1416,"_extension":18},"/en-us/blog/upgrade-runners-for-mr-pipelines",{"title":1399,"description":1400,"ogTitle":1399,"ogDescription":1400,"noIndex":6,"ogImage":734,"ogUrl":1401,"ogSiteName":685,"ogType":686,"canonicalUrls":1401,"schema":1402},"Private Runner upgrade required for GitLab 11.10 MR pipelines","All users of Merge Request Pipelines must ensure they are using GitLab Runners > version 11.8.","https://about.gitlab.com/blog/upgrade-runners-for-mr-pipelines","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Private Runner upgrade required for users of Merge Request Pipelines in GitLab 11.10\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-04-16\",\n      }",{"title":1404,"description":1400,"authors":1405,"heroImage":734,"date":1407,"body":1408,"category":717,"tags":1409},"Private Runner upgrade required for users of Merge Request Pipelines in GitLab 11.10",[1406],"Jason Yavorska","2019-04-16","\nThe 11.10 release, shipping April 22, introduces a [Premium tier](/pricing/premium/) improvement\nfor [MR Pipelines](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html) where we now\nbuild the [combined ref (source + target branch)](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html)\nas part of the merge request pipeline.\n\nUsers of MR Pipelines with private GitLab Runners of version 11.8 or older\nmust upgrade to 11.9 or newer, or you will run into the issue described in [gitlab-ee#11122](https://gitlab.com/gitlab-org/gitlab-ee/issues/11122),\nwhere you receive the error message `Your runner is outdated, please upgrade your runner`. You can upgrade by\nfollowing the instructions on the [Runner installation guide](https://docs.gitlab.com/runner/#install-gitlab-runner).\nUsers of GitLab's shared Runner fleet are not impacted by this issue.\n\nPlease let us know in the comments if you run into any issues.\n",[1410,9],"patch releases",{"slug":1412,"featured":6,"template":699},"upgrade-runners-for-mr-pipelines","content:en-us:blog:upgrade-runners-for-mr-pipelines.yml","Upgrade Runners For Mr Pipelines","en-us/blog/upgrade-runners-for-mr-pipelines.yml","en-us/blog/upgrade-runners-for-mr-pipelines",{"_path":1418,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1420,"config":1426,"_id":1428,"_type":13,"title":1429,"_source":15,"_file":1430,"_stem":1431,"_extension":18},"/en-us/blog/external-url/gitlab-16-10-release","external-url",{"title":1421,"description":1422,"heroImage":1423,"date":1424,"category":1387,"tags":1425},"GitLab 16.10 Release","GitLab 16.10 released with semantic versioning in the CI/CD catalog","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668956/Blog/Hero%20Images/16.10_cover_image_-_Blog-1800x800.png","2024-03-21",[9],{"featured":6,"externalUrl":1427},"https://about.gitlab.com/releases/2024/03/21/gitlab-16-10-released/","content:en-us:blog:external-url:gitlab-16-10-release.yml","Gitlab 16 10 Release","en-us/blog/external-url/gitlab-16-10-release.yml","en-us/blog/external-url/gitlab-16-10-release",{"_path":1433,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1434,"config":1440,"_id":1442,"_type":13,"title":1443,"_source":15,"_file":1444,"_stem":1445,"_extension":18},"/en-us/blog/external-url/gitlab-16-11-release",{"title":1435,"description":1436,"heroImage":1437,"date":1438,"category":1387,"tags":1439},"GitLab 16.11 Release","GitLab 16.11 released with GitLab Duo Chat general availability","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099004/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_1od9f5DGEA0ntKLVnJbA2p_1750099004258.png","2024-04-18",[9,495],{"featured":6,"externalUrl":1441},"https://about.gitlab.com/releases/2024/04/18/gitlab-16-11-released/","content:en-us:blog:external-url:gitlab-16-11-release.yml","Gitlab 16 11 Release","en-us/blog/external-url/gitlab-16-11-release.yml","en-us/blog/external-url/gitlab-16-11-release",{"_path":1447,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1448,"config":1454,"_id":1456,"_type":13,"title":1457,"_source":15,"_file":1458,"_stem":1459,"_extension":18},"/en-us/blog/external-url/gitlab-16-8-release",{"title":1449,"description":1450,"heroImage":1451,"date":1452,"category":1051,"tags":1453},"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","2024-01-18",[9],{"featured":6,"externalUrl":1455},"https://about.gitlab.com/releases/2024/01/18/gitlab-16-8-released/","content:en-us:blog:external-url:gitlab-16-8-release.yml","Gitlab 16 8 Release","en-us/blog/external-url/gitlab-16-8-release.yml","en-us/blog/external-url/gitlab-16-8-release",{"_path":1461,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1462,"config":1468,"_id":1470,"_type":13,"title":1471,"_source":15,"_file":1472,"_stem":1473,"_extension":18},"/en-us/blog/external-url/gitlab-16-9-release",{"title":1463,"description":1464,"heroImage":1465,"date":1466,"category":1387,"tags":1467},"GitLab 16.9 Release","16.9 features GitLab Duo Chat with wider Beta access, usability improvements to the CI/CD variables page, more options for auto-canceling pipelines, and more!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668947/Blog/Hero%20Images/16.9_cover_image_-_Blog-1800x800.png","2024-02-15",[9,495],{"featured":90,"externalUrl":1469},"https://about.gitlab.com/releases/2024/02/15/gitlab-16-9-released/","content:en-us:blog:external-url:gitlab-16-9-release.yml","Gitlab 16 9 Release","en-us/blog/external-url/gitlab-16-9-release.yml","en-us/blog/external-url/gitlab-16-9-release",{"_path":1475,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1476,"config":1482,"_id":1484,"_type":13,"title":1485,"_source":15,"_file":1486,"_stem":1487,"_extension":18},"/en-us/blog/external-url/gitlab-17-0-release",{"title":1477,"description":1478,"heroImage":1479,"date":1480,"category":1387,"tags":1481},"GitLab 17.0 Release","GitLab 17.0 released with generally available CI/CD Catalog and AI Impact analytics dashboard.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665762/Blog/Hero%20Images/blog-gl17-release-hero-17-0-93-1800x945-fy25__1_.png","2024-05-16",[9],{"featured":90,"externalUrl":1483},"https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/","content:en-us:blog:external-url:gitlab-17-0-release.yml","Gitlab 17 0 Release","en-us/blog/external-url/gitlab-17-0-release.yml","en-us/blog/external-url/gitlab-17-0-release",{"_path":1489,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1490,"config":1496,"_id":1498,"_type":13,"title":1499,"_source":15,"_file":1500,"_stem":1501,"_extension":18},"/en-us/blog/external-url/gitlab-17-1-release",{"title":1491,"description":1492,"heroImage":1493,"date":1494,"category":1387,"tags":1495},"GitLab 17.1 Release","GitLab 17.1 released with Model registry available in beta and multiple GitLab Duo Code Suggestions in VS Code.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669047/Blog/Hero%20Images/product-gl17-blog-release-cover-17-1-0093-1800x945-fy25.png","2024-06-20",[9,1051,495],{"featured":90,"externalUrl":1497},"https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/","content:en-us:blog:external-url:gitlab-17-1-release.yml","Gitlab 17 1 Release","en-us/blog/external-url/gitlab-17-1-release.yml","en-us/blog/external-url/gitlab-17-1-release",{"_path":1503,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1504,"config":1510,"_id":1512,"_type":13,"title":1513,"_source":15,"_file":1514,"_stem":1515,"_extension":18},"/en-us/blog/external-url/gitlab-17-10-released",{"title":1505,"description":1506,"heroImage":1507,"date":1508,"category":1051,"tags":1509},"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","2025-03-20",[9],{"featured":90,"externalUrl":1511},"https://about.gitlab.com/releases/2025/03/20/gitlab-17-10-released/","content:en-us:blog:external-url:gitlab-17-10-released.yml","Gitlab 17 10 Released","en-us/blog/external-url/gitlab-17-10-released.yml","en-us/blog/external-url/gitlab-17-10-released",{"_path":1517,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1518,"config":1524,"_id":1526,"_type":13,"title":1527,"_source":15,"_file":1528,"_stem":1529,"_extension":18},"/en-us/blog/external-url/gitlab-17-11-released",{"title":1519,"description":1520,"heroImage":1521,"date":1522,"category":1051,"tags":1523},"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","2025-04-17",[9],{"featured":6,"externalUrl":1525},"https://about.gitlab.com/releases/2025/04/17/gitlab-17-11-released/","content:en-us:blog:external-url:gitlab-17-11-released.yml","Gitlab 17 11 Released","en-us/blog/external-url/gitlab-17-11-released.yml","en-us/blog/external-url/gitlab-17-11-released",{"_path":1531,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1532,"config":1538,"_id":1540,"_type":13,"title":1541,"_source":15,"_file":1542,"_stem":1543,"_extension":18},"/en-us/blog/external-url/gitlab-17-2-release",{"title":1533,"description":1534,"heroImage":1535,"date":1536,"category":1051,"tags":1537},"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","2024-07-18",[9,1051,495],{"featured":90,"externalUrl":1539},"https://about.gitlab.com/releases/2024/07/18/gitlab-17-2-released/","content:en-us:blog:external-url:gitlab-17-2-release.yml","Gitlab 17 2 Release","en-us/blog/external-url/gitlab-17-2-release.yml","en-us/blog/external-url/gitlab-17-2-release",{"_path":1545,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1546,"config":1552,"_id":1554,"_type":13,"title":1555,"_source":15,"_file":1556,"_stem":1557,"_extension":18},"/en-us/blog/external-url/gitlab-17-3-release",{"title":1547,"description":1548,"heroImage":1549,"date":1550,"category":1051,"tags":1551},"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","2024-08-15",[9,1051],{"featured":6,"externalUrl":1553},"https://about.gitlab.com/releases/2024/08/15/gitlab-17-3-released/","content:en-us:blog:external-url:gitlab-17-3-release.yml","Gitlab 17 3 Release","en-us/blog/external-url/gitlab-17-3-release.yml","en-us/blog/external-url/gitlab-17-3-release",{"_path":1559,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1560,"config":1566,"_id":1568,"_type":13,"title":1569,"_source":15,"_file":1570,"_stem":1571,"_extension":18},"/en-us/blog/external-url/gitlab-17-4-release",{"title":1561,"description":1562,"heroImage":1563,"date":1564,"category":1051,"tags":1565},"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","2024-09-19",[9,1051,495,717],{"featured":6,"externalUrl":1567},"https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/","content:en-us:blog:external-url:gitlab-17-4-release.yml","Gitlab 17 4 Release","en-us/blog/external-url/gitlab-17-4-release.yml","en-us/blog/external-url/gitlab-17-4-release",{"_path":1573,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1574,"config":1580,"_id":1582,"_type":13,"title":1583,"_source":15,"_file":1584,"_stem":1585,"_extension":18},"/en-us/blog/external-url/gitlab-17-5-release",{"title":1575,"description":1576,"heroImage":1577,"date":1578,"category":1051,"tags":1579},"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","2024-10-17",[9],{"featured":6,"externalUrl":1581},"https://about.gitlab.com/releases/2024/10/17/gitlab-17-5-released/","content:en-us:blog:external-url:gitlab-17-5-release.yml","Gitlab 17 5 Release","en-us/blog/external-url/gitlab-17-5-release.yml","en-us/blog/external-url/gitlab-17-5-release",{"_path":1587,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1588,"config":1594,"_id":1596,"_type":13,"title":1597,"_source":15,"_file":1598,"_stem":1599,"_extension":18},"/en-us/blog/external-url/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta",{"title":1589,"description":1590,"heroImage":1591,"date":1592,"category":1051,"tags":1593},"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","2024-11-21",[1051,495,9],{"featured":90,"externalUrl":1595},"https://about.gitlab.com/releases/2024/11/21/gitlab-17-6-released/","content:en-us:blog:external-url: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/external-url/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta.yml","en-us/blog/external-url/gitlab-17-6-released-with-self-hosted-duo-chat-in-beta",{"_path":1601,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1602,"config":1608,"_id":1610,"_type":13,"title":1611,"_source":15,"_file":1612,"_stem":1613,"_extension":18},"/en-us/blog/external-url/gitlab-17-7-released",{"title":1603,"description":1604,"heroImage":1605,"date":1606,"category":1051,"tags":1607},"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","2024-12-19",[9,1051,495],{"featured":90,"externalUrl":1609},"https://about.gitlab.com/releases/2024/12/19/gitlab-17-7-released/","content:en-us:blog:external-url:gitlab-17-7-released.yml","Gitlab 17 7 Released","en-us/blog/external-url/gitlab-17-7-released.yml","en-us/blog/external-url/gitlab-17-7-released",{"_path":1615,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1616,"config":1622,"_id":1624,"_type":13,"title":1625,"_source":15,"_file":1626,"_stem":1627,"_extension":18},"/en-us/blog/external-url/gitlab-17-8-released",{"title":1617,"description":1618,"heroImage":1619,"date":1620,"category":1051,"tags":1621},"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","2025-01-16",[9,1051],{"featured":90,"externalUrl":1623},"https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/","content:en-us:blog:external-url:gitlab-17-8-released.yml","Gitlab 17 8 Released","en-us/blog/external-url/gitlab-17-8-released.yml","en-us/blog/external-url/gitlab-17-8-released",{"_path":1629,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1630,"config":1636,"_id":1638,"_type":13,"title":1639,"_source":15,"_file":1640,"_stem":1641,"_extension":18},"/en-us/blog/external-url/gitlab-17-9-released",{"title":1631,"description":1632,"heroImage":1633,"date":1634,"category":1051,"tags":1635},"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","2025-02-20",[9],{"featured":90,"externalUrl":1637},"https://about.gitlab.com/releases/2025/02/20/gitlab-17-9-released/","content:en-us:blog:external-url:gitlab-17-9-released.yml","Gitlab 17 9 Released","en-us/blog/external-url/gitlab-17-9-released.yml","en-us/blog/external-url/gitlab-17-9-released",{"_path":1643,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1644,"config":1650,"_id":1652,"_type":13,"title":1653,"_source":15,"_file":1654,"_stem":1655,"_extension":18},"/en-us/blog/external-url/gitlab-18-1-released",{"title":1645,"description":1646,"heroImage":1647,"date":1648,"category":1051,"tags":1649},"GitLab 18.1 released","This release includes Maven virtual registry (beta), Duo Code Review, compromised password detection, and SLSA Level 1 with components.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750333905/erq4ak30f6zxjjcsmt4y.png","2025-06-19",[9,1051],{"featured":90,"externalUrl":1651},"https://about.gitlab.com/releases/2025/06/19/gitlab-18-1-released/","content:en-us:blog:external-url:gitlab-18-1-released.yml","Gitlab 18 1 Released","en-us/blog/external-url/gitlab-18-1-released.yml","en-us/blog/external-url/gitlab-18-1-released",{"_path":1657,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1658,"config":1664,"_id":1666,"_type":13,"title":1667,"_source":15,"_file":1668,"_stem":1669,"_extension":18},"/en-us/blog/external-url/gitlab-18-2-released",{"title":1659,"description":1660,"heroImage":1661,"date":1662,"category":1051,"tags":1663},"GitLab 18.2 released","Newest release features Duo Agent Platform in the IDE (beta) and Custom workflow statuses for issues and tasks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752756250/ndfasndpqclcourduxxa.png","2025-07-17",[9],{"featured":6,"externalUrl":1665},"https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/","content:en-us:blog:external-url:gitlab-18-2-released.yml","Gitlab 18 2 Released","en-us/blog/external-url/gitlab-18-2-released.yml","en-us/blog/external-url/gitlab-18-2-released",{"_path":1671,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1672,"config":1678,"_id":1680,"_type":13,"title":1681,"_source":15,"_file":1682,"_stem":1683,"_extension":18},"/en-us/blog/external-url/gitlab-18-3-released",{"title":1673,"description":1674,"heroImage":1675,"date":1676,"category":1051,"tags":1677},"GitLab 18.3 released","Latest version of GitLab includes Duo Agent Platform in Visual Studio (Beta) and embedded views.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1755782394/swplm3yztdrbrlyztaro.png","2025-08-21",[9],{"featured":6,"externalUrl":1679},"https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/","content:en-us:blog:external-url:gitlab-18-3-released.yml","Gitlab 18 3 Released","en-us/blog/external-url/gitlab-18-3-released.yml","en-us/blog/external-url/gitlab-18-3-released",{"_path":1685,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1686,"config":1692,"_id":1694,"_type":13,"title":1695,"_source":15,"_file":1696,"_stem":1697,"_extension":18},"/en-us/blog/external-url/gitlab-18-4-released",{"title":1687,"description":1688,"heroImage":1689,"date":1690,"category":1051,"tags":1691},"GitLab 18.4 released","Latest version of GitLab includes Duo Model Selection generally available, Knowledge Graph, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758202527/zbdm4mehauv3poqetyhk.png","2025-09-18",[1051,9],{"featured":90,"template":699,"externalUrl":1693},"https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/","content:en-us:blog:external-url:gitlab-18-4-released.yml","Gitlab 18 4 Released","en-us/blog/external-url/gitlab-18-4-released.yml","en-us/blog/external-url/gitlab-18-4-released",{"_path":1699,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1700,"config":1706,"_id":1708,"_type":13,"title":1709,"_source":15,"_file":1710,"_stem":1711,"_extension":18},"/en-us/blog/external-url/gitlab-18-released",{"title":1701,"description":1702,"heroImage":1703,"date":1704,"category":1051,"tags":1705},"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","2025-05-15",[9,1051],{"featured":6,"externalUrl":1707},"https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/","content:en-us:blog:external-url:gitlab-18-released.yml","Gitlab 18 Released","en-us/blog/external-url/gitlab-18-released.yml","en-us/blog/external-url/gitlab-18-released",{"_path":1713,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1714,"config":1720,"_id":1722,"_type":13,"title":1723,"_source":15,"_file":1724,"_stem":1725,"_extension":18},"/en-us/blog/external-url/gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9",{"title":1715,"description":1716,"heroImage":1717,"date":1718,"category":782,"tags":1719},"GitLab Critical Patch Release: 17.4.2, 17.3.5, 17.2.9","Learn more about this critical patch release.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","2024-10-09",[9,782],{"featured":6,"externalUrl":1721},"https://about.gitlab.com/releases/2024/10/09/patch-release-gitlab-17-4-2-released/","content:en-us:blog:external-url:gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9.yml","Gitlab Critical Patch Release 17 4 2 17 3 5 17 2 9","en-us/blog/external-url/gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9.yml","en-us/blog/external-url/gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9",{"_path":1727,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1728,"config":1734,"_id":1736,"_type":13,"title":1737,"_source":15,"_file":1738,"_stem":1739,"_extension":18},"/en-us/blog/external-url/gitlab-patch-release-16-11-1-16-10-4-16-9-6",{"title":1729,"description":1730,"heroImage":1717,"date":1731,"category":1387,"tags":1732},"GitLab Patch Release: 16.11.1, 16.10.4, 16.9.6","Learn more about GitLab Patch Release: 16.11.1, 16.10.4, 16.9.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).","2024-04-24",[1410,9,1733],"security releases",{"featured":6,"externalUrl":1735},"https://about.gitlab.com/releases/2024/04/24/patch-release-gitlab-16-11-1-released/","content:en-us:blog:external-url:gitlab-patch-release-16-11-1-16-10-4-16-9-6.yml","Gitlab Patch Release 16 11 1 16 10 4 16 9 6","en-us/blog/external-url/gitlab-patch-release-16-11-1-16-10-4-16-9-6.yml","en-us/blog/external-url/gitlab-patch-release-16-11-1-16-10-4-16-9-6",{"_path":1741,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1742,"config":1747,"_id":1749,"_type":13,"title":1750,"_source":15,"_file":1751,"_stem":1752,"_extension":18},"/en-us/blog/external-url/gitlab-patch-release-17-2-1-17-1-3-17-0-5",{"title":1743,"description":1744,"heroImage":1717,"date":1745,"category":1051,"tags":1746},"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).","2024-07-24",[9,1733],{"featured":6,"externalUrl":1748},"https://about.gitlab.com/releases/2024/07/24/patch-release-gitlab-17-2-1-released/","content:en-us:blog:external-url: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/external-url/gitlab-patch-release-17-2-1-17-1-3-17-0-5.yml","en-us/blog/external-url/gitlab-patch-release-17-2-1-17-1-3-17-0-5",{"_path":1754,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1755,"config":1761,"_id":1763,"_type":13,"title":1764,"_source":15,"_file":1765,"_stem":1766,"_extension":18},"/en-us/blog/external-url/gitlab-patch-release-17-8-2-17-7-4-17-6-5",{"title":1756,"description":1757,"heroImage":1758,"date":1759,"category":1051,"tags":1760},"GitLab Patch Release: 17.8.2, 17.7.4, 17.6.5","Learn more about this release for GitLab Community Edition (CE) and Enterprise Edition (EE).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2025-02-12",[9,1733],{"featured":6,"externalUrl":1762},"https://about.gitlab.com/releases/2025/02/12/patch-release-gitlab-17-8-2-released/","content:en-us:blog:external-url: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/external-url/gitlab-patch-release-17-8-2-17-7-4-17-6-5.yml","en-us/blog/external-url/gitlab-patch-release-17-8-2-17-7-4-17-6-5",{"_path":1768,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1769,"config":1774,"_id":1776,"_type":13,"title":1777,"_source":15,"_file":1778,"_stem":1779,"_extension":18},"/en-us/blog/external-url/gitlab-security-release-16-10-1-16-9-3-16-8-5",{"title":1770,"description":1771,"heroImage":1717,"date":1772,"category":782,"tags":1773},"GitLab Security Release: 16.10.1, 16.9.3, 16.8.5","Learn more about GitLab Security Release: 16.10.1, 16.9.3, 16.8.5 for GitLab Community Edition (CE) and Enterprise Edition (EE).","2024-03-27",[1733,782,9],{"featured":6,"externalUrl":1775},"https://about.gitlab.com/releases/2024/03/27/security-release-gitlab-16-10-1-released/","content:en-us:blog:external-url:gitlab-security-release-16-10-1-16-9-3-16-8-5.yml","Gitlab Security Release 16 10 1 16 9 3 16 8 5","en-us/blog/external-url/gitlab-security-release-16-10-1-16-9-3-16-8-5.yml","en-us/blog/external-url/gitlab-security-release-16-10-1-16-9-3-16-8-5",{"_path":1781,"_dir":1419,"_draft":6,"_partial":6,"_locale":7,"content":1782,"config":1787,"_id":1789,"_type":13,"title":1790,"_source":15,"_file":1791,"_stem":1792,"_extension":18},"/en-us/blog/external-url/gitlab-security-release-16-9-2-16-8-4-16-7-7",{"title":1783,"description":1784,"heroImage":1717,"date":1785,"category":782,"tags":1786},"GitLab Security Release: 16.9.2, 16.8.4, 16.7.7","Learn more about GitLab Security Release: 16.9.2, 16.8.4, 16.7.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).","2024-03-06",[1733,9],{"featured":6,"externalUrl":1788},"https://about.gitlab.com/releases/2024/03/06/security-release-gitlab-16-9-2-released/","content:en-us:blog:external-url:gitlab-security-release-16-9-2-16-8-4-16-7-7.yml","Gitlab Security Release 16 9 2 16 8 4 16 7 7","en-us/blog/external-url/gitlab-security-release-16-9-2-16-8-4-16-7-7.yml","en-us/blog/external-url/gitlab-security-release-16-9-2-16-8-4-16-7-7",{"_path":1794,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1795,"content":1800,"config":1808,"_id":1810,"_type":13,"title":1811,"_source":15,"_file":1812,"_stem":1813,"_extension":18},"/en-us/blog/a-guide-to-the-high-impact-breaking-changes-in-gitlab-17-0",{"title":1796,"description":1797,"ogTitle":1796,"ogDescription":1797,"noIndex":6,"ogImage":817,"ogUrl":1798,"ogSiteName":685,"ogType":686,"canonicalUrls":1798,"schema":1799},"A guide to the high-impact breaking changes in GitLab 17.0","Find, assess, and mitigate the impact of deprecations and breaking changes in this year’s major release.","https://about.gitlab.com/blog/a-guide-to-the-high-impact-breaking-changes-in-gitlab-17-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A guide to the high-impact breaking changes in GitLab 17.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Martin Brümmer\"},{\"@type\":\"Person\",\"name\":\"Sam Wiskow\"}],\n        \"datePublished\": \"2024-04-10\",\n      }",{"title":1796,"description":1797,"authors":1801,"heroImage":817,"date":1804,"body":1805,"category":1806,"tags":1807},[1802,1803],"Martin Brümmer","Sam Wiskow","2024-04-10","GitLab 17.0 is coming on May 16. This version, a major release, will include many exciting improvements to GitLab, but also removes some deprecated features. Visit the [Deprecations page](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=17.0) to see what is scheduled for removal in 17.0 and keep reading for an overview of the highest impact removals.\n\nAdditionally, this year we are introducing three windows during which we expect breaking changes to be enabled on GitLab.com:\n\n- 2024-04-22 09:00 UTC to 2024-04-24 22:00 UTC\n\n- 2024-04-29 09:00 UTC to 2024-05-01 22:00 UTC\n\n- 2024-05-06 09:00 UTC to 2024-05-08 22:00 UTC\n\n**Note:** Some breaking changes may fall slightly outside of these windows in exceptional circumstances.\n\n**Update:** We have created a [public issue](https://gitlab.com/gitlab-com/Product/-/issues/13310) with more details about which changes should land in which windows.\n\n## High-impact breaking changes in GitLab 17.0\n\nWe have identified the following high-impact removals in 17.0. We define “high impact” as potentially disrupting critical workflows, such as continuous integration (CI), continuous deployment (CD), compliance, or the availability of the instance. That’s why we suggest you should prioritize these breaking changes first when preparing for the major release. While you can find detailed information on each breaking change in the linked documentation, we’ve provided some notes about the affected features and potential impact in this overview.\n\n### Self-managed deployment\n- [Postgres 13 deprecated](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#postgresql-13-deprecated)\n    - Impacts all self-managed customers. Failing to upgrade to Postgres 14 will break the deployment.\n    - Postgres 14 is already supported starting from GitLab 16.2.0.\n- [omniauth-azure-oauth2 gem is deprecated](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#omniauth-azure-oauth2-gem-is-deprecated)\n    - Impacts self-managed customers who use the `omniauth-azure-oauth2` provider for authentication.\n    - Without migration to `omniauth_openid_connect`, users will no longer be able to sign in using the Azure login button.\n- [Min concurrency and max concurrency in Sidekiq options](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#min-concurrency-and-max-concurrency-in-sidekiq-options)\n    - Impacts GitLab deployments that have `sidekiq['min_concurrency']` and `sidekiq['max_concurrency']` configured in their `gitlab.rb`.\n    - Failure to migrate will break the deployment.\n\n###  CI\n- [Registration tokens and server-side runner arguments in POST /api/v4/runners endpoint](https://docs.gitlab.com/ee/update/deprecations.html#registration-tokens-and-server-side-runner-arguments-in-post-apiv4runners-endpoint)\n    - Impacts custom automations that provision runners.\n    - Potentially breaks CI pipelines by disabling runner provisioning.\n- [File type variable expansion fixed in downstream pipelines](https://docs.gitlab.com/ee/update/deprecations.html#file-type-variable-expansion-fixed-in-downstream-pipelines)\n    - Impacts pipelines using [downstream pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html) passing [File-type variables](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html#pass-cicd-variables-to-a-downstream-pipeline) to the downstream pipeline.\n    - Changed behavior may break the downstream pipeline due to a change in variable content.\n\n- [after_script keyword will run for canceled jobs](https://docs.gitlab.com/ee/update/deprecations.html#after_script-keyword-will-run-for-cancelled-jobs)\n    - Impacts pipelines using the [after_script](https://docs.gitlab.com/ee/ci/yaml/#after_script) keyword.\n    - Changed behavior may break pipelines or cause unexpected pipeline results.\n- [Old versions of JSON web tokens are deprecated](https://docs.gitlab.com/ee/update/deprecations.html#old-versions-of-json-web-tokens-are-deprecated), [HashiCorp Vault integration will no longer use CI_JOB_JWT by default](https://docs.gitlab.com/ee/update/deprecations.html#hashicorp-vault-integration-will-no-longer-use-ci_job_jwt-by-default), and [JWT /-/jwks instance endpoint is deprecated](https://docs.gitlab.com/ee/update/deprecations.html#jwt--jwks-instance-endpoint-is-deprecated)\n    - Impacts pipelines relying on the `CI_JOB_JWT or CI_JOB_JWT_V2` CI variables.\n    - The removal of the variable may break Vault integrations or otherwise cause pipelines to fail.\n\n### CD\n- [The pull-based deployment features of the GitLab agent for Kubernetes is deprecated](https://docs.gitlab.com/ee/update/deprecations.html#the-pull-based-deployment-features-of-the-gitlab-agent-for-kubernetes-is-deprecated)\n    - Impacts projects using the GitLab agent for Kubernetes for deployments.\n    - The change may break CD workflows relying on the GitLab agent for Kubernetes.\n    - The agent itself is not deprecated and still used for a number of features, like communicating with the cluster, its API endpoints and pushing information about events in the cluster to GitLab.\n\n- [Agent for Kubernetes option ca-cert-file renamed](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#agent-for-kubernetes-option-ca-cert-file-renamed)\n    - Impacts customers installing Kubernetes agents behind a self-signed certificate.\n    - The change may impact CD workflows relying on connecting Kubernetes clusters to GitLab via the agent.\n\n### Package\n- [npm package uploads now occur asynchronously](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#npm-package-uploads-now-occur-asynchronously)\n    - Impacts projects [publishing npm or Yarn packages to the GitLab registry](https://docs.gitlab.com/ee/user/packages/npm_registry/#publish-to-gitlab-package-registry).\n    - Due to the asynchronous upload, pipelines may break that expect packages to be available as soon as they are published.\n\n- [Dependency Proxy: Access tokens to have additional scope checks](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#dependency-proxy-access-tokens-to-have-additional-scope-checks)\n    - Impacts projects using the Dependency Proxy with a group access token or personal access token that have insufficient [scopes](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy).\n    - Because tokens without the required scopes will fail, this may break pipelines by rejecting docker login and docker pull requests.\n\n- [Maven repository group permissions](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#breaking-change-to-the-maven-repository-group-permissions)\n    - Impacts projects using the Maven repository at the group level where user permissions are not set up correctly.\n    - Because users without correct permissions will fail to access the requested packages, this change may break pipelines for those users.\n\n### GitLab.com\n- [Upgrading the operating system version of GitLab SaaS runners on Linux](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#upgrading-the-operating-system-version-of-gitlab-saas-runners-on-linux)\n    - Impacts pipelines using `saas-linux-*-amd64` tagged shared runners on GitLab.com that use outdated Docker-in-Docker or Kaniko versions.\n    - The outdated versions will be unable to detect the container runtime and fail, breaking the pipeline.\n\n- [Deprecating Windows Server 2019 in favor of 2022](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#deprecating-windows-server-2019-in-favor-of-2022)\n    - Impacts pipelines using `shared-windows` and `windows-1809` tagged shared runners on GitLab.com.\n    - Affected jobs will not be picked up by runners, thus blocking the pipeline.\n    - You can identify affected jobs by [searching](https://docs.gitlab.com/ee/user/search/exact_code_search.html) for the deprecated tags in your .yml files.\n\n- [Removal of tags from small SaaS runners on Linux](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#removal-of-tags-from-small-saas-runners-on-linux)\n    - Impacts pipelines using shared runners tagged `docker`, `east-c`, `gce`, `git-annex`, `linux`, `mongo`, `mysql`, `ruby`, or  `shared` on GitLab.com.\n    - Affected jobs will not be picked up by runners, thus blocking the pipeline.\n    - You can identify affected jobs by [searching](https://docs.gitlab.com/ee/user/search/exact_code_search.html) for the deprecated tags in your .yml files.\n\n### Ultimate only\n- [Security policy fields newly_detected and match_on_inclusion are deprecated](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#security-policy-field-newly_detected-is-deprecated)\n    - Impacts groups and projects that have merge request approval policies (previously: scan result policies) enabled and use the deprecated keywords.\n    - Without migration, the rules enforced by the policies will stop working, causing potential compliance violations.\n\n- [Required Pipeline Configuration is deprecated](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#required-pipeline-configuration-is-deprecated)\n    - Impacts Ultimate self-managed customers using required pipeline configuration.\n    - Without migration, the required configuration will no longer be used by projects, impacting all pipelines that are run on the instance.\n\n- [Proxy-based DAST is deprecated](https://docs.gitlab.com/ee/update/deprecations.html#proxy-based-dast-deprecated)\n    - Impacts projects that are using DAST with the variable `DAST_BROWSER_SCAN` set to false.\n    - Without migration, DAST scans in existing pipelines will fail.\n    - Follow the recommended changes outlined in the [DAST migration guide](https://docs.gitlab.com/ee/user/application_security/dast/proxy_based_to_browser_based_migration_guide.html) to ensure DAST can continue scanning your applications.\n\n## See all removals in GitLab 17.0\n\nFor more detailed information and to see all the removals coming up in this year's major release, please visit the [Deprecations page](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=17.0).\n\n> Live demo! Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Register today!](https://about.gitlab.com/seventeen/)\n","bulletin-board",[495,1051,9],{"slug":1809,"featured":90,"template":699},"a-guide-to-the-high-impact-breaking-changes-in-gitlab-17-0","content:en-us:blog:a-guide-to-the-high-impact-breaking-changes-in-gitlab-17-0.yml","A Guide To The High Impact Breaking Changes In Gitlab 17 0","en-us/blog/a-guide-to-the-high-impact-breaking-changes-in-gitlab-17-0.yml","en-us/blog/a-guide-to-the-high-impact-breaking-changes-in-gitlab-17-0",8,[678,704,729,749,768,790,812,832,854],1758326245232]