fix: quiet flag to stop credential process errors

[joshrivers]

Resolves #159

• main.initializeLogger() now installs a no-op logger as the global logger if a "quiet" flag has been passed to the CLI argument parser
  • Added coverage for initializeLogger to establish its behavior with different flags or defaults
• Added -q, --quiet, and --non-interactive flags as options on the assume subcommand. These could be moved to a higher scope later if useful, but they currently only appear to be relevant to this subcommand
• Modified the credential process template to add the -q flag on profile creation
• Updated README with current help output
• Changed references to ioutil.ReadFile to os.ReadFile to resolve deprecation notes
• Partially resolved a unit test race condition which was making GitHub Actions builds fail intermittently
  • Purged build caches, since any successful runs would prevent subsequent failures
  • Added pre- and post- removal of the lock-file to allow test runs to complete without stopping due to the lock
  • Ensured the defer functions were established before test operations which could crash the process

Discussion: the root problem here is the frequent use of zap.Fatal() through the application code. This causes the test execution process to immediately terminate without collecting failure logging when any application error occurs. Since the zap logger is not initialized for test runs, it is difficult to see where the problem is happening without debugging. Debugging is hard since it worked 100% of the time on my machine, only failing in the GitLab Actions. I wasn't able to determine if the failure was due to the main and assume tests having an interaction because of concurrency, or due to interactions between subsequent runs in the Actions environment with restored caches. I suspect the former, but it got late. I was thinking that the same behavior, but with better failure notification in the tests might be achieved by using zap.Panic() rather than zap.Fatal(), but I haven't thought through the implications. Providing a wrapper interface/factory for zap that could be overridden with a mock in the tests would also solve the same problems. The temp file location might also have a testing override to ensure that test cases are isolated from each other.

Not fixed:

• The executable name provided in the credential process template can include spaces from the file system path. This can cause failures if the go-aws-sso executable is not in a "normal" location. I'm not 100% certain that just quoting the fully qualified executable path in that file works cross-platform. Go does not have a batteries-included version of the Python shlex.quote function and I didn't want to add a dependency for a different issue than the one I was working on.

[theurichde]

Sorry for keeping you waiting so long. Holiday season is finally over, time for some review 🔍 😀

First of all: Thanks for your PR, your contribution and your input! I really appreciate that!

Regarding the non-interactive alias - I would simply drop it, as it adds no benefit imo; --quiet or -q are totally fine.

What do you think?

[theurichde]

Discussion: the root problem here is the frequent use of zap.Fatal() through the application code.

I will take that point with me and create an issue out of it to have a look and work on it. Thanks for the detailed input! Edgy edge cases sometimes bite back.

[theurichde]

Not fixed: The executable name provided in the credential process template can include spaces from the file system path.

Interesting point! I will also create an issue for that, to look into and play around with it.

[joshrivers]

Sorry for keeping you waiting so long. Holiday season is finally over, time for some review 🔍 😀

First of all: Thanks for your PR, your contribution and your input! I really appreciate that!

Regarding the non-interactive alias - I would simply drop it, as it adds no benefit imo; --quiet or -q are totally fine.

What do you think?

I agree. Keeping it simple is better.