Automating Releases with GitHub Actions

[@dotkoon]

This tutorial helped me a lot, thank you!

[@MrZasimovich]

Thanks a lot for the Tutorial and link to the source code!

[@aarondz789]

Keep going.Thanks.

[@peoray]

Thank you for the tutorial :)
Quick question! It seems that the action only runs from when the yml file was created as it does not show commits from when the project was created. Is there a way to show all the commits from the start of the project until the time the tag is created?

[@nodematic]

It should include all commits between the new semver-looking tag and the latest semver-looking tag before it. To get a release with everything since the initial project commit then, you could tag the initial commit (e.g., "v0.0.1"), then tag your latest commit (e.g., "v0.1.0").
This retroactive initial commit tagging approach will work as long as you don't already have a bunch of semver-looking tags in the repo. In that case, you may need to just manually edit the GitHub Release and paste in additional commits.

[@peoray]

@@nodematic Thanks for the reply but I'm confused. Do you mean, I can manually add a new tag as long as I don't have other tags in between?

[@nodematic]

The plugin logic is a bit complex, but yes, I think you're correct. Basically, when the plugin creates a new tagged release, it will find every commit since the previous tag before it, and reports those commits. So, to have commits since the start of the repository, you have two choices, depending on if the repository already has tags or not:
1. (If there are no tags in the repo) Tag the initial commit (e.g., "v0.0.0"), then tag your release commit and it will report all of your commits since the initial commit.
2. (If tags are already in the repo) I don't know how to automatically do this with the plugin, so maybe just create a tagged release, then manually "Edit" the release in the GitHub UI, and manually add the additional commits. You could get the additional commits in the right format to manually copy-paste into the release by running something like the command here gist.github.com/nodematiclabs/12dcb4a1137363af35c7755ab9801bd7 (I used bash/Linux here)
Note that when I say "tags" here, I mean tags that look like a version (semver stuff like "v2.3.35"). A tag like "foo" is ignored by the plugin.

[@aswinshanmugam2387]

Thank you for the Video :). Got same clarity.
can we use dependabot in "First" repo to check changes in actions in "Second" repo.
If there is a change in "Second" repo, dependabot should trigger the actions automatically in First repo.
Is that possible?

[@nodematic]

That might be possible with a webhooks setup in the second repository and a workflow dispatch trigger in the first repository, but you would probably need to create and run a bit of software yourself for this to work. I don't believe there's an easy way to achieve the setup you describe.

[@larrylampley6504]

Tonya hackney