r/gitlab

I built a CLI tool called glsec that statically analyzes .gitlab-ci.yml files for security misconfigurations. Think of zizmor or actionlint, but for GitLab CI.

It catches things like:

• Script injection via user-controlled variables (e.g. $CI_COMMIT_MESSAGE)
• Mutable or unpinned image tags (e.g. image: node:latest)
• Hardcoded secrets in variables
• curl | bash in script blocks - remote code execution without integrity check

It maps findings to OWASP CI/CD Security Risks.

Still early days, but already 50 rules and growing. I'd love feedback on what you're seeing in the wild and contributions are very welcome if you want to add rules or improve coverage.

Are there other tools you use for CI/CD pipeline security that I should know about?

Hey everyone,
l've been a developer for a while now and I kept running into the same problem - I had dozens of repos, half-built projects, and scattered scripts sitting in GitHub doing nothing. Every time I wanted to start something new, I'd think "I feel like I've already built part of this somewhere..." but I never knew where.
So 1 built RepoFuse.
What it does:
RepoFuse connects to your GitHub, scans your existing repositories, and uses Al to surface buildable product ideas based on what you've already written.
Instead of starting from scratch, it finds the patterns, modules, and logic you've already built — and shows you what you're closer to shipping than you think.
Who it's for:
Solo devs and indie hackers sitting on a graveyard of half-finished projects
Dev teams who want to extract more value from
their existing codebase
• Non-technical founders working with developers who want to understand what's already been built
Why I built it:
Most "idea generators" give you generic SaaS ideas with no connection to your actual skills or existing work. RepoFuse is different — every idea it surfaces is grounded in code you've already written. It's not guessing. It's analyzing.
Where it's at:
RepoFuse is fully launched and live. You can con V your GitHub and get your first analysis today.

https://repofuse.com

Hey everyone,
l've been a developer for a while now and I kept running into the same problem - I had dozens of repos, half-built projects, and scattered scripts sitting in GitHub doing nothing. I have shipped many products, all with near zero performance… this time I believe I finally created something great. Maybe even life changing.. hopefully for the users, not just me!!

Every time I wanted to start something new, I'd think "I feel like I've already built part of this somewhere..." but I never knew where.
So 1 built RepoFuse.

What it does:
RepoFuse connects to your GitHub, GitLab, scans your existing repositories, and uses Al to surface buildable product ideas based on what you've already written. THEN GIVES YOU THE MISSING CODE. Now, All you have to do to finish that half finished project you gave up on months ago is download the missing code & put it into GitHub/Gitlab.

Who it's for:

Solo devs and indie hackers sitting on a graveyard of half-finished projects
Dev teams who want to extract more value from
their existing codebase
• Non-technical founders working with developers who want to understand what's already been built
Why I built it:
Most "idea generators" give you generic SaaS ideas with no connection to your actual skills or existing work. RepoFuse is different — every idea it surfaces is grounded in code you've already written. It's not guessing. It's analyzing.
Where it's at:
RepoFuse is fully launched and live. You can connect your GitHub and sign up now

Anybody noticed vscode running commands their iTerm lately? When I check history after app start, i see the following:

sh -c echo "WSL=${WSL_DISTRO_NAME:-false}" && echo "SSH=$( [ -n "$SSH_CLIENT" ] || [ -n "$SSH_TTY" ] || [ -n "$SSH_CONNECTION" ] && echo true || echo false )" && echo "DOCKER=$( [ -f /.dockerenv ] && echo true || echo false )" && echo "CYGWIN=${CYGWIN:-false}" && echo "MINGW=${MINGW_PREFIX:-${MSYSTEM:-false}}"

and also another one

ps -p $$ -o comm=

anyone else is facing this issue? the pipelines are stuck at "Created" or multiple pipelines are created automatically and are still stuck at "Created". layoffs yesterday, runners resigned today 👀

#14 611.2 /app/Driver/Driver.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json. #14 611.2 /app/Driver/Driver.csproj : error NU1301: The HTTP request to 'GET https://api.nuget.org/v3/index.json' has timed out after 100000ms.

I get this anywhere in a runner I try to do (for example) a dotnet restore or other action that depends upon nuget.

This has overnight happened to every single project in my namespace, can't build any .net part on a runner.

Runners can connect to npm just fine for any node projects.

Nuget status and gitlab status both say no issue.

Any great ideas?

Finally we will be proftabile for the first time. Feel bad for gitlab employees. But as investir we want yo make money.

The live complaint about coding agents this month is context loss. Every session burns time rediscovering the repo. Switching between Claude Code, Codex, Cursor resets everything. Token costs balloon before the actual work starts. The pain is real and the threads are not exaggerating.

What the complaint stops short of is the second-order version of the same problem.

If the agent has no persistent memory of your repo, you almost certainly have no persistent record of the agent either. Each session ends, the trace evaporates, and the only thing left is the diff and your memory of how it felt to work with that instance today. Next session, you start from scratch. Not just on context. On evidence.

Concretely: you assigned a refactor to your agent two weeks ago. It went well. You routed another refactor to it last week. That one had problems you caught in review. Can you say, from a record, what was different between the two sessions? Where the agent made different decisions? Whether the second session was an off day or the beginning of a pattern?

Most teams I have talked to cannot. The agent reports completion. The PR ships or doesn't. The session is gone. The next routing call gets made on a feeling.

The reason context loss feels so expensive is that you are paying twice. Once for the agent to rediscover the repo. Again, more quietly, for the team to rediscover whether this instance is the one to trust on this kind of work.

This is becoming visible in concrete ways. Claude Code just shipped a /goal mode that runs async until a condition is met. The Mythos scan found a real curl vulnerability that the maintainer then verified. Both are signals that the agent is doing more, less observed. The record question gets louder the longer you are not watching.

The interesting question is not how to give the agent more memory. It is: what would you keep, per session, if you were going to build a record of each agent instance that actually informed the next routing decision? Decisions made, scope respected, places it pushed back, places it did not. The kind of thing that, six sessions in, would tell you something the model card never will.

I’m a CS student and as the title say I’m a complete beginner in Git. I have never used it but I want to learn because I know it’ll be useful for my future career.

So is there anyone who knows some tips and an effective way to learn it? Or any groups or projects that will help me? Please, if you have this kind of information, I would like to know if you can share it with me.

Thank you very much.

I’m evaluating gitlab ultimate and duo agent platform as we look to make an acquisition decision at work. I notice the following:

1. A single complex agent request (stand up a Django project’s boilerplate) seemed to consume all 24 credits allotted in the trial.
2. I seem to be unable to view per-session metrics for credit use to confirm 24 credits were consumed as I think (on the off chance there is some behavior only allowing one agent session to be executed in a trial).

Am I going crazy here? On GitHub this would all be covered by a single premium request.

Hi all,

I have a GitLab CI pipeline where the first job checks whether updates are available (for example, newer dependencies/releases).

If updates exist → I want the subsequent jobs to run (build, package, publish, etc.)

If no updates exist → I want those jobs to not be created/run at all (not just run and immediately exit with “nothing to update”).

Something like:

check_updates
   ↓
if update found:
   build
   package
   publish

if no update:
   stop here

I already looked at dotenv artifacts, but as I understand it, rules are evaluated at pipeline creation time, so runtime variables/artifacts can’t affect job creation. rules:exists also seems to only work with repo files, not artifacts created by previous jobs.

What’s the cleanest GitLab-native way to achieve this?

• Dynamic child/downstream pipeline generated by the first job?
• Some workflow:rules trick?
• Another pattern I’m missing?

Curious how others solve “runtime discovery → conditionally create jobs” in GitLab CI.

Thanks!