Giters

nginxinc / kic-reference-architectures

MARA: Modern Application Reference Architecture

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

bug: jenkins runs fail when process tries to read keyboard input for passwords

qdzlug opened this issue · comments

commented

Describe the bug
When running via jenkins the process aborts with the following errors:

[2022-07-26T20:47:45.914Z] + echo ****

[2022-07-26T20:47:45.914Z] + /jenkins/workspace/jay_lke_mara/pulumi/python/runner -p linode up

[2022-07-26T20:47:46.868Z] /usr/lib/python3.8/getpass.py:91: GetPassWarning: Can not control echo on the terminal.

[2022-07-26T20:47:46.868Z]   passwd = fallback_getpass(prompt, stream)

[2022-07-26T20:47:46.868Z] Warning: Password input may be echoed.

[2022-07-26T20:47:46.868Z] Harbor administrator password: Traceback (most recent call last):

[2022-07-26T20:47:46.868Z]   File "/usr/lib/python3.8/getpass.py", line 69, in unix_getpass

[2022-07-26T20:47:46.868Z]     old = termios.tcgetattr(fd)     # a copy to save

[2022-07-26T20:47:46.868Z] termios.error: (25, 'Inappropriate ioctl for device')

[2022-07-26T20:47:46.868Z] 

[2022-07-26T20:47:46.868Z] During handling of the above exception, another exception occurred:

[2022-07-26T20:47:46.868Z] 

[2022-07-26T20:47:46.868Z] Traceback (most recent call last):

[2022-07-26T20:47:46.868Z]   File "/jenkins/workspace/jay_lke_mara/pulumi/python/automation/main.py", line 482, in <module>

[2022-07-26T20:47:46.868Z]     main()

[2022-07-26T20:47:46.868Z]   File "/jenkins/workspace/jay_lke_mara/pulumi/python/automation/main.py", line 213, in main

[2022-07-26T20:47:46.868Z]     init_secrets(env_config=env_config, pulumi_projects=provider.execution_order())

[2022-07-26T20:47:46.868Z]   File "/jenkins/workspace/jay_lke_mara/pulumi/python/automation/main.py", line 398, in init_secrets

[2022-07-26T20:47:46.868Z]     value = getpass(prompt)

[2022-07-26T20:47:46.868Z]   File "/usr/lib/python3.8/getpass.py", line 91, in unix_getpass

[2022-07-26T20:47:46.868Z]     passwd = fallback_getpass(prompt, stream)

[2022-07-26T20:47:46.868Z]   File "/usr/lib/python3.8/getpass.py", line 126, in fallback_getpass

[2022-07-26T20:47:46.868Z]     return _raw_input(prompt, stream)

[2022-07-26T20:47:46.868Z]   File "/usr/lib/python3.8/getpass.py", line 148, in _raw_input

[2022-07-26T20:47:46.868Z]     raise EOFError

[2022-07-26T20:47:46.868Z] EOFError

script returned exit code 1

This happens even when the values are passed into the configuration file during the job setup:

   $WORKSPACE/pulumi/python/venv/bin/pulumi config set linode:harbor_password "Zf4dabEA" --secret -C pulumi/python/config -s marajenklke${BUILD_NUMBER}
          $WORKSPACE/pulumi/python/venv/bin/pulumi config set linode:harbor_db_password "Zf4dabEA" --secret -C pulumi/python/config -s marajenklke${BUILD_NUMBER}
          $WORKSPACE/pulumi/python/venv/bin/pulumi config set linode:harbor_sudo_user_password "Zf4dabEA" --secret -C pulumi/python/config -s marajenklke${BUILD_NUMBER}

Looking at the code, it appears we just prompt without checking to see if the value is already present:

        harbor_secrets = [SecretConfigKey(key_name='linode:harbor_password',
                                          prompt='Harbor administrator password'),
                          SecretConfigKey(key_name='linode:harbor_db_password',
                                          prompt='Harbor database password'),
                          SecretConfigKey(key_name='linode:harbor_sudo_user_password',
                                          prompt='Harbor instance sudo user password')]
        harbor_project = PulumiProject(path='infrastructure/linode/harbor',
                                       description='Harbor',
                                       config_keys_with_secrets=harbor_secrets)

To Reproduce
Steps to reproduce the behavior:

  1. Deploy Linode via Jenkins
  2. Process will fail as shown above

Expected behavior
The process should honor the passwords already present in the config file.

Your environment

  • Version of the repo: 24ee0c0 on automation-api branch

Additional context
None

commented

Not a bug; we were putting the configuration variables into the wrong config - with the automation-api changes, the secrets config is carried in the kubernetes/secrets project.

Moving the secrets to the correct project resolved this issue.