-
Notifications
You must be signed in to change notification settings - Fork 285
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.
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
ci: custom check to verify uniform sibling dependency versions #1534
Labels
bug
Something isn't working
dependencies
Pull requests that update a dependency file
Developer_Experience
good-first-issue
Good for newcomers
good-first-issue-400-expert
Hacktoberfest
Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Nice-to-Have
P3
Priority 3: Medium
Security
Related to existing or potential security vulnerabilities
Comments
petermetz
added
bug
Something isn't working
dependencies
Pull requests that update a dependency file
Developer_Experience
good-first-issue
Good for newcomers
good-first-issue-400-expert
Hacktoberfest
Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Nice-to-Have
P3
Priority 3: Medium
Security
Related to existing or potential security vulnerabilities
labels
Nov 11, 2021
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Nov 12, 2021
…edger-cacti#1534 With this, the `yarn custom-checks` script will go through all the package.json files and validate the following things: 1. The top level "version" property in the package.json of the package is set to a value that equals whatever is set as the project-wide version of the monorepo as defined by the lerna.json file's "version" property. (the latter gets automatically bumped by the relese process) 2. Verifies that all dependencies within each package.json pointing to sibling packages are also using the correct version from lerna.json as described above. 3. Same check as in 2) but for the "devDependencies" section of each package.json file within the monorepo. The upside of this custom check is that maintainers no longer need to manually ensure that the version numbers are kept up to date which was especially tricky when a new package is being added in a pull request that has been open for a while and we issued one or more releases during the lifetime of the pull request. Fixes hyperledger-cacti#1534 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Nov 16, 2021
…edger-cacti#1534 With this, the `yarn custom-checks` script will go through all the package.json files and validate the following things: 1. The top level "version" property in the package.json of the package is set to a value that equals whatever is set as the project-wide version of the monorepo as defined by the lerna.json file's "version" property. (the latter gets automatically bumped by the relese process) 2. Verifies that all dependencies within each package.json pointing to sibling packages are also using the correct version from lerna.json as described above. 3. Same check as in 2) but for the "devDependencies" section of each package.json file within the monorepo. The upside of this custom check is that maintainers no longer need to manually ensure that the version numbers are kept up to date which was especially tricky when a new package is being added in a pull request that has been open for a while and we issued one or more releases during the lifetime of the pull request. Fixes hyperledger-cacti#1534 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
takeutak
pushed a commit
that referenced
this issue
Nov 16, 2021
With this, the `yarn custom-checks` script will go through all the package.json files and validate the following things: 1. The top level "version" property in the package.json of the package is set to a value that equals whatever is set as the project-wide version of the monorepo as defined by the lerna.json file's "version" property. (the latter gets automatically bumped by the relese process) 2. Verifies that all dependencies within each package.json pointing to sibling packages are also using the correct version from lerna.json as described above. 3. Same check as in 2) but for the "devDependencies" section of each package.json file within the monorepo. The upside of this custom check is that maintainers no longer need to manually ensure that the version numbers are kept up to date which was especially tricky when a new package is being added in a pull request that has been open for a while and we issued one or more releases during the lifetime of the pull request. Fixes #1534 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Leeyoungone
pushed a commit
to Leeyoungone/cactus
that referenced
this issue
Nov 19, 2021
…edger-cacti#1534 With this, the `yarn custom-checks` script will go through all the package.json files and validate the following things: 1. The top level "version" property in the package.json of the package is set to a value that equals whatever is set as the project-wide version of the monorepo as defined by the lerna.json file's "version" property. (the latter gets automatically bumped by the relese process) 2. Verifies that all dependencies within each package.json pointing to sibling packages are also using the correct version from lerna.json as described above. 3. Same check as in 2) but for the "devDependencies" section of each package.json file within the monorepo. The upside of this custom check is that maintainers no longer need to manually ensure that the version numbers are kept up to date which was especially tricky when a new package is being added in a pull request that has been open for a while and we issued one or more releases during the lifetime of the pull request. Fixes hyperledger-cacti#1534 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com> Signed-off-by: Youngone Lee <youngone.lee@accenture.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Something isn't working
dependencies
Pull requests that update a dependency file
Developer_Experience
good-first-issue
Good for newcomers
good-first-issue-400-expert
Hacktoberfest
Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Nice-to-Have
P3
Priority 3: Medium
Security
Related to existing or potential security vulnerabilities
Description
As a maintainer of a monorepo I want to have the CI ensure that we use the same version of sibling packages so that there's no strange, hard to trace issues (related to this at least) during the build.
(add more description and relevant links)
Acceptance Criteria
./tools/
directory1.0.0-rc.2
but of course this has to dynamically change within the check itself according to each release.The text was updated successfully, but these errors were encountered: