Describe the solution you'd like
When I create a manual build, I would like the option to add my release notes to it so that when the build is done, the release notes will be the text I entered instead of the last commit message.
Describe alternatives you've considered
_(positives and negatives in parens)_
1) Best outcome, most frustrating: Disable automatic distribution, create a manual build, wait for the build to finish (---), edit the release notes and then distribute.
2) Less than ideal outcome but allows me to get the build out asap: Leave automatic distribution on, wait for the the build to finish (-), build finishes and gets distributed with an email with the commit message as the release notes (-), edit the release notes at your convenience (+) but hope you edit the notes in time before your QA team asks what's in the build because commit messages like "_Merge branch xyz into abc_" isn't always the best description or a complete summary of the release (---) 馃槄
Additional context
None.
I would note that the TestFlight distributions already allows you to do just this :ok_hand:
Hear ya that those workarounds are less than ideal. What would a good solution look like for you? Would you want a file that you check in that has the release notes to be picked up and populated when your automatic build kicks off?
If I'm using a manual build, having the Release Notes field in the build config window like the TestFlight one would be perfect. For automated builds, I'm guessing the best thing would be to use the CHANGELOG.md file and take the content under the first h2 header (until the 2nd h2 header) or something to that effect. Dumber version would be to take the entire release_notes.txt contents.
For automated builds, I'm guessing the best thing would be to use the CHANGELOG.md file and take the content under the first h2 header (until the 2nd h2 header) or something to that effect. Dumber version would be to take the entire release_notes.txt contents.
馃憦 馃憦 馃憦
Would also be cool to have the option to overwrite this / do this via the appcenter-cli tools appcenter build queue command.
Currently it's just triggers a build without any options.
Additionally, haven't seen any way to do this via the api: https://openapi.appcenter.ms/
I only do manual builds. When I submit to TestFlight there's a text field for the Release Notes as part of the distribution step. This exact UI should populate the Release Notes that are sent to Distribution Groups.
It should also be possible to edit the Release Notes later and have emails sent to the Distribution Group without creating a new release. HockeyApp does this.
I don't want to hijack this issue, but I would be a big fan of being able to specify release notes for automated builds. The most simple option would be to just have a text file that, if exists, would be used to populate the release notes. Everyone can use their own pre-build logic to populate that file. Alternatively, a new build script of which the output is used for release notes would work just fine as well.
There is a way to do this via the API but it doesn't work. It fails parsing newlines, even if they're escaped. The issue was first reported here https://github.com/Microsoft/appcenter/issues/210 and auto-closed for no response but is NOT resolved. Attempting to include multi-line release notes via the API call returns the following error, no matter what combination of newline-escaping I try. (It works if I include only a single line, but that's pretty useless.)
API call failed with 400: <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>SyntaxError: Unexpected token <br> in JSON at position 82<br> at JSON.parse (<anonymous>)<br> at parse (/home/node/data/node_modules/body-parser/lib/types/json.js:89:19)<br> at /home/node/data/node_modules/body-parser/lib/read.js:121:18<br> at invokeCallback (/home/node/data/node_modules/raw-body/index.js:224:16)<br> at done (/home/node/data/node_modules/raw-body/index.js:213:7)<br> at IncomingMessage.onEnd (/home/node/data/node_modules/raw-body/index.js:273:7)<br> at IncomingMessage.emit (events.js:203:15)<br> at IncomingMessage.EventEmitter.emit (domain.js:466:23)<br> at endReadableNT (_stream_readable.js:1145:12)<br> at process._tickCallback (internal/process/next_tick.js:63:19)</pre>
</body>
</html>
Updating the release notes through the API in a build script is something I hadn't yet considered - good to know that it wouldn't work XD.
EDIT: I might still try it though, the example in the issue you mentioned clearly isn't valid JSON so I can see why that wouldn't work. What kind of escaping did you try?
Allowing for a release-notes file is the best idea as it should cover all bases without needing to build out new UI. This should be minimal work the way I see it as the App Center CLI Distribute API already allows for a release notes file parameter.
https://github.com/microsoft/appcenter-cli/blob/4078689885794095a4842779e993fefa22dc29fa/src/commands/distribute/release.ts#L82
Regarding your last point, I created the following feature request to allow to tap into a post deployment script. If we had this we could just run a script following successful deployment to update the latest App Center built distribution.
https://github.com/microsoft/appcenter/issues/1989
I don't want to hijack this issue, but I would be a big fan of being able to specify release notes for automated builds. The most simple option would be to just have a text file that, if exists, would be used to populate the release notes. Everyone can use their own pre-build logic to populate that file. Alternatively, a new build script of which the output is used for release notes would work just fine as well.
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.
It's stale because it's not addressed, msftbot, not because it's not wanted.
Yeah. This is one of those obvious 1.0 type features. It鈥檚 completely ridiculous that it still has not been implemented even years later.
My guess is that most companies have either developed their own jury-rigged workaround solution by now or have few enough apps (like us) that it鈥檚 not too much of a pain to just handle manually.
Most helpful comment
If I'm using a manual build, having the Release Notes field in the build config window like the TestFlight one would be perfect. For automated builds, I'm guessing the best thing would be to use the
CHANGELOG.mdfile and take the content under the firsth2header (until the 2ndh2header) or something to that effect. Dumber version would be to take the entirerelease_notes.txtcontents.