I personally don't like how multiple builds of Danger makes it edit it's first comment instead of posting new ones, because it makes the comment chain rather confusing. It's specially worse to my team since we use 'Test it!' to trigger it, so usually the comments section consist of the same guy posting 'Test it!' a few times, with a single Danger comment on the top of the chain. Visually, it doesn't look nice.. It would be really cool if it had an option to post new comments instead of editing the first one.
That does sound like a useful option 馃憤 - not sure what the arg could be maybe --no-edit?
@orta --immutable-comment, --static-comment, --no-modify-comments?
--replace-comment?
Since this would be a result of multiple runs of danger, perhaps --new-comment ?
Hrm, if this will result in a new comment _every_ time, then we should re-use existing infrastructure - we already support a --danger_id=<id> The identifier of this Danger instance option, so this should be --unique-danger-id which would create a timestamp based id, which means it will create a new comment each time.
I'm not sure what that's about piv199 - however, if you wanted to, you could do this without writing any code too:
bundle exec danger --danger_id="$BUILD_NUMBER"
That worked @orta ! Awesome!
I do believe this functionality needs an argument with a more obvious name though, so I'll definitely take a shot at this :)
Implemented in #632.
Most helpful comment
Hrm, if this will result in a new comment _every_ time, then we should re-use existing infrastructure - we already support a
--danger_id=<id> The identifier of this Danger instanceoption, so this should be--unique-danger-idwhich would create a timestamp based id, which means it will create a new comment each time.I'm not sure what that's about piv199 - however, if you wanted to, you could do this without writing any code too:
bundle exec danger --danger_id="$BUILD_NUMBER"