-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expected a value to be true. Got: false #78
Comments
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 |
Definitely 👍 |
Can we somehow do that by default, in the application bootstrapper? automatic-releases/bin/console.php Line 108 in 2008a9e
|
I think you would do that here, by messing with the currently not provided automatic-releases/bin/console.php Line 168 in 2008a9e
A typical $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 |
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 |
You'd need to add |
What about #78 (comment) ? |
All right, 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
|
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ý ***@***.***> 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
<#78 (comment)>,
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 |
See #78 (comment) , how about putting |
Yeah. You can also call
|
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:
These messages really should be improved so user knows what to do to make it work. |
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
?)The text was updated successfully, but these errors were encountered: