laminas / automatic-releases

Automated release process for `laminas/` projects, usable as github action
Other
141 stars 23 forks source link

Expected a value to be true. Got: false #78

Open greg0ire opened 4 years ago

greg0ire commented 4 years ago

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

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 commented 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.

beberlei commented 4 years ago

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

Ocramius commented 4 years ago

Most likely, yes

greg0ire commented 4 years ago

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

Definitely 👍

one level should be enough to display a stack trace

Ocramius commented 4 years ago

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

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

greg0ire commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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
greg0ire commented 4 years ago

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 commented 3 years ago

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

Ocramius commented 3 years ago

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 .

ostrolucky commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

greg0ire commented 3 years ago

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 commented 3 years ago

Yeah. You can also call

$output->setVerbosity(OutputInterface::VERBOSITY_DEBUG);
ostrolucky commented 3 years ago

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 commented 3 years ago

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