mozilla-l10n / android-l10n-tooling Goto Github PK

update-l10n is triggered whenever a push to the android-components, fenix or focus-android repos happens. This includes pushes to any branch, including ones we don't actually watch, as well as branches being created/deleted. Each time it's triggered by any one repo, we run the job for all 3.
It seems like there should a way to skip a bunch of work if we only trigger when the main branch is updated, and only run the job for the repo that triggered us. (AFAICT the extra jobs are one reason we end up with PRs with multiple force pushes in quick succession, e.g. mozilla-l10n/android-l10n#492)

This way, if the commit is generated multiple times with the same data, the same commit is created.

It probably makes the most sense for the date to be the date of the commit that last touched any of the files in the export.

The importer runs git commit -a, which only adds already known files to the index, but not new ones.

We should fix that so that new localizations are also added to the commits.

CC @Delphine @tomprince

Aiui, the cron feeds the changed file list into the command line. This breaks when the command line crosses the shell's max line length.

The current line of thinking: let's stop shoehorning this variable-length thing into the command line. If possible, let's create an artifact with that data, and pass that in. This will likely require build-decision changes.

It would be nice if the PRs could be batched so a repository only receives a single PR once a day instead of a bunch of small ones.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

The code in

claims to find the first child, but it finds the last. It also assumes that the branch point isn't a good revision to use, which is also wrong.

The right answer is to go through all the revisions from the branch point to the base branch head, and see where we added the branch to the config.

We'd like to drop Python 2 support in taskgraph, but need to update all consumers to Python 3 first.

Since Reality is sunsetting and will need no further l10n work, we want to remove automation related to it.
We are working on this with Matjaz on Friday, between 1600 and 1900 UTC.
I believe automation can stop before then. Thanks!
@escapewindow @mathjazz

I've noticed that TC reruns all automation when you flag a review on a PR.
I've also noticed that TC actually creates pull requests in other repos when you create a PR from the upstream repo, I'm not sure that's a good idea.

We should harden our entry points and permissions a bit, I guess.

CC @Callek @tomprince

Change the branch used for android-components from master to main.

For more context see:

• mozilla-mobile/android-components#10137
• mozilla-mobile/android-components#10647

Originally posted by @escapewindow in #8

Currently, the tasks will fail if there are no change.

[task 2021-07-27T23:40:31.646Z] executing ['create-l10n-branch', '--repo', 'mozilla-mobile/android-components', '--branch', 'android-components-quarantine', 'android-l10n']
[task 2021-07-27T23:40:31.883Z] Traceback (most recent call last):
[task 2021-07-27T23:40:31.883Z]   File "/usr/local/bin/create-l10n-branch", line 8, in <module>
[task 2021-07-27T23:40:31.883Z]     sys.exit(main())
[task 2021-07-27T23:40:31.883Z]   File "/usr/local/lib/python3.7/site-packages/mozxchannel/git/process.py", line 341, in main
[task 2021-07-27T23:40:31.883Z]     graph = handle(args.target, args.branch, args.repo, pull=args.pull)
[task 2021-07-27T23:40:31.883Z]   File "/usr/local/lib/python3.7/site-packages/mozxchannel/git/process.py", line 25, in handle
[task 2021-07-27T23:40:31.883Z]     graph.loadRevs()
[task 2021-07-27T23:40:31.883Z]   File "/usr/local/lib/python3.7/site-packages/mozxchannel/git/process.py", line 62, in loadRevs
[task 2021-07-27T23:40:31.883Z]     for n, branch in enumerate(repo.branches()):
[task 2021-07-27T23:40:31.883Z]   File "/usr/local/lib/python3.7/site-packages/mozxchannel/git/repository.py", line 70, in branches
[task 2021-07-27T23:40:31.883Z]     rev = self.lookup_branch(self.branch).target
[task 2021-07-27T23:40:31.883Z] AttributeError: 'NoneType' object has no attribute 'target'

Something to do with branch updates again.
I'd love to solve the root problem here, but a workaround of creating a bogus branch may also be acceptable for now.

We have been in this cycle multiple times now:

• The L10N automation opens a PR with updated translations
• An engineer comes along approves the PR and instructs bors to run the tests and land the PR
• The L10N automation pushes an update to the PR
• Bors cancels the request since the state of the PR has changed.
• An engineer comes along and instructs bors to retry
• The L10N automation pushes an update to the PR
• Bors cancels the request since the state of the PR has changed.
• An engineer comes along and instructs bors to retry
• ...

I'm not sure what a good solution for that is. One option is batching (#15), which at least reduces the probability of that happening. Another option may be to not update a PR if it is already approved.