feat: GitHub action to rename module #51
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ARR4N
requested review from
a team,
darioush,
ceyonur and
michaelkaplan13
and removed request for
a team
darioush
approved these changes
Oct 11, 2024
| description: 'Upstream commit on which to base module renaming' | ||
| required: true | ||
| type: string | ||
| default: '2bd6bd01d2e8561dd7fc21b631f4a34ac16627a1' |
There was a problem hiding this comment.
is it possible to use a tag or a commit here?
This was referenced Oct 11, 2024
ARR4N
added a commit
that referenced
this pull request
Oct 11, 2024
## Why this should be merged #51 had a bug when checking whether or not to open a PR. I was originally blocking everything if _not_ on main instead of doing something if on it. The [manually dispatched run therefore didn't open a PR as expected](https://github.com/ava-labs/libevm/actions/runs/11299366394/job/31430160561). ## How this works Change `!=` to `==` ## How this was tested n/a Signed-off-by: Arran Schlosberg <[email protected]>
ARR4N
added a commit
that referenced
this pull request
Oct 17, 2024
## Why this should be merged Signs commits for auto-renaming the Go module, originally introduced in #51 with unsigned commits that can't be merged to `main`. ## How this works Changes the commit action to use [`ghcommit`](https://github.com/planetscale/ghcommit), which was made specifically to allow for keyless signing (GitHub signs the commit). The workflow no longer opens a PR to the `renamed-go-module` branch as it's redundant and the generated branch can be used directly. The commit message includes the `workflow_dispatch` trigger branch as well as a hash of the workflow file for a complete audit trail. I removed the commented-out PR trigger as it's unnecessary. In development we can now just trigger the workflow on the dev branch. ## How this was tested Inspecting [the commit](572b8ab) generated by a [workflow run](https://github.com/ava-labs/libevm/actions/runs/11357025696/job/31589219847). It is identical in modifications to the one reviewed in #59.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why this should be merged
Automate renaming of the Go module from
github.com/ethereum/go-ethereumtogithub.com/ava-labs/libevm.How this works
Before starting this PR, I branched the
renamed-go-modulebranch offmaster(the upstream geth branch; our default is calledmain). It has been protected to require PRs, which are automatically generated by the workflow introduced in this PR.The new workflow is designed to be manually dispatched with an input string of the commit hash to use as a source for renaming. On dispatch, it:
renamed-go-module.Intended usage
When performing an upstream sync to pull in new geth code, this workflow will first be run against the geth commit we intend to merge. After the generated PR is merged, the
renamed-go-modulebranch will be the one incorporated intomain.Note that the
renamed-go-modulebranch requires two reviewers to approve. The user who dispatches the workflow SHOULD be one, with any other valid reviewer as the other. This is because a single-reviewer workflow would allow any user to update therenamed-go-modulebranch because the PR author isgithub-actions.How this was tested
Inspection of the generated PR #57 as well as the workflow run that generated it.