Github не работает php

codedokode / Как установить PHP.md

Ниже — старая, неподдерживаемая версия.

Ты можешь установить интерпретатор PHP себе на компьютер. Это позволит тебе запускать у себя программы. В отличие от сервисов типа ideone, ты можешь запускать программы без ограничения по размеру и времени работы, можешь читать/сохранять данные в файл, можешь работать с сетью и интернетом.

В инструкции упоминается командная строка. Если ты с ней не работал, можешь почитать мой краткий курс молодого бойца на эту тему: https://gist.github.com/codedokode/10539568

Обрати внимание, на Windows XP можно поставить максимум PHP5.4 (и Apache 2.2). Для более новых версий надо обновиться.

Обрати внимание, инструкция немного устарела. Теперь страница скачивания бинарников под Windows находится тут: http://windows.php.net/download/ x86 — версия для 32-битной ОС, x64 — 64-битная версия (она не очень проверенная, если не заработает — придется ставить 32-битную). Из Thread Safe и Non Thread Safe выбирай Thread Safe (c поддержкой многопоточности).

Вот, таким образом ты можешь установить PHP и запускать скрипты из командной строки. Учти, что во многих IDE (PhpStorm, Netbeans PHP) эта возможность уже встроена и в них программу можно просто запускать нажатием одной клавиши.

Также, тебе может захотеться запускать программы на PHP не только из командной строки, но и через браузер. Для этого нужен веб-сервер — программа, которая взаимодействует с браузером и отвечает на его запросы (веб-сервер принимает запрос на загрузку страницы от браузера и запускает нужный PHP скрипт, а результат работы отдает обратно в браузер). Обычно для этого ставят Апач, но для начала тебе вполне хватит встроенного в PHP сервера. Чтобы запустить его, перейди в папку со своими PHP файлами:

(Естественно, надо подставить в эти команды имя диска и папки где у тебя на самом деле хранятся файлы). После этого запускай PHP в режиме сервера (то есть он запустится и будет ждать запросов от браузера):

-S обозначает «запуститься в режиме сервера». Надо написать именно заглавную S, c маленькой буквой не заработает. localhost обозначает принимать соединения только со своего компьютера, и не принимать соединения с других устройств (если хочешь чтобы твой сервер был доступен во всей локальной сети, пиши вместо localhost адрес 0.0.0.0 — после этого к тебе можно будет зайти по ip и что-нибудь набить ).

9091 — это номер порта, на котором сервер будет ждать соединения от браузера. Если произойдет ошибка и будет написано что этот порт уже занят, введи другое число (от 1 до 65534), например 9092 .

После того, как сервер запущен, ты можешь запускать программы в той папке через браузер. Для этого набери в нем http://localhost:9091/test.php — должен будет запуститься скрипт test.php и его результат работы отобразится в браузере (а в консоли ты увидишь строчку с его названием, и сообщения об ошибках если таковые будут).

Если ты расшарил сервер на всю сеть, указав адрес 0.0.0.0 при запуске, то можешь зайти на него с другого устройства, указав IP компьютера: http://10.2.3.4:9091/test.php . Если у тебя есть роутер то с 0.0.0.0 зайти можно только из твоей домашней сети, если нет роутера или ты прокинешь порт наружу — из всей сети провайдера, если у тебя подключен «белый IP», то вообще со всего мира.

Ты можешь запустить несколько серверов в нескольких консолях, если вдруг понадобится, но не забудь указать каждому свой уникальный номер порта.

Для завершения работы сервера нажми в консоли Ctrl + C (если ты читал мой гайд по командной строке то и так знаешь, что эта комбинация клавиш завершает выполняющуюся программу).

Источник

Интеграция PHP проекта на GitHub и Scrutinizer

Регистрируемся в Scrutinizer

Проще, наверное, войти через вашу учетную запись в GitHub, т.к. это избавит вас от необходимости линковать ваш GitHub профиль, а делать это все равно придется.

Для установки приложения Scrutinizer переходим по ссылке, этот шаг можно пропустить, но имейте ввиду, что в дальнейшем у вас не будут работать интерактивные плюшки и будет висеть нотификация: Scrutinizer GitHub App Is Not Installed.

