search

fluffynuts / NExpect

An assertions framework for .NET with a BDD-like feel, inspired by Chai and Jasmine, designed to be user-extensible
BSD 3-Clause "New" or "Revised" License
22 stars 8 forks source link

add github release workflow #33

Closed viceice closed 1 year ago

viceice commented 1 year ago

autogenerate github release with commit list as changelog

viceice commented 1 year ago

can squash the commits, or you can use squash merge to only have a single commit on main later

fluffynuts commented 1 year ago

looks interesting - would it be possible to tie this off to a version, ie not @latest? I'd like any changes to this to be only introduced intentionally; I'm assuming you've already tested that it works as expected (:

fluffynuts commented 1 year ago

@viceice bump can this workflow be versioned so that NExpect doesn't rely on a moving target?

Here's my concern: if, somehow, your account is compromised, someone could update the workflow and compromise at least NExpect. Versioning also means that when/if you make a cool upgrade, I'll know about it, because I'll have to see it in a PR (:

viceice commented 1 year ago

@viceice bump can this workflow be versioned so that NExpect doesn't rely on a moving target?

Here's my concern: if, somehow, your account is compromised, someone could update the workflow and compromise at least NExpect. Versioning also means that when/if you make a cool upgrade, I'll know about it, because I'll have to see it in a PR (:

Sure, but there is no v1 tag, so i can only pin to full version.

BTW: You can use renovate to let you suggest update pr's. I can help to configure, as i'm a maintainer of renovate 😉

fluffynuts commented 1 year ago

@viceice bump can this workflow be versioned so that NExpect doesn't rely on a moving target? Here's my concern: if, somehow, your account is compromised, someone could update the workflow and compromise at least NExpect. Versioning also means that when/if you make a cool upgrade, I'll know about it, because I'll have to see it in a PR (:

Sure, but there is no v1 tag, so i can only pin to full version.

That's perfect; since you're going to be the primary user of the output (at least for now), I'm quite sure you'll raise if it doesn't do what works for you (:

BTW: You can use renovate to let you suggest update pr's. I can help to configure, as i'm a maintainer of renovate wink

Thanks, I'll consider it; tbh, I mostly keep things up-to-date (enough) manually, but it might be interesting to try, when I get a gap :sweat_smile:

fluffynuts commented 1 year ago

mind you, I say you're the primary user for now, but this and PeanutButter would probably benefit from some kind of automated release changelog, so, let's see how nexpect goes (:

viceice commented 1 year ago

I'll test renovate on my fork, so you can see what renovate would suggest 🤗

viceice commented 1 year ago

mind you, I say you're the primary user for now, but this and PeanutButter would probably benefit from some kind of automated release changelog, so, let's see how nexpect goes (:

i hope there are more users who use nexpect and renovate, so there ist hopefully more benefit for all. 😅

fluffynuts commented 1 year ago

@viceice seems to be working nicely (: thanks (:

image

fluffynuts commented 1 year ago

A question I have is around how the title is generated - in this case, it's about accurate, but if I were to add new features, how does that happen? I've had a quick look at the workflow and it's not obvious to me. A (possbily) better generic title would just be "Release {version number}"

viceice commented 1 year ago

A question I have is around how the title is generated - in this case, it's about accurate, but if I were to add new features, how does that happen? I've had a quick look at the workflow and it's not obvious to me. A (possbily) better generic title would just be "Release {version number}"

The title isn't easily configurable with the generated version. You can define a fixed name or the action will use the tag name as title

https://github.com/marvinpinto/action-automatic-releases#supported-parameters

viceice commented 1 year ago

btw: the action uses conventional-commits-parser^1 internally to make the changelog sections.

fluffynuts commented 1 year ago

@viceice ah, ok, so there must have been a "fixes" prefix in the commit that made it into the "bug fixes" section. It would be nice to figure out a way for conventional-commits-parser to "understand" gitmoji - the aim of conventional commits and gitmoji is the same - I just find the latter more succinct and a little more "fun"

viceice commented 1 year ago

Sorry, that's not supported by that library 😞

fluffynuts commented 1 year ago

eh, it's not the end of the world - free releases done on a tag is a win anyway (: