Updating NuGet reference in a different repo in Azure DevOps - azure-devops

I have set up a multi-repo in Azure DevOps using Git. Assume I have 2 repos (Repo A and B) for simplicity.
Repo A's outcome is a common library DLL. Repo B references Repo A's generated DLL (via a NuGet package).
The CD pipeline of Repo A pushes the NuGet package (which was packed during the CI pipeline of Repo A) to my Azure Artifacts feed.
Is there a way to add a task in the CD pipeline of Repo A to automatically change the NuGet package reference (to a newer version) in the project of Repo B? This way, when Repo B gets pulled on the local repository, the reference would be updated instead of going through the NuGet Package Manager and updating manually in Visual Studio?
Update:
After applying your suggestions, everything is working perfectly except the fact that when I pull the changes of RepoB to my local repo, the new NuGet package of Repo A is not available in the packages folder [of Repo B] and I have to manually get it from the Package Manager.
Pre-Build event helps here but I want Repo B be fully up-to-date upon pulling from Azure Repos.
Below is the CD pipeline of Repo A.

Is there a way to add a task in the CD pipeline of Repo A to automatically change the NuGet package reference (to a newer version) in the project of Repo B?
There is no such out-of-the-box approach to doing this.
The simple way is:
Add a Pre-build event to the project in the Repo B with following command line:
nuget.exe update $(ProjectDir)packages.config
In case, when Repo B gets pulled on the local repository, the reference would be updated when you build the project in the repo B. But the limitation for this way is that this method will only modify our local files and will not directly modify the files in the repo. We still need to submit the changes to the repo manually.
The Complex way is:
Add a command line task in the CD pipeline of Repo A to use git command line to clone repo B:
git config --global user.email "xxx#xyz.com"
git config --global user.name "Admin"
git clone <repo> <directory>
Then add powershell or any other task to update the Reference, HintPath info in the project file and the package version in the packages.config file.
After modifying the files, add another command line task to submit the changes to the repo:
git commit -m "Update package version"
git push -u origin master
Update:
When you use git clone <repo> <directory> to clone the repo, you need to provide your certificate in your source link, usually using PAT:
The link looks like:
https://<OrganizationName>#dev.azure.com/<OrganizationName>/MyTestProject/_git/TestSample
Then we need to replace the first OrganizationName with PAT. So, it will be:
https://<PAT>#dev.azure.com/<OrganizationName>/MyTestProject/_git/TestSample
For your case, it should be:
https://<PAT>#xxxxx.Visualstudio.com/....
Then I could clone it successfully.
Hope this helps.

This can be done a bit differently than asked.
Using Project References (Newer projects):
Change your Repo B project's package reference version to get the latest using the wilcard symbol * in the Version attribute.
<PackageReference Include="MyPackageName" Version="*" />
Using packages.config
packages.config does not support the wildcard symbol and takes a few more steps.
You will need to add the following to your nuget.config file inside the <configuration> section:
<config>
<add key="dependencyversion" value="Highest" />
</config>
Be sure that the nuget.config is a part of the repo.
Then In the pipeline's Nuget restore task under the Feeds to use section select Feed in my NuGet.config and then specify the path to the repo's nuget.config.
In either case, when Repo B compiles in the pipeline it will grab the latest. When the repo is pulled down clean or for the first time it will grab the latest on the initial compile as well and on any new version that has been published.

Related

Add Husky(Git Hooks) into Azure DevOps Project

My repository is on AzureDevops, and I cloned it by the button: "Clone in VS Code". The repository was cloned correctly. I have the files from package.json, .gitignore, etc...
But I don't have a .git folder. And I would like to install some tool to standardize code commits. I try to install husky 7 but it doesn't find the .git folder which doesn't really exist.
Is there any way to use git hooks for the repository within Azure Devops?
Is there any other tool for standardizing commits that works in an Azure Devops repository?
When i try to install husky, i get that error: .git can't be found (see https://git.io/Jc3F9)
husky -v = ^7.0.0,
npm -v = 6.14.12

GitHub pipeline/CI to generate files and push them back to the repository

I maintain a public repository on GitHub where changes are only made to a single YAML file. I'm looking for a solution to process that file on every push and generate files based on it. Essentially, a pipeline or CI should parse the file and create many different markdown files. These files (or more specifically, the changes to these files) should then be pushed back to the repository.
Requirements:
Manual changes to the YAML file and automatic changes to the markdown files should both be pushed to the master branch.
The version history should be kept (e.g. forced push might not work).
There is an arbitrary number of files that are generated.
There are Travis providers for GitHub Pages and GitHub Releases. But both have limitations that make them unsuitable for my requirements.
Using what tool/CI/pipeline can I achieve that on GitHub? I would prefer a service over a self-hosted CI.
Assuming that you already have the program/script to parse the YAML file and to generate the Markdown files, I can give you some insights on how I would do this from Jenkins CI. While I draw my experience from running my own instance, there are also hosted options such as CloudBees that you can explore.
Create a new Jenkins Freestyle project.
Under the Source Code Management section, configure your GitHub project coordinates.
Under Build Triggers section, activate the 'Build when a change is pushed to GitHub' option. That would launch the CI job at the moment you push a new version of the YAML file into the repository.
Under the build section, add an Execute shell build step.
In the shell step, launch the program or script that processes the YAML file/generates the .md files. End the script by adding the git add ., git commit -m "message", git pull and git push commands (assumes git is in the path).
Enable the new job to make it active in Jenkins.
You can do this now with the free GitHub Actions option for the repositories.
You need to put this step into your YAML file.
- name: Commit back to GitHub
run: |
git config --global user.name "github-actiuons[bot]"
git config --global user.email "41898282+github-actions[bot]#users.noreply.github.com"
git add -A
git commit -m "Updating some file"
git push
There are some items in the marketplace, but they didn't work for me.
The email of the bot is based on this thread:
https://github.community/t/github-actions-bot-email-address/17204
Update the commit message.
Be careful with the folder paths if you decide to push a specific file in a folder.

Jenkins Publish to Separate Repo than Source Managed

I'm trying to write a job in Jenkins that pulls my latest code from a Github repo, zips it all up, and then pushes it to another builds Github repo. The Publisher event in post-build seems to only push back to the repo you specify in source code management. Is there a way I can push to a different/separate repo?
You can create the zip and than use a bash command with git push ...
Another option is to keep the zip in artifacts repository - Nexus or artifactory ...

How do I download artifacts from GitHub during build?

I need as a part of the build process to download contents from external github repository. I set up repository under "services" but I can not find a task which will download artifacts from that repo.
I use TFS 2017 on prem. My repository is already set to Git repo and I need to have one of build steps to pull data from yet another Git repo. How do i do that?
Build for the same github repo
If you want to download artifacts to your local path, you only need to use copy files task in your build definition.
Get source: select Github and use github token to authoize. If you want CI build, set in Triggers Tab.
Copy Files: set $(Build.SourcesDirectory) as Source Folder, specify the file you want to download in Contents, set a local path as Target Folder.
If you want to download/publish artifacts to VSTS server or share folder, you can use copy files task and publish build artifacts task in you build defnition.
Get source: select from github.
Copy Files: set $(Build.SourcesDirectory) as Source Folder, specify the file you want to download in Contents, set $(build.artifactstagingdirectory) as Target Folder.
Publish Build Artifacts: set $(build.artifactstagingdirectory) as Path to Publish, select the type you want to publish.
The way to connect github repo for TFS build:
In TFS build definition -> Repository Tab -> select External Git -> click Manage to add an External Git Service Endpoint -> input your github repo URL, username and password -> OK -> Then select the endpoint as connection.
Build for a git repo, and also need to download code from another github repo
You can use Command Line task to clone the github repo to your $(Build.SourcesDirectory) folder.
Settings of command Line task:
Tool: git
Arguments: clone https://github.com/username/repo
Now the code of the github repo is cloned in $(Build.SourcesDirectory)\repo.

repo manifest and branches in git repository

I copied the android repositories to local pc with repo init and repo sync, the branch is ics_rb7.
In manifest.xml file, revision is ics_rb7.2, that's supposed to mean the branch in each project, right? However, the branch ics_rb7.2 doesn't exist on all projects in the repository. How do we know which branch in the projects is the default cloned one? Thanks,
The branch that you specify in your repo init is the branch to use for the manifest repository only. You can find this repository in .repo/manifests. This branch is not necessarily (or even usually) the same branch that will be used for the individual projects.
The manifest.xml file in .repo is actually a symbolic link to the specific manifest within the manifests repository (use ls -l to see which one). It is created when you do a repo init, using the branch (-b) and manifest (-m) flags that you specified to determine which one to use, or using the defaults (e.g. master and default.xml) if you didn't specify these flags.
The manifest file specifies the default revision for projects using the element, but the individual elements can override this and specify a different revision. This may explain why some of your projects do not have the ics_rb7.2 branch.
If you want to work out what the manifest branch is for a given project, you can either look at the manifest.xml file, or do a git branch -a and look for a branch that looks like this:
remotes/m/my_manifest_branch