Appcenter: Get release notes from text file or build script for automated builds

[ElteHupkes]

Describe the solution you'd like
I would like to be able to specify the release notes for an automated build through a text file or build script. Pushing to certain branches is almost a one step solution to a distributed build, except right now I still have to go in and manually change the release notes. The latest commit message tends not to be a suitable message to actually display to our users. It would be great if I had some other way of specifying a commit message for automated builds.

Describe alternatives you've considered
I could try something through the API from a build script, although I'm not sure if I can still change the release notes once the build action is already underway, and setting up the tokens would be a hassle. I could also take the latest release notes and create a commit local to the build server that includes them. Depending on the order in which App Center fetches the commit message for the release notes this may be a viable workaround. Came up with this while creating this issue, I'll try ;).

[alexcnichols]

Thanks for reaching out @ElteHupkes. Adding some automation around release notes could make distribution easier, I agree. I've seen it done using add-ins with commit messages over in GitHub and with work items in Azure DevOps before. Adding @botatoes for visibility and consideration with other priorities in this area.

[ElteHupkes]

@alexcnichols Thanks! For my potential workaround, do you have any idea exactly how the build fetches the latest commit message? I see at the end of my build log that a distribution task is called:

##[section]Starting: Create distribution
==============================================================================
Task         : App Center distribute
Description  : Distribute app builds to testers and ***s via Visual Studio App Center
Version      : 3.158.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/deploy/app-center-distribute
==============================================================================
##[section]Finishing: Create distribution

Which from its documentation seems to take either a file with release notes or a direct message, but I don't think I can see which one is used or where it comes from. If it uses the message from the exact commit hash that its building with I probably won't be able to change it in the build script, but in any other scenario I may have something to work with.

[alexcnichols]

Not sure @ElteHupkes. If you are considering the Azure Pipelines route.. the App Center distribute task does off that ability to reference a file in the repo. Since you mentioned that the commit messages themselves were more internally-facing than customer-facing, updating a CHANGELOG type of file in the repo with the latest release notes prior to distribution could be the way to go. https://docs.microsoft.com/en-us/appcenter/distribution/vsts-deploy

[ElteHupkes]

@alexcnichols Thanks, but currently everything is running through App Center and App Center alone, which I like a lot, so I'm probably going to keep on hoping for a workaround in that context - or a feature of course :).

[shrikanthkr]

This one seems to be a necessary feature when we totally rely on appcenter for building and distribution.

[calintamas]

+1

[jfrolich]

It would be very nice to have a way to set release messages during the build process. The latest commit message is pretty bad, and it would be nice to get it from the latest git tag or something. We could do it ourselves if release notes could be set by setting for instance a environment variable in the build process.

[clemblanco]

Please make an optional CHANGELOG.md or CHANGELOG file located at the root the default source for release notes when present rather than the latest commit message.

[jfrolich]

@clemblanco: Github releases using git tags are probably a more structured way of doing that (and you can pin a release to a commit).

[clemblanco]

@jfrolich I'm not sure I understand. We use Git tags and Github releases once it's all merged but the release notes on AppCenter when distributing or testing purposes are always using the latest commit message by default. Would be nice to have this grabbing the content of a CHANGELOG file instead.

This is what I'm talking about, on AppCenter:

This would be for the people testing a specific build from AppCenter to know what has changed. If we automate the distribution to a specific destination, we can only have one default value or have to manually type it in AppCenter every time.

[gturedi]

how can we put last 10 commit messages to release notes on gradle builds?

[dkoprowski]

I was trying to git amend last commit message inside post-clone script but it doesn't work. They must catch message somehow.

I don't understand why there is no way to inject release notes despite of Azure Pipeline takes those arguments - looks like an easy feature to implement and it's here for more than six months now.

[github4es]

How are people doing the customer-facing release notes via app center now then?
I see this is supported via the cli

appcenter distribute stores publish \
--file /path/to/file.aab \
--store Production \
--app {app_owner}/{app_name} \
--release-notes "Some note."

[ElteHupkes]

I do them by hand for production releases, and the beta releases just don't have release notes. Calling the API from a build script kinda seems to defeat the purpose to me.

[clemblanco]

Any news on this? I can do this using the CLI but I want AppCenter to automate that so I don't have to run any command myself.

appcenter distribute stores publish \
--file /path/to/file.ipa \
--store Production \
--app {app_owner}/{app_name} \
--release-notes-file CHANGELOG

[joehanna]

Please make an optional CHANGELOG.md or CHANGELOG file located at the root the default source for release notes when present rather than the latest commit message.

This is a great concept which is also employed by other CI/CD providers. The build should take the release notes from a markdown file from within the repo, but the path to it usually defined in the build configuration (eg Bitrise)

Please, no more “magic” files/scripts in the root of the repo. Build scripts and files should be in a sub folder (.appcenter?) so they don’t have to be looked at every time we view the repo. These items are ultimately set-and-forget files.

[hugo-advizr]

We also need this for our use case since we distribute multiple apps on behalf of our clients and we’d like to automate the whole distribution process.

Is there a workaround to programmatically set the release notes today?

[dkoprowski]

Hey, @hugo-advizr it is possible to use webhooks. I've created a simple Nodejs service that receives HTTP POST from AppCenter, generates description and edit description trough HTTP callback.

It takes lots for workaround work and a server but it is possible...

[ElteHupkes]

It might be possible to do something with one of the build scripts, changing the release notes through the App Center API post clone. On the other hand, it's possible (likely, actually, when I think about it) that the whole build configuration is already retrieved at that point and it won't make a difference before the next build. That fact combined with how crappy this is to debug (you basically need to do a whole build and distribute to check if your approach is working) has kept me from pursuing this so far. Also, we have release notes in multiple languages, which aren't supported even manually in App Center right now.

[hugo-advizr]

@dkoprowski @ElteHupkes thanks a lot for your feedback, it seems any workaround today requires a lot of tinkering and even if possible it'll be flaky at best.

Can anyone from the AppCenter dev team (@botatoes @alexcnichols) give some feedback on the idea of simply allowing an env variable to be set to override the release notes for the current build? this seems pretty easy to implement and it'd allow for any logic to grab the contents on our end.

[coldacid]

I'm partial to using a tag message rather than a changelog file, since changelog files tend to have changes for more than just the latest version. A tag message is far more likely to have a list of only what's changed since the last version instead.

[jfrolich]

I'm partial to using a tag message rather than a changelog file, since changelog files tend to have changes for more than just the latest version. A tag message is far more likely to have a list of only what's changed since the last version instead.

100% agree. It will have as the benefit that all those messages are part of the github repo (and easy to see what has been changed for a diff).

[rodrigomafei]

I believe reading a changelog file would be a good solution.