[{"data":1,"prerenderedAt":767},["ShallowReactive",2],{"/en-us/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines":3,"navigation-en-us":35,"banner-en-us":461,"footer-en-us":478,"William Arias-Daniel Helfand":722,"next-steps-en-us":745,"footer-source-/en-us/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines/":760},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":12,"config":24,"_id":28,"_type":29,"title":30,"_source":31,"_file":32,"_stem":33,"_extension":34},"/en-us/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines","blog",false,"",{"config":9,"title":10,"description":11},{"noIndex":6},"Variable and artifact sharing in GitLab parent-child pipelines","Learn how to simplify complex CI/CD pipelines with these best practices for sharing data in more modular pipeline setups. ",{"title":10,"description":11,"authors":13,"heroImage":16,"date":17,"body":18,"category":19,"tags":20},[14,15],"William Arias","Daniel Helfand","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664198/Blog/Hero%20Images/Self-Hosted_1800x945.png","2025-10-16","Software projects have different evolving needs and requirements. Some have\nsaid that *software is never finished, merely abandoned*. Some software\nprojects are small and others are large with complex integrations. Some have\ndependencies on external projects, while others are self-contained.\nRegardless of the size and complexity, the need to validate and ensure\nfunctionality remains paramount. \n\n\nCI/CD pipelines can help with the challenge of building and validating software projects consistently, but, much like the software itself, these pipelines can become complex with many dependencies. This is where ideas like [parent-child pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#parent-child-pipelines) and data exchange in CI/CD setups become incredibly important.\n\nIn this article, we will cover common CI/CD data exchange challenges users may encounter with parent-child pipelines in GitLab — and how to solve them. You'll learn how to turn complex CI/CD processes into more manageable setups. \n\n## Using parent-child pipelines\n\nThe pipeline setup in the image below illustrates a scenario where a project could require a large, complex pipeline. The whole project resides in one repository and contains different modules. Each module requires its own set of build and test automation steps. \n\n\nOne approach to address the CI/CD configuration in a scenario like this is to break down the larger pipeline into smaller ones (i.e., child pipelines) and keep a common CI/CD process that is shared across all modules in charge of the whole orchestration (i.e., parent pipeline).\n\n\n![CI/CD configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1760617772/hizwvhmgxn6exbmvsnrv.png)\n\n\nThe parent-child pipeline pattern allows a single pipeline to orchestrate one or many downstream pipelines. Similar to how a single pipeline coordinates the execution of multiple [jobs](https://docs.gitlab.com/ci/jobs/), the parent pipeline coordinates the running of full pipelines with one or more jobs.\n\n\nThis pattern has been shown to be helpful in a variety of use cases:\n\n\n* Breaking down large, complex pipelines into smaller, manageable pieces  \n\n* Conditionally executing certain pipelines as part of a larger CI/CD process  \n\n* Executing pipelines in parallel  \n\n* Helping manage user permissions to access and run certain pipelines \n\n\n\nGitLab’s current CI/CD structure supports this pattern and makes it simple to implement parent-child pipelines. While there are many benefits when using the parent-child pipeline pattern with GitLab, one question we often get is how to share data between the parent and child pipelines. In the next sections, we’ll go over how to make use of GitLab variables and artifacts to address this concern.\n\n\n### Sharing variables\n\n\nThere are cases where it is necessary to pass the output from a parent pipeline job to a child pipeline. These outputs can be shared as variables, [artifacts](https://docs.gitlab.com/ci/jobs/job_artifacts/), and [inputs](https://docs.gitlab.com/ci/inputs/).\n\n\nConsider a case where we create a custom variable `var_1` during the runtime of a job:\n\n\n\n```\n\nstages:\n  - build\n  - triggers\n\n# This job only creates a variable \n\ncreate_var_job:\n  stage: build\n  script:\n    - var_1=\"Hi, I'm a Parent pipeline variable\"\n    - echo \"var_1=$var_1\" >> var.env\n  artifacts:\n    reports:\n      dotenv: var.env\n```\n\n\nNotice that the variable is created as part of the script steps in the job (during runtime). In this example, we are using a simple string `\"Hi, I'm a Parent pipeline variable\"` to illustrate the main syntax required to later share this variable with a child pipeline. Let's break down the `create_var_job`  and analyze the main steps from this GitLab job \n\n\nFirst, we need to save `var_1` as `dotenv`:\n\n\n```\n  script:\n    - var_1=\"Hi, I'm a pipeline variable\"\n    - echo \"var_1=$var_1\" >> var.env\n```\n\n\nAfter saving `var_1` as `var.env`, the next important step is to make this variable available as an artifact produced by the `create_var_job`. To do that, we use the following syntax: \n\n\n```\n\nartifacts:\n    reports:\n      dotenv: var.env\n```\n\n\nUp to this point, we have created a variable during runtime and saved it as a `dotenv` report. Now let's add the job that should trigger the child pipeline:\n\n\n```\n\ntelco_service_a:\n  stage: triggers\n  trigger:\n    include: service_a/.gitlab-ci.yml\n  rules:\n    - changes:\n        - service_a/*\n```\n\n\nThe goal of `telco_service_a`  job is to find the `.gitlab-ci.yml` configuration of the child pipeline,  which is defined in this case as `service_a,` and trigger its execution. Let's examine this job: \n\n\n```\n\ntelco_service_a:\n  stage: triggers\n  trigger:\n    include: service_a/.gitlab-ci.yml\n```\n\n\nWe see it belongs to another `stage` of the pipeline named `triggers.`This job will run only after `create_var_job` from the first stage successfully finishes and where the variable  `var_1` we want to pass is created.\n\n\nAfter defining the stage, we use the reserved words `trigger` and `include` to tell GitLab where to search for the child pipeline configuration, as illustrated in the YAML below:\n\n\n```\n  trigger:\n    include: service_a/.gitlab-ci.yml\n```\n\n\nOur child-pipeline YAML configuration is under `service_a/.gitlab-ci.yml` folder in the GitLab repository, for this example. \n\n\n![child-pipeline YAML configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1760617772/ujkirpbifthpuujkcm6f.png)\n\n\n\u003Cp>\u003C/p>\n\n\n\u003Ccenter>\u003Ci>Child pipelines folders with configurations\u003C/i>\u003C/center>\n\n\n\u003Cp>\u003C/p>\n\n\nTake into consideration that the repository structure depicted above can vary. What matters is properly pointing the  `triggers: include` properties at the location of your child-pipeline configuration in your repository.\n\n\nFinally, we use `rules: changes` to indicate to GitLab that this child pipeline should be triggered only if there is any change in any file in the `service_a/.gitlab-ci.yml` directory, as illustrated in the following code snippet:\n\n\n```\n\nrules:\n    - changes:\n        - service_a/*\n```\n\n\nUsing this rule helps to optimize cost by triggering the child pipeline job only when necessary. This approach is particularly valuable in a monorepo architecture where specific modules contain numerous components, allowing us to avoid running their dedicated pipelines when no changes have been made to their respective codebases.\n\n\n#### Configuring the parent pipeline \n\n\nUp to this point, we have put together our parent pipeline. Here's the full code snippet for this segment:\n\n```\n\n# Parent Pipeline Configuration\n\n# This pipeline creates a custom variable and triggers a child pipeline\n\n\nstages:\n  - build\n  - trigger\n\ncreate_var_job:\n  stage: build\n  script:\n    - var_1=\"Hi, I'm a Parent pipeline variable\"\n    - echo \"var_1=$var_1\" >> var.env\n  artifacts:\n    reports:\n      dotenv: var.env\n\ntelco_service_a:\n  stage: triggers\n  trigger:\n    include: service_a/.gitlab-ci.yml\n  rules:\n    - changes:\n        - service_a/*\n```\n\n\nWhen GitLab executes the YAML configuration in the GitLab UI, the parent pipeline gets rendered as follows:\n\n\n![parent pipeline rendering](https://res.cloudinary.com/about-gitlab-com/image/upload/v1760617771/e1azkkr0rnzd42dzkw1x.png)\n\n\nNotice the label \"trigger job,\" which indicates this job will start the execution of another pipeline configuration.\n\n\n#### Configuring the child pipeline \n\n\nMoving forward, let's now focus on the child pipeline configuration, where we expect to inherit and print the value of the `var_1` created in the parent pipeline.\n\n\nThe pipeline configuration in `service_a/.gitlab_ci.yml` has the following definition:\n\n\n```\n\nstages:\n  - build\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"this job inherits the variable from the Parent pipeline:\"\n    - echo $var_1\n  needs:\n    - project: gitlab-da/use-cases/7-4-parent-child-pipeline\n      job: create_var_job\n      ref: main\n      artifacts: true\n```\n\n\nLike before, let's break down this pipeline and highlight the main parts to achieve our goal. This pipeline only contains one stage (i.e., `build)` and one job (i.e., `build_a)`. The script in the job contains two steps:\n\n\n```\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"this job inherits the variable from the Parent pipeline:\"\n    - echo $var_1\n```\n\n\nThese two steps print output during the execution. The most interesting one is the second step, `echo $var_1`, where we expect to print the variable value inherited from the parent pipeline. Remember, this was a simple string with value: `\"Hi, I'm a Parent pipeline variable.\"` \n\n\n#### Inheriting variables using needs\n\n\nTo set and link this job to inherit variables from the parent pipeline, we use the reserved GitLab CI properties `needs` as depicted in the following snippet:\n\n\n```\n\nneeds:\n    - project: gitlab-da/use-cases/7-4-parent-child-pipeline\n      job: create_var_job\n      ref: main\n      artifacts: true\n```\n\n\nUsing the \"needs\" keyword, we define dependencies that must be completed before running this job. In this case, we pass four different values. Let's walk through each one  of them:\n\n\n* **Project:** The complete namespace of the project where the main `gitlab-ci.yml` containing the parent pipeline YAML is located. Make sure to include the absolute path.  \n\n* **Job:** The specific job name in the parent pipeline from where we want to inherit the variable.   \n\n* **Ref:** The name of the branch where the main `gitlab-ci.yml` containing the parent pipeline YAML is located.   \n\n* **Artifacts:** Where we set a boolean value, indicating that artifacts from the parent pipeline job should be downloaded and made available to this child pipeline job.\n\n\n**Note:** This specific approach using the needs property is only available to GitLab Premium and Ultimate users. We will cover another example for GitLab community users later on. \n\n\n#### Putting it all together \n\n\nNow let's assume we make a change to any of the files under `service_a` folder and commit the changes to the repository. When GitLab detects the change, the rule we set up will trigger the child job pipeline execution. This gets displayed in the GitLab UI as follows:\n\n\n![Rule triggering the child job pipeline execution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1760617771/e1azkkr0rnzd42dzkw1x.png)\n\n\nClicking on the `telco_service_a`  will take us to the jobs in the child pipeline:\n\n\n![Jobs in pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1760617773/vftjkg7ct2wqmew1e3yk.png)\n\n\nWe can see the parent-child relationship, and finally, by clicking on the `build_a job`, we can visually verify the variable inheritance in the job execution log:\n\n\n![Verifying the variable inheritance in the job execution log](https://res.cloudinary.com/about-gitlab-com/image/upload/v1760617758/hxfkfmev9hebbqhgcvoh.png)\n\n\nThis output confirms the behavior we expected. The custom runtime variable `var_1` created in the parent job is inherited in the child job, unpacked from the `dotenv` report, and its value accessible as can be confirmed in Line 26 above.\n\n\nThis use case illustrates how to share custom variables that can contain any value between pipelines. This example is intentionally simple and can be extrapolated to more realistic scenarios. Take, for instance, the following CI/CD configuration, where the custom variable we need to share is the tag of a Docker image:\n\n\n```\n\n# Pipeline \n\n\nbuild-prod-image:\n  tags: [ saas-linux-large-amd64 ]\n  image: docker:20.10.16\n  stage: build\n  services:\n    - docker:20.10.16-dind\n  \n  script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker build -t $PRODUCTION_IMAGE .\n    - docker push $PRODUCTION_IMAGE\n    - echo \"UPSTREAM_CONTAINER_IMAGE=$PRODUCTION_IMAGE\" >> prodimage.env\n\n  artifacts:\n    reports:\n      dotenv: prodimage.env\n\n  rules:\n     - if: '$CI_COMMIT_BRANCH == \"main\"'\n       when: always\n     - when: never\n```\n\n\nAnd use the variable with the Docker image tag, in another job that updates a Helm manifest file:\n\n\n```\n\nupdate-helm-values:\n    stage: update-manifests\n    image:\n        name: alpine:3.16\n        entrypoint: [\"\"]\n  \n    before_script:\n         - apk add --no-cache git curl bash yq\n         - git remote set-url origin https://${CI_USERNAME}:${GITOPS_USER}@${SERVER_PATH}/${PROJECT_PATH}\n         - git config --global user.email \"gitlab@gitlab.com\"\n         - git config --global user.name \"GitLab GitOps\"\n         - git pull origin main\n    script:\n          - cd src\n          - echo $UPSTREAM_CONTAINER_IMAGE\n          - yq eval -i \".spec.template.spec.containers[0].image |= \\\"$UPSTREAM_CONTAINER_IMAGE\\\"\" store-deployment.yaml\n          - cat store-deployment.yaml\n          - git pull origin main\n          - git checkout -B main\n          - git commit -am '[skip ci] prod image update'\n          - git push origin main\n    needs:\n      - project: gitlab-da/use-cases/devsecops-platform/simply-find/simply-find-front-end\n        job: build-prod-image\n        ref: main\n        artifacts: true\n```\n\n\nMastering how to share variables between pipelines while maintaining the relationship between them enables us to create more sophisticated workflow orchestration that can meet our software building needs. \n\n\n### Using GitLab Package Registry to share artifacts\n\n\nWhile the needs feature mentioned above works great for Premium and Ultimate users, GitLab also has features to help achieve similar results for Community Edition users. One suggested approach is to store artifacts in the [GitLab Package Registry](https://docs.gitlab.com/user/packages/package_registry/). \n\n\nUsing a combination of the variables provided in GitLab CI/CD jobs and the GitLab API, you can upload artifacts to the GitLab Package Registry from a parent pipeline. In the child pipeline, you can then access the uploaded artifact from the package registry using the same variables and API to access the artifact. Let’s take a look at the example pipeline and some supplementary scripts that illustrate this:\n\n\n**gitlab-ci.yml (parent pipeline)**\n\n\n```\n\n# Parent Pipeline Configuration\n\n# This pipeline creates an artifact, uploads it to Package Registry, and triggers a child pipeline\n\n\nstages:\n  - create-upload\n  - trigger\n\nvariables:\n  PACKAGE_NAME: \"pipeline-artifacts\"\n  PACKAGE_VERSION: \"$CI_PIPELINE_ID\"\n  ARTIFACT_FILE: \"artifact.txt\"\n\n# Job 1: Create and upload artifact to Package Registry\n\ncreate-and-upload-artifact:\n  stage: create-upload\n  image: alpine:latest\n  before_script:\n    - apk add --no-cache curl bash\n  script:\n    - bash scripts/create-artifact.sh\n    - bash scripts/upload-to-registry.sh\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"push\"\n\n# Job 2: Trigger child pipeline\n\ntrigger-child:\n  stage: trigger\n  trigger:\n    include: child-pipeline.yml\n    strategy: depend\n  variables:\n    PARENT_PIPELINE_ID: $CI_PIPELINE_ID\n    PACKAGE_NAME: $PACKAGE_NAME\n    PACKAGE_VERSION: $PACKAGE_VERSION\n    ARTIFACT_FILE: $ARTIFACT_FILE\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"push\"\n```\n\n\n**child-pipeline.yml**\n\n\n```\n\n# Child Pipeline Configuration\n\n# This pipeline downloads the artifact from Package Registry and processes it\n\n\nstages:\n  - download-process\n\nvariables:\n  # These variables are passed from the parent pipeline\n  PACKAGE_NAME: \"pipeline-artifacts\"\n  PACKAGE_VERSION: \"$PARENT_PIPELINE_ID\"\n  ARTIFACT_FILE: \"artifact.txt\"\n\n# Job 1: Download and process artifact from Package Registry\n\ndownload-and-process-artifact:\n  stage: download-process\n  image: alpine:latest\n  before_script:\n    - apk add --no-cache curl bash\n  script:\n    - bash scripts/download-from-registry.sh\n    - echo \"Processing downloaded artifact...\"\n    - cat $ARTIFACT_FILE\n    - echo \"Artifact processed successfully!\"\n```\n\n\n**upload-to-registry.sh**\n\n\n```\n\n#!/bin/bash\n\n\nset -e\n\n\n# Configuration\n\nPACKAGE_NAME=\"${PACKAGE_NAME:-pipeline-artifacts}\"\n\nPACKAGE_VERSION=\"${PACKAGE_VERSION:-$CI_PIPELINE_ID}\"\n\nARTIFACT_FILE=\"${ARTIFACT_FILE:-artifact.txt}\"\n\n\n# Validate required variables\n\nif [ -z \"$CI_PROJECT_ID\" ]; then\n    echo \"Error: CI_PROJECT_ID is not set\"\n    exit 1\nfi\n\n\nif [ -z \"$CI_JOB_TOKEN\" ]; then\n    echo \"Error: CI_JOB_TOKEN is not set\"\n    exit 1\nfi\n\n\nif [ -z \"$CI_API_V4_URL\" ]; then\n    echo \"Error: CI_API_V4_URL is not set\"\n    exit 1\nfi\n\n\nif [ ! -f \"$ARTIFACT_FILE\" ]; then\n    echo \"Error: Artifact file '$ARTIFACT_FILE' not found\"\n    exit 1\nfi\n\n\n# Construct the upload URL\n\nUPLOAD_URL=\"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${PACKAGE_NAME}/${PACKAGE_VERSION}/${ARTIFACT_FILE}\"\n\n\n# Upload the file using curl\n\nresponse=$(curl -w \"%{http_code}\" -o /tmp/upload_response.json \\\n    --header \"JOB-TOKEN: $CI_JOB_TOKEN\" \\\n    --upload-file \"$ARTIFACT_FILE\" \\\n    \"$UPLOAD_URL\")\n\nif [ \"$response\" -eq 201 ]; then\n    echo \"Upload successful!\"\nelse\n    echo \"Upload failed with HTTP code: $response\"\n    exit 1\nfi\n\n```\n\n\n**download-from-regsitry.sh**\n\n\n```\n\n#!/bin/bash\n\n\nset -e\n\n\n# Configuration\n\nPACKAGE_NAME=\"${PACKAGE_NAME:-pipeline-artifacts}\"\n\nPACKAGE_VERSION=\"${PACKAGE_VERSION:-$PARENT_PIPELINE_ID}\"\n\nARTIFACT_FILE=\"${ARTIFACT_FILE:-artifact.txt}\"\n\n\n# Validate required variables\n\nif [ -z \"$CI_PROJECT_ID\" ]; then\n    echo \"Error: CI_PROJECT_ID is not set\"\n    exit 1\nfi\n\n\nif [ -z \"$CI_JOB_TOKEN\" ]; then\n    echo \"Error: CI_JOB_TOKEN is not set\"\n    exit 1\nfi\n\n\nif [ -z \"$CI_API_V4_URL\" ]; then\n    echo \"Error: CI_API_V4_URL is not set\"\n    exit 1\nfi\n\n\nif [ -z \"$PACKAGE_VERSION\" ]; then\n    echo \"Error: PACKAGE_VERSION is not set\"\n    exit 1\nfi\n\n\n# Construct the download URL\n\nDOWNLOAD_URL=\"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${PACKAGE_NAME}/${PACKAGE_VERSION}/${ARTIFACT_FILE}\"\n\n\n# Download the file using curl\n\nresponse=$(curl -w \"%{http_code}\" -o \"$ARTIFACT_FILE\" \\\n    --header \"JOB-TOKEN: $CI_JOB_TOKEN\" \\\n    --fail-with-body \\\n    \"$DOWNLOAD_URL\")\n\nif [ \"$response\" -eq 200 ]; then\n    echo \"Download successful!\"\nelse\n    echo \"Download failed with HTTP code: $response\"\n    exit 1\nfi\n\n```\n\n\nIn this example, the parent pipeline uploads a file to the GitLab Package Registry by calling a script named `upload-to-registry.sh`. The script gives the artifact a name and version and constructs the API call to upload the file to the package registry. The parent pipeline is able to authenticate using a `$CI_JOB_TOKEN` to push the artifact.txt file to the registry. \n\n\nThe child pipeline operates the same as the parent pipeline by using a script to construct the API call to download the artifact.txt file from the package registry. It also is able to authenticate to the registry using the `$CI_JOB_TOKEN`. \n\n\nSince the GitLab Package Registry is available to all GitLab users, it helps to serve as a central location for storing and versioning artifacts. It is a great option for users working with many kinds of artifacts and needing to version artifacts for workflows even beyond CI/CD. \n\n\n### Using inputs to pass variables to a child pipeline\n\n\nIf you made it this far in this tutorial, and you have plans to start creating new pipeline configurations, you might want to start by evaluating if your use case can benefit from using **inputs** to pass variables to other pipelines. \n\n\nUsing inputs is a recommended way to pass variables when you need to define specific values in a CI/CD job and have those values remain fixed during the pipeline run. Inputs might offer certain advantages over the method we implemented before. For example, with inputs, you can include data validation through options (i.e., values must be one of these: \\[‘staging', ‘prod’\\]), variable descriptions, type checking, and assign default values before the pipeline run. \n\n\n#### Configuring CI/CD inputs\n\n\nConsider the following parent pipeline configuration:\n\n\n```\n\n# .gitlab-ci.yml (main file)\n\nstages:\n - trigger\n\ntrigger-staging:\n stage: trigger\n trigger:\n   include:\n     - local: service_a/.gitlab-ci.yml\n       inputs:\n         environment: staging\n         version: \"1.0.0\"\n```\n\n\nLet's zoom in at the main difference between the code snippet above and the previous parent pipeline examples in this tutorial: \n\n\n```\n\ntrigger:\n   include:\n     - local: service_a/.gitlab-ci.yml\n       inputs:\n         environment: staging\n         version: \"1.0.0\"\n```\n\n\nThe main difference is using the reserved word \"inputs\". This part of the YAML configuration can be read in natural language as: “trigger the child pipeline defined in `service_a.gitlab-ci.yml` and make sure to pass ‘environment: staging’ and ‘version:1.0.0’ as input variables that the child pipeline will know how to use.\n\n\n#### Reading CI/CD inputs in child pipelines\n\n\nMoving to the child pipeline, it must contain in its declaration a spec that defines the inputs it can take. For each input, it is possible to add a little description, a set of predefined options the input value can take, and the type of value it will take. This is illustrated as follows: \n\n\n```\n\n# target pipeline or child-pipeline in this case\n\n\nspec:\n  inputs:\n    environment:\n      description: \"Deployment environment\"\n      options: [staging, production]\n    version:\n      type: string\n      description: \"Application version\"\n\n\n---\n\n\nstages:\n  - deploy\n# Jobs that will use the inputs\n\ndeploy:\n  stage: deploy\n  script:\n     -  echo \"Deploying version $[[ inputs.version ]] to $[[ inputs.environment ]]\"\n\n```\n\n\nNotice from the code snippet that after defining the spec, there is a YAML document separator \"---\"  followed by the actual child pipeline definition where we access the variables `$[[ inputs.version ]]` and `$[[ inputs.environment ]]\"` from the defined inputs using input interpolation.\n\n\n## Get hands-on with parent-child pipelines, artifacts, and more\n\n\nWe hope this article has helped with navigating the challenge of sharing variables and artifacts in parent-child pipeline setups.\n\n\nTo try these examples for yourself, feel free to view or fork the [Premium/Ultimate](https://gitlab.com/gitlab-da/use-cases/devsecops-platform/devops-platform-wave/scenarios/scenario7-deep-dive-into-build-automation-and-ci/7-4-parent-child-pipeline/-/tree/main) and the [GitLab Package Registry](https://gitlab.com/gitlab-da/playground/dhelfand/parent-child-pipeline-with-package-registry-artifacts) examples of sharing artifacts.\n\n\nYou can also sign up for a [30-day free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/) to experience all the features GitLab has to offer. Thanks for reading!\n","engineering",[21,22,23],"CI/CD","DevSecOps","tutorial",{"featured":25,"template":26,"slug":27},true,"BlogPost","variable-and-artifact-sharing-in-gitlab-parent-child-pipelines","content:en-us:blog:variable-and-artifact-sharing-in-gitlab-parent-child-pipelines.yml","yaml","Variable And Artifact Sharing In Gitlab Parent Child Pipelines","content","en-us/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines.yml","en-us/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines","yml",{"_path":36,"_dir":37,"_draft":6,"_partial":6,"_locale":7,"data":38,"_id":457,"_type":29,"title":458,"_source":31,"_file":459,"_stem":460,"_extension":34},"/shared/en-us/main-navigation","en-us",{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":388,"minimal":419,"duo":438,"pricingDeployment":447},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/","gitlab logo","header",{"text":45,"config":46},"Get free trial",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"Talk to sales",{"href":52,"dataGaName":53,"dataGaLocation":43},"/sales/","sales",{"text":55,"config":56},"Sign in",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,104,199,204,309,369],{"text":61,"config":62,"cards":64,"footer":87},"Platform",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"The most comprehensive AI-powered DevSecOps Platform",{"text":68,"config":69},"Explore our Platform",{"href":70,"dataGaName":63,"dataGaLocation":43},"/platform/",{"title":72,"description":73,"link":74},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":75,"config":76},"Meet GitLab Duo",{"href":77,"dataGaName":78,"dataGaLocation":43},"/gitlab-duo/","gitlab duo ai",{"title":80,"description":81,"link":82},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":83,"config":84},"Learn more",{"href":85,"dataGaName":86,"dataGaLocation":43},"/why-gitlab/","why gitlab",{"title":88,"items":89},"Get started with",[90,95,100],{"text":91,"config":92},"Platform Engineering",{"href":93,"dataGaName":94,"dataGaLocation":43},"/solutions/platform-engineering/","platform engineering",{"text":96,"config":97},"Developer Experience",{"href":98,"dataGaName":99,"dataGaLocation":43},"/developer-experience/","Developer experience",{"text":101,"config":102},"MLOps",{"href":103,"dataGaName":101,"dataGaLocation":43},"/topics/devops/the-role-of-ai-in-devops/",{"text":105,"left":25,"config":106,"link":108,"lists":112,"footer":181},"Product",{"dataNavLevelOne":107},"solutions",{"text":109,"config":110},"View all Solutions",{"href":111,"dataGaName":107,"dataGaLocation":43},"/solutions/",[113,137,160],{"title":114,"description":115,"link":116,"items":121},"Automation","CI/CD and automation to accelerate deployment",{"config":117},{"icon":118,"href":119,"dataGaName":120,"dataGaLocation":43},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[122,125,129,133],{"text":21,"config":123},{"href":124,"dataGaLocation":43,"dataGaName":21},"/solutions/continuous-integration/",{"text":126,"config":127},"AI-Assisted Development",{"href":77,"dataGaLocation":43,"dataGaName":128},"AI assisted development",{"text":130,"config":131},"Source Code Management",{"href":132,"dataGaLocation":43,"dataGaName":130},"/solutions/source-code-management/",{"text":134,"config":135},"Automated Software Delivery",{"href":119,"dataGaLocation":43,"dataGaName":136},"Automated software delivery",{"title":138,"description":139,"link":140,"items":145},"Security","Deliver code faster without compromising security",{"config":141},{"href":142,"dataGaName":143,"dataGaLocation":43,"icon":144},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[146,150,155],{"text":147,"config":148},"Application Security Testing",{"href":142,"dataGaName":149,"dataGaLocation":43},"Application security testing",{"text":151,"config":152},"Software Supply Chain Security",{"href":153,"dataGaLocation":43,"dataGaName":154},"/solutions/supply-chain/","Software supply chain security",{"text":156,"config":157},"Software Compliance",{"href":158,"dataGaName":159,"dataGaLocation":43},"/solutions/software-compliance/","software compliance",{"title":161,"link":162,"items":167},"Measurement",{"config":163},{"icon":164,"href":165,"dataGaName":166,"dataGaLocation":43},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[168,172,176],{"text":169,"config":170},"Visibility & Measurement",{"href":165,"dataGaLocation":43,"dataGaName":171},"Visibility and Measurement",{"text":173,"config":174},"Value Stream Management",{"href":175,"dataGaLocation":43,"dataGaName":173},"/solutions/value-stream-management/",{"text":177,"config":178},"Analytics & Insights",{"href":179,"dataGaLocation":43,"dataGaName":180},"/solutions/analytics-and-insights/","Analytics and insights",{"title":182,"items":183},"GitLab for",[184,189,194],{"text":185,"config":186},"Enterprise",{"href":187,"dataGaLocation":43,"dataGaName":188},"/enterprise/","enterprise",{"text":190,"config":191},"Small Business",{"href":192,"dataGaLocation":43,"dataGaName":193},"/small-business/","small business",{"text":195,"config":196},"Public Sector",{"href":197,"dataGaLocation":43,"dataGaName":198},"/solutions/public-sector/","public sector",{"text":200,"config":201},"Pricing",{"href":202,"dataGaName":203,"dataGaLocation":43,"dataNavLevelOne":203},"/pricing/","pricing",{"text":205,"config":206,"link":208,"lists":212,"feature":296},"Resources",{"dataNavLevelOne":207},"resources",{"text":209,"config":210},"View all resources",{"href":211,"dataGaName":207,"dataGaLocation":43},"/resources/",[213,246,268],{"title":214,"items":215},"Getting started",[216,221,226,231,236,241],{"text":217,"config":218},"Install",{"href":219,"dataGaName":220,"dataGaLocation":43},"/install/","install",{"text":222,"config":223},"Quick start guides",{"href":224,"dataGaName":225,"dataGaLocation":43},"/get-started/","quick setup checklists",{"text":227,"config":228},"Learn",{"href":229,"dataGaLocation":43,"dataGaName":230},"https://university.gitlab.com/","learn",{"text":232,"config":233},"Product documentation",{"href":234,"dataGaName":235,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":237,"config":238},"Best practice videos",{"href":239,"dataGaName":240,"dataGaLocation":43},"/getting-started-videos/","best practice videos",{"text":242,"config":243},"Integrations",{"href":244,"dataGaName":245,"dataGaLocation":43},"/integrations/","integrations",{"title":247,"items":248},"Discover",[249,254,258,263],{"text":250,"config":251},"Customer success stories",{"href":252,"dataGaName":253,"dataGaLocation":43},"/customers/","customer success stories",{"text":255,"config":256},"Blog",{"href":257,"dataGaName":5,"dataGaLocation":43},"/blog/",{"text":259,"config":260},"Remote",{"href":261,"dataGaName":262,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":264,"config":265},"TeamOps",{"href":266,"dataGaName":267,"dataGaLocation":43},"/teamops/","teamops",{"title":269,"items":270},"Connect",[271,276,281,286,291],{"text":272,"config":273},"GitLab Services",{"href":274,"dataGaName":275,"dataGaLocation":43},"/services/","services",{"text":277,"config":278},"Community",{"href":279,"dataGaName":280,"dataGaLocation":43},"/community/","community",{"text":282,"config":283},"Forum",{"href":284,"dataGaName":285,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":287,"config":288},"Events",{"href":289,"dataGaName":290,"dataGaLocation":43},"/events/","events",{"text":292,"config":293},"Partners",{"href":294,"dataGaName":295,"dataGaLocation":43},"/partners/","partners",{"backgroundColor":297,"textColor":298,"text":299,"image":300,"link":304},"#2f2a6b","#fff","Insights for the future of software development",{"altText":301,"config":302},"the source promo card",{"src":303},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":305,"config":306},"Read the latest",{"href":307,"dataGaName":308,"dataGaLocation":43},"/the-source/","the source",{"text":310,"config":311,"lists":313},"Company",{"dataNavLevelOne":312},"company",[314],{"items":315},[316,321,327,329,334,339,344,349,354,359,364],{"text":317,"config":318},"About",{"href":319,"dataGaName":320,"dataGaLocation":43},"/company/","about",{"text":322,"config":323,"footerGa":326},"Jobs",{"href":324,"dataGaName":325,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":325},{"text":287,"config":328},{"href":289,"dataGaName":290,"dataGaLocation":43},{"text":330,"config":331},"Leadership",{"href":332,"dataGaName":333,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":335,"config":336},"Team",{"href":337,"dataGaName":338,"dataGaLocation":43},"/company/team/","team",{"text":340,"config":341},"Handbook",{"href":342,"dataGaName":343,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":345,"config":346},"Investor relations",{"href":347,"dataGaName":348,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":350,"config":351},"Trust Center",{"href":352,"dataGaName":353,"dataGaLocation":43},"/security/","trust center",{"text":355,"config":356},"AI Transparency Center",{"href":357,"dataGaName":358,"dataGaLocation":43},"/ai-transparency-center/","ai transparency center",{"text":360,"config":361},"Newsletter",{"href":362,"dataGaName":363,"dataGaLocation":43},"/company/contact/","newsletter",{"text":365,"config":366},"Press",{"href":367,"dataGaName":368,"dataGaLocation":43},"/press/","press",{"text":370,"config":371,"lists":372},"Contact us",{"dataNavLevelOne":312},[373],{"items":374},[375,378,383],{"text":50,"config":376},{"href":52,"dataGaName":377,"dataGaLocation":43},"talk to sales",{"text":379,"config":380},"Support portal",{"href":381,"dataGaName":382,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":384,"config":385},"Customer portal",{"href":386,"dataGaName":387,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":389,"login":390,"suggestions":397},"Close",{"text":391,"link":392},"To search repositories and projects, login to",{"text":393,"config":394},"gitlab.com",{"href":57,"dataGaName":395,"dataGaLocation":396},"search login","search",{"text":398,"default":399},"Suggestions",[400,402,406,408,412,416],{"text":72,"config":401},{"href":77,"dataGaName":72,"dataGaLocation":396},{"text":403,"config":404},"Code Suggestions (AI)",{"href":405,"dataGaName":403,"dataGaLocation":396},"/solutions/code-suggestions/",{"text":21,"config":407},{"href":124,"dataGaName":21,"dataGaLocation":396},{"text":409,"config":410},"GitLab on AWS",{"href":411,"dataGaName":409,"dataGaLocation":396},"/partners/technology-partners/aws/",{"text":413,"config":414},"GitLab on Google Cloud",{"href":415,"dataGaName":413,"dataGaLocation":396},"/partners/technology-partners/google-cloud-platform/",{"text":417,"config":418},"Why GitLab?",{"href":85,"dataGaName":417,"dataGaLocation":396},{"freeTrial":420,"mobileIcon":425,"desktopIcon":430,"secondaryButton":433},{"text":421,"config":422},"Start free trial",{"href":423,"dataGaName":48,"dataGaLocation":424},"https://gitlab.com/-/trials/new/","nav",{"altText":426,"config":427},"Gitlab Icon",{"src":428,"dataGaName":429,"dataGaLocation":424},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":426,"config":431},{"src":432,"dataGaName":429,"dataGaLocation":424},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":434,"config":435},"Get Started",{"href":436,"dataGaName":437,"dataGaLocation":424},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":439,"mobileIcon":443,"desktopIcon":445},{"text":440,"config":441},"Learn more about GitLab Duo",{"href":77,"dataGaName":442,"dataGaLocation":424},"gitlab duo",{"altText":426,"config":444},{"src":428,"dataGaName":429,"dataGaLocation":424},{"altText":426,"config":446},{"src":432,"dataGaName":429,"dataGaLocation":424},{"freeTrial":448,"mobileIcon":453,"desktopIcon":455},{"text":449,"config":450},"Back to pricing",{"href":202,"dataGaName":451,"dataGaLocation":424,"icon":452},"back to pricing","GoBack",{"altText":426,"config":454},{"src":428,"dataGaName":429,"dataGaLocation":424},{"altText":426,"config":456},{"src":432,"dataGaName":429,"dataGaLocation":424},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":462,"_dir":37,"_draft":6,"_partial":6,"_locale":7,"title":463,"button":464,"image":469,"config":473,"_id":475,"_type":29,"_source":31,"_file":476,"_stem":477,"_extension":34},"/shared/en-us/banner","is now in public beta!",{"text":465,"config":466},"Try the Beta",{"href":467,"dataGaName":468,"dataGaLocation":43},"/gitlab-duo/agent-platform/","duo banner",{"altText":470,"config":471},"GitLab Duo Agent Platform",{"src":472},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":474},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":479,"_dir":37,"_draft":6,"_partial":6,"_locale":7,"data":480,"_id":718,"_type":29,"title":719,"_source":31,"_file":720,"_stem":721,"_extension":34},"/shared/en-us/main-footer",{"text":481,"source":482,"edit":488,"contribute":493,"config":498,"items":503,"minimal":710},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":483,"config":484},"View page source",{"href":485,"dataGaName":486,"dataGaLocation":487},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":489,"config":490},"Edit this page",{"href":491,"dataGaName":492,"dataGaLocation":487},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":494,"config":495},"Please contribute",{"href":496,"dataGaName":497,"dataGaLocation":487},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":499,"facebook":500,"youtube":501,"linkedin":502},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[504,551,603,647,676],{"title":200,"links":505,"subMenu":520},[506,510,515],{"text":507,"config":508},"View plans",{"href":202,"dataGaName":509,"dataGaLocation":487},"view plans",{"text":511,"config":512},"Why Premium?",{"href":513,"dataGaName":514,"dataGaLocation":487},"/pricing/premium/","why premium",{"text":516,"config":517},"Why Ultimate?",{"href":518,"dataGaName":519,"dataGaLocation":487},"/pricing/ultimate/","why ultimate",[521],{"title":522,"links":523},"Contact Us",[524,527,529,531,536,541,546],{"text":525,"config":526},"Contact sales",{"href":52,"dataGaName":53,"dataGaLocation":487},{"text":379,"config":528},{"href":381,"dataGaName":382,"dataGaLocation":487},{"text":384,"config":530},{"href":386,"dataGaName":387,"dataGaLocation":487},{"text":532,"config":533},"Status",{"href":534,"dataGaName":535,"dataGaLocation":487},"https://status.gitlab.com/","status",{"text":537,"config":538},"Terms of use",{"href":539,"dataGaName":540,"dataGaLocation":487},"/terms/","terms of use",{"text":542,"config":543},"Privacy statement",{"href":544,"dataGaName":545,"dataGaLocation":487},"/privacy/","privacy statement",{"text":547,"config":548},"Cookie preferences",{"dataGaName":549,"dataGaLocation":487,"id":550,"isOneTrustButton":25},"cookie preferences","ot-sdk-btn",{"title":105,"links":552,"subMenu":560},[553,557],{"text":554,"config":555},"DevSecOps platform",{"href":70,"dataGaName":556,"dataGaLocation":487},"devsecops platform",{"text":126,"config":558},{"href":77,"dataGaName":559,"dataGaLocation":487},"ai-assisted development",[561],{"title":562,"links":563},"Topics",[564,569,574,579,584,588,593,598],{"text":565,"config":566},"CICD",{"href":567,"dataGaName":568,"dataGaLocation":487},"/topics/ci-cd/","cicd",{"text":570,"config":571},"GitOps",{"href":572,"dataGaName":573,"dataGaLocation":487},"/topics/gitops/","gitops",{"text":575,"config":576},"DevOps",{"href":577,"dataGaName":578,"dataGaLocation":487},"/topics/devops/","devops",{"text":580,"config":581},"Version Control",{"href":582,"dataGaName":583,"dataGaLocation":487},"/topics/version-control/","version control",{"text":22,"config":585},{"href":586,"dataGaName":587,"dataGaLocation":487},"/topics/devsecops/","devsecops",{"text":589,"config":590},"Cloud Native",{"href":591,"dataGaName":592,"dataGaLocation":487},"/topics/cloud-native/","cloud native",{"text":594,"config":595},"AI for Coding",{"href":596,"dataGaName":597,"dataGaLocation":487},"/topics/devops/ai-for-coding/","ai for coding",{"text":599,"config":600},"Agentic AI",{"href":601,"dataGaName":602,"dataGaLocation":487},"/topics/agentic-ai/","agentic ai",{"title":604,"links":605},"Solutions",[606,608,610,615,619,622,626,629,631,634,637,642],{"text":147,"config":607},{"href":142,"dataGaName":147,"dataGaLocation":487},{"text":136,"config":609},{"href":119,"dataGaName":120,"dataGaLocation":487},{"text":611,"config":612},"Agile development",{"href":613,"dataGaName":614,"dataGaLocation":487},"/solutions/agile-delivery/","agile delivery",{"text":616,"config":617},"SCM",{"href":132,"dataGaName":618,"dataGaLocation":487},"source code management",{"text":565,"config":620},{"href":124,"dataGaName":621,"dataGaLocation":487},"continuous integration & delivery",{"text":623,"config":624},"Value stream management",{"href":175,"dataGaName":625,"dataGaLocation":487},"value stream management",{"text":570,"config":627},{"href":628,"dataGaName":573,"dataGaLocation":487},"/solutions/gitops/",{"text":185,"config":630},{"href":187,"dataGaName":188,"dataGaLocation":487},{"text":632,"config":633},"Small business",{"href":192,"dataGaName":193,"dataGaLocation":487},{"text":635,"config":636},"Public sector",{"href":197,"dataGaName":198,"dataGaLocation":487},{"text":638,"config":639},"Education",{"href":640,"dataGaName":641,"dataGaLocation":487},"/solutions/education/","education",{"text":643,"config":644},"Financial services",{"href":645,"dataGaName":646,"dataGaLocation":487},"/solutions/finance/","financial services",{"title":205,"links":648},[649,651,653,655,658,660,662,664,666,668,670,672,674],{"text":217,"config":650},{"href":219,"dataGaName":220,"dataGaLocation":487},{"text":222,"config":652},{"href":224,"dataGaName":225,"dataGaLocation":487},{"text":227,"config":654},{"href":229,"dataGaName":230,"dataGaLocation":487},{"text":232,"config":656},{"href":234,"dataGaName":657,"dataGaLocation":487},"docs",{"text":255,"config":659},{"href":257,"dataGaName":5,"dataGaLocation":487},{"text":250,"config":661},{"href":252,"dataGaName":253,"dataGaLocation":487},{"text":259,"config":663},{"href":261,"dataGaName":262,"dataGaLocation":487},{"text":272,"config":665},{"href":274,"dataGaName":275,"dataGaLocation":487},{"text":264,"config":667},{"href":266,"dataGaName":267,"dataGaLocation":487},{"text":277,"config":669},{"href":279,"dataGaName":280,"dataGaLocation":487},{"text":282,"config":671},{"href":284,"dataGaName":285,"dataGaLocation":487},{"text":287,"config":673},{"href":289,"dataGaName":290,"dataGaLocation":487},{"text":292,"config":675},{"href":294,"dataGaName":295,"dataGaLocation":487},{"title":310,"links":677},[678,680,682,684,686,688,690,694,699,701,703,705],{"text":317,"config":679},{"href":319,"dataGaName":312,"dataGaLocation":487},{"text":322,"config":681},{"href":324,"dataGaName":325,"dataGaLocation":487},{"text":330,"config":683},{"href":332,"dataGaName":333,"dataGaLocation":487},{"text":335,"config":685},{"href":337,"dataGaName":338,"dataGaLocation":487},{"text":340,"config":687},{"href":342,"dataGaName":343,"dataGaLocation":487},{"text":345,"config":689},{"href":347,"dataGaName":348,"dataGaLocation":487},{"text":691,"config":692},"Sustainability",{"href":693,"dataGaName":691,"dataGaLocation":487},"/sustainability/",{"text":695,"config":696},"Diversity, inclusion and belonging (DIB)",{"href":697,"dataGaName":698,"dataGaLocation":487},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":350,"config":700},{"href":352,"dataGaName":353,"dataGaLocation":487},{"text":360,"config":702},{"href":362,"dataGaName":363,"dataGaLocation":487},{"text":365,"config":704},{"href":367,"dataGaName":368,"dataGaLocation":487},{"text":706,"config":707},"Modern Slavery Transparency Statement",{"href":708,"dataGaName":709,"dataGaLocation":487},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":711},[712,714,716],{"text":537,"config":713},{"href":539,"dataGaName":540,"dataGaLocation":487},{"text":542,"config":715},{"href":544,"dataGaName":545,"dataGaLocation":487},{"text":547,"config":717},{"dataGaName":549,"dataGaLocation":487,"id":550,"isOneTrustButton":25},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",[723,735],{"_path":724,"_dir":725,"_draft":6,"_partial":6,"_locale":7,"content":726,"config":730,"_id":732,"_type":29,"title":14,"_source":31,"_file":733,"_stem":734,"_extension":34},"/en-us/blog/authors/william-arias","authors",{"name":14,"config":727},{"headshot":728,"ctfId":729},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667549/Blog/Author%20Headshots/warias-headshot.jpg","warias",{"template":731},"BlogAuthor","content:en-us:blog:authors:william-arias.yml","en-us/blog/authors/william-arias.yml","en-us/blog/authors/william-arias",{"_path":736,"_dir":725,"_draft":6,"_partial":6,"_locale":7,"content":737,"config":741,"_id":742,"_type":29,"title":15,"_source":31,"_file":743,"_stem":744,"_extension":34},"/en-us/blog/authors/daniel-helfand",{"name":15,"config":738},{"headshot":739,"ctfId":740},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662418/Blog/Author%20Headshots/dhelfand.png","b9sRP0HJhdPsOEruWUfih",{"template":731},"content:en-us:blog:authors:daniel-helfand.yml","en-us/blog/authors/daniel-helfand.yml","en-us/blog/authors/daniel-helfand",{"_path":746,"_dir":37,"_draft":6,"_partial":6,"_locale":7,"header":747,"eyebrow":748,"blurb":749,"button":750,"secondaryButton":754,"_id":756,"_type":29,"title":757,"_source":31,"_file":758,"_stem":759,"_extension":34},"/shared/en-us/next-steps","Start shipping better software faster","50%+ of the Fortune 100 trust GitLab","See what your team can do with the intelligent\n\n\nDevSecOps platform.\n",{"text":45,"config":751},{"href":752,"dataGaName":48,"dataGaLocation":753},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":50,"config":755},{"href":52,"dataGaName":53,"dataGaLocation":753},"content:shared:en-us:next-steps.yml","Next Steps","shared/en-us/next-steps.yml","shared/en-us/next-steps",{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":761,"content":763,"config":766,"_id":28,"_type":29,"title":30,"_source":31,"_file":32,"_stem":33,"_extension":34},{"config":762,"title":10,"description":11},{"noIndex":6},{"title":10,"description":11,"authors":764,"heroImage":16,"date":17,"body":18,"category":19,"tags":765},[14,15],[21,22,23],{"featured":25,"template":26,"slug":27},1761814440152]