Open greg0ire opened 4 years ago
Hmm, perhaps we could change the verbosity to be higher by default?
BTW, the tool bails out early on most operations by design, since it's really easy to mess up git when preconditions aren't met.
@ocramius could this be related to the branch name being 2.7 not 2.7.x?
Most likely, yes
Hmm, perhaps we could change the verbosity to be higher by default?
Definitely 👍
Can we somehow do that by default, in the application bootstrapper?
I think you would do that here, by messing with the currently not provided $input
argument: https://github.com/laminas/automatic-releases/blob/2008a9e98f65c0dcacb90eabb4d12987080ed1d7/bin/console.php#L168
A typical bin/console
of a symfony app looks like this (excerpt):
$input = new ArgvInput();
if (null !== $env = $input->getParameterOption(['--env', '-e'], null, true)) {
putenv('APP_ENV='.$_SERVER['APP_ENV'] = $_ENV['APP_ENV'] = $env);
}
if ($input->hasParameterOption('--no-debug', true)) {
putenv('APP_DEBUG='.$_SERVER['APP_DEBUG'] = $_ENV['APP_DEBUG'] = '0');
}
(new Dotenv())->bootEnv(dirname(__DIR__).'/.env');
if ($_SERVER['APP_DEBUG']) {
umask(0000);
if (class_exists(Debug::class)) {
Debug::enable();
}
}
$kernel = new Kernel($_SERVER['APP_ENV'], (bool) $_SERVER['APP_DEBUG']);
$application = new Application($kernel);
$application->run($input);
An alternative is to use the SHELL_VERBOSITY
env var… maybe set it if it is not specified?
Ok, i created a second branch named 2.7.x and even changed it to be the default branch, it still fails with the same error.
I added LOG_LEVEL=DEBUG
to this task, which is how bin/console.php here allows to change the config, but it didn't lead to an expanded stacktrace.
You'd need to add -vvv
to the commands being run: I don't think any other env variables are being considered at all.
You'd need to add -vvv to the commands being run: I don't think any other env variables are being considered at all.
What about https://github.com/laminas/automatic-releases/issues/78#issuecomment-706596751 ?
All right, SHELL_VERBOSITY=3
is the trick, the error happens in Laminas\AutomaticReleases\Github\Api\GraphQL\Query\GetMilestoneChangelog\Response\Milestone->assertAllIssuesAreClosed()
.
I assumed it creates a new, next milestone and moves the issues, I can obviously do that manually.
Then the next thing happens :-( https://github.com/doctrine/orm/runs/1237872494?check_suite_focus=true
[2020-10-11T10:11:48.144944+00:00] automatic-releases.INFO: CommitReleaseChangelog: no changes to commit. [] []
In Process.php line 252:
[Symfony\Component\Process\Exception\ProcessFailedException]
The command "'git' 'push' 'origin' 'temporary-branch5f82da676cfaa3.98563296
:2.7.x'" failed.
Exit Code: 1(General error)
Working directory: /github/workspace
Output:
================
Error Output:
================
To https://github.com/doctrine/orm.git
! [rejected] temporary-branch5f82da676cfaa3.98563296 -> 2.7.x (
non-fast-forward)
error: failed to push some refs to 'https://v1.12b60c6b8369e134fe1f1f482e53
bccacca1c218:x-oauth-basic@github.com/doctrine/orm.git'
hint: Updates were rejected because a pushed branch tip is behind its remot
e
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Exception trace:
at /app/vendor/symfony/process/Process.php:252
Symfony\Component\Process\Process->mustRun() at /app/src/Git/PushViaConsole.php:31
Laminas\AutomaticReleases\Git\PushViaConsole->__invoke() at /app/src/Application/Command/ReleaseCommand.php:113
Since you added some troubleshooting commits on top of 2.7.x, the message is correct I think. I don't understand why the tag was not created on the tip of the branch though. Was it maybe created in a previous try, before you pushed the commits?
We have same issue in doctrine-bundle now https://github.com/doctrine/DoctrineBundle/runs/1381977513?check_suite_focus=true
Can you try adding -vvv
to that build step?
On Tue, Nov 10, 2020, 21:54 Gabriel Ostrolucký notifications@github.com wrote:
We have same issue in doctrine-bundle now https://github.com/doctrine/DoctrineBundle/runs/1381977513?check_suite_focus=true
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/laminas/automatic-releases/issues/78#issuecomment-724960635, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFVECKWZ44NKKWXRE34OLSPGSCBANCNFSM4SLHGBOQ .
Add it where? I am not familiar with github actions and these don't seem like normal commands https://github.com/doctrine/DoctrineBundle/blob/1.12.x/.github/workflows/release-on-milestone-closed.yml
I would try smashing it into the "command" value - IIRC it's just concatenated: https://github.com/laminas/automatic-releases/blob/1.8.0/action.yml#L20
I had to create release yesterday, so in the end I created it manually. Let's see next time when we will be creating release. Meanwhile, can't you make this default?
Verbosity by default sounds good, just unsure how to do that on symfony/console
🤔
See https://github.com/laminas/automatic-releases/issues/78#issuecomment-706596751 , how about putting SHELL_VERBOSITY=3
in the env if not already defined?
Yeah. You can also call
$output->setVerbosity(OutputInterface::VERBOSITY_DEBUG);
I debugged this issue in doctrine/migrations and it turns out this bot expects all issues assigned to the milestone we are closing closed. If you don't have everything closed, then it throws this obscure error.
Similar issue is when you merge lower branch to upper one and the close the milestone. There is nothing to sync in that case and bot will then complain with another obscure error:
Expected a value less than or equal to 299. Got: 422
These messages really should be improved so user knows what to do to make it work.
With both #125 and #138, the exceptions should now make more sense: keeping this open though, until we see the next cryptic.
Bug Report
Summary
laminas:automatic-releases:release
crashes without a stack trace, just the unhelpful error message in the titleCurrent behavior
How to reproduce
Running the action on
doctrine/orm
2.7 should workExpected behavior
No crash, or at least, a crash with a stack trace (use
-vvv
?)