Skip to content

Python script to migrate non-SR projects - #1859

Open
rmunn wants to merge 1 commit into
developfrom
feature/migrate-projects-to-send-receive
Open

rmunn wants to merge 1 commit into
developfrom
feature/migrate-projects-to-send-receive

Conversation

@rmunn

@rmunn rmunn commented Oct 22, 2026

Copy link
Copy Markdown
Collaborator

Written by Claude Code (mostly Opus 5, some Opus 5.5), tested on local dev machine.

This is a Python script to migrate the projects identified in sillsdev/languageforge-lexbox#2414 as being worth migrating to LexBox and FW Lite. It needs sillsdev/LfMerge#361 and sillsdev/languageforge-lexbox#2439 to be merged first before the script can run.

Some projects, those with custom fields created in LF, will need a two-step process: run the script once, which will determine the XML to put into the FW project in order to define the custom fields. Then clone the Mercurial repo, add that XML as a new Mercurial commit, and push that commit to Lexbox. Then run the script again. The script is intended to run on the Language Forge app container, and that container cannot push Mercurial repos to LexBox, so the custom-fields commit needs to be a manual process. There are only six projects that look like they will need this, however, so it's not as onerous as it might sound.

For all other projects, the script will run as-is without any manual steps. Once the script runs, there will be a (projectCode)-migrate project on the server with a copy of the project's data, and a new LexBox project with the same (projectCode)-migrate name that contains the project's data in FW format. That data can then be brought into FieldWorks Lite.

@rmunn rmunn self-assigned this Oct 22, 2026
@rmunn rmunn added engineering Tasks which do not directly relate to a user-facing feature or fix large task Issues which have been estimated by the team lead to require substantial effort and time labels Oct 22, 2026
@github-actions

github-actions Bot commented Oct 22, 2026 •

Copy link
Copy Markdown

Unit Test Results

362 tests   362 ✅  8s ⏱️
 37 suites    0 💤
  1 files      0 ❌

Results for commit b31b4f9.

♻️ This comment has been updated with latest results.

Written by Claude Code (mostly Opus 5, some Opus 5.5), tested on local
dev machine.

Some projects, those with custom fields created in LF, will need a
two-step process: run the script once, which will determine the XML to
put into the FW project in order to define the custom fields. Then clone
the Mercurial repo, add that XML as a new Mercurial commit, and push
that commit to Lexbox. Then run the script again. The script is intended
to run on the Language Forge `app` container, and that container cannot
push Mercurial repos to LexBox, so the custom-fields commit needs to be
a manual process. There are only six projects that look like they will
need this, however, so it's not as onerous as it might sound.

For all other projects, the script will run as-is without any manual
steps. Once the script runs, there will be a `(projectCode)-migrate`
project on the server with a copy of the project's data, and a new
LexBox project with the same `(projectCode)-migrate` name that contains
the project's data in FW format. That data can then be brought into
FieldWorks Lite.
@rmunn
rmunn force-pushed the feature/migrate-projects-to-send-receive branch from 2344f04 to b31b4f9 Compare October 22, 2026 06:24
@rmunn

rmunn commented Oct 22, 2026

Copy link
Copy Markdown
Collaborator Author

I am actually slightly disturbed that all checks have passed on this PR, because it shows there's a hole in our checks. I deliberately specified a version of the lfmerge Docker image that doesn't exist yet, and won't exist until the bugfix PR sillsdev/LfMerge#361 is merged. But apparently we don't have any checks that would catch that "mistake". (Which in this case was on purpose so that the PR couldn't be merged until the bugfix PR is merged).

Probably not worth investing time to fix the checks on a server we're planning to sunset, but I did want to mention that the "mistake" in docker/lfmerge/Dockerfile was very much on purpose.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

engineering Tasks which do not directly relate to a user-facing feature or fix large task Issues which have been estimated by the team lead to require substantial effort and time

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant