Git is the industry standard for software development, but I thasn’t been fully adopted in Debian packaging yet. Debian development is still based on uploading tarballs via FTP.

I believe that git-based workflows could enhance collaboration, transparency, and productivity for one of the world’s most vital open source projects. Increasing the use of salsa.debian.org, Debian's GitLab instance, would be a good step towards collaborative git usage.

My Gitlab Pages site works well under domain.com but not under www.domain.com. The www subdomain leads to a 401 message: "You don't have permission to access the resource."

My DNS has a CNAME entry for www pointing to domain.com. When I asked the DNS provider what the problem might be they said "Please contact your hosting provider and provide us with the record needed to be set for www in the DNS zone. The changes should have worked already."

The reason I need this is that some old-school people visiting our website still type www. into the URL bar.

Support for GitHub actions

now with zero-downtime garbage collection.

works like a charm

Crafting pipeline configurations with YAML can be intricate and challenging because YAML isn't a programming language, Developers may find themselves reinventing the wheel each time they try to create new configurations because they don't have visibility into existing configurations and work that others may have already done, resulting in inefficiency.

GitLab 16.7 introduces the CI/CD Catalog (Beta), with the goal of enhancing developer efficiency

Hi everyone

I have read through the documentation now several times, and I just want to soundboard something with someone. Regarding the environments we can set up. Is this meant for example as a production cluster and a dev cluster? And if so, is it possible to put a docker swarm cluster in there? I don't see how gitlab will 'know' how to deploy an application to docker swarm? What am I missing? Or am I better off just deploying "manually" via the CI/CD pipeline like I am doing now?

TIA

Hi community

I have a pipeline where a stack (service) is deployed to my docker swarm. I want to use $CI_PROJECT_NAME in my docker service definition file to define the docker service name. But it seems the variable is not being expanded, or something else is wrong. I need to have a generic yml so I can distribute this to all devs and they don't have to change anything.

Example of what I am trying to achieve:

version: '3.9'
services:
  $CI_PROJECT_NAME:
    image: myregistry/devops1/$CI_PROJECT_NAME/$CI_PROJECT_NAME:latest
    deploy:
      replicas: 3
      endpoint_mode: dnsrr
      update_config:
        parallelism: 1
        delay: 3s
        order: start-first
        failure_action: rollback
        monitor: 1m
      restart_policy:
        max_attempts: 3
      placement:
        max_replicas_per_node: 1
    networks:
      - microservices
    volumes:
      - apache-logs:/var/log/

networks:
  microservices:
    external: true


volumes:
  apache-logs:
    driver: local
    driver_opts:
      o: bind
      device: /mnt/swarm_shared/services/$CI_PROJECT_NAME
      type: none

I know this is not a docker forum, but was thinking the issue is with my pipeline rather than my docker compose file. I would appreciate any help I can get. TIA

EDIT: As per this community post I used a sed replacement command to solve my problem. Ugly, but functional.

Thanks for the input!

[Investigating] Our investigation into the root cause of the issue is still underway. Once availability has been restored, full details regarding the incident will be posted in the incident issue here: gitlab.com/gitlab-com/gl-infra/production/-/issues/15997

If you have lost both your normal 2FA method and your 10 backup codes, you can retrieve new ones if you can authenticate via SSH.

ssh [email protected] 2fa_recovery_codes

https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh