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.

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

Closed
petermetz opened this issue Nov 11, 2021 · 0 comments · Fixed by #1535
Closed

ci: custom check to verify uniform sibling dependency versions #1534

petermetz opened this issue Nov 11, 2021 · 0 comments · Fixed by #1535
Assignees
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
Copy link
Contributor

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

  1. A new custom check is developed within the ./tools/ directory
  2. Said custom check is included in the existing npm script that the CI runs for custom checks
  3. The custom check ensures that all monorepo packages who depend on each other are doing so using the latest released version number which at the time of this writing is 1.0.0-rc.2 but of course this has to dynamically change within the check itself according to each release.
@petermetz 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 petermetz self-assigned this 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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant