GitTools/GitVersion

[ISSUE]: Cannot git fetch --unshallow with AzureDevOps

jzabroski opened this issue · 7 comments

Prerequisites

  • I have written a descriptive issue title
  • I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.Tool

GitVersion version

5.12

Operating system

Windows

What are you seeing?

This may not be a "GitVersion" issue but I imagine half of all GitVersion users have the same problem as me. On a NEW AzureDevOps pipeline (created today), fetchDepth: 0 does not seem to be respected. The error message I get on GitVersion/Execute@0 is

  INFO [08/06/24 15:43:06:60] Begin: Calculating base versions
    INFO [08/06/24 15:43:06:63] NextVersion in GitVersion configuration file: 5.2.0 with commit count source External Source
  INFO [08/06/24 15:43:06:66] End: Calculating base versions (Took: 63.77ms)
  ERROR [08/06/24 15:43:06:87] An unexpected error occurred:
GitVersion.GitVersionException: Cannot find commit 89e8138 #1848: Ensure English validation messages in tests. Please ensure that the repository is an unshallow clone with `git fetch --unshallow`.
 ---> LibGit2Sharp.NotFoundException: object not found - no match for id (214345132f8b599ce72fdd21bf966baf894aae2d)

I've configured my ci/cd build pipeline to use fetchDepth: 0, as described in AzureDevOps pipleine official documentation steps.checkout Shallow Fetch

https://github.com/fluentmigrator/fluentmigrator/blob/c7efaa137419963f2126cfb98a8fc96fac6230fc/azure-pipelines-pullrequests.yml#L24-L25

I'm not the only user with this problem, c.f. #3612 (comment)

Worth noting, on GitHub, if you change your default branch name from master to main, you need to re-create your AzureDevOps pipeline, as AzureDevOps permanently caches that pipeline file as belonging to the master branch (this isn't documented anywhere online, and something I figured out empirically through testing).

What is expected?

Perhaps a better guidance than just git fetch --unshallow. Perhaps working more closely with key CI/CD vendors to ensure GitVersion works as expected. It's almost as if these vendors have no idea how users use their pipelines when fundamental things like these break, so the hope/aspiration is that education is key.

Steps to Reproduce

  1. Create new Azure DevOps pipeline file with the following:
    trigger: none
    
    pr:
      branches:
        include:
        - main
    
    pool:
      vmImage: 'windows-latest'
    
    steps:
     - checkout: self
       fetchDepth: 0
    
     - task: gitversion/setup@0
       displayName: 'Install GitVersion (using GitTools 0.10.2.23031113 or later)'
       inputs:
         versionSpec: '5.12'
         includePrerelease: true
    
     - task: gitversion/execute@0
       displayName: 'Execute GitVersion (using GitTools 0.10.2.23031113 or later)'
       inputs:
         updateAssemblyInfo: false
  2. Give Azure DevOps access to your GitHub repo
  3. Run pipeline

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

This build will be deleted automatically in a few weeks as its a free organization (open source project):

https://dev.azure.com/fluentmigrator/fluentmigrator/_build/results?buildId=981&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=63e8042a-f367-5aec-692c-fcc654be55e4

Changing

 - checkout: self
   fetchDepth: 0

to

 - checkout: self
   clean: true
   fetchDepth: 0
   fetchTags: true

Fixed the problem, but I do not understand why. The logged command does not do a git fetch --unshallow:

Starting: Checkout fluentmigrator/fluentmigrator@main to s
==============================================================================
Task         : Get sources
Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
Version      : 1.0.0
Author       : Microsoft
Help         : [More Information](https://go.microsoft.com/fwlink/?LinkId=798199)
==============================================================================
Syncing repository: fluentmigrator/fluentmigrator (GitHub)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.45.2.windows.1
git lfs version
git-lfs/3.4.0 (GitHub; windows amd64; go 1.20.6; git d06d6e9e)
git init "D:\a\1\s"
Initialized empty Git repository in D:/a/1/s/.git/
git remote add origin https://github.com/fluentmigrator/fluentmigrator
git config gc.auto 0
git config core.longpaths true
git config --get-all http.https://github.com/fluentmigrator/fluentmigrator.extraheader
git config --get-all http.extraheader
git config --get-regexp .*extraheader
git config --get-all http.proxy
git config http.version HTTP/1.1
git --config-env=http.extraheader=env_var_http.extraheader fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin

probably clean: true

probably clean: true

The docs say that is the default (Effectively): https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/steps-checkout?view=azure-pipelines#clean-property

If the clean property is unset, then its default value is configured by the clean setting in the UI settings for YAML pipelines, which is set to true by default.

I'm not sure where the "UI settings for YAML pipelines" is, but I don't think we would have turned this off.

Hmm... old PRs (created before the pipeline was set-up) do not work still. For some reason they still have depth=1.

image

That when you Edit the pipelines /Triggers/Yaml

Hmm... I do not have that UI. I only get the raw YAML. That being said, if I "Update Branch" on the PR, it resolves the problem. I was under the impression "Run using latest resources" implied using the latest pipeline yaml file. I was able to figure it out with this view that implied it was injecting its own checkout task.

image

so in any case that's an Azure Pipelines issue not a GitVersion.

Btw I'd recommend if possible to install the latest version of the Azure Pipeline Task https://marketplace.visualstudio.com/items?itemName=gittools.gittools

I will close this one