ci: automate release

[hanbyul-here]

Close #1236

Description of Changes

Add packages, and configuration to make automated release work Add an action to release a package every Monday Add an action to check PR title to follow conventional commit pattern

Notes & Questions About Changes

If you would like to peek at how our release will look like with automation, I experimented it in this repo. Heads-up that there are many empty releases because I was experimenting with scheduling (cron) : https://github.com/hanbyul-here/release-test/releases/

Conventional commit format

For conventional commits, we have a couple of options for adoption:

1. Require PR title to follow the conventional commit format.
2. Require every commit message to follow the conventional commit format.

I think either approach can work as long as we maintain consistency. Personally, I find option 2 a bit challenging since features or fixes often involve multiple commits, making conventional commit prefixes redundant information.

Currently, this PR only enforces that the PR title follows the conventional commit format. However, this requires some changes to the repository setup. Specifically:

1. We need to modify the merge commit message to use the PR title instead of GitHub's default automated message (Merged...). - We can do this through GitHub repo settings.
2. Optionally, we could set "squash and merge" as the default merge method. This would make sure that each PR results in a single commit on the main branch, creating a cleaner commit history. (do we really need all those "WIP" commits on the main branch?) That said, I’m slightly hesitant about squash-and-merge because it makes it harder to trace individual commits, even though we can still use reflog to recover them if necessary.

Using conventional commit as a productivity tool

The action that I am using actually offers a lot of functionality, such as ticket number validation and labeling. I adopted the most minimum possible settings, but maybe we can take more advantage of it? @aboydnw - This is the package I am using and there are detailed writings about what it can do on its read me page: https://github.com/ytanikin/PRConventionalCommits would you find anything useful ?

Validation / Testing

I'd like to go over this PR together. Some items to check together

• How deploy key is tied to an individual (If I need to offboard from VEDA, deploy key would need to be refreshed)
• How to trigger release manually
• Change GitHub PR default setting (to use the title of PR instead of creating an additional message Merged...)

[netlify[bot]]

✅ Deploy Preview for veda-ui ready!

Name	Link
🔨 Latest commit	b9afbd955074d92d9d25a5205749c672f7443fa5
🔍 Latest deploy log	https://app.netlify.com/sites/veda-ui/deploys/673ed9427e6d2c0008748cb2
😎 Deploy Preview	https://deploy-preview-1269--veda-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[aboydnw]

@aboydnw - This is the package I am using and there are detailed writings about what it can do on its read me page: https://github.com/ytanikin/PRConventionalCommits would you find anything useful ?

I see task labeling and ticket number validation as optional features. Personally, I don't think we need either of these at this point. Just my opinion, though, feel free to implement if you disagree.

Task Labeling:

• The only issue type label I like to use is "Bug" and that's really just for outward visibility and tracking. I think the differences between all the other issue types (feature, ci/cd, task, improvement, etc) are relatively small and don't really change anything about how we solve, communicate, or prioritize them. For example, if we were really interested in minimizing new feature requests for a while, or clearing out a bunch of tech debt tasks, then maybe this label would be more valuable. At the moment, though, I don't think we use this sort of thing in our workflow to warrant using this feature.

Ticket Number Validation:

• I assume this is to make sure everything we do has a ticket associated with it. I think if we were really tight about story points and understanding velocity. Or if we were somehow compensated based on number of tickets we completed, then maybe something like this would be more valuable. Right now, I think this would only add an admin layer that we probably don't need. I think we're pretty good about only opening PRs that are related to tickets, we don't have people going rogue and doing work unrelated to the sprint goals. And when we do, it's usually for a really good reason and I wouldn't want to slow that down.

[AliceR]

Thank you for your efforts to improve our release process @hanbyul-here !

I personally agree that prefixing every commit might be excessive, especially when writing smaller feature commits. I’d lean towards the approach of requiring the PR title to follow the conventional commit format (1. Require PR title to follow the conventional commit format).

Regarding squashing, I think it’s best to clean up the WIP/fix/comment commits locally before opening a PR or marking it as ready for review. I usually handle this with an interactive rebase, allowing me to merge, rewrite, or refine commit messages and descriptions as needed. That way, we can keep the history clean but still complete in the main branch, which can sometimes be useful for tracing back a thought or decision.

---

By the way, should the task type for this PR be "ci"? I see "feat" as something that typically involves user-facing changes, whereas this is only about the CI pipeline.