riscy / melpazoid

A bundle of CI scripts for testing Emacs packages, primarily submissions to MELPA.
GNU General Public License v3.0
79 stars 17 forks source link

Stack at building container #1

Closed conao3 closed 1 year ago

conao3 commented 4 years ago

Hi!

This project looks so cool! But I try this project, stack at Building container...

$ MELPA_PR_URL=https://github.com/melpa/melpa/pull/6725 make
python melpazoid.py
Cloning https://github.com/srfi-explorations/emacs-srfi
Building container... 🐳
^CTraceback (most recent call last):
  File "melpazoid.py", line 563, in <module>
    check_melpa_pr(os.environ['MELPA_PR_URL'])
  File "melpazoid.py", line 495, in check_melpa_pr
    return run_checks(recipe, elisp_dir, clone_address, pr_data)
  File "melpazoid.py", line 82, in run_checks
    check_containerized_build(_package_name(recipe))
  File "melpazoid.py", line 91, in check_containerized_build
    output = subprocess.check_output(['make', 'test', f"PACKAGE_NAME={package_name}"])
  File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.8/subprocess.py", line 491, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
  File "/usr/lib/python3.8/subprocess.py", line 1011, in communicate
    stdout = self.stdout.read()
KeyboardInterrupt
make: *** [Makefile:6: run] Interrupt

How to debug this issue? My OS is linux, Emacs-26.3

riscy commented 4 years ago

Hey! Thanks for saying so, I think it's starting to come together.

The "Building container..." step can sometimes take a couple of minutes -- it's downloading a big fat Ubuntu base image. It probably takes longer than it needs to.

The good news is that once it downloads the Ubuntu base image, Docker caches that layer, so you won't need to wait that long again.

conao3 commented 4 years ago

More than two days have passed. It's more natural to assume that docker builds are stuck rather than taking that long.

Or, if this package do a docker pull, please show the information without hiding it so that the user knows how long to wait. There is no status and I feel uneasy about being kept waiting.

riscy commented 4 years ago

Yeah -- there is a --quiet flag that is enabled. If you edit the Makefile and remove it and then type "make test" you should see the output scroll. Two days is probably too long. :)

The other thing you could do to diagnose it is monitor your network activity. Most of what the docker build is doing should be downloading stuff.

If you check the build logs they mostly take around three minutes, and the majority of that is spent building the container.

conao3 commented 4 years ago

Same result... Some dependencies missing?

$ git diff
diff --git a/Makefile b/Makefile
index 9916010..ba07dba 100644
--- a/Makefile
+++ b/Makefile
@@ -15,5 +15,5 @@ term: image

 .PHONY: image
 image:
-       @docker build --build-arg PACKAGE_NAME --quiet \
+       @docker build --build-arg PACKAGE_NAME \
                --tag ${IMAGE_NAME} -f Dockerfile .

$ MELPA_PR_URL=https://github.com/melpa/melpa/pull/6725 make
python melpazoid.py
Cloning https://github.com/srfi-explorations/emacs-srfi
Building container... 🐳
^CTraceback (most recent call last):
  File "melpazoid.py", line 563, in <module>
    check_melpa_pr(os.environ['MELPA_PR_URL'])
  File "melpazoid.py", line 495, in check_melpa_pr
    return run_checks(recipe, elisp_dir, clone_address, pr_data)
  File "melpazoid.py", line 82, in run_checks
    check_containerized_build(_package_name(recipe))
  File "melpazoid.py", line 91, in check_containerized_build
    output = subprocess.check_output(['make', 'test', f"PACKAGE_NAME={package_name}"])
  File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.8/subprocess.py", line 491, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
  File "/usr/lib/python3.8/subprocess.py", line 1011, in communicate
    stdout = self.stdout.read()
KeyboardInterrupt
make: *** [Makefile:6: run] Interrupt
riscy commented 4 years ago

Try using "make test" instead -- the python subprocess module unfortunately buffers all the output, so you won't see what's going on in the container. Don't worry, "make test" will pick up where the build left off, so you won't have to specify MELPA_PR_URL, etc.

riscy commented 4 years ago

Also, I'm excited to get this working for you too, so don't hesitate to ask lots of questions here! I'd also like to incorporate the indentation checks you added.

riscy commented 1 year ago

Closing this for now, but let me know if there is more to reopen for. (Or maybe we open another issue.)