instruction: Give practical examples of github-actions gitlab-ci implementation
output: Help us learn about your current experience with the documentation. Take the survey . CI/CD pipelines Tier : Free, Premium, Ultimate Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated CI/CD pipelines are the fundamental component of GitLab CI/CD. Pipelines are configured in a .gitlab-ci.yml file by using YAML keywords . Pipelines can run automatically for specific events, like when pushing to a branch, creating a merge request, or on a schedule. When needed, you can also run pipelines manually. Pipelines are composed of: Global YAML keywords that control the overall behavior of the project’s pipelines. Jobs that execute commands to accomplish a task. For example, a job could compile, test, or deploy code. Jobs run independently from each other, and are executed by runners . Stages, which define how to group jobs together. Stages run in sequence, while the jobs in a stage run in parallel. For example, an early stage could have jobs that lint and compile code, while later stages could have jobs that test and deploy code. If all jobs in a stage succeed, the pipeline moves on to the next stage. If any job in a stage fails, the next stage is not (usually) executed and the pipeline ends early. A small pipeline could consist of three stages, executed in the following order: A build stage, with a job called compile that compiles the project’s code. A test stage, with two jobs called test1 and test2 that run various tests on the code. These tests would only run if the compile job completed successfully. A deploy stage, with a job called deploy-to-production . This job would only run if both jobs in the test stage started and completed successfully. To get started with your first pipeline, see Create and run your first GitLab CI/CD pipeline . Types of pipelines Pipelines can be configured in many different ways: Basic pipelines run everything in each stage concurrently, followed by the next stage. Pipelines that use the needs keyword run based on dependencies between jobs and can run more quickly than basic pipelines. Merge request pipelines run for merge requests only (rather than for every commit). Merged results pipelines are merge request pipelines that act as though the changes from the source branch have already been merged into the target branch. Merge trains use merged results pipelines to queue merges one after the other. Parent-child pipelines break down complex pipelines into one parent pipeline that can trigger multiple child sub-pipelines, which all run in the same project and with the same SHA. This pipeline architecture is commonly used for mono-repos. Multi-project pipelines combine pipelines for different projects together. Configure a pipeline Pipelines and their component jobs and stages are defined with YAML keywords in the CI/CD pipeline configuration file for each project. When editing CI/CD configuration in GitLab, you should use the pipeline editor . You can also configure specific aspects of your pipelines through the GitLab UI: Pipeline settings for each project. Pipeline schedules . Custom CI/CD variables . If you use VS Code to edit your GitLab CI/CD configuration, the GitLab Workflow extension for VS Code helps you validate your configuration and view your pipeline status . Run a pipeline manually History Run pipeline name changed to New pipeline in GitLab 17.7. Inputs option introduced in GitLab 17.11 with a flag named ci_inputs_for_pipelines . Enabled by default. Inputs option generally available in GitLab 18.1. Feature flag ci_inputs_for_pipelines removed. Pipelines can be manually executed, with predefined or manually-specified variables . You might do this if the results of a pipeline (for example, a code build) are required outside the standard operation of the pipeline. To execute a pipeline manually: On the left sidebar, select Search or go to and find your project. Select Build > Pipelines . Select New pipeline . In the Run for branch name or tag field, select the branch or tag to run the pipeline for. (Optional) Enter any: Inputs required for the pipeline to run. Default values for inputs are prefilled, but can be modified. Input values must follow the expected type. CI/CD variables . You can configure variables to have their values prefilled in the form . Using inputs to control pipeline behavior offers improved security and flexibility over CI/CD variables. Select New pipeline . The pipeline now executes the jobs as configured. View manual pipeline variables History Introduced in GitLab 17.2 with a flag named ci_show_manual_variables_in_pipeline . Disabled by default. Generally available in GitLab 18.4 with a project setting. Feature flag ci_show_manual_variables_in_pipeline removed. You can see all variables that are specified when the pipeline runs manually. Prerequisites: You must have the Owner role for the project. The required role depends on what you want to do: Action Minimum role View variable names Guest View variable values Developer Configure visibility setting Owner When you turn on this setting, users with the Developer role can view variable values that might contain sensitive information from any manual pipeline run. For sensitive data like credentials or tokens, use protected variables or external secrets management instead of manual pipeline variables. To view manual pipeline variables: On the left sidebar, select Search or go to and find your project. Select Settings > CI/CD . Select Display pipeline variables . Go to Build > Pipelines and select a pipeline that was run manually. Select the Manual Variables tab. Variable values are masked by default. If you have the Developer role or higher, you can select the eye icon to reveal values. Prefill variables in manual pipelines History Markdown rendering on the Run pipeline page Introduced in GitLab 17.11. You can use the description and value keywords to define pipeline-level (global) variables that are prefilled when running a pipeline manually. Use the description to explain information such as what the variable is used for, and what the acceptable values are. You can use Markdown in the description. Job-level variables cannot be pre-filled. In manually-triggered pipelines, the New pipeline page displays all pipeline-level variables that have a description defined in the .gitlab-ci.yml file. The description displays below the variable. You can change the prefilled value, which overrides the value for that single pipeline run. Any variables overridden by using this process are expanded and not masked . If you do not define a value for the variable in the configuration file, the variable name is still listed, but the value field is blank. For example: variables : DEPLOY_CREDENTIALS : description : "The deployment credentials." DEPLOY_ENVIRONMENT : description : "Select the deployment target. Valid options are: 'canary', 'staging', 'production', or a stable branch of your choice." value : "canary" In this example: DEPLOY_CREDENTIALS is listed in the New pipeline page, but with no value set. The user is expected to define the value each time the pipeline is run manually. DEPLOY_ENVIRONMENT is pre-filled in the New pipeline page with canary as the default value, and the message explains the other options. Because of a known issue , projects that use compliance pipelines can have prefilled variables not appear when running a pipeline manually. To workaround this issue, change the compliance pipeline configuration . Configure a list of selectable prefilled variable values History Introduced in GitLab 15.5 with a flag named run_pipeline_graphql . Disabled by default. The options keyword was introduced in GitLab 15.7. Generally available in GitLab 15.7. Feature flag run_pipeline_graphql removed. The variables list sometimes did not populate correctly due to a bug , which was resolved in GitLab 15.9. You can define an array of CI/CD variable values the user can select from when running a pipeline manually. These values are in a dropdown list in the New pipeline page. Add the list of value options to options and set the default value with value . The string in value must also be included in the options list. For example: variables : DEPLOY_ENVIRONMENT : value : "staging" options : - "production" - "staging" - "canary" description : "The deployment target. Set to 'staging' by default." Run a pipeline by using a URL query string You can use a query string to pre-populate the New pipeline page. For example, the query string .../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar pre-populates the New pipeline page with: Run for field: my_branch . Variables section: Variable: Key: foo Value: bar File: Key: file_foo Value: file_bar The format of the pipelines/new URL is: .../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value> The following parameters are supported: ref : specify the branch to populate the Run for field with. var : specify a Variable variable. file_var : specify a File variable. For each var or file_var , a key and value are required. Add manual interaction to your pipeline Manual jobs , allow you to require manual interaction before moving forward in the pipeline. You can do this straight from the pipeline graph. Select Run ( play ) to execute that particular job. For example, your pipeline can start automatically, but require a manual action to deploy to production . In the following example, the production stage has a job with a manual action: Start all manual jobs in a stage If a stage contains only manual jobs, you can start all the jobs at the same time by selecting Run all manual ( play ) above the stage. If the stage contains non-manual jobs, the option is not displayed. Skip a pipeline To push a commit without triggering a pipeline, add [ci skip] or [skip ci] , using any capitalization, to your commit message. Alternatively, with Git 2.10 or later, use the ci.skip Git push option . The ci.skip push option does not skip merge request pipelines. Delete a pipeline Users with the Owner role for a project can delete a pipeline: On the left sidebar, select Search or go to and find your project. Select Build > Pipelines . Select either the pipeline ID (for example #123456789 ) or the pipeline status icon (for example Passed ) of the pipeline to delete. In the top right of the pipeline details page, select Delete . Deleting a pipeline does not automatically delete its child pipelines . See issue 39503 for more details. Deleting a pipeline expires all pipeline caches, and deletes all immediately related objects, such as jobs, logs, artifacts, and triggers. This action cannot be undone . Pipeline security on protected branches A strict security model is enforced when pipelines are executed on protected branches . The following actions are allowed on protected branches if the user is allowed to merge or push to that specific branch: Run manual pipelines (using the Web UI or pipelines API ). Run scheduled pipelines. Run pipelines using triggers. Run on-demand DAST scan. Trigger manual actions on existing pipelines. Retry or cancel existing jobs (using the Web UI or pipelines API). Variables marked as protected are accessible to jobs that run in pipelines for protected branches. Only assign users the right to merge to protected branches if they have permission to access sensitive information like deployment credentials and tokens. Runners marked as protected can run jobs only on protected branches, preventing untrusted code from executing on the protected runner and preserving deployment keys and other credentials from being unintentionally accessed. To ensure that jobs intended to be executed on protected runners do not use regular runners, they must be tagged accordingly. Review the documentation to understand how access to protected variables and runners work in the context of Merge request pipelines. Review the deployment safety page for additional security recommendations for securing your pipelines. Trigger a pipeline when an upstream project is rebuilt (deprecated) Tier : Premium, Ultimate Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated This feature was deprecated in GitLab 17.6 and is planned for removal in 19.0. Use CI/CD jobs with pipeline trigger tokens instead. This is a breaking change. You can set up your project to automatically trigger a pipeline based on tags in a different project. When a new tag pipeline in the