-
Notifications
You must be signed in to change notification settings - Fork 29
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
Translation bot #12
Translation bot #12
Conversation
workflows/create-pull-request.yaml
Outdated
strategy: | ||
fail-fast: false | ||
matrix: | ||
repos: ["de-german", "fr-french"] |
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 it matter in which repository the bot runs? Are there any benefits / drawbacks of running it in the translation repository WRT the origin repository?
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.
One drawback for having it in each repo would be code duplication. Any updates would require updating it in each repo.
Though, on the other hand, this problem would disappear to a large extent it the bot was a reusable GH action. We could have the action in translation-guide
repo and other repos just with minimal config using it.
workflows/create-pull-request.yaml
Outdated
with: | ||
token: ${{ secrets.PAT }} | ||
repository: solidity-docs/translation-guide | ||
path: .github-workflow |
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.
Can you explain this?
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.
Looks like the bot uses a Personal Access Token. The repos it's accessing are all public so it's not needed just for reading. For pushing and creating PRs the action might actually need to use bot's token but I'd try with secrets.GITHUB_TOKEN
first and only go for PAT if that's proven not to be enough.
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.
@chriseth
Yes, indeed, this part is not really intuitive. I need to fetch the repository for external shell scripts. The flow will look like this:
- fetch translation repository
- fetch merge scripts (from the same repository as GitHub Action)
- fetch original repository and merge it to translation repository
- publish sync branch with a merge commit
- create a pull request
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.
@cameel
I am using Bot Personal Access Token. I wanted the PR to be created by customized "Solidity PR Bot" and not generic "GitHub Action". Is this ok?
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.
As we agreed on the call, it should work both with and without a dedicated account for the bot. We'll probably use it without an account but we can keep an option open to start using one later.
workflows/create-pull-request.yaml
Outdated
- name: Create merge commit | ||
id: merge | ||
run: | | ||
./.github-workflow/scripts/merge-conflicts.sh |
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.
Is there a benefit in having two script files?
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 two scripts are fine but what I don't like about it is that input an output is passed implicitly through shell env. I think the scripts should take input through parameters and I'd also make the second script just print the body to the output, without being aware that it's running in CI. I.e.:
.github-workflow/scripts/merge-conflicts.sh "$BOT_USERNAME" "$BOT_EMAIL"
title="Sync with ethereum/solidity@develop $(date +%d-%m-%Y)"
body="$(.github-workflow/scripts/generate-PR-body.sh)"
printf "pr_title=%s\n" "$(title)" >> "$GITHUB_ENV"
printf "pr_body<<EOF\n%s\nEOF\n" "$(body)" >> "$GITHUB_ENV"
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.
yes, I fixed inputs, but right now I do not see a clear way how to fix outputs. GITHUB_ENV and echo ::set-output
are the only ways that I found.
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.
GITHUB_ENV
is fine, it's just that I'd keep it in yaml and pass data from the script in a more CI-agnostic way.
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 I do not get it. peter-evans/create-pull-request@v3
action is accepting strings, not yaml files.
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.
By "in yaml" I meant in create-pull-request.yaml
. I.e. keep it out of the Bash script. See my snippet a few comments above. It shows exactly what I meant.
In any case, this is not critical. I'd change it but I'm still going to approve if you prefer it as is.
workflows/create-pull-request.yaml
Outdated
strategy: | ||
fail-fast: false | ||
matrix: | ||
repos: ["de-german", "fr-french"] |
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.
One drawback for having it in each repo would be code duplication. Any updates would require updating it in each repo.
Though, on the other hand, this problem would disappear to a large extent it the bot was a reusable GH action. We could have the action in translation-guide
repo and other repos just with minimal config using it.
workflows/create-pull-request.yaml
Outdated
with: | ||
token: ${{ secrets.PAT }} | ||
repository: solidity-docs/translation-guide | ||
path: .github-workflow |
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.
Looks like the bot uses a Personal Access Token. The repos it's accessing are all public so it's not needed just for reading. For pushing and creating PRs the action might actually need to use bot's token but I'd try with secrets.GITHUB_TOKEN
first and only go for PAT if that's proven not to be enough.
@o-lenczyk Can you push your changes? I see that you marked many comments as resolved but they're not yet resolved in the code - it's still the same code I reviewed last time. |
yup, I wanted to push everything at once |
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.
There are only a few small issues remaining:
- Should work with and without PAT as agreed on the call
- Include last tag in PR title and commit description as agreed on the call
- Minor quoting issues (see unresolved comments)
I'd like to get this merged soon so I'd be also fine with leaving (1) and (2) for upcoming PRs as long as you create issues so that we don't forget about them. Though I think (2) is minor enough to still do it here.
scripts/generate-PR-body.sh
Outdated
set -euo pipefail | ||
|
||
function title { | ||
echo "Sync with ethereum/solidity@develop $(date +%d-%m-%Y)" |
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.
Can you include the tag in PR title (and commit description)?
On the call we agreed to leave labels for #15 but the title change is simpler so it was meant to be still applied here.
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.
will this be ok?
"Sync with ethereum/solidity@$(git describe --tags --always english/develop) $(date +%d-%m-%Y)"
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 see that it looks like this in https://github.com/solidity-docs-test/pl-polish/pull/60:
Sync with ethereum/solidity@v0.8.12-88-ga5a65eec9 09-03-2022 (PR #60)
I think it's good.
At least for the purposes of this PR it's exactly what I wanted and we can tweak it later if necessary. It's a bit crowded with details now but all the details are useful in some way so I'm not even sure we can really improve on that.
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.
After the tests, I think putting the most recent tag in PR title can be misleading. The source of the PR is always the most recent commit, the most recent tag is not always the most recent revision.
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.
Oh, you mean that the last tag is e.g. 0.8.13 while the commits now will be a part of 0.8.14? That's true, but getting that is (slightly) more complicated. You need to run scripts/get_version.sh
to get it.
But we still need some way to separate PRs for one version from another. If you can run that script to get the actual version, great. If not, I think that the version from the tag is better than nothing.
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'm marking as approved since this looks ready in terms of functionality.
One last change before we merge though is to disable it for now so that it does not run on existing repos before we finish testing in the test org and before the repos are converted.
Would be good for @chriseth to take a final look at this.
Also, please mark the PR as non-draft. |
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 suggested some final tweaks but PR seems fine technically. We should re-enable the bot somewhere though to have a final look at the PRs it creates.
The README probably will need to be adjusted to contain only info relevant to translators (perhaps we should have a separate file for details of bot management that are only relevant to us) but I'm assuming we'll do that with @franzihei once the bot is up and running.
Also, now that repos are actually migrated, we should add the ones that are ready to the matrix. I originally assumed we'd be merging before we launch but now it looks like the merge will be the launch.
The PR only needed small tweaks and could be merged but I cannot push to the branch here so I had to create a new one: #23. This one is now redundant so I'm closing it. |
Resolves #8.
This PR adds:
You can see example PR here or here.