As part of the Xamarin.Forms open-source nature the builds are also accessible for you to see. While the advantages are more than one, two really stand out. First, as a contributor, you can now see how your changes integrate with the rest of the code. Second, as a user, you can access the artifacts of a build, test and verify if a PR fixes your issue. This last one is what we will learn in this blog post.
See how to do all described in this post in a video. Don’t forget to subscribe!
Continuous Integration for Xamarin.Forms #
With all the great (and FREE) tooling out there, it’s almost a crime to not have some form of continuous integration (CI) for your project. Xamarin.Forms is no exception. The Forms team has all kinds of builds, deploys and automated tests going on. But for this post I want to specifically talk about the builds associated to pull requests (PRs).
For each PR, the first thing that will happen is a build to see if everything compiles. For core team members this will happen automatically, for contributors they will trigger one for you manually.
Whenever a build is running or done, you can go look at the steps and logs by following the links in the Github status section. This section can be seen in the below screenshot. By clicking on the “Details” link behind each status check, you will find more information.
In case of the
xamarin-forms-ci status, which is the CI build, you will go to the public Azure DevOps instance.
Status section for a pull request
If you are a contributor and the build seems to fail, that is where you can find the reason and fix it without needing to wait on a team member to give you feedback. However, if you are a user that is wondering if a certain PR will fix your issue, this is very interesting as well.
For a PR that is already merged it is a bit harder, the status section is removed so a link to Azure DevOps is not available anymore. You can still go to the Azure DevOps page and search for the PR number and locate it that way, or, depending on when the build was merged and to what branch, it should show up in the nightly buids. More on that in this previous post.
Build Artifacts #
As part of the CI builds, we also create a couple of artifacts; the NuGet packages containing the new code. Since our builds are now public, you have the ability to download these locally and install them onto your project!
A pull request is always targeting a specific version of Xamarin.Forms. When a regression bug is addressed, the target version might even be an older stable version. If it’s a new feature it will target master and will land in the next, unreleased Forms version.
The artifacts will only contain the current state of that targeted branch + the changes in that PR. When trying the changes from an artifact NuGet, keep this in mind. If the version is different than what you’ve used before, you might see more changes than you’ve bargained for or in some cases maybe other features that you were using are not yet in that downloaded NuGet.
Enough talking, let’s learn how we can leverage this and test things!
How to Test, Today #
You can do this yourself, today for any PR that has a successfully completed build attached. This you can see in the Github status section that we have seen before. Find the
xamarin-forms-ci one and click the Details button. This will take you to the Azure DevOps page for this build. In the screenshot underneath you can see that there are 3 related artifacts.
Find the artifacts here in the build overview page
Click on that label and you are taken to the page that shows you the actual artifacts. One of those artifacts will be labeled “nuget”. There are a couple of others that you can ignore. These are just files, so you can click through it until you see actual nupkg files. You can see that in the screenshot below.
Download a file from the artifacts
Behind each line, as you hover over it, you will see a download button on the right. This allows you to either download a single file or a whole folder as a zip.
If you just need the core Xamarin.Forms package, download just that one. If you’re also using Maps or Material for instance, download those too. Put them all together in a local folder. Make note of the version number you see in the artifacts overview, you will need that later.
I have a previous post that walks you through how to use NuGet packages locally. You can read it here.
What you do from here is just add a local NuGet feed to your Visual Studio, point your project to that, update the NuGets like you normally would and see if you issue is resolved. Simple as that!
A Word of Caution #
As mentioned earlier above: these artifacts contain only a specific set of changes.
Please note that these NuGet package artifacts are no sustainable solution and should only be used to verify that a certain issue is fixed or test something specific. These artifacts will only contain the code of the Forms version that the PR is targeting + the fix in the PR.
You should never release a version of your app to production with a NuGet package you’ve downloaded from a CI build.
Wrapping up #
In this post you have learned how to find, download and consume continuous integration artifacts for Xamarin.Forms. With that, you can easily make progress without having to wait on a core team member if you are the contributor. But it doesn’t stop there; as a end-user, or maybe you’ve reported the issue, you can also easily test if a certain PR fixes the issue in your own codebase.
If you didn’t know about this yet, I hope you learned a thing or two and this will make it easier to collaborate directly with the team.
If you are just interested in testing the latest bits, you can also use the nightly build. That way you will always have the latest hot bits and can also see
Hero image based on: Technology vector created by stories - www.freepik.com