The old loader (bundle2 loader) already received this treatment which
ensures Mercurial doesn't pick up on any user customization, but I
apparently forgot to apply the same changes to the new one.
Details
Details
- Reviewers
ardumont - Group Reviewers
Reviewers - Commits
- rDLDHGaa80a360e236: Also use minimal env in the new Mercurial loader
Diff Detail
Diff Detail
- Repository
- rDLDHG Mercurial loader
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 21058 Build 32682: Phabricator diff pipeline on jenkins Jenkins console · Jenkins Build 32681: arc lint + arc unit
Event Timeline
Comment Actions
Build has FAILED
Patch application report for D5625 (id=20065)
Could not rebase; Attempt merge onto f03f274065...
Updating f03f274..2ec0206 Fast-forward swh/loader/mercurial/from_disk.py | 9 ++++++++- swh/loader/mercurial/hgutil.py | 3 ++- 2 files changed, 10 insertions(+), 2 deletions(-)
Changes applied before test
commit 2ec0206482f46491086791b6b8718d5094cb4d77
Author: Raphaël Gomès <rgomes@octobus.net>
Date: Mon Apr 26 23:26:09 2021 +0200
Also use minimal env in the new Mercurial loader
The old loader (bundle2 loader) already received this treatment which
ensures Mercurial doesn't pick up on any user customization, but I
apparently forgot to apply the same changes to the new one.
commit 1d8b26c042011f3271e451b11b670f37b44e8685
Author: Raphaël Gomès <rgomes@octobus.net>
Date: Tue Apr 27 10:53:56 2021 +0200
Use billiard instead of stdlib multiprocessing
This circumvents a few celery-related issues, and is consistent with
what the rest of the codebase does.Link to build: https://jenkins.softwareheritage.org/job/DLDHG/job/tests-on-diff/205/
See console output for more information: https://jenkins.softwareheritage.org/job/DLDHG/job/tests-on-diff/205/console
Comment Actions
Build is green
Patch application report for D5625 (id=20078)
Could not rebase; Attempt merge onto f03f274065...
Updating f03f274..457fb88 Fast-forward swh/loader/mercurial/from_disk.py | 9 ++++++++- swh/loader/mercurial/hgutil.py | 18 +++++++++++++----- swh/loader/mercurial/tests/test_hgutil.py | 11 +++++++---- 3 files changed, 28 insertions(+), 10 deletions(-)
Changes applied before test
commit 457fb88bf36d6c4eedee5e9423f9747e3ea4abf4
Author: Raphaël Gomès <rgomes@octobus.net>
Date: Mon Apr 26 23:26:09 2021 +0200
Also use minimal env in the new Mercurial loader
The old loader (bundle2 loader) already received this treatment which
ensures Mercurial doesn't pick up on any user customization, but I
apparently forgot to apply the same changes to the new one.
commit a89783c52f2e3c44e08018e0c5fa99f54471f994
Author: Raphaël Gomès <rgomes@octobus.net>
Date: Tue Apr 27 10:53:56 2021 +0200
Use billiard instead of stdlib multiprocessing
This circumvents a few celery-related issues, and is consistent with
what the rest of the codebase does.See https://jenkins.softwareheritage.org/job/DLDHG/job/tests-on-diff/210/ for more details.
Comment Actions
Build is green
Patch application report for D5625 (id=20170)
Could not rebase; Attempt merge onto 504ee123ce...
Updating 504ee12..aa80a36 Fast-forward swh/loader/mercurial/from_disk.py | 9 ++++++++- swh/loader/mercurial/hgutil.py | 24 ++++++++++++++++++------ swh/loader/mercurial/tests/test_hgutil.py | 11 +++++++---- 3 files changed, 33 insertions(+), 11 deletions(-)
Changes applied before test
commit aa80a360e236a1a5e155ed83af0bdcc88bf83d74
Author: Raphaël Gomès <rgomes@octobus.net>
Date: Mon Apr 26 23:26:09 2021 +0200
Also use minimal env in the new Mercurial loader
The old loader (bundle2 loader) already received this treatment which
ensures Mercurial doesn't pick up on any user customization, but I
apparently forgot to apply the same changes to the new one.
commit 23260277700970ffabcfaa386e3ce5c619c8294f
Author: Raphaël Gomès <rgomes@octobus.net>
Date: Tue Apr 27 10:53:56 2021 +0200
Use billiard instead of stdlib multiprocessing
This circumvents a few celery-related issues, and is consistent with
what the rest of the codebase does.
stdlib multiprocessing is not able to spawn children from daemonic
processes, and even says so plainly if you try:
`AssertionError: daemonic processes are not allowed to have children`
This is incompatible with the SWH infrastructure which needs to do this
exactly. Fortunately, we're already using billiard and celery. I'm
assuming that there could be other blocking or annoying differences
between stdlib and billiard, but we will save ourselves the trouble of
finding out.See https://jenkins.softwareheritage.org/job/DLDHG/job/tests-on-diff/218/ for more details.