Use YAML for build pipeline

[bdukes]

This adds a YAML definition for the build, so that pull requests can make incremental changes to the build process, and to publicly document the build process.

This is just a copy of the existing build process, using the View YAML feature in pipelines.

[SkyeHoefling]

This is a great idea! I had a couple thoughts I wanted to share

• Hosted Build Pool (see comment inline)
• Triggers - How are the build triggers working? I don't see anything defined here and it is something we can trigger for PRs, tags, commits to develop, etc. I think declaring more in yaml is better than having anything hidden in Azure DevOps

[SkyeHoefling]

As microsoft updates build agents, build failures can happen as there can be different versions of SDKs installed. This is a notorious problem in the multi-platform development world and isn't as important for a project like DNN. My best practice I've been using is specifying vmImage instead of name. This would give us more granular control over what Hosted-Agent is being used to reduce the risk of random build failures.

Suggested change

	name: Hosted VS2017
	vmImage: windows-2019

This may not work as a drop-in replacement. We may need to add a jobs root node and specify pool on each job. See the docs below for more details

• https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml

[bdukes]

Thanks for the feedback @ahoefling! I've added the triggers info (as well as fixed some differences between the current pipeline and this new pipeline that I hadn't realized were in my original commit).

Regarding the pool/VM image, I agree, we should move to Windows 2019. However, I'd prefer this PR to be just moving to YAML with our current config, and then we can have a separate PR to switch pools. @mitchelsellers @valadas we don't have any specific guidance from .NET Foundation around needing to use particular build agents, right? We're free to jump to the windows-2019 agent?

[mitchelsellers]

Love this.

We are free to use any available agent

[SkyeHoefling]

@bdukes

I've added the triggers info (as well as fixed some differences between the current pipeline and this new pipeline that I hadn't realized were in my original commit).

Did you add a triggers: section? I am not seeing it in the latest code push

https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#ci-triggers

[bdukes]

Whoops, didn't push that part, thanks for the catch :-)

[SkyeHoefling]

Thanks for adding the triggers, this is looking much better. See comments for question about pattern matching branches for triggers

[SkyeHoefling]

I thought this was an implied setting, not sure if it is necessary. I usually use includes to define specific branches or patterns I want to build.

Example:

trigger:
  branches:
    include:
    - main
    - releases/v*
  tags:
    include:
    - v*

[bdukes]

Yes, that's the default. It felt weird to add the section and then completely rely on the defaults. It feels like adding the branches section gives a hint to someone who might want to adjust the trigger configuration. If others feel like it's better with it removed, I'm happy to do that as well.

[SkyeHoefling]

@bdukes

It felt weird to add the section and then completely rely on the defaults

This is a really great point and we should update this to include something useful. I do not think it is a wise idea to have it build all branches. Looking at our current branch structure I see there is the cake-frosting branch that you are working on. I don't think that should automatically build every time a new commit is pushed. That should only build once the PR is opened. These are just some of my opinions on the topic and if the core team thinks this is fine, go ahead with the merge.

I am thinking something like this may be more appropriate

trigger:
  branches:
    include:
    - develop
  tags:
    include:
    - v*

This will build any push to the develop branch and any tag that is prefixed with v. For example v10.0.0 will trigger a build.

(see PR comment below for how this will handle PRs)

[valadas]

For the trigger on v* tags, I would like to do something later after we move (if we succeed) to cake-frosting. On my own projects I have an automation on creation of a release/x.x.x branch. It produces an RC pre-release with automated release notes and mentions based on merged PRs with matching milestone. Then when merging a release/x.x.x branch into master, it tags and produces a release with the same things but not RC.

[SkyeHoefling]

I like the v* tag because I can tag builds for production release and release client. It is something that you can apply regex to parse the version depending on the defined convention.

For example

• v10.0.0
• v10.0.0-RC1

Both of those tags will trigger a build. I have a build step using a regex that checks for the -RC1 which will then generate the build as a Release Client. If the regex matches the production build format of v10.0.0 it will generate the production build

[valadas]

yep, the v tags stay the same with what I have, it's just not the trigger. The triggers are creating a release/1.2.3 branch which fires up a series of events:

• Tags v1.2.3-rc1 (or rc2 or rc3 on next commits to that branch)
• Produces release notes
• Produces an unpublished release with the artifacts and all.

Then when release/1.2.3 get's merged into master, same process other than the tag is v1.2.3 (no rc-*)

It's about the same as what I currently do manually for each release other than not having to do it manually 😄

On top of that when we get this working we also have the proper triggers to adjust the issue templates because we need 2 events for that, when we release an RC and when we release a non-RC.

But yeah, the tags would be the exact same

[SkyeHoefling]

Same comment as above

[SkyeHoefling]

@bdukes
Following up to #4327 (comment)

Currently the way the PR trigger is written it will start a build for any pull request to any branch. I am not sure if this is the best decision as there are branches that we may not want to auto-build against. This may be an incorrect assumption for me to make, but has been a best practice for projects I have worked on.

Perhaps we adjust the PR workflow to only build against the main branches of the repo using the following yaml

pr:
  branches:
    include:
    - develop
    - master
    - future/10

[valadas]

Awesome

[valadas]

I will merge this after the build...