Docker-in-Docker via dind has historically been widely used in CI environments. It means the "inner" containers have a layer of isolation from the host. A single CI runner container supports every pipeline container without polluting the host's Docker daemon.

This is probably confusing because the "host" in --network=host does not mean host as in the underlying runner host / 'baremetal' system. To understand what is happening here, we must first understand how the docker:dind service works. When you use the service docker:dind to power docker commands from your build job, you are running containers 'on' the docker:dind service; it is the docker daemon. When you provide the --host option to docker run it refers to the host network of the daemon I.E. the docker:dind container, not the underlying system host.

When you specify FF_NETWORK_PER_BUILD that was specifying the docker network for the build job and its service containers that encapsulates all of your job's containers.

return &container.HostConfig{ DNS: e.Config.Docker.DNS, DNSSearch: e.Config.Docker.DNSSearch, RestartPolicy: neverRestartPolicy, ExtraHosts: e.Config.Docker.ExtraHosts, Privileged: e.Config.Docker.Privileged, NetworkMode: e.networkMode, Binds: e.volumesManager.Binds(), ShmSize: e.Config.Docker.ShmSize, Tmpfs: e.Config.Docker.ServicesTmpfs, LogConfig: container.LogConfig{ Type: "json-file", },

I'm closing this issue as extra_hosts config is now passed to build containers and services.

When a job uses needs, it no longer downloads all artifacts from previous stages by default, because jobs with needs can start before earlier stages complete. With needs you can only download artifacts from the jobs listed in the needs configuration.

Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.

One of the reasons that some projects don't use Gitlab's issues and use an external tracking platform is the lack of issues relations. Without relations issues are just flat, no way to actually track progress of big features. No way to create a "meta" issue that depends on 4 other or create subtasks and so on. The same problem exists on Github too. It would surely make a difference if Gitlab offers a full features tracking issue, instead of just flat issues. Relations is a major first step towards that.

A user wants to comment on a single parameter name in a function. It is highlighted as a unique part of the syntax tree, and they're not happy with the particular name the author of the MR chose. Problem: The user can only comment on the entire line, because "lines" are considered the most fundamental building block in our Diffs UI.

You can also check out the video below to see how the structure comes together in GitLab. Read more about Agile at GitLab See more information about our Agile delivery solution Build your Agile roadmap in GitLab

how was your code review experience with this merge request? Please tell us how we can continue to iterate and improve: Leave a 👍 or a 👎 on this comment to describe your experience.

Good commit hygiene is considered a best practice. GitLab should encourage and enable these kinds of best practices. This feature currently creates a problem and requires workarounds that remove information, or significant manual work.

As you've probably already guessed, we've decided to replace the current Web IDE with one built on top of VS Code. In the coming milestones, we will build out custom support for the features not already available in the VS Code core, and validate that the workflows you already depend on in the Web IDE are handled in the new experience. We're working with the team that builds our amazing GitLab Workflow extension for VS Code to make it available in the browser so we can bundle it in the Web IDE, and bring all those great features along for the ride. That includes bringing merge request comments into the Web IDE for the first time ever!

Overall, if speed is your primary concern and you’re on a budget, then Circle CI is the clear choice. If you’re not looking to run a ton of builds each month and your code is already in Github, then Github Actions can offer similar performance with the added convenience of having everything under one service. Even though we liked Travis better, our main criteria was value, and since you can’t use Travis for free after the first month, GitLab was able to grab the third slot, despite it being weaker in almost every other category.

We overload the meaning of "GFM" to mean "GitLab Flavored Markdown", which is a superset of GitHub's version. However it can cause confusion as they are not the same thing.

my/path/.my-custom-file.yml@mygroup/another-project:refname

export CI_SERVER_NAME="GitLab" export CI_SERVER_REVISION="70606bf" export CI_SERVER_VERSION="8.9.0"

How to set it up

We want the GraphQL API to be the primary means of interacting programmatically with GitLab. To achieve this, it needs full coverage - anything possible in the REST API should also be possible in the GraphQL API.

GitLab App

The needs: keyword enables executing jobs out-of-order, allowing you to implement a directed acyclic graph in your .gitlab-ci.yml. This lets you run some jobs without waiting for other ones, disregarding stage ordering so you can have multiple stages running concurrently.

"We should try to find a replacement for omgwtfssl, which is currently used to generate self-signed certificates. The name is inappropriate and unprofessional."

Malicious code pushed to your .gitlab-ci.yml file could compromise your variables and send them to a third party server regardless of the masked setting. If the pipeline runs on a protected branch or protected tag, it could also compromise protected variables.

Here is a simplified example of a malicious .gitlab-ci.yml

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

uses a pre-clone step to seed the project with a recent archive of the repository. This is done for several reasons: It speeds up builds because a 800 MB download only takes seconds, as opposed to a full Git clone.

GIT_DEPTH: '1' helps a little bit but we could speed up our pipelines massively for jobs that only rely on an image that is the sole dependency to run the job.

Standard Markdown Extended Markdown in GitLab

If you’re working in spreadsheet software (for example, Microsoft Excel, Google Sheets, or Apple Numbers), you can copy from a spreadsheet, and GitLab will paste it as a Markdown table. For example, suppose you have the following spreadsheet:

See the documentation for HTML::Pipeline’s SanitizationFilter class for the list of allowed HTML tags and attributes. In addition to the default SanitizationFilter allowlist, GitLab allows span, abbr, details and summary elements.

You can add a table of contents to a Markdown file, wiki page, or issue/merge request description, by adding the tag [[_TOC_]] on its own line. It will appear as an unordered list that links to the various headers.

Make it easier to paste tab delimited data into a markdown table format.

In a basic configuration, GitLab runs a pipeline each time changes are pushed to a branch. If you want the pipeline to run jobs only when merge requests are created or updated, you can use pipelines for merge requests.

In this example

Some GitLab features can behave differently for each environment. For example, you can create a secret variable to be injected only into a production environment.

To follow conventions of naming across GitLab, and to further move away from the build term and toward job, some CI/CD environment variables were renamed for GitLab 9.0 release.

Enable the sub-chart The way we’ve chosen to implement compartmentalized sub-charts includes the ability to disable the components that you may not want in a given deployment. For this reason, the first setting you should decide on is enabled.

Gitlab API can be used

Using the special CI_REGISTRY_USER variable: The user specified by this variable is created for you in order to push to the Registry connected to your project. Its password is automatically set with the CI_REGISTRY_PASSWORD variable. This allows you to automate building and deploying your Docker images and has read/write access to the Registry. This is ephemeral, so it's only valid for one job.

NOTE: Note: If you have 2 Factor Authentication enabled in your account, you need to pass a personal access token instead of your password in order to login to GitLab's Container Registry.

With a single file in the repository, everyone with read access can see the contents, making it much more inviting to improve and review the build scripts.

This issue is being considered for the next milestone. Please review it and vote on this thread if it is workflowready for development : ✅ ready ⛔ not ready (add reason in the thread) 1️⃣ 2️⃣ 3️⃣ 5️⃣ weight

It seems weird to me that we are trying to enforce commit messages when they are not really visible or used in the GitLab workflow at all. This is what you see most of the time when interacting with the commit list. I've taken time to compose a nice descriptive body and it is hidden by default:

In the near future, given the increase in the use and profile of preprint servers and alternative publishing platforms, such as F1000 Research, it will be necessary to identify how many relevant platforms exist, to describe their scientific scope (i.e., covered disciplines), and, similar to the way that researchers evaluate the aims and scope of journals, to compare their characteristics and policies.

n the near future, given the increase in the use and profile of preprintservers, and alternative publishing platforms such as F1000 Researc

In recent days, if a meeting ends early, employees at GitLab will invite their children to take over for a bit.“People will throw out, ‘Anyone have kids home from school who want to chat with my kids?’” says Darren Murph, who leads employee culture and onboarding at GitLab.

GitLab, a San Francisco-based provider of hosted git software, recently changed its company handbook to declare it won't ban potential customers on "moral/value grounds," and that employees should not discuss politics at work.

Implementando CI com GitLab