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

fix(lerna): aggressive patch bump #1163

Open
wants to merge 20 commits into
base: release-v10
Choose a base branch
from

Conversation

SudilHasithaCognite
Copy link
Contributor

@SudilHasithaCognite SudilHasithaCognite commented Oct 7, 2024

Addressing Lerna aggressive versioning

We restrict new npm releases to [release]-tagged commits because lerna is
quite aggressive in its versioning. Changes to any file not ignored by Lerna will
cause a PATCH bump. Markdown files and tests are ignored, but changing anything else,
like a comment in a source file, will trigger a new version,
irrespective of conventional commits.

References

  1. Lerna documentation: https://github.com/lerna/lerna/tree/main/libs/commands/version#--no-git-tag-version

Modifications made

  1. Create a dummy NPM package to verify the release logic to NPM registry.
  2. Added aRC tag removal script.
  3. Verify the expected behavior.
  4. Updated the CONTRIBUTIONS.md

@SudilHasithaCognite SudilHasithaCognite requested a review from a team October 7, 2024 09:28
@SudilHasithaCognite SudilHasithaCognite added the do-not-merge don't merge this PR until this label is gone. label Oct 8, 2024
Copy link

@EliasBjorne EliasBjorne left a comment

Choose a reason for hiding this comment

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

Im not too familiar with this setup, but from what I see, it seems like this changes a bit of the release logic. We should then also update the
CONTRIBUTING Readme
so it mirrors these changes. Both regarding to the logic we should have when we remove
--conventional-commits

The logic around bump-verion etc.

I'm not too opinionated on what the best release strategy is as long as it is well documented

.github/workflows/release.yaml Show resolved Hide resolved
.github/workflows/release.yaml Outdated Show resolved Hide resolved
@SudilHasithaCognite SudilHasithaCognite removed the do-not-merge don't merge this PR until this label is gone. label Oct 11, 2024
@SudilHasithaCognite
Copy link
Contributor Author

Im not too familiar with this setup, but from what I see, it seems like this changes a bit of the release logic. We should then also update the CONTRIBUTING Readme so it mirrors these changes. Both regarding to the logic we should have when we remove --conventional-commits

The logic around bump-verion etc.

I'm not too opinionated on what the best release strategy is as long as it is well documented

Updated the contributing guidelines.

@SudilHasithaCognite SudilHasithaCognite self-assigned this Oct 25, 2024
Copy link

@EliasBjorne EliasBjorne left a comment

Choose a reason for hiding this comment

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

I think we should add some details on how we want to work with release branches. In other repos I have worked with, all fixes are merged into master, and then fixes are cherry picked from master to release branches. We should have some documentation on how we want to do this?

CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated
@@ -166,72 +172,4 @@ git push && git push --tags
```

This will make a commit with the updated `package.json`, create a new git tag, and publish to npm.
Make sure you are logged in to npm, talk to a maintainer.

## Code overview
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder why the "Code overview" section is removed in the PR?

Comment on lines +102 to +108
if [[ "${GITHUB_REF}" == "refs/heads/master" ]]; then
EVENT_PATH_CONTENT=$(cat ${GITHUB_EVENT_PATH} | jq -r '.')
HEAD_COMMIT_MSG=$(echo $EVENT_PATH_CONTENT | jq -r '.head_commit.message')
MERGE_COMMIT_MSG=$(echo $EVENT_PATH_CONTENT | jq -r '.commits[-1].message')

if [[ "$HEAD_COMMIT_MSG" == *"Merge"* && "$HEAD_COMMIT_MSG" == *"release-"* && "$HEAD_COMMIT_MSG" == *"[release]"* ]] ||
[[ "$MERGE_COMMIT_MSG" == *"Merge"* && "$MERGE_COMMIT_MSG" == *"release-"* && "$MERGE_COMMIT_MSG" == *"[release]"* ]]; then
Copy link
Contributor

Choose a reason for hiding this comment

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

These checks are a bit hard to read. What's the intention?

Copy link
Contributor

Choose a reason for hiding this comment

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

Nice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants