search

customerio / cio-sdk-tools

A self service tool to run diagnostics on your mobile SDK installation
MIT License
2 stars 0 forks source link

ci: added distribution and linting #3

Closed Shahroz16 closed 11 months ago

Shahroz16 commented 11 months ago

You can ignore all ts under src files because it's just linting.

We made sure all code-related changes were done #2 and this is just for linting and deployments

github-actions[bot] commented 11 months ago

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: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` 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](https://www.conventionalcommits.org/). **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 commented 11 months ago

@levibostian thanks for the feedback, regarding the reutilization of the code from the npm mobile repositories. The code might be similar but it's not identical because we aren't using yarn anywhere and relying on npm. But in those, we are using yarn and npm both everywhere.

Secondly, those workflows and scripts had some extra steps which might not always be needed, for example, slack postings. Plus they consist of extra/un-utilized steps and conditions, you might also find typos like deploying cocoa pods whereas those npm modules don't deploy anything on cocoa pods.

I plan on cleaning those scripts up later on but didn't want to make that a part of this ticker to avoid scoop creep.

levibostian commented 11 months ago

Great. If you could create a ticket to make node workflows/scripts more re-usable that would be great.