From 60741a8cd1f1496fc18235b83bcf30507d2102d0 Mon Sep 17 00:00:00 2001 From: soridalac Date: Fri, 30 Oct 2026 14:43:21 -0700 Subject: [PATCH 1/4] chore: add missing OSS compliance files --- CODEOWNERS | 2 ++ CONTRIBUTING.md | 43 +++++++++++++++++++++++++++++++++++++++++++ DEVELOPING.md | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 94 insertions(+) create mode 100644 CONTRIBUTING.md create mode 100644 DEVELOPING.md diff --git a/CODEOWNERS b/CODEOWNERS index 0ded67ad..37df2687 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -3,3 +3,5 @@ # Comment line immediately above ownership line is reserved for related other information. Please be careful while editing. #ECCN:Open Source +#GUSINFO:Platform CLI,Platform CLI +* @salesforcecli/cli diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..dbbbe3c9 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,43 @@ +## Contributing + +1. The [DEVELOPING](DEVELOPING.md) doc has details on how to set up your environment. +1. Familiarize yourself with the codebase by reading the docs, which you can generate locally by running `yarn docs`. +1. Create a new issue before starting your project so that we can keep track of + what you are trying to add/fix. That way, we can also offer suggestions or + let you know if there is already an effort in progress. +1. Fork this repository. +1. Create a _topic_ branch in your fork based on the main branch. Note, this step is recommended but technically not required if contributing using a fork. +1. Edit the code in your fork. +1. Write appropriate tests for your changes. Try to achieve at least 95% code coverage on any new code. No pull request will be accepted without unit tests. +1. Sign CLA (see [CLA](#cla) below). +1. Send us a pull request when you are done. We'll review your code, suggest any + needed changes, and merge it in. + +### CLA + +External contributors will be required to sign a Contributor's License +Agreement. You can do so by going to https://cla.salesforce.com/sign-cla. + +## Branches + +- We work in branches off of `main`. +- Our released (aka. _production_) branch is `main`. +- Our work happens in _topic_ branches (feature and/or bug-fix). + - feature as well as bug-fix branches are based on `main` + - branches _should_ be kept up-to-date using `rebase` + - [commit messages are enforced](DEVELOPING.md#When-you-are-ready-to-commit) + - see below for further merge instructions + +### Releasing + +- A new version of this library will be published upon merging PRs to `main`, with the version number increment based on commitizen. + +## Pull Requests + +- Develop features and bug fixes in _topic_ branches. +- _Topic_ branches can live in forks (external contributors) or within this repository (committers). + \*\* When creating _topic_ branches in this repository please prefix with `/`. + +### Merging Pull Requests + +- Pull request merging is restricted to squash & merge only. diff --git a/DEVELOPING.md b/DEVELOPING.md new file mode 100644 index 00000000..540eea03 --- /dev/null +++ b/DEVELOPING.md @@ -0,0 +1,49 @@ +## Pre-requisites + +1. We typically use the active NodeJS LTS. If you need to work with multiple versions of Node, you + might consider using [nvm](https://github.com/creationix/nvm). +1. This repository uses [yarn](https://yarnpkg.com/) to manage node dependencies. Please install yarn globally using `npm install --global yarn`. + +## Typical workflow + +You would only do this once after you cloned the repository. + +1. Clone this repository from git. +1. `cd` into the cloned repository. +1. We develop using feature brances off `main` and release from the `main` branch. At + this point, you should do initiate a `git checkout -t origin/main`. +1. `yarn` to bring in all the top-level dependencies. +1. Open the project in your editor of choice. + +###### When you are ready to commit + +1. We enforce commit message format. We recommend using [commitizen](https://github.com/commitizen/cz-cli) by installing it with `yarn global add commitizen` then commit using `git cz` which will prompt you questions to format the commit message. +1. Before commit and push, husky will run several hooks to ensure the message and that everything lints and compiles properly. + +## List of Useful commands + +### `yarn compile` + +This compiles the typescript to javascript. + +### `yarn clean` + +This cleans all generated files and directories. Run `yarn clean-all` to also clean up the node_module directories. + +### `yarn test` + +This tests the typescript using ts-node. + +### `yarn docs` + +This generates documentation into the `docs` directory. + +### `yarn lint` + +This lints all the typescript. If there are no errors/warnings +from tslint, then you get clean output. But, if there are errors from tslint, +you will see a long error that can be confusing – just focus on the tslint +errors. The results of this are deeper than what the tslint extension in VS Code +does because of [semantic lint +rules](https://palantir.github.io/tslint/usage/type-checking/) which requires a +tsconfig.json to be passed to tslint. From e3be9a03db590b1b0bd67e023df52b3c51ea0132 Mon Sep 17 00:00:00 2001 From: soridalac Date: Mon, 2 Nov 2026 12:19:56 -0800 Subject: [PATCH 2/4] chore: simplify CONTRIBUTING.md, remove DEVELOPING.md for GHA repo --- CONTRIBUTING.md | 15 +++------------ DEVELOPING.md | 49 ------------------------------------------------- 2 files changed, 3 insertions(+), 61 deletions(-) delete mode 100644 DEVELOPING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index dbbbe3c9..e8d8794d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,14 +1,11 @@ ## Contributing -1. The [DEVELOPING](DEVELOPING.md) doc has details on how to set up your environment. -1. Familiarize yourself with the codebase by reading the docs, which you can generate locally by running `yarn docs`. 1. Create a new issue before starting your project so that we can keep track of what you are trying to add/fix. That way, we can also offer suggestions or let you know if there is already an effort in progress. -1. Fork this repository. +1. Fork this repository (external contributors) or branch off main (committers). 1. Create a _topic_ branch in your fork based on the main branch. Note, this step is recommended but technically not required if contributing using a fork. -1. Edit the code in your fork. -1. Write appropriate tests for your changes. Try to achieve at least 95% code coverage on any new code. No pull request will be accepted without unit tests. +1. Edit the code in your fork/branch. 1. Sign CLA (see [CLA](#cla) below). 1. Send us a pull request when you are done. We'll review your code, suggest any needed changes, and merge it in. @@ -21,16 +18,10 @@ Agreement. You can do so by going to https://cla.salesforce.com/sign-cla. ## Branches - We work in branches off of `main`. -- Our released (aka. _production_) branch is `main`. +- Other repos reference `main` directly from this repository. - Our work happens in _topic_ branches (feature and/or bug-fix). - feature as well as bug-fix branches are based on `main` - branches _should_ be kept up-to-date using `rebase` - - [commit messages are enforced](DEVELOPING.md#When-you-are-ready-to-commit) - - see below for further merge instructions - -### Releasing - -- A new version of this library will be published upon merging PRs to `main`, with the version number increment based on commitizen. ## Pull Requests diff --git a/DEVELOPING.md b/DEVELOPING.md deleted file mode 100644 index 540eea03..00000000 --- a/DEVELOPING.md +++ /dev/null @@ -1,49 +0,0 @@ -## Pre-requisites - -1. We typically use the active NodeJS LTS. If you need to work with multiple versions of Node, you - might consider using [nvm](https://github.com/creationix/nvm). -1. This repository uses [yarn](https://yarnpkg.com/) to manage node dependencies. Please install yarn globally using `npm install --global yarn`. - -## Typical workflow - -You would only do this once after you cloned the repository. - -1. Clone this repository from git. -1. `cd` into the cloned repository. -1. We develop using feature brances off `main` and release from the `main` branch. At - this point, you should do initiate a `git checkout -t origin/main`. -1. `yarn` to bring in all the top-level dependencies. -1. Open the project in your editor of choice. - -###### When you are ready to commit - -1. We enforce commit message format. We recommend using [commitizen](https://github.com/commitizen/cz-cli) by installing it with `yarn global add commitizen` then commit using `git cz` which will prompt you questions to format the commit message. -1. Before commit and push, husky will run several hooks to ensure the message and that everything lints and compiles properly. - -## List of Useful commands - -### `yarn compile` - -This compiles the typescript to javascript. - -### `yarn clean` - -This cleans all generated files and directories. Run `yarn clean-all` to also clean up the node_module directories. - -### `yarn test` - -This tests the typescript using ts-node. - -### `yarn docs` - -This generates documentation into the `docs` directory. - -### `yarn lint` - -This lints all the typescript. If there are no errors/warnings -from tslint, then you get clean output. But, if there are errors from tslint, -you will see a long error that can be confusing – just focus on the tslint -errors. The results of this are deeper than what the tslint extension in VS Code -does because of [semantic lint -rules](https://palantir.github.io/tslint/usage/type-checking/) which requires a -tsconfig.json to be passed to tslint. From f92e8a06c1b783f5c23126b5caaeb80202225f2c Mon Sep 17 00:00:00 2001 From: soridalac Date: Mon, 2 Nov 2026 12:38:37 -0800 Subject: [PATCH 3/4] fix: update contributing.md --- CONTRIBUTING.md | 35 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e8d8794d..7d8b478d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,34 +1,31 @@ ## Contributing -1. Create a new issue before starting your project so that we can keep track of - what you are trying to add/fix. That way, we can also offer suggestions or - let you know if there is already an effort in progress. -1. Fork this repository (external contributors) or branch off main (committers). -1. Create a _topic_ branch in your fork based on the main branch. Note, this step is recommended but technically not required if contributing using a fork. -1. Edit the code in your fork/branch. -1. Sign CLA (see [CLA](#cla) below). -1. Send us a pull request when you are done. We'll review your code, suggest any - needed changes, and merge it in. +1. Please create a new issue [here](https://github.com/forcedotcom/cli/issues) before starting any work so that we can also offer suggestions or let you know if there is already an effort in progress. +1. Sign the Salesforce [CLA](#cla). +1. The CLI team will review your pull request and provide feedback. +1. Once merged, a new release of `@salesforcecli/github-workflows` will be published to [npm](https://www.npmjs.com/package/@salesforcecli/github-workflows). ### CLA -External contributors will be required to sign a Contributor's License +External contributors are required to sign a Contributor License Agreement. You can do so by going to https://cla.salesforce.com/sign-cla. ## Branches - We work in branches off of `main`. +- Our release (aka. _production_) branch is `main`. - Other repos reference `main` directly from this repository. - Our work happens in _topic_ branches (feature and/or bug-fix). - - feature as well as bug-fix branches are based on `main` - - branches _should_ be kept up-to-date using `rebase` + - Feature as well as bug-fix branches are based on `main` + - Branches _should_ be kept up-to-date using `rebase` ## Pull Requests -- Develop features and bug fixes in _topic_ branches. -- _Topic_ branches can live in forks (external contributors) or within this repository (committers). - \*\* When creating _topic_ branches in this repository please prefix with `/`. - -### Merging Pull Requests - -- Pull request merging is restricted to squash & merge only. +- Develop features and bug fixes in _topic_ branches off main, or forks. +- _Topic_ branches can live in forks (external contributors) or within this repository (internal contributors). + - When creating _topic_ branches in this repository please prefix with `/`. For example: `mb/refactor-tests`. +- Use [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) to drive semver versioning. Examples: + - `chore: my chore message` --> No release + - `fix: my fix message` --> Patch release + - `feat: my feat message` --> Minor release +- PRs will be reviewed and merged by the CLI team. From 6fd144a08df588a2e18d87d7fa695b79558d8fc7 Mon Sep 17 00:00:00 2001 From: Sorida <96142310+soridalac@users.noreply.github.com> Date: Tue, 3 Nov 2026 09:24:53 -0800 Subject: [PATCH 4/4] Fix: Add Code of Conduct reference to CONTRIBUTING.md --- CONTRIBUTING.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7d8b478d..80553b8e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,6 @@ ## Contributing +1. Please read our [Code of Conduct](CODE_OF_CONDUCT.md). 1. Please create a new issue [here](https://github.com/forcedotcom/cli/issues) before starting any work so that we can also offer suggestions or let you know if there is already an effort in progress. 1. Sign the Salesforce [CLA](#cla). 1. The CLI team will review your pull request and provide feedback.