Arun Kulshreshtha <akulshreshtha@janestreet.com> [Thu, 04 Jan 2024 14:45:31 -0500] rev 51309
narrow: prevent removal of ACL-defined excludes
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Thu, 04 Jan 2024 14:41:18 -0500] rev 51308
narrow: add test demonstrating bug in acl exclusion enforcement
Anton Shestakov <av6@dwimlabs.net> [Mon, 08 Jan 2024 13:35:02 +0100] rev 51307
contrib: add a set of scripts to run pytype in Docker
Having a simple way to run pytype for developers can massively shorten
development cycle. Using the same Docker image and scripts that we use on our
CI guarantees that the result achieved locally will be very similar to (if not
the same as) the output of our CI runners.
Things to note: the Dockerfile needs to do a little dance around user
permissions inside /home/ci-runner/ because:
- on one hand, creating new files on the host (e.g. .pyi files inside .pytype/)
should use host user's uid and gid
- on the other hand, when we run the image as uid:gid of host user, it needs to
be able to read/execute files inside the image that are owned by ci-runner
Since local user's uid might be different from ci-runner's uid, we execute this
very broad chmod command inside /home/ci-runner/, but then run the image as the
host user's uid:gid.
There might be a better way to do this.
Anton Shestakov <av6@dwimlabs.net> [Mon, 18 Dec 2023 15:52:17 -0300] rev 51306
pytype: use "$(hg root)" instead of `hg root` to make shellcheck happier
Anton Shestakov <av6@dwimlabs.net> [Mon, 18 Dec 2023 15:40:48 -0300] rev 51305
pytype: update check-pytype.sh to select target automatically
We have python3.11 on CI, so we can run pytype targeting that version. On the
other hand, we don't have python3.7 on CI anymore, so we can't run pytype for
3.7 anymore (interpreter not found). I think it's fine to make pytype select
the appropriate target depending on the version of the interpreter it's running
under.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 19 Dec 2023 22:54:52 +0100] rev 51304
git-hgext: adjust to the lack of `changelog.heads` method
We don't have a `heads` method returning nodeid, but this is very easy to get
the same result.
This was flagged by pytype.
We can note that the fact this code did not break is probably a good sign that
it is dead code.
However this is a question outside of the scop of this series.