The random thoughts of Richard Fennell on technology and software development
It may have passed you by, it had me as I had not created a PAT for a while, but managing custom security for PATs in Azure DevOps is much easier since Sprint 140.
You now get some help to pick the correct ‘limited’ rights set by the simple grouping of rights.
We just need some more detailed documentation on what each option actually maps to permissions wise now to complete the picture
When I started creating OSS extensions for Azure DevOps Pipelines (starting on TFSPreview, then VSO, then VSTS and now named Azure DevOps) I made the mistake of putting all my extensions in a single GitHub repo. I thought this would make life easier, I was wrong, it should have been a repo per extension.
I have considered splitting the GitHub repo, but as a number of people have forked it, over 100 at the last count, I did not want to start a chain of chaos for loads of people.
This initial choice has meant that until very recently I could not use the Pull Request triggers in Azure DevOps Pipelines against my GitHub repo. This was because all builds associated with the repo triggered on any extension PR. So, I had to trigger builds manually, providing the branch name by hand. A bit of a pain, and prone to error.
I am pleased to say that with the roll out of Sprint 140 we now get the option to add a path filter to PR triggers on builds linked to GitHub repo; something we have had for Azure DevOps hosted Git repos since Sprint 126.
So now my release process is improved. If I add a path filter as shown below, my build and hence release process trigger on a PR just as I need.
It is just a shame that the GitHub PR only checks the build, not the whole release, before saying all is OK. Hope we see linking to complete Azure DevOps Pipelines in the future.
Whilst I was off work last week TFS 2018 Update 3 was released. As stated in the 2018.3 release notes this is the final bug fix update release of TFS 2018.
The next major release of TFS will not be named TFS 2019 as you might have expected, but will use the new name of Azure DevOps Server. You can see the features planned for this next release in the Azure DevOps Features Timeline
The Azure DevOps (VSTS) team have published the promised postmortem on the outage on the 4th of September.
It gives good detail on what actually happened to the South Central Azure Datacenter and how it effected VSTS (as it was then called).
More interestingly it provides a discussion of mitigations they plan to put in place to stop a single datacentre failure having such a serious effect in the future.
Great openness as always from the team
Today Microsoft made a big announcement, VSTS is now Azure DevOps.
The big change is they have split VSTS into 5 services you can use together or independently, including Azure Pipelines for CI/CD – free for open source and available in the GitHub CI marketplace.
An important thing to note is that IT IS NOT JUST FOR AZURE.
Don’t be afraid of the name. There a wide range of connectors to other cloud providers such as AWS and Google Cloud, as will as many other DevOps tools
The documentation for the VSTS WIKI suggests you can embed a video in a VSTS WIKI using the markdown/HTML
<video src="_media/vstswiki_mid.mp4" width=400 controls> </video>
Problem is that this does not seem to work, the MP4 just does not appear, you get an empty video player.
However, if you swap to a full URL it does work e.g.
<video src="https://sec.ch9.ms/ch9/7247/7c8ddc1a-348b-4ba9-ab61-51fded6e7247/vstswiki_high.mp4" width=400 controls> </video>
This is a problem if you wish to store media locally in your WIKI
The workaround is to either place the MP4 file in some URL accessible location e.g. some Azure web space (not really addressing the problem), or more usefully use the VSTS API to get the file out the repo that backs the WIKI.
The format of the HTML tag becomes
<video src="https://vstsinstance.visualstudio.com/MyTeamProject/_apis/git/repositories/MyTeamProject.wiki/Items?path=_media%2Fvstswiki_high.mp4 width=400" controls> </video>
This will get the current version of the file on default branch, you can add extra parameters to to specify versions and branches if required as per the API documentation.
So not a perfect solution as you have to think about branches and versions, they are not handled automatically, but at least it does work
When you want to register a build agent with VSTS, you use the VSTS instance’s URL and a user’s Personal Access Token (PAT). Whilst doing this today I connected to the VSTS instance OK but got the error “Agent pool not found”.when I was asked to pick the agent pool to add the new agent to.
As the user who’s PAT I was using was a Build Administrator I was a bit confused, but then I remembered to check their user access level. It was set to Stakeholder, once this was changed to Basic I was able to register the agent without use.
Also, so as to not use up a Basic license, when I did not need to, I swapped the user back to being a Stakeholder once the agent was registered. This can be done as the token used for the actual build is not the one used to register it, but one assigned at build time by VSTS.
You have always been able to customise your Team Projects in TFS, by editing a host of XML files, but it was not a pleasant experience. In VSTS a far more pleasant to use web based inherited customisation model was added, much to, I think, most administrators relief.
If you used the TFS DB migration service you ended up with a VSTS instance full of the the XML style team projects, and you were stuck there, with no way to change these to the new inherited mode, that is until now as Microsoft have released to preview a conversion tool.
I have been trying this tool to migrate all our active XML based team projects to Inherited equivalents, and it has worked very well for me, but I have to say, we don’t have any hugely complex customisations, so your mileage may vary depending on how much you modified your XML based team project templates.
However, I wanted to go further than the basic process as documented
Since moving to VSTS all our new team project have been created using an inherited template based on Scrum. I wanted to move all our active XML based team project to this standardised template. This took a little extra work.
The basic process is easy as to change Inherited Process you
REMEMBER: A really nice touch (with XML and Inherited templates) is that you can just switch back if you don’t like the result, no data is lost when you swap templates, but some of it might be hidden as fields are not shown on the new work item types.
The problem I had was that our old XML based team project templates had different customisation to our current inherited standard. To address this I needed to
So once done, I was then able to migrate all the team project to my target process template.
So a very nice experience, and one that now means we can make sure all our team projects use the same set of customisation. No longer do we need to worry about customising in XML and Inherited models.
Whilst writing some training material for VSTS I hit a problem creating a TFVC workspace. I was using VS2017, linking a TFVC Repo to a local folder. I was connecting to the VSTS instance using an MSA.
In Team Explorer, when I came to do a ‘Map & Get’ to map the source locations I got a ‘TF14061: The workspace ws_1_18;Project Collection Build Service does not exist’ error
Strange error, which I could see no obvious reason for. Turns out the work around was just to press the ‘Advanced’ link/button and accept the defaults
I have a VSTS build extension that can apply a VSTS generated build number to Android APK packages. This takes a VSTS build number and generates, and applies, the Version Name (a string) and Version Code (an integer) to the APK file manifest.
The default parameters mean that the behaviour of this task is to assume (using a regular expression) the VSTS build number has at least three fields major.minor.patch e.g. 1.2.3, and uses the 1.2 as the Version Name and the 3 as the Version Code.
Now, it is important to note that the Version Code must be a integer between 1 and 2100000000 and for the Google Play Store it must be incrementing between versions.
So maybe these default parameter values for this task are not the best options?
When we use the Android Manifest Versioning task for our tuServ Android packages we use different parameter values, but we recently found these values still cause a problem.
Our VSTS build generates build numbers with four parts $(Major).$(Minor).$(Year:yy)$(DayOfYear).$(rev:r)
So we end up with build numbers in the form 1.2.18101.1
The Android version task is set in the build to make
The problem is if we do more than 9 builds in a day, which is likely due to our continuous integration process, and release one of the later builds to the Google Play store, then the next day any build with a lower revision than 9 cannot be released to the store as its Version Code is lower than the previously published one e.g.
So the second Version Code is 10x smaller, hence the package cannot be published.
The answer in the end was straightforward and found by one of our engineers Peter (@sarkimedes). It was to change the final block of the VSTS build number to $(rev:rrr), as detailed in the VSTS documentation. Thus zero padding the revision from .1 to .001. This allows up to 1000 builds per day before the problem of altering the Version Code order of magnitude problem occurs. Obviously, if you think you might do more than 1000 internal builds in a day you could zero pack as many digits as you want.
So using the new build version number
So a nice fix without any need to alter the Android Manifest Versioning task’s code. However, changing the default Version Code parameter to {1}{2}{3} is probably advisable.