Source Link

When searching for a repository starting from an initial path /a/b, the search follows a specific hierarchy of paths, looking for either a valid git directory or a .git file.

Search Order:

1. /a/b/.git
2. /a/b/
3. /a/.git
4. /a
5. /.git
6. /

Key Rules:

• Only paths on the same device as the initial path are considered.
• On Windows, \ separators are normalized to / before searching.
• A .git file must start with the gitdir: prefix followed by a valid git directory path. Relative paths in a .git file are relative to the directory containing the file.
• Linked Working Trees: A repository is a linked working tree if its git directory is different from its common directory and a gitdir file is present in the git directory containing the absolute path to the working directory.
• Bare Repositories: A repository is considered bare if core.bare is set to true and it is not a linked working tree.

Git configuration files follow a specific format and support recursive includes.

Parsing Rules

• Files may start with an optional BOM.
• Section and subsection names can be separated by multiple whitespace characters.
• No whitespace is allowed between a terminating subsection quote " and the closing bracket ].
• Variables defined outside of a section are allowed (they appear in git config --list but cannot be queried via git config --get).
• If a fully qualified variable name already exists, it is treated as multi-valued.

Includes and Conditional Includes

• Recursion Limit: Recursive includes stop at a depth of 10.
• Path Resolution:
  • If the path starts with ./ or .\ (Windows), it is joined with the directory containing the current config file.
  • If the path starts with ~/ or ~\ (Windows), the tilde is expanded to the home directory.
  • If the path is not absolute, it is joined with the current directory.
  • If the path ends with a directory separator, ** is appended to the path.
• Pattern Matching: Path patterns are matched against the repository's git directory using fnmatch. Patterns must use / for directory separators.

When using 1ES pipeline templates (templates-official), every publish artifact execution triggers additional security scans. To minimize this overhead, you should use the outputParentDirectory feature of 1ES templates.

Implementation Steps:

1. Gather all build outputs into the $(Build.ArtifactStagingDirectory) using a task like CopyFiles@2.
2. Configure the templateContext.outputs parameter in your template call to point to these locations.

Note: Multiple outputs are ONLY applicable to 1ES PT publishing (using templates-official).

# azure-pipelines.yml
extends:
  template: azure-pipelines/MicroBuild.1ES.Official.yml@MicroBuildTemplate
  parameters:
    stages:
    - stage: build
      jobs:
      - template: /eng/common/templates-official/jobs/jobs.yml@self
        parameters:
          # 1ES makes use of outputs to reduce security task injection overhead
          templateContext:
            outputs:
            - output: pipelineArtifact
              displayName: 'Publish logs from source'
              continueOnError: true
              condition: always()
              targetPath: $(Build.ArtifactStagingDirectory)/artifacts/log
              artifactName: Logs
          jobs:
          - job: Windows
            steps:
            - script: echo "friendly neighborhood" > artifacts/marvel/spiderman.txt
          # copy build outputs to artifact staging directory for publishing
          - task: CopyFiles@2
              displayName: Gather build output
              inputs:
                SourceFolder: '$(System.DefaultWorkingDirectory)/artifacts/marvel'
                Contents: '**'
                TargetFolder: '$(Build.ArtifactStagingDirectory)/artifacts/marvel'

There are three primary ways to distribute PDBs (debug symbols) for managed code. Choose the method based on your requirements for package size, user opt-in, and feed compatibility.

|                                         | snupkg                      | Include in main package | Embed in assembly |
|-----------------------------------------|-----------------------------|--------------------------|-------------------|
| No user opt-in required to load symbols | ✅                          | ❌                       | ✅                 |
| No increase in size of main package     | ✅                          | ❌                       | ❌                 |
| No increase in size of assemblies       | ✅                          | ✅                       | ❌                 |
| Supported by all package feeds          | ❌ (Supported on NuGet.org) | ✅                       | ✅                 |

.gitignore files determine which files are ignored by Git. They follow a specific order of precedence and matching logic.

Precedence (Order of evaluation)

1. Default patterns: ., .., .git
2. The inner-most .gitignore file (in the directory being checked)
3. The outer-most .gitignore file (search stops at the working directory)
4. The info/exclude file under the common directory
5. The file specified by core.excludesFile in the configuration

Pattern Types

• Negative Pattern: Starts with !. Removes the ! to match the file instead of ignoring it.
• Directory Pattern: Ends with /.
• Full Path Pattern: Contains a / after the trailing / is removed. These match against the path relative to the directory containing the .gitignore file.
• Standard Pattern: Matches only against the last component of the path (file or directory name).

Matching Rules

• Case Sensitivity: Matching is case-insensitive if core.ignorecase is set to true.
• Separators: Input paths must use / directory separators. Even on Windows, \ is not considered a directory separator for matching.
• Wildcards: In Full Path Patterns, the wildcards ?, *, and [] do not match the / character.
• Directory Matching: If a pattern is a directory pattern, it will only match if the input path is a directory path.