https://pantsbuild.org/ logo
Join Slack
Powered by
Hi everyone, I'm looking for some help regarding g...
# general
l
Hi everyone, I'm looking for some help regarding general build problems. First of all, I can't run pants on my MacOS due to corporate firewall and custom SSL certificate derived from Zscaler. I described the problem as GitHub issue here: https://github.com/pantsbuild/pants/issues/22727 I was able to bypass it, by running pants in Docker container. I mount my codebase to the container and run pants inside. Then, I get this when running `pants package ::`:
Copy code
$ pants package ::
13:29:39.22 [INFO] Initializing scheduler...
13:29:39.34 [INFO] Scheduler initialized.
13:29:39.41 [INFO] Completed: Scheduling: Building 1 requirement for faas_repository.pex from the python-default.lock resolve: boto3==1.40.43
13:29:39.41 [INFO] Completed: Scheduling: Build python_aws_lambda_function artifact for lambda_functions/create_grafana:lambda
13:29:39.43 [ERROR] 1 Exception encountered:

Engine traceback:
  in `package` goal

IntrinsicError: Error setting permissions on /lambdas/dist/lambda_functions.create_grafana/lambda.zip: Permission denied (os error 13)
I can't bypass this. Anyone knows how to overcome this issue?
w
For the SSL problem, does that mean 
scie-pants
worked? Or are you pulling it down separately? https://github.com/pantsbuild/scie-pants
At first glance, that looks like a scie-pants problem, but I'm on mobile - so can't check code
l
@wide-midnight-78598 
scie-pants
doesn't work on my Mac, because of custom SSL. In Docker container it does.
scie-pants
doesn't work on my Mac, because it fails on downloading cpython PEX files from Github releases. It throws exception of SSL certificate validation
w
Okay, and I’m assuming you’re using the latest scie=pants?
l
Correct. The last one. Installed through homebrew
w
Similar to this one, at a glance: https://github.com/pantsbuild/scie-pants/issues/403
But it looks like you tried one of those resolutions already
l
Correct. Setting the 
SSL_CERT_FILE
worked for me inside a Docker container, but it didn't solve the problem on my Mac. By the way - the Docker container is running on the same Mac I have the first problem
@wide-midnight-78598 if you could point me to the code which triggers this download:
Copy code
<https://github.com/pantsbuild/pants/releases/download/release_2.28.0/pants.2.28.0-cp311-darwin_arm64.pex>
I could also dig by myself to lookup for a solution that might work on my Mac behind the firewall
w
I’m not actually sure. I dont spend much time in scie-pants, but I would expect it to be in the tools project - maybe part of the ptex file
Could also get kicked off in the install_pants.py file
Silly question - is there an easy way to reproduce this category of problem outside of a corporate network? I’ve never run into a problem like this myself - but over the years, we’ve had several types of this problem crop up. Would be nice to be able to create a reproduction case for both pants and scie pants. I vaguely recall there is some way by somehow invalidating or trashing your OS’s certs, forcing you to specify one. Or maybe a timestamp invalidation could work. A CI reproduction case would definitely solve this category of bugs for us…
f
I'm running into this 
SSL_CERT_FILE
issue too, though not with 
scie-pants
but the tools that pants downloads via rust (like ruff). My hopythesis here is that rust isn't respecting the env var I've got a reproduction for mac using https://mitmproxy.org/ here https://github.com/chris-smith-zocdoc/pants-mitm-issue Though you should be able to adopt it for linux easily (mitmproxy is cross platform)
Copy code
[DEBUG] Error while downloading <https://github.com/astral-sh/ruff/releases/download/0.13.0/ruff-aarch64-apple-darwin.tar.gz>: Error downloading file: error sending request for url (<https://github.com/astral-sh/ruff/releases/download/0.13.0/ruff-aarch64-apple-darwin.tar.gz>) (retryable)

IntrinsicError: Error downloading file: error sending request for url (<https://github.com/astral-sh/ruff/releases/download/0.13.0/ruff-aarch64-apple-darwin.tar.gz>)
mitmproxy reports
Copy code
Client TLS handshake failed. The client does not trust the proxy's certificate for <http://github.com|github.com> (tlsv1 alert unknown ca)
Hmm setting
Copy code
[GLOBAL]
ca_certs_path = <path>
Does allow it to work though. Should that be required? The docs state
By default, Pants will respect and pass through the 
SSL_CERT_DIR
and 
SSL_CERT_FILE
environment variables.
Which is why I didn't set that initially https://www.pantsbuild.org/stable/docs/using-pants/restricted-internet-access#setting-up-a-certificate-authority
b
@fresh-mechanic-68429 I bet you can remove the pants.toml edit and run with 
--no-pantsd
and the env vars then work (not that you should do things this way, but just to prove out a debugging point). If so, same as here: https://github.com/pantsbuild/pants/issues/22932
f
The reproduction I provided is using 
--no-pantsd
already
b
Aha. Ok then.
19 Views
Open in Slack
PreviousNext
Powered by