Added Build YML Params for Generating GitHub Release Notes

[SkyeHoefling]

Description of PR...

Integrating with new build template for automating release notes

Changes made

• Added new parameters required by build template

PR Template Checklist

• Fixes Bug
• Feature solution
• DevOps

closes: #20

[SkyeHoefling]

@valadas @nvisionative

I added the GitHub Release Notes implementation to the DevOps Repo which we use in our build yml file in this repo. The changes allow us to provide new parameters specific for adding GitHub Release Notes.

3 new Parameters

• githubOrganization - This is useful is someone is testing github releases on a fork
• githubRepo - this is needed to pass the repo name to the gren tool that is invoked by the build process
• releaseBranch - if a project uses a non-standard release branch they can override it with this parameter. The default release branch is master

To get all of this to work a repo maintainer will need to include the correct Token securely through Azure DevOps. I will go over this in detail at the next Core Modules meeting

Follow Up Items:

• I didn't add the github-release-notes configuration file (that can be done later)
• We aren't passing any additional flags to the gren release command such as tags or version

Important

• The fact of merging this branch will create a new release of the DNN.Wiki Module. Perhaps we should coordinate a new release of this project since master and development have diverged a little a bit.

[valadas]

Please do not merge this until we are in agreement to do so (just in case someone else decides to merge this by mistake)

[valadas]

Since this repo has no specific maintainer, I think we should clean it, use development for development and master for releases.

[EPTamminga]

@valadas There is one additional branch (Issue12), that can be deleted.
Master is the current default branch, the default can be set to the branch development.

[SkyeHoefling]

It looks like we have 2 options:

Option 1

1. Create PR to merge develoment into master
2. Rebase/Merge this branch
3. Complete this pull request into master (which would generate a new release)
4. Set default branch as development

Option 2

1. Update this branch to point to development instead of master
2. set default branch as development

Maybe we go with the path of least resistance right now and go with option 2

[david-poindexter]

@ahoefling @valadas @EPTamminga - I have been doing some research this past week on GitHub branching strategies and have learned a lot. I think the concept of having a master and development (or develop) is an old one that trickled into a lot of early GitHub repos due to Git Flow. The truth is GitHub is a bit different from traditional Git systems because of the concepts of Issues and Pull Requests. Therefore, most modern GitHub repos employ the branching strategy of having a master. That is the current release and is the default branch for the repo. And while there are variations in GitHub flows out there, the vast consensus is to simply have feature branches (e.g., branches tied to issues, like an issue-19 branch that relates to issue #19) and then make pull requests against master.

For larger efforts, you can create a feature branch that pull requests can be made against to "stage" for a later merge to master.

The idea with modern CI/CD is also to release often. Therefore, I am of the mindset that we should release upon every merge to master and would simply not merge anything to master that is not release-ready.

Keeping evergreen branches for both master and development (or develop) is a lot of overhead for small projects like these DNN core modules. Abandoning this flow will make things much more simple for repo owners and maintainers. It will also simplify the flow for people wanting to contribute.

Thoughts?

[SkyeHoefling]

Thanks @nvisionative for chiming in on this. I agree with everything you have to say and in my experience most GitHub projects want people making PRs to the master branch.

A good compromise is updating the release cadence to be done via git tags instead of branch merging. Many projects don't even cut release branches anymore since git tags solves the problem without adding unnecessary branches. I believe this was a discussion we had on the DNN Platform project last year.

We could add the ability to do release tagging instead of releasing on commits to master.

[valadas]

I would prefer release tagging instead of automatically having a release on each merge. I do not like the idea of a release for each merged PR, sometimes, you need a couple PRs to make something happen and fix some stuff after more testing, etc. I think we should be able to manually trigger a release (either with a tag or straight up manual process).

[EPTamminga]

@nvisionative @valadas I support the suggestions of David, The fewer branches there are, the better. So a master branch should be enough. Any PR to the master creates a release, CI/CD promotes to release often
If you have a set of PR's to create something (solve an issue, or create a single feature), you can create your (working) branch, do all your subsequent PR's on that branch and when everything is finished, merge the final result into master and delete your (working) branch.
Auto-generating release notes on every release will help get the release notes in shape before a "normal/full" release is done.
A normal/full release, eg with a DNN type version # like 07.00.03, can be a tag.

[valadas]

I am unclear on the meaning of release vs a normal/full release. CI will make a build on each pull request, it will also generate a build on each merge to either development or master depending on how it is configured but that will not (by default) generate a public release in the releases page of github, that would still be done manually right ? By putting a tag on master.

[EPTamminga]

@valadas A public release is what I named a full/normal release.
The project owner says: ok, let’s make this release a point in time and name that one a formal module release: create a new release # (xx.yy.zz), put it in the GH release page, make sure that the release notes are correct, update documentation and generate some noise about it, eg by a blog, FB post, forum post, tweets, article in the DNN digest, etc.

[valadas]

@EPTamminga ok, for me that is a release, the other builds are just "nightly builds" or builds. Now if I understood correctly, the automatic release notes would update the release notes on the github release page from all the issue names (titles) between 2 release tags right?

So if I understand correctly, we could remove the development branch and use only master. Commits to master would just cause a build for validating and for testers to have a quick way to test nightly builds. Then when we manually create a release, Github asks for a tag for the release and this is what fires up a release build. Right ? We can then cleanup the release notes by editing the issue titles/tags if needed.

The only issue I find with deleting the development branch is that we then no longer have a branch that matches exactly the currently published release, so to get that you need to find that history using the release tag. Not a big issue though.

[EPTamminga]

@valadas Right.
Builds (commits to master, not just nightly) and releases (by a new tag).

[david-poindexter]

I agree guys - this sounds like a solid approach to move forward with. @ahoefling how does that impact your work for Build Pipeline based the preferred trigger above?