feat(ci): adds more CI validations, introduces semantic release (#74)

[ygrishajev]

Feature: Enhance CI Validations and Introduce Semantic Release

This pull request introduces several enhancements to our Continuous Integration (CI) pipeline and implements Semantic Release for automated version management and changelog generation. These changes aim to bolster code quality and streamline our release process.

Key Changes

1. ESLint Integration

   • Added an ESLint check as a pre-commit hook to ensure that any commits comply with our coding standards.
   • Integrated ESLint checks into our CI pipeline to validate code style and catch issues early in the review process.

2. Commit Linting

   • Implemented commit linting both as a pre-commit hook and within the CI to enforce our commit message guidelines. This ensures that all commit messages are consistent and follow the Conventional Commits specification.

3. Semantic Release

   • Adopted Semantic Release to automate the versioning and changelog generation process. This tool leverages information from commit messages to determine version bumps and generate comprehensive changelogs automatically upon merging changes into the main branch.

4. Code Coverage Reporting

   • Enhanced our CI pipeline to include the upload of code coverage reports to Codecov. This allows us to monitor and maintain code quality effectively by reviewing coverage metrics for each pull request.

Benefits

• Improved Code Quality: By enforcing strict linting rules before commits and during CI, we reduce the likelihood of errors and ensure code consistency across the project.
• Automated Releases: Semantic Release automates the release cycle, reduces the manual effort required for version management, and ensures that our changelog is always up-to-date.
• Consistency in Commits: Enforcing commit message guidelines helps maintain a clean and navigable project history, facilitating easier troubleshooting and review processes.
• Transparent Code Quality Metrics: With code coverage results now visible on Codecov, contributors and reviewers can directly observe and address any areas lacking sufficient testing.

Additional Notes

• Please ensure to install the necessary hooks by running npm install after pulling these changes.
• Review the updated GitHub Actions configurations to understand the new CI checks.

Associated Issues

• Resolves Implement Commit Convention and Release Automation #74

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[ygrishajev]

as discussed with @baktun14 we also would need to properly handle commit linting for squash merge. On the surface solution is to take PR title as a squash commit and lint it to allow merge

[ygrishajev]

@akash-network/cloudmos I suggest that we split checks into dedicated jobs:

1. linting
2. tests
3. commit linting

Then protect merge in to main the same way it's done in https://github.com/akash-network/akash-api/settings/branch_protection_rules/34186868

This way those would run independently addressing a scenario like when you're pushing commits that wouldn't pass linting but would pass tests.

However there's an issue with this anyway. There is no way to conditionally allow a certain type of merge (squash/rebase/merge). So to address any case a feature PR would need to have valid commit messages AND the title. This would require to come up with proper commit names as you go and might kill the purpose of squash merge.

Let's try to work out what we'd like this to be

[baktun14]

@akash-network/cloudmos I suggest that we split checks into dedicated jobs:

1. linting
2. tests
3. commit linting

Then protect merge in to main the same way it's done in https://github.com/akash-network/akash-api/settings/branch_protection_rules/34186868

This way those would run independently addressing a scenario like when you're pushing commits that wouldn't pass linting but would pass tests.

However there's an issue with this anyway. There is no way to conditionally allow a certain type of merge (squash/rebase/merge). So to address any case a feature PR would need to have valid commit messages AND the title. This would require to come up with proper commit names as you go and might kill the purpose of squash merge.

Let's try to work out what we'd like this to be

Yea it would be a bit annoying to have to have valid commits AND title. Not the biggest deal, but I think since we've been doing squash merges from the beginning, it make sense to only apply the pr title contraint and suggest for the commits if you plan to do a normal merge.

[ygrishajev]

Yea it would be a bit annoying to have to have valid commits AND title. Not the biggest deal, but I think since we've been doing squash merges from the beginning, it make sense to only apply the pr title contraint and suggest for the commits if you plan to do a normal merge.

So one another way to do this may be to ONLY allow squash commits (not sure how would that work with just 1 in pr) and validate the title.

And another one (a mild one) would be not to fail a check but to post a warning.

I'd prob try going with the more strict one.

[baktun14]

Yea it would be a bit annoying to have to have valid commits AND title. Not the biggest deal, but I think since we've been doing squash merges from the beginning, it make sense to only apply the pr title contraint and suggest for the commits if you plan to do a normal merge.

So one another way to do this may be to ONLY allow squash commits (not sure how would that work with just 1 in pr) and validate the title.

And another one (a mild one) would be not to fail a check but to post a warning.

I'd prob try going with the more strict one.

Yea makes sense to me

[troian]

1. set the following in the project settings. that way commit will be clean

2. it is still good practice to format all commits within PR with semantics of conventional commits