This is fork from https://marketplace.visualstudio.com/items?itemName=fakhrulhilal-maktum.GitDownloader because the original project is Archived.
Git Downloader
This task will download git repository as an addition to default source. Consider this task as workaround where TFS build with git repository can only download 1 repository. Then this task will download another git repository required by your TFS build definition. This task assumes that git is already installed in PATH environment variable or %ProgramFiles%\Git within TFS build agent's machine.
Parameters
Repository URL
URL of git repository. The repository should be public that can be downloaded without authentication. If it's the same location of main repository (specified in Get sources/first task of the build), then it's automatically uses the same credential.
Use $(Build.Repository.GitUri) to refer relative URI for git URL, examples:
Repository Path
Full path to store the git repository. If not specified, then it will be located in $(Build.GitDirectory)\[repo name].
Branch/tag
Branch/tag to checkout. By default, it will download single branch/tag and will checkout to that branch/tag automatically.
Clean
If this is true, it will remove previously downloaded repository and use git clone command to download. Otherwise, it will stash everything and pull the remote branch/tag.
By default, this task expects public git repository that can be downloaded without authentication. But when the git repository is located in same TFS server, than it requires OAuth token for successful download. You can enable it in Options tab and check for Allow scripts to access OAuth token like screenshot below:
For YAML build, we need to expose the token to environment variable manually (named SYSTEM_ACCESSTOKEN) as follows:
- task: fakhrulhilal-maktum.GitDownloader.git-downloader.GitDownloader@0
displayName: Build Scripts
inputs:
RepositoryUrl: '$(Build.Repository.GitUri)/repo'
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
The git URL is considered the same TFS server when it's located in the same URL as TFS server (ignoring HTTP protocol). Supposed we have TFS public URL http://yourdomain/, so these URLs are considered the same TFS server:
- https://yourdomain/tfs/DefaultCollection/TeamProject/_git/GitRepo
- http://yourdomain/tfs/DefaultCollection/_git/TeamProject
- https://yourdomain/tfs/DefaultCollection/AnotherTeamProject/_git/GitRepo
- https://yourdomain/tfs/DefaultCollection/_git/AnotherTeamProject
- $(Build.Repository.GitUri)/GitRepo
And these are considered as different TFS server (means should be downloadable without authentication):
This extension relies on $(System.TeamFoundationCollectionUri) variable to check for same server. To ensure which domain your TFS server is running on, try to create dummy build definition and create one PowerShell task containing this code:
Write-Host "$Env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI"
Requirements
Pipeline Agent
This plugin uses new Powershell3 handler that requires at least pipeline agent version 1.95.1.
Azure DevOps Server
As of Powershell3 handler, this plugin requires at least TFS 2015 Update 2.
GitLab Integration for Azure Pipelines
This extension integrates GitLab with Azure Pipelines. With this extension, you will be able to download the sources from a GitLab repository (using clone command) and use downloaded sources in Azure Pipelines. The extension comes as an artifact source in Release Management and also has a Build task to download sources in your build pipeline.
3rd Party Notices
- GitLab is the trademark of GitLab, Inc. The GitLab trademark and logo are associated with GitLab - For details go to GitLab License page.
- This extension has been developed by Utkarsh Shigihalli and is not associated with GitLab.
Usage
1. Connecting to GitLab
The extension provides a GitLab service connection to connect to GitLab using a Personal access token (PAT).
To connect, go to Project Settings | Service connections tab and create a New service connection and click on GitLab
You will now see a window asking for GitLab details. Enter your GitLab UserName and API Token. Give service connection a name and Verify connection.
If you verified successfully, click OK to save.
2. Downloading GitLab repo in Release
Once you have the GitLab service connection setup, go to Release hub in Azure Pipelines and edit a release definition. Click Add [1 in image below] on artifacts and select GitLab [2 in image below].
You will then need to select the GitLab service connection you created. Once you select, the extension will list all the repositories you own, and after that you will have three options to select artifact version.
Latest from default branch: This will download the default branch for the repository.Latest from specific branch: This will list all the available branches and download the latest commit from the selected branch.Specify at the time of release creation: As the name suggests, you will have the option to specify the commit id while triggering a release.
Save the release definition and trigger a new release.
In the dialog which opens, you will see all your linked artifacts. You will have an option to fill in the commit id if you have selected specify at the time of release creation for an artifact source.
3. Browse artifacts
Once you link your artifact to release, you will also be able to browse the linked artifacts from GitLab in any of the tasks in your pipeline. In the image below, I am browsing artifacts from GitLab inside a Copy Files task. Cool right?
4. Downloading GitLab repo in Build
In some scenarios, you may also want to consume the GitLab repository in your Azure Pipelines build definition. The extension provides the build task to clone and download the repository.
In your build definition, search for the task and you should see the task listed.
Click Add and select the created GitLab service connection. Once you do that, as you can see from the screenshot, you will be able to select the repository, branch and version. You will have to specify the Download Path to which the source from GitLab should be downloaded. In the image below, I am setting it to a Azure DevOps variable $(build.sourcedirectory) but you can use any valid path.
Changes
- v#{Release.ReleaseName}#
- v1.0.7
- Fix issue 2 where only user owned repos were fetched rather than membership
- v1.0.5
- Fix issue 8 where on-premises URL configured in the endpoint was not considered
- Merge pull request #6
- Other minor fixes
- v1.0.0
For more details please see GitHub releases
Feedback
Please rate the extension and share/tweet to spread the word!!
- Found a bug or need to make a feature request? - Raise it as an issue.
- Have a question? - Raise it here in the Q and A section.
Credits
Special thanks to Sriram Balasubramaniam, Omesh Pandita, Romil Goyal, Ashok Kirla and Gopinath Chigakkagari from Microsoft product team, for all the guidance and support in developing this extension.
