3969e02b27
* Fix Git HTTP smart host detection regression test test/issues/el-get-issue-1920.el revealed that Git HTTP smart host detection is broken. Not all hosts support the HEAD HTTP request method. For example, github.com for HEAD (let ((url-request-method "HEAD")) (url-retrieve-synchronously "https://github.com/dimitri/el-get.git/info/refs\?service\=git-upload-pack")) responds HTTP/1.1 405 Method Not Allowed Server: GitHub Babel 2.0 Content-Type: text/plain Content-Security-Policy: default-src 'none'; sandbox Content-Length: 0 X-Frame-Options: DENY X-GitHub-Request-Id: C1DA:12E32:2B6C9D7:302B1C2:61C9A4E8 while for GET (let ((url-request-method "GET")) (url-retrieve-synchronously "https://github.com/dimitri/el-get.git/info/refs\?service\=git-upload-pack")) responds HTTP/1.1 200 OK Server: GitHub Babel 2.0 Content-Type: application/x-git-upload-pack-advertisement Content-Security-Policy: default-src 'none'; sandbox Transfer-Encoding: chunked expires: Fri, 01 Jan 1980 00:00:00 GMT pragma: no-cache Cache-Control: no-cache, max-age=0, must-revalidate Vary: Accept-Encoding X-Frame-Options: DENY X-GitHub-Request-Id: C22C:5E15:3923777:3D822AC:61CA332A Other hosts like git.sr.ht do support HEAD, of course. Furthermore, the HTTP status code wasn't checked, that's why hosts like github.com would be classified as "dumb" hosts. This commit checks the HTTP status code, and if the status is not 200 or 304 for the HEAD HTTP request method, it tries GET. HEAD is tried first, because GET might be more expensive for big repositories. The regression test is adapted as well. * Fix byte compiler warnings |
||
|---|---|---|
| .. | ||
| el-get-issue-176.el | ||
| el-get-issue-200.el | ||
| el-get-issue-284.el | ||
| el-get-issue-289.el | ||
| el-get-issue-303.el | ||
| el-get-issue-310.el | ||
| el-get-issue-400.el | ||
| el-get-issue-407.el | ||
| el-get-issue-418.el | ||
| el-get-issue-432.el | ||
| el-get-issue-446.el | ||
| el-get-issue-513.el | ||
| el-get-issue-535.el | ||
| el-get-issue-541.el | ||
| el-get-issue-548.el | ||
| el-get-issue-559.el | ||
| el-get-issue-579.el | ||
| el-get-issue-581.el | ||
| el-get-issue-583.el | ||
| el-get-issue-586.el | ||
| el-get-issue-589.el | ||
| el-get-issue-592.el | ||
| el-get-issue-594.el | ||
| el-get-issue-596.el | ||
| el-get-issue-613.el | ||
| el-get-issue-615.el | ||
| el-get-issue-619.el | ||
| el-get-issue-628.el | ||
| el-get-issue-632.el | ||
| el-get-issue-640.el | ||
| el-get-issue-642.el | ||
| el-get-issue-650.el | ||
| el-get-issue-652.el | ||
| el-get-issue-656.el | ||
| el-get-issue-659.el | ||
| el-get-issue-672.el | ||
| el-get-issue-683.el | ||
| el-get-issue-730.el | ||
| el-get-issue-772.el | ||
| el-get-issue-809.el | ||
| el-get-issue-810.el | ||
| el-get-issue-835.el | ||
| el-get-issue-1006.el | ||
| el-get-issue-1028.el | ||
| el-get-issue-1189.el | ||
| el-get-issue-1348.el | ||
| el-get-issue-1389.el | ||
| el-get-issue-1454.el | ||
| el-get-issue-1472.el | ||
| el-get-issue-1562.el | ||
| el-get-issue-1615.el | ||
| el-get-issue-1752.el | ||
| el-get-issue-1920.el | ||
| el-get-issue-1939.el | ||
| el-get-issue-new-2.el | ||
| el-get-issue-new.el | ||
| foo.php | ||
| issue-741-elpa-install-error.el | ||
| README.md | ||
| run-all-tests.sh | ||
| run-test-interactive.sh | ||
| run-test.sh | ||
Old issue reproducers
This directory contains tests to replicate old issues that came up, but since they generally require network access to install packages they can't reliably be used for an automated test suite.
el-get manual tests
Tries to cover some known issues, example that will allow building a regression test suite some day.
Typical run (in bash):
mkdir -p /tmp/test/.emacs.d/el-get/
rm -rf /tmp/test/.emacs.d/el-get/*
HOME=/tmp/test /usr/bin/emacs-snapshot-gtk -Q -batch -L . -l el-get \
-l test/el-get-issue-303.el
At the moment you need to run the el-get-issue scripts with some known working el-get version to know what to expect, and you probably need to have el-get installed at +~/dev/emacs/el-get/+ for this to work as-is.
Yet it might be useful.
el-get automated tests
Simple script-based automation
In the test directory, there is a simple bash script called +run-test.sh+ that attempts to automate the manual steps detailed above. The script creates a temporary home directory and runs emacs in batch mode, first loading el-get and then the specified test file. An invocation equivalent to the above would look like this (starting from the main el-get directory):
test/run-test.sh el-get-issue-303.el
or even just
test/run-test.sh 303
The script takes care of cleaning up the temporary directory after the test, so you can run tests one after the other without previous tests causing problems for later ones. The bahavior of the +run-test.sh+ script can be customized with a few environment variables:
TMPDIRandTEST_HOME, for controlling where the temporary home directory is created;EL_GET_LIB_DIR, the directory where the el-get code resides;EMACS, which can be used to override the copy of emacs found in yourPATH, or to provide one if there is no emacs in yourPATHor it is installed under a nonstandard name.
You can run multiple tests by simply providing multiple test files to
run-test.sh:
test/run-test.sh 200 303 310
When running multiple tests, the script will wait 5 seconds between tests, since many tests involve downloading files from the same few servers (Github, emacswiki, marmalade, etc.), and it is impolite to download a large number of files in rapid succession just for testing. There is a script called +run-all-tests.sh+ that acts as a shortcut for running all the available tests.
Sometimes you may want to run a test in an interactive emacs session
so that you can use Emacs' debugging facilities to investigate what
went wrong. To do this, use run-test-interactive.sh instead of
run-test.sh.
If simply want to test installation, updating, and removal of one or
more recipes, you can use the test-recipe.sh script.