In a CI/CD pipeline, what is the main reason to trigger deployments based on Git tags instead of branches?
Think about why tags are used to mark releases.
Tags are used to mark specific commits, often releases. Triggering deployments on tags ensures only stable, versioned code is deployed.
Given the following command, what will it output?
git tag --list "v1.*"
Assume the repository has tags: v1.0, v1.1, v2.0, v1.2-beta, v1.3
Check how the wildcard * works in tag filtering.
The glob pattern "v1.*" matches tags starting with 'v1.' followed by any characters: v1.0, v1.1, v1.2-beta, v1.3. v2.0 does not match.
Choose the correct GitLab CI YAML snippet that triggers the deploy job only when a tag starts with 'release-'.
Look for the syntax that supports regex matching on tags.
GitLab CI uses 'rules' with 'if' conditions to match regex on tags. Option A correctly triggers deploy only on tags starting with 'release-'.
A Jenkins pipeline is configured to trigger on tags, but deployments do not start when new tags are pushed. Which is the most likely cause?
Check webhook settings for event types.
Jenkins webhooks must be configured to listen for tag push events. If only branch pushes trigger, tags won't start deployments.
Arrange the steps in the correct order to enable deployment triggers from Git tags.
Think about configuring before pushing tags.
First configure the pipeline to listen for tags, then write job rules, push the tag, and finally verify deployment.