Node dependencies management #205
Replies: 1 comment 3 replies
-
|
hi @yeraydavidrodriguez thank you for the good summary!. I want to add that I do not remember why we decided not to use the A `dependanbot's commit looks like:
I think the original reason was that we wanted to have all commit signed. But all commits are signed anyway by the GitHub bot. I suppose it does not matter if we sign them with our bot GPG key or the GitHub GPG key, does it? Unless we want to sign commits with our GPG key I do not see any problem anymore. The could have been also a misunderstanding. When we merge a PR we lose the original author commit signature if we use "rebase and merge" option because GitHub creates new commits even if FF is possible. The new commits have the GitHub bot signature. But I suppose no matter what merge strategy we use we still have at least the bot signature. In the future we are planning to have at least two branches Anyway, we have to decide if it still makes sense or not. Becuase definitively it's a slower and more painful way to do it. |
Beta Was this translation helpful? Give feedback.
-
|
I've just found out why we did not want to use the
The $ git show --pretty=fuller --show-signature 3787ed9b8e643913415dd5484cf215a37e368e26
commit 3787ed9b8e643913415dd5484cf215a37e368e26
Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
AuthorDate: Tue May 17 00:33:05 2022 +0000
Commit: Jose Celano <[email protected]>
CommitDate: Tue May 17 09:11:37 2022 +0100
build(deps): bump actions/setup-node from 3.1.1 to 3.2.0
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3.1.1 to 3.2.0.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v3.1.1...v3.2.0)
---
updated-dependencies:
- dependency-name: actions/setup-node
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <[email protected]>
|
Beta Was this translation helpful? Give feedback.
-
|
I've rebased that commit: $ git show --pretty=fuller --show-signature 7f0a6bd72195528a643f6151a70c2b928c5e258b
commit 7f0a6bd72195528a643f6151a70c2b928c5e258b
gpg: Signature made mar 17 may 2022 10:17:37 WEST
gpg: using RSA key 76BF41FD8C0589E1D5288B29E7279F2518CA55C6
gpg: Good signature from "Nautilus Cyberneering [bot] (Online Key) <[email protected]>" [ultimate]
Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
AuthorDate: Tue May 17 00:33:05 2022 +0000
Commit: Nautilus Cyberneering [bot] [josecelano] <[email protected]>
CommitDate: Tue May 17 10:17:37 2022 +0100 |
Beta Was this translation helpful? Give feedback.
-
|
This is another commit example where the
|
Beta Was this translation helpful? Give feedback.
-
We have had some internal discussions on how to manage node dependencies in a safe, error-free way, without having to consume too much time.
General Dependencies update approach
Currently, dependabot warns us about new versions in the dependencies, as described in the package.json file. And also, we use yarn as the project package manager.
Those two facts gives us some alternatives on how to manage the dependencies. The most obvious ones are:
1.1. We use github's branch merge button to make it fast and quick
1.2. We use manual rebase+merge to apply the updates
yarn upgradecommand to apply all (or just a subset) of the updates and we manually close dependabot's issues after doing so (although they should be automatically closed by dependabots after applied).Both options have caveats and things to consider:
1.1. Github merge/rebase buttons has issues regarding commit signatures. We do not use them in "regular" code PRs, so we shouldn't use it for dependency updates.
1.2. Manual rebase+merge of each one of the dependencies update can be very time consuming, specially as dependencies grow larger.
2.
yarn upgradehonors the version range specification in the package definition file, while dependabot proposes all kind of updates. This means that, if we specify "only minor updates" in our package.json (something very usual), some dependabots PRs won't be applied just by usingyarn upgradeAfter a discussion with @josecelano , we though that the option 2 is the most adequate, but we should use
yarn upgrade --latest. Then, manually close any dependabot update already applied with this (should be all, usually)Issues and branches
Dependencies updates should be in an independent branch, as any other code modification. We propose reusing always the same issue and the same branch for dependencies update. That way we have a dependency update history (issue) and a consistent updates branch that can be used for automation. If a dependency breaks the code (i.e, does not compile or the tests do not pass), it should be solved in a separate, specific issue.
The updates steps
Given everything, the process of dependencies updates would be as follows:
General update (roughly once a week):
yarn upgrade --majorIf a security alert is warned by dependabot (critical security vulnerability)
Please, @josecelano , @da2ce7 , @ivanramosnet , make your comments and amends on all this.
Beta Was this translation helpful? Give feedback.
All reactions