Snipps

When working with GitLab CI/CD, workflow:rules help control whether a pipeline should run at all. It’s important to understand how these rules work because they differ from regular job rules, especially when it comes to supported syntax.

✅ What You Can Do in workflow:rules

• Use basic comparisons like == or !=
• Use logical conditions with && and ||
• Use functions like startsWith($VARIABLE, "value")
• Use $CI_COMMIT_BRANCH, $CI_COMMIT_TAG, and similar predefined variables
• Wrap the full condition in single quotes

Example:

workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main" || startsWith($CI_COMMIT_BRANCH, "feature/")'
      when: always
    - when: never

❌ What You Can’t Do in workflow:rules

• No regular expressions (e.g., =~ /pattern/) — these only work in job-level rules
• No complex YAML syntax like nested objects inside if
• No unquoted expressions — always quote the full condition

💡 Pro Tip:

If you need to skip certain runs based on the commit message (e.g., [nopublish]), do that inside job rules, not workflow:rules.

some_job:
  rules:
    - if: '$CI_COMMIT_MESSAGE =~ /\\[nopublish\\]/'
      when: never
    - when: always

Conclusion

Use workflow:rules to define when a pipeline runs, based on simple branch or tag conditions. Keep regex and detailed logic in job-level rules to avoid syntax errors.

If you're using ChatGPT and can't find a conversation you previously had, you might wonder whether it was archived and how to get it back. Here's a quick guide to understanding how ChatGPT handles old chats and how to find them again.

Where Are Archived Chats?

ChatGPT doesn’t currently have a separate “Archived” section like some messaging apps. However, chats you’ve had are saved automatically unless you manually delete them.

Here’s how to access them:

• On Desktop (chat.openai.com):

1. 1. Log in to your account.
   2. Use the search bar at the top of the left sidebar.
   3. Type keywords from your previous chat to bring it up.

• On Mobile App:

1. 1. Open the ChatGPT app.
   2. Tap the menu (☰) or swipe from the left.
   3. Use the search function to look through older chats.

Things to Keep in Mind

• Archived chats are not truly "hidden" — they're just not pinned or recent.
• If you deleted a chat, it’s gone permanently.
• Make sure you're logged into the correct account, especially if you’ve used multiple sign-in methods (like Apple ID, Google, or email).

There’s no “Archived” folder in ChatGPT, but you can use the search tool to find older chats. Deleted chats can’t be restored, but if not deleted, they remain available through the search feature.

When building CI pipelines in GitLab for multiple projects, you often need to pass a list of project names to a script. However, GitLab CI doesn’t support arrays as environment variables. The best solution is to pass the values as a comma-separated string and split them inside your PowerShell script. This method is clean, compatible, and easy to maintain.

Implementation

Step 1: Define the project list as a CSV string in .gitlab-ci.yml

variables:
  PROJECT_NAMES: "ProjectA,ProjectB,ProjectC"

Step 2: Pass it as a parameter to the PowerShell script

script:
  - powershell -ExecutionPolicy Bypass -File .\Create-Pipeline.ps1 -projectNamesRaw "$env:PROJECT_NAMES"

Step 3: Process the string inside the PowerShell script

param(
    [Parameter(Mandatory)]
    [string]$projectNamesRaw
)

# Split and trim project names into an array
$projectNames = $projectNamesRaw -split ',' | ForEach-Object { $_.Trim() }

foreach ($projectName in $projectNames) {
    Write-Output "Processing project: $projectName"
    # Your logic here
}

Why This Works

• GitLab treats all variables as strings, so this approach avoids format issues
• -split creates an array inside PowerShell
• Trim() ensures clean names even with extra spaces

You can fetch scripts during the CI job using curl or wget. This allows you to avoid submodules or includes, especially when you just need to run a script without checking it into your repo.

Example:

variables:
  CI_SCRIPTS_BASE_URL: "https://gitlab.com/your-group/ci-templates/-/raw/main/CI"

before_script:
  - mkdir -p CI
  - curl -sSL -o CI/setup.ps1 "$CI_SCRIPTS_BASE_URL/setup.ps1"
  - curl -sSL -o CI/config.xml "$CI_SCRIPTS_BASE_URL/config.xml"

Advantages:

• Simple and flexible
• Works even if the shared files are in a private repo (with token)

When to use: If you want a lightweight setup without managing submodules.

GitLab allows you to include .gitlab-ci.yml files from other repositories. This is a powerful way to reuse pipeline templates across projects.