Даем ему все скоупы, которые требует. Не бойтесь, Scrutinizer не удалит ваши репозитории и никак вам не навредит. Это нужно для того, чтобы приложение могло общаться с вашим GitHub по АПИ и в real-time управлять вашим Check Suite, давая ему обратную связь, и кодом в ваших PR для удобства ревью и тд.

Пример, как выглядит окно установки Scrutinizer

Создаем глобальную конфигурацию

Вообще говоря, если у вас много репозиториев, то Best Practies считается правильным иметь одну глобальную конфигурацию, где хранить общие настройки, а специфичные конфиги выносить в конфигурации ваших репозиториев, как бы перезаписывая отдельные куски конфигураций.

Чтобы создать глобальную конфигурацию перейдите по ссылке.

Пример глобальной конфигурации для PHP проекта

Обратите внимание, что проверки, описанные ниже, будут приводить к фейлу сборки, поэтому, если для вас некоторые из них не нужны, удалите или понизьте лимиты:

Проверки для сборок

Хотел бы отметить, всегда указывайте ваше окружение (версию PHP, базы данных и тд), т.к. значения по умолчанию могут меняться и ваши сборки в один прекрасный день будут зафейлены. Что собственно и приключилось со мной буквально на днях, когда релизнулся PHP 8.0.1.

Настройка репозитория

По сути мы просто добавляем свой репозиторий с GitHub, для этого переходим по ссылке.

Пример окна добавления репозитория

Начинаете вводить название репозитория и автозаполнение автоматически выдаст все доступные публичные репозитории, указываете язык и все.

Далее идем в настройки вашего репозитория, которые находятся вот тут:
https://scrutinizer-ci.com/g/ваш-логин/название-репозитория/settings

Настройка Check Suite

Тут немного остановимся и я расскажу почему.

Дело в том, что сборки Scrutinizer довольно медленные, даже для одного окружения сборка с анализом и покрытием может длиться минут 20.

За это время ваши обычные проверки в GitHub CI уже могут быть пройдены, линтеры показали ваши ошибки или вы вспомнили, что что-то забыли, и успеели толкнуть пару-тройку коммитов до завершения сборки Scrutinizer.

Tracking Settings

По умолчанию каждый коммит будет добавлять в очередь сборку. Таким образом, чтобы дождаться заветной зеленой галочки в CheckSuite, придется ждать не один час, ну а если там ошибка или ваши сборки очень сложные, то и того дольше.

Pull-Request Tracking — отвечает за запуск сборок только для Pull-реквестов в основную ветку.

Pull-Request Notification — отвечает за то, как вы хотите узнавать о результатах сборки и анализа, например, через GitHub Check Suite.

Tracked Branches — отвечает за запуск сборок при пушах. Рекомендую, выставить опцию «Track only branches listed below» и указать вашу основную ветку.

Здесь находится пример с правильными настройками

Auto-Cancel Non-Finished Inspections

Если вы все же успели толкнуть пару коммитов до завершения сборок, эти настройки отменят предыдущие задания и сразу перезапустят их для вашего последнего коммита.

Это удобно, ведь нас не интересуют результаты билдов для промежуточных коммитов.

Здесь находится пример с правильными настройками

Настройка конфигурации репозитория

Переходим по ссылке:
https://scrutinizer-ci.com/g/ваш-логин/название-репозитория/settings/build-config

Важно выбрать вашу глобальную конфигурацию.

Пример, как задействовать глобальную конфигурацию

В некоторых случаях сборки могут падать из-за отсутствия phpcs в коде вашего репозитория, в таком случае добавьте этот файл.

А в ваш composer.json в секцию require-dev добавьте:

Начало работы

Теперь, давайте толкнем коммит в основную ветку и посмотрим, как выглядит Check Suite со Scrutinizer.

Пример корректной интеграции с GitHub

