-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Add automation for updating OpenSSL
dependency
#45605
Conversation
Review requested:
|
1. Check the `CHANGES.md` file in the [repo](https://github.com/quictls/openssl) | ||
for things that might require changes in Node.js. | ||
2. Check the diffs to ensure the changes are right. Even if there are no changes | ||
in the source, `buildinf.h` files will be updated because they have timestamp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to this PR, but we should add a task somwhere to see if we can address this. Having it be more repeatable would be good.
tools/dep_updaters/update-openssl.sh
Outdated
exit 1 | ||
fi | ||
|
||
command -v perl >/dev/null 2>&1 || { echo >&2 "Error: 'Perl' required but not installed."; exit 1; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again likely a follow on, but I wonder if we need to pin/capture what versions of perl etc was used. The same might be asked about the environment/os level in the action but. Not a blocker for this PR as we don't specify/fix those when people are running manually today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I'm adding the labels to not backport it to versions that use openssl 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll review it properly tomorrow, but I believe is better to have a workflow_dispatch
instead. At least I think we'll have more control on those updates. Wdyt @mhdawson?
This will only create one commit instead of two? I don't know if that will make the PR harder to review. |
Are the changes manually reviewed? Since the update consists a copy-paste of an entire repo followed by regenerating config files programatically, the resulting PRs are pretty big. For example, the latest update in this PR #45309 has changes in 800 files, with I ask because the current CI workflow for creating PRs to update dependencies assume that all dependencies will be updated using a single commit. If there's value in having two commits for OpenSSL we can do it, but it will require modifying that workflow to have a special case for OpenSSL separate from the rest of the dependencies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there's value in having two commits for OpenSSL we can do it, but it will require modifying that workflow to have a special case for OpenSSL separate from the rest of the dependencies.
There's a value in two commits. The second commit is arch build and normally some errors are caught in this phase (for example, nasm build issue - mentioned in the maintaining guide) so you just need to re-do the second one.
@RafaelGSS do you mean we should have |
Yes, the first option. Triggering it manually through workflow_dispatch. |
I think having the ability to trigger it manually would be good, but having a PR auto generated and available when there is a new release seems useful, provided it does not require manual work most of the time. I think for OpenSSL we probably want to try to keep as up to date as possible in the main branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I think we are good to go. As discussed previously in a SecurityWG meeting, adding the support for two commits will be a bit out-of-scope.
Therefore, I'm fine moving forward with it, and if needed, we include support for multiple commits.
The current documentation does say to land as 2 commits so unless its hard/lots of work to do that I'm thinking we should do that now versus later. @richardlau what's your take? |
My take is that the conservative option is the status quo -- two commits. On one hand that allows people to validate the first commit -- you should be able to get the exact same files. Keeping that property may be helpful in the future in terms of potential work around supply chain/verifying our dependencies. The second commit has timestamps and local directories written into it which makes it harder to compare/validate. On the other hand the two commit approach has always been the exception to the
|
@facutuesca I think it would be best to try to implement the 2 commits unless its going to take a larger effort. |
It will require including that support in our current tooling (dep_updaters) |
@mhdawson @RafaelGSS @richardlau I changed it to create 2 commits instead of one. I re-requested reviews since the new approach is different enough that it should be reviewed as a new PR. The things to keep in mind are:
(edit: for some reason I cannot correctly re-request reviews, maybe a permissions issue since I also don't have permissions to add reviewers) |
persist-credentials: false | ||
- name: Check if update branch already exists | ||
run: | | ||
BRANCH_EXISTS=$(git ls-remote --heads origin actions/tools-update-openssl) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this block the automatic backport. We won't be able to update v14 and v16 at same time considering the race condition of the branch creation.
So, I'll include the labels dont-land-on-vX
and after landing you will need to manually backport and change the branch name to actions/tools-update-openssl-vX
.
Does that make sense to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same logic used for the other deps. See this line from the current dependency update action:
node/.github/workflows/tools.yml
Line 153 in 9b1ed04
branch: actions/tools-update-${{ matrix.id }} # Custom branch *just* for this Action. |
As far as I understand, this would be already an issue for corepack
, eslint
, etc right? Since the branches created for them are called tools-update-corepack
and tools-update-eslint
without mentioning the Node version.
Do you know how those are handled currently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have different versions of eslint/corepack in each release line. Could you check if the bot has ever opened PR targeting other branches instead of main
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bot will not because the automatic scheduled runs only happen on the default branch:
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
Scheduled workflows run on the latest commit on the default or base branch.
# Only run rest of the workflow if the update branch does not yet exist | ||
if: ${{ env.BRANCH_EXISTS == '' }} | ||
run: | | ||
NEW_VERSION=$(gh api repos/quictls/openssl/releases -q '.[].tag_name|select(contains("openssl-3"))|ltrimstr("openssl-")' | head -n1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this also blocks the automatic backport to v14.x. We use the original repo on v14.x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does v14.x
have any existing action for dependency updates? I could not find any
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently there is no automation via Actions for dependency updates for any version of Node.js outside of the main branch.
Add a Github Action that checks for new versions of the `OpenSSL` library, and creates a PR to update it if a newer version than the one present in the repo is found. Refs: nodejs/security-wg#828
ping @mhdawson |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Add a Github Action that checks for new versions of the `OpenSSL` library, and creates a PR to update it if a newer version than the one present in the repo is found. Refs: nodejs/security-wg#828 PR-URL: #45605 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]> Reviewed-By: Marco Ippolito <[email protected]>
Landed in c4103c1 |
Add a Github Action that checks for new versions of the `OpenSSL` library, and creates a PR to update it if a newer version than the one present in the repo is found. Refs: nodejs/security-wg#828 PR-URL: #45605 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]> Reviewed-By: Marco Ippolito <[email protected]>
Add a Github Action that checks for new versions of the `OpenSSL` library, and creates a PR to update it if a newer version than the one present in the repo is found. Refs: nodejs/security-wg#828 PR-URL: #45605 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]> Reviewed-By: Marco Ippolito <[email protected]>
Add a Github Action that checks for new versions of the
OpenSSL
library, and creates a PR to update it if a newer version than the one present in the repo is found.Refs: nodejs/security-wg#828