How it works:

include:
  - project: 'your-group/ci-templates'
    ref: 'main'
    file: '/CI/jobs.yml'

Limitations:

• Only works with YAML files (not PowerShell, XML, etc.)
• Files must be structured as valid GitLab CI YAML

Best for: Reusing standard pipeline jobs or templates.

Using Git submodules is a clean way to share CI scripts between projects. You create a separate repository for your shared CI folder and link it as a submodule inside each project.

Steps:

1. Move your shared CI files (scripts, configs, etc.) into a separate Git repo.

2. In each project, add the submodule:

   git submodule add https://gitlab.com/your-group/ci-templates.git CI

3. Commit the changes:
   

   git add .gitmodules CI
   git commit -m "Add CI submodule"

4. Update submodules when cloning:
   

   git submodule update --init --recursive

Benefits:

• Keeps scripts version-controlled and consistent
• Easy to manage changes centrally

Use this when: You want full access to the CI folder and version control it tightly.

Managing CI/CD scripts and configurations across multiple projects can quickly become a challenge. Repeating the same files and logic leads to maintenance overhead and inconsistency. This Snipp explores how to centralize your CI scripts and use them across different GitLab projects, using reliable and maintainable techniques.

This guide introduces three practical approaches:

• Git submodules
• GitLab includes
• Downloading scripts at runtime

Each method suits different use cases, and this Snipp Set helps you choose the right one and implement it cleanly.

When writing scripts in YAML (such as for Azure DevOps pipelines), using colons : inside commands like Write-Host can sometimes trigger validation warnings in tools like Visual Studio.

This happens because YAML uses colons to define key-value pairs, and it may confuse your script as malformed YAML if colons aren't properly handled.

Here's how to avoid the issue:

✔️ Recommended Solutions

1. Use multi-line block with |
Best for longer scripts or when readability matters.

steps:
  - powershell: |
      Write-Host "Value is: 42"

2. Quote single-line scripts
Wrap the whole command in single or double quotes.

steps:
  - script: "Write-Host 'Value is: 42'"
    displayName: 'Print Value'

❌ Avoid this pattern:

steps:
  - script: Write-Host "Value is: 42"  # ❌ Unquoted colon — may cause YAML error

When working with software versions like 1.0.2 or 3.45.12-SNAPSHOT, it's common to use regular expressions (regex) to validate or extract these patterns. This Snipp shows you a simple and effective way to match such version numbers using regex.

What We Want to Match:

• 1.0.2
• 3.32.34
• 3.45.12-SNAPSHOT

These are typical semantic version numbers and may optionally include a suffix like -SNAPSHOT.

The Regex:

^\d+\.\d+\.\d+(?:-SNAPSHOT)?$

How It Works:

• ^ — Start of the string
• \d+ — One or more digits (major, minor, patch)
• \. — Dots separating version parts
• (?:-SNAPSHOT)? — Optional suffix (non-capturing group)
• $ — End of the string

Matches:

• ✔️ 1.0.2
• ✔️3.32.34
• ✔️3.45.12-SNAPSHOT

Not Matched:

• ❌ 1.0
• ❌3.2.4-RELEASE
• ❌a.b.c

This pattern is useful when validating software version inputs in forms, logs, or build scripts.

When configuring GitLab CI/CD pipelines, two common keywords—rules: and only:—determine when a job should run. While they can seem similar, they have key differences in flexibility and functionality.

rules: – The Modern Way

rules: is the recommended and more powerful approach. It lets you control job execution using:

• Branch names
• File changes
• Commit messages
• Environment variables
• Custom conditions (when: never, when: manual, etc.)

Example:

rules:
  - if: $CI_COMMIT_BRANCH =~ /^feature|issue\/.*$/
    changes:
      - global.json
      - src/**/*
  - if: $CI_COMMIT_BRANCH == "dev" && $CI_COMMIT_MESSAGE =~ /\[nopublish\]/
    when: never

Tipp: To detect changes to a file in the repo's root (like global.json), just add the filename without a path:

only: – The Legacy Filter

only: is simpler but limited. It matches jobs based on:

• Branches
• Tags
• Pipelines from merge requests

It cannot check file changes or commit messages.

Example:

only:
  - /^feature\/.*$/
  - main
  - dev

Best Practice

Use rules: for:

• Complex logic
• File or folder-based triggers
• Future-proofing pipelines

Stick with only: only for very simple setups or when updating legacy code.