При желании эти проверки можно сделать обязательными (все или только часть) в настройках вашего репозитория на GitHub (в разделе настроек ограничений веток), — об этом я рассказывал в своем предыдущем посте про автоматизацию ручных действий с GitHub Actions.

Интерактив от Scrutinizer в ревью

После интеграции и успешно пройденной сборки в Scrutinizer появится три кнопки: Code Intelligence, Issues и Coverage.

По сути это визуализированный результат анализа вашего кода, очень помогает ревьюить, наверное.

А покрытие кода выглядит примерно так

При наведении на методы и переменные Code Intelligence подсвечивает типы возвращаемых значений, а зеленые маркеры справа от нумератора строк сообщают о покрытии тестами.

В целом, это удобно, хотя я к Code Intelligence еще не привык.

Я буду рад, если мой опыт был вам полезен и вот такие красивые отчеты вас будут мотивировать писать совершенный код.

Если у вас что-то не получилось с первого раза, не отчаивайтесь.

Попробуйте проанализировать отчеты сборок Scrutinizer, нотификации, возможно вы что-то упустили настраивая интеграцию. Помните, неразрешимых проблем тут нет.

Ну а если, вы все же отчаялись и у вас ничего не получилось, мои контакты открыты для вас, напишите мне, и мы вместе решим вашу проблему.

Источник

Сайт Github Pages не обнаруживает index.html

12 ответов

Это было исправлено автоматически. Мне просто пришлось немного подождать, пока настройки вступят в силу.

Я также столкнулся с той же проблемой сегодня (28.05.2020). Предположим, что вы все сделали правильно (инструкции в https://pages.github.com/) вы должно быть настроено хранилище с именами username.github.io и index.html .

Для меня сработало то, что я выбрал тему Джекилла. Сначала перейдите к Settings репо. В разделе GitHub Pages найдите Theme Chooser , а затем нажмите Choose a Theme . Он перенаправит вас на страницу GitHub с несколькими темами, которые вы можете выбрать. Выберите тему, которая вам нравится, и нажмите Select Theme . Выполнив эти шаги, я обновил свой username.github.io , и страница работала правильно.

Нажатие на второй коммит исправило это для меня.

Видя другие ответы, где изменения исправляют это, я предполагаю, что вам нужно запустить несколько развертываний, чтобы заставить его работать.

Каждый толчок вызовет новое развертывание. Вы можете отслеживать развертывание по адресу https://github.com/username/username.github.io/deployments .

У меня была похожая проблема для частного хранилища. Мой проект Git содержал index.html в корневом каталоге, но страница не отображалась по пути http(s):// .github.io/

Решение в любом случае (общедоступное хранилище или нет) состоит в том, чтобы включить страницы GitHub в настройках хранилища проекта в разделе «Страницы GitHub».

Однако следует помнить, что включение страниц в закрытом хранилище делает файлы .html общедоступными.

Это случилось со мной, и как только я сделал еще один коммит, проблема решилась сама собой. Я просто добавил пробел в файл index.html в моей папке dist, зафиксировал и отправил это изменение в мою ветку gh-pages и BAM! Теперь я могу получить доступ к username.github.io/repository/index.html, просто перейдя в username.github.io/repository.

Довольно поздно на вечеринку, но вот как я исправил это для себя сегодня.

Перейти к настройкам для вашего репозитория: вы можете найти вкладку Настройки на своей странице репо.

Прокрутите вниз до раздела GitHub Pages на странице настроек.

На панели у вас будет информация Источник , в которой говорится: «Ваш сайт GitHub Pages в настоящее время создается из gh-pages branch ». ,

Однако в моих случаях весь код находился в ветке master . Поэтому я выбрал ветку из выпадающего списка в качестве основного, и всего за минуту она была успешно опубликована.

Столкнулся с этим сегодня (октябрь-06-2019)

Я дважды проверил все настройки, все они не исправили проблему, если я не изменил некоторый контент в моем файле index.html. Я также добавил несколько файлов в репо, чтобы сделать его «живым», но тщетно.

Итак, в моем случае я открыл свой index.html прямо в браузере, щелкнул по редактированию и добавил одно слово, зафиксировал основную ветку, обновился, и это заняло менее 5 секунд, и он снова заработал.

Постскриптум Я попробовал почти все решения, предоставленные где-нибудь, у меня ничего не получалось

Если вы не используете Jekyll, обходной путь — поместить файл с именем .nojekyll в корневой каталог.

Мой index.html имел следующую настройку DOCTYPE:

Исправлена проблема для меня.

Если вы не используете Jekyll, удалите файл _config.yml из репозитория. Это исправило проблему для меня.

Вы также можете попытаться отправить локальный репозиторий снова.

Похожая проблема. Мне пришлось создать случайные изменения в моем html, пройти процесс git add / commit / push. Это исправило это для меня! Теперь я могу получить доступ к своей странице, не добавляя .html в конце URL.

У меня была точно такая же проблема. Если вы попробуете ссылку, найденную в указанном репозитории> Настройки> Страницы GitHub, через час после публикации всего кода, страница GitHub будет работать.

Источник

Команда ‘git pull’ работает с терминала, но не с php shell_exec () через хук репозитория git

Я создал webhook в моем репозитории github, который публикует URL-адрес ловушки на моем работающем сервере, чтобы запустить команду pull для обновления файлов репо на сервере.

Проблема в том, что файл хука, который я создал, находится в /var/www/site/web/hookfile.php (туда отправляется почтовый запрос. Я также получаю ответ от тела)

и мои файлы репо находятся в / var / www / git-repo /

это не обновляет git-repo, когда я помещаю что-либо в свой репозиторий github.
Я запускаю эту команду, используя терминал и он работает.

Но через мой php файл не работает

Решение

shell_exec () завершается с ошибкой, потому что только отчет STDOUT, а не STDERR.

Обычно это ошибка разрешения, и она может быть исправлена ​​добавлением разрешения пользователю, выполняющему php (apache?)

Но может быть и ошибка подключения к удаленному хранилищу (аутентификация, ssh-ключи, …).

Другие решения

Прежде всего, в вашем php-файле я запускаю тест для вашего экземпляра сервера, чтобы получить какие-либо сообщения об ошибках, выводимые на экран, потому что семейство функций exec () просто завершается с ошибкой и только сообщает STDOUT, а не STDERR:

в моем случае это выдало ошибку, что он не мог найти команду git из-за отсутствия двоичного пути, определенного для пользователя apache. Следовательно, необходимо указать полный путь к двоичному файлу git. Его можно получить, найдя его вручную или запустив в оболочке:

он вернул (далее называется YOU_FULL_GIT_BINARY_PATH_HERE):

Полный путь с помощью команды git, например ‘/ usr / local / git / bin / git status’ теперь хорошо выполняет команды git.

Другое дело, чтобы пользователь вашего веб-сервера имел достаточно прав для чтения / записи в вашу папку / файлы репо. Я установил, что мой принадлежит пользователю apache (другие версии Centos 6.8 могут быть www: www или www-data: www-data и т. Д.):

Чтобы гарантировать, что все добавленные файлы наследуют правильные разрешения, выполните:

Выше должен получить ваш скрипт для запуска команд сейчас. Хотя это не преодолевает приглашение пароля git использовать команду git pull для пользователя git, установленного в файле YOUR_WEB_OR_REPO_FODLER / .git / config. Выполнение команды ниже в репо:

команда запросит пароль и позволит вам сохранить его локально. Обратите внимание, что ваш сохраненный пароль не будет зашифрован и защищен только файловой системой, например, в /root/.git-credentials. Это позволит запускать «git pull» без запроса пароля.

Это не идеально для моей полностью автоматизированной среды непрерывной интеграции, в которой развертывается тестовый VPS по требованию, поскольку для этого требуется хотя бы один раз вручную ввести пароль пользователя git (определенный в репозитории .git / config git).

Поскольку моя среда всегда должна выполняться на коде из исходной / главной копии удаленного компьютера, я также запускаю

перед вызовом ‘git pull’, чтобы гарантировать, что любые локальные изменения будут потеряны навсегда, или сделайте полный сброс вместо этого, используя:

Источник