Expected a value to be true. Got: false

[greg0ire]

Bug Report

Q	A
Version(s)	1.8.0

Summary

laminas:automatic-releases:release crashes without a stack trace, just the unhelpful error message in the title

Current behavior

• crash as seen at https://github.com/doctrine/orm/runs/1236034190?check_suite_focus=true#step:4:14
• no stack trace

How to reproduce

Running the action on doctrine/orm 2.7 should work

Expected behavior

No crash, or at least, a crash with a stack trace (use -vvv?)

[Ocramius]

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.

[beberlei]

@ocramius could this be related to the branch name being 2.7 not 2.7.x?

[Ocramius]

Most likely, yes

[greg0ire]

Hmm, perhaps we could change the verbosity to be higher by default?

Definitely 👍

one level should be enough to display a stack trace

[Ocramius]

Can we somehow do that by default, in the application bootstrapper?

https://github.com/laminas/automatic-releases/blob/2008a9e98f65c0dcacb90eabb4d12987080ed1d7/bin/console.php#L108

[greg0ire]

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

See https://github.com/symfony/console/blob/3b597067ee2b07ef6fbbebfe2afa0e88fae9a8a7/Application.php#L904-L926

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?

[beberlei]

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.

[beberlei]

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.

[Ocramius]

You'd need to add -vvv to the commands being run: I don't think any other env variables are being considered at all.

[greg0ire]

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 ?

[beberlei]

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.

[beberlei]

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:[email protected]/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

[greg0ire]

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?

[ostrolucky]

We have same issue in doctrine-bundle now https://github.com/doctrine/DoctrineBundle/runs/1381977513?check_suite_focus=true

[Ocramius]

Can you try adding -vvv to that build step?

On Tue, Nov 10, 2020, 21:54 Gabriel Ostrolucký [email protected] 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 .

[ostrolucky]

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

[Ocramius]

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

[ostrolucky]

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?

[Ocramius]

Verbosity by default sounds good, just unsure how to do that on symfony/console 🤔

[greg0ire]

See https://github.com/laminas/automatic-releases/issues/78#issuecomment-706596751 , how about putting SHELL_VERBOSITY=3 in the env if not already defined?

[ostrolucky]

Yeah. You can also call

$output->setVerbosity(OutputInterface::VERBOSITY_DEBUG);

[ostrolucky]

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.

[Ocramius]

With both #125 and #138, the exceptions should now make more sense: keeping this open though, until we see the next cryptic.