Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: kotlin binary validator #183

Merged
merged 2 commits into from
Mar 31, 2023
Merged

docs: kotlin binary validator #183

merged 2 commits into from
Mar 31, 2023

Conversation

Shahroz16
Copy link
Contributor

@Shahroz16 Shahroz16 commented Mar 29, 2023 •
edited
Loading

Moved from the mobile repo to android one.

Complete each step to get your pull request merged in. Learn more about the workflow this project uses.

  • Assign members of your team to review the pull request.
  • Wait for pull request status checks to complete. If there are problems, fix them until you see that all status checks are passing.
  • Wait until the pull request has been reviewed and approved by a teammate
  • After pull request is approved, and you determine it's ready add the label "Ready to merge" to the pull request and it will automatically be merged.

@github-actions
Copy link

github-actions bot commented Mar 29, 2023 •
edited
Loading

Pull request title looks good 👍!

If this pull request gets merged, it will not cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.0.0. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

  • feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

  • fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

  • docs: - This pull request is making documentation changes, only.

  • refactor: - A change was made that doesn't fix a bug or add a feature.

  • test: - Adds missing tests or fixes broken tests.

  • style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

  • perf: - Changes improve performance of the code.

  • build: - Changes to the build system (maven, npm, gulp, etc)

  • ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

  • chore: - Other changes to project that don't modify source code or test files.

  • revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

@Shahroz16 Shahroz16 changed the title docs: Kotlin Binary Validator docs: kotlin binary validator Mar 29, 2023
@github-actions
Copy link

github-actions bot commented Mar 29, 2023 •
edited
Loading

Hey, there @Shahroz16 👋🤖. I'm a bot here to help you.

⚠️ Pull requests into the branch main typically only allows changes with the types: fix. From the pull request title, the type of change this pull request is trying to complete is: docs. ⚠️

This pull request might still be allowed to be merged. However, you might want to consider make this pull request merge into a different branch other then main.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

  • feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

  • fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

  • docs: - This pull request is making documentation changes, only.

  • refactor: - A change was made that doesn't fix a bug or add a feature.

  • test: - Adds missing tests or fixes broken tests.

  • style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

  • perf: - Changes improve performance of the code.

  • build: - Changes to the build system (maven, npm, gulp, etc)

  • ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

  • chore: - Other changes to project that don't modify source code or test files.

  • revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

@codecov
Copy link

codecov bot commented Mar 30, 2023 •
edited
Loading

Codecov Report

Merging #183 (69e5bd5) into main (3ed104a) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main     #183   +/-   ##
=========================================
  Coverage     63.52%   63.52%           
  Complexity      218      218           
=========================================
  Files            91       91           
  Lines          2051     2051           
  Branches        263      263           
=========================================
  Hits           1303     1303           
  Misses          646      646           
  Partials        102      102

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@github-actions
Copy link

Build available to test
Version: Shahroz-binary-validator-SNAPSHOT
Repository: https://s01.oss.sonatype.org/content/repositories/snapshots/

@Shahroz16 Shahroz16 requested a review from a team March 31, 2023 10:55
mrehan27
mrehan27 approved these changes Mar 31, 2023
View reviewed changes
Copy link
Contributor

@mrehan27 mrehan27 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some minor suggestions

docs/dev-notes/KotlinBinaryValidator Outdated
```groovy
apiValidation {
ignoredPackages += [
'io/customer/base/extenstions',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we please format this? 🤓

docs/dev-notes/KotlinBinaryValidator Outdated
ignoredProjects += [
'common-test',
'app',
]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formatting 🤓

docs/dev-notes/KotlinBinaryValidator Outdated

## Setup

Since its a simple Gradle plugin, we just need to add this code to our top level `build.gradle` file:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Since its a simple Gradle plugin, we just need to add this code to our top level `build.gradle` file:
Since it is a simple Gradle plugin, we just need to add this code to our top level `build.gradle` file:

docs/dev-notes/KotlinBinaryValidator Outdated
## Integrations

These `checks` are currently integrated with both
- `lefthook` - Using a pre-commit from lefthook, it will run the `apiCheck` task (and automatically run `apiDump` for you if it fails) when you try to create a new commit in the repository.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- `lefthook` - Using a pre-commit from lefthook, it will run the `apiCheck` task (and automatically run `apiDump` for you if it fails) when you try to create a new commit in the repository.
- `lefthook` - Using a pre-commit from lefthook, it will run the `apiCheck` task (and automatically run `apiDump` for you if it fails) when you try to create a new commit in the repository.

@Shahroz16 Shahroz16 merged commit a410e6d into main Mar 31, 2023
@Shahroz16 Shahroz16 deleted the Shahroz-binary-validator branch March 31, 2023 12:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mrehan27 mrehan27 mrehan27 approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Shahroz16 @mrehan27