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

Translation bot #12

Closed
wants to merge 4 commits into from
Closed

Translation bot #12

wants to merge 4 commits into from

Conversation

o-lenczyk
Copy link
Contributor

@o-lenczyk o-lenczyk commented Feb 7, 2022

Resolves #8.

This PR adds:

  • GitHub Action, that will run every night
  • bash script that will merge ethereum/solidity into the translated repository and push a commit with merge conflicts that need to be resolved
  • bash script that will create PR body with a list of changed files in docs directory (as tasks)
  • instructions on how to set up the Bot and how to create a translation repository

You can see example PR here or here.

@o-lenczyk o-lenczyk changed the title #8 Translation bot Translation bot Feb 7, 2022
strategy:
fail-fast: false
matrix:
repos: ["de-german", "fr-french"]
Copy link

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?

Copy link
Collaborator

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.

scripts/merge-conflicts.sh Outdated Show resolved Hide resolved
with:
token: ${{ secrets.PAT }}
repository: solidity-docs/translation-guide
path: .github-workflow
Copy link

Choose a reason for hiding this comment

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

Can you explain this?

Copy link
Collaborator

@cameel cameel Feb 8, 2022

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.

Copy link
Contributor Author

@o-lenczyk o-lenczyk Feb 13, 2022

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

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

- name: Create merge commit
id: merge
run: |
./.github-workflow/scripts/merge-conflicts.sh
Copy link

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?

Copy link
Collaborator

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"

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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 Show resolved Hide resolved
strategy:
fail-fast: false
matrix:
repos: ["de-german", "fr-french"]
Copy link
Collaborator

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.

with:
token: ${{ secrets.PAT }}
repository: solidity-docs/translation-guide
path: .github-workflow
Copy link
Collaborator

@cameel cameel Feb 8, 2022

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.

workflows/create-pull-request.yaml Outdated Show resolved Hide resolved
workflows/create-pull-request.yaml Outdated Show resolved Hide resolved
workflows/create-pull-request.yaml Outdated Show resolved Hide resolved
workflows/create-pull-request.yaml Outdated Show resolved Hide resolved
workflows/create-pull-request.yaml Outdated Show resolved Hide resolved
scripts/merge-conflicts.sh Outdated Show resolved Hide resolved
scripts/merge-conflicts.sh Outdated Show resolved Hide resolved
@cameel
Copy link
Collaborator

cameel commented Feb 16, 2022

@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.

@o-lenczyk
Copy link
Contributor Author

o-lenczyk commented Feb 17, 2022

@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

scripts/merge-conflicts.sh Outdated Show resolved Hide resolved
scripts/set-assignees.sh Outdated Show resolved Hide resolved
.github/workflows/create-daily-docs-sync-pr.yaml Outdated Show resolved Hide resolved
scripts/merge-conflicts.sh Outdated Show resolved Hide resolved
.github/workflows/create-daily-docs-sync-pr.yaml Outdated Show resolved Hide resolved
.github/workflows/create-daily-docs-sync-pr.yaml Outdated Show resolved Hide resolved
.github/workflows/create-daily-docs-sync-pr.yaml Outdated Show resolved Hide resolved
scripts/set-assignees.sh Outdated Show resolved Hide resolved
scripts/set-assignees.sh Outdated Show resolved Hide resolved
scripts/set-assignees.sh Outdated Show resolved Hide resolved
Copy link
Collaborator

@cameel cameel left a 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:

  1. Should work with and without PAT as agreed on the call
  2. Include last tag in PR title and commit description as agreed on the call
  3. 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/set-assignees.sh Outdated Show resolved Hide resolved
scripts/merge-conflicts.sh Outdated Show resolved Hide resolved
.github/workflows/create-daily-docs-sync-pr.yaml Outdated Show resolved Hide resolved
set -euo pipefail

function title {
echo "Sync with ethereum/solidity@develop $(date +%d-%m-%Y)"
Copy link
Collaborator

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.

Copy link
Contributor Author

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)"

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

@cameel cameel Apr 7, 2022

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.

Copy link
Collaborator

@cameel cameel left a 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.

.github/workflows/README.md Outdated Show resolved Hide resolved
.github/workflows/README.md Outdated Show resolved Hide resolved
.github/workflows/create-daily-docs-sync-pr.yaml Outdated Show resolved Hide resolved
@cameel
Copy link
Collaborator

cameel commented Mar 9, 2022

Also, please mark the PR as non-draft.

README.md Outdated Show resolved Hide resolved
Copy link
Collaborator

@cameel cameel left a 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.

scripts/merge-conflicts.sh Show resolved Hide resolved
scripts/merge-conflicts.sh Show resolved Hide resolved
.github/workflows/README.md Show resolved Hide resolved
@cameel
Copy link
Collaborator

cameel commented Jul 8, 2022

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.

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.

Repo Automation: Diff Bot for Translation Updates
4 participants