@AndrewKvalheim Yes, good question, and thinking: May I suggest regarding your comment and question?
The linter should know about the "!vault
" YAML Tag 1 and where its use is applicable, so that linting supports it as encoded 2 in the file (binary stream).
For this, exposing the secrets to the linter does not look necessary to me. More the contrary, as the current diagnostic message suggests to me, not only should the secrets not be exposed to the linter, but, the linter should not expose the parsing of the encrypted value/s at and after the point the linter starts to require secrets to do its job.
To resolve this, I'd suggest to build-back the parsing of !vault
serializations to just linting the format of such data rather than decoding it.
In my opinion, the linter not being able to transform a secret into a plain is not an error or a warning, not even something to inform about or to offer diagnostics for. The current messages' only reason to exist - as I understand it - is to inform any user of the utility 3 about its limitations and the flaw to process Ansible documents containing !vault
tags. However, it is unknown to me why the linter didn't just treat the data-type as string and not further leave it as-is. This might be a limitation of the linting infrastructure in use.
Rationale is that this is a linter, not a decrypter. 4
From your perspective, would you consider such another reduced approach more feasible than the proposed disclosing publishing of ansible vault password stores to the linter? Or would what I've outlined actually break the overall linting infrastructure of the current design?
ansible-lint(1)
user command)
@ktomk do you think we handle that in n98-magerun2 in any way?
Same as composer likely, this is how I read the recent testing (thanks @amenk).
This works because of $input->isInteractive()
here:
https://github.com/netz98/n98-magerun2/blob/40af6e4e0e8199919699e6f5248bfc7b4032f033/src/N98/Magento/Command/MagentoCoreProxyCommand.php#L65
For regression testing it would be good to have a branch with a robo task that demonstrates it. @amenk, would it be easy to create and push? If all goes well it should be easy to fix and then we would not need to provide addition read-me/release notes on such easy to miss/puzzling behaviour (by behaviour also a regression).
@amenk Thanks, that's what I thought. Can you try to invoke robo prefixed with the unbuffer
command (part of the expect
package)? If that works, this strongly points to TTY handling of the Symfony Console component in use and a potential solution could be similar as in Composer.
Yes, more or less.
What we have done in the past was to make secrets "optional" so that things failed not at setup but at use/access (e.g. not decrypting a key if the password is n/a) so it became clear which builds depend on secrets and until where we could just run without any.
@amenk: Please try and see if it works:
sprintf('php8.1 %s %s | cat', ...
#####
and please share which operating system and shell.
This might be similar: https://github.com/composer/composer/issues/9454#issuecomment-725357457
https://github.com/gollum/gollum/blob/3767a11d21aea98d5d9ba08bf10934752cfe6d49/lib/gollum/committer.rb
https://github.com/travis-ci/travis-yaml
https://github.com/travis-ci/travis-yaml
Thanks for reporting. IIRC this is unsupported for the docker service. As a workaround just using the "docker" service should suffice for testing.
Phive 0.15.2 (also 0.15.1) is talkative when passing output into head(1)
and similar utilities:
$ phive --version | head -n 1
Phive 0.15.2 - Copyright (C) 2015-2023 by Arne Blankerts, Sebastian Heuer and Contributors
[ERROR] An error occurred while processing your request:
fwrite(): write of 1 bytes failed with errno=32 Broken pipe
#0 src/shared/cli/output/ConsoleOutput.php(49)
#1 unknown file(0): PharIo\Phive\Cli\Runner->errorHandler()
#2 src/shared/cli/output/ConsoleOutput.php(49): fwrite()
#3 src/shared/cli/Runner.php(192): PharIo\Phive\Cli\ConsoleOutput->writeText()
#4 src/shared/cli/Runner.php(242): PharIo\Phive\Cli\Runner->showFooter()
#5 src/shared/cli/Runner.php(95): PharIo\Phive\Cli\Runner->execute()
#6 (354): PharIo\Phive\Cli\Runner->run()
#7 {main}
Environment: PHP 7.4.33 (on Linux 5.15.0-60-generic)
Phive Version: 0.15.2
This should not have happened and is most likely a bug.
Please report it at https://github.com/phar-io/phive/issues, make sure you include
the full output of this error message. Thank you!
Reported per request in the message.
Workaround:
phive ... 2>/dev/null | head -n 1
###########
Additional Info:
IMHO the warning is not necessary in this case. I could not find any verbose or quiet switches, no idea how this is handled on utility level. I normally allow failures writing to standard output ignoring broken pipe if it was available at initialization (e.g. @fwrite(STDOUT, ...)
), YMMV.
no changes. @Kryslynn23 feel free to open an issue first if you'd like to make a proposal, we can fiddle with the code then more easily.
merge info about database structure, closes #83
in ref to 4a4226b (update clean database, 2023-01-26).
fix internal linking
fix typo/misspell
fix nav title case
includes fixup of unintended reordering in 4a4226b (update clean database, 2023-01-26).
add change-log redirects
the change-log is hosted on seatable.io, to preserve the existing links redirect. this is an improvement as currently the manual only shows the link to the file and the user needs to click.
via mkdocs-redirect plugin1
update clean database
typos and touch-up.
bump gh-actions versions
from warning:
Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2, actions/setup-python@v2. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
and warning:
The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
bump gh-actions versions
from warning:
Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2, actions/setup-python@v2. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
and warning:
The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
update clean database
typos and touch-up.
bump gh-actions versions
from warning:
Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2, actions/setup-python@v2. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
squash! bump gh-actions versions
The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
bump gh-actions versions
from warning:
Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2, actions/setup-python@v2. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
@dada-dudu: if you rename a file, leave the old one with a link to the new (and if possible only split by content/context to preserve the old meaning if possible). this makes using the manual over time easier. just FYI.