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:
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:
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:
Move your shared CI files (scripts, configs, etc.) into a separate Git repo.
In each project, add the submodule:
git submodule add https://gitlab.com/your-group/ci-templates.git CI
git add .gitmodules CI
git commit -m "Add CI submodule"
git submodule update --init --recursive
Benefits:
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:
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:
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.
1.0.2
3.32.34
3.45.12-SNAPSHOT
These are typical semantic version numbers and may optionally include a suffix like -SNAPSHOT
.
^\d+\.\d+\.\d+(?:-SNAPSHOT)?$
^
— 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 string1.0.2
3.32.34
3.45.12-SNAPSHOT
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 Wayrules:
is the recommended and more powerful approach. It lets you control job execution using:
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 Filteronly:
is simpler but limited. It matches jobs based on:
It cannot check file changes or commit messages.
Example:
only:
- /^feature\/.*$/
- main
- dev
Use rules:
for:
Stick with only:
only for very simple setups or when updating legacy code.
Behind Nvidia’s AI dominance is a software platform most people have never heard of — CUDA. Created in 2004 by Ian Buck, CUDA began as a side project and turned into a secret weapon that powers everything from ChatGPT to cutting-edge robotics.
While rivals focus on building faster chips, CUDA gives Nvidia something harder to copy: an ecosystem. With over 900 libraries and deep adoption across industries, it’s why 90% of AI workloads run on Nvidia hardware today. Buck, once a startup founder, now leads the team defending and evolving this strategic edge — and some say he may even be in line to lead Nvidia next.
Curious how one quiet innovation shaped the future of AI?
Read the full story at Meet Ian Buck, the Architect of CUDA, Nvidia's $3.5 Trillion Moat - Business Insider
Open source software (OSS) has evolved from a niche hobby to the backbone of mission-critical systems—from cloud infrastructure to AI platforms and government services. Today, embracing OSS isn’t optional; it’s a strategic choice offering several key benefits:
However, businesses must also navigate challenges: support isn’t automatic (so consider vendor-backed services), choose active and well-governed projects, and understand licensing implications before adoption .
By forging smart open source strategies—engaging with communities, investing in support, and contributing back—companies can accelerate growth, control costs, and stay ahead in an evolving digital landscape.
Original link: https://towardsdatascience.com/why-open-source-is-no-longer-optional-and-how-to-make-it-work-for-your-business/
When writing YAML scripts for CI/CD pipelines, it's important to use the correct file path format and handle special characters properly. A common issue developers face is using Windows-style backslashes (\
) in paths, which YAML and many tools like Visual Studio interpret as escape characters. Another is forgetting to quote paths that contain special characters like *
.
To avoid these issues, follow these simple practices.
Always use forward slashes /
in your paths. This format works on all platforms and avoids YAML parsing errors.
Instead of: {project}\publish\bin
Use:
{project}/publish/bin
If your path includes special characters such as *
, wrap the string in double quotes. This tells YAML to treat the entire string as a literal value, not as a command or reference.
Correct usage:
"{project}/publish/bin/*"
These small adjustments help make your YAML files more robust and portable.