Skip to content

Add a --dry-run flag to validate the config - #331

Merged
F1bonacc1 merged 4 commits into
F1bonacc1:mainfrom
lopter:lo-config-check-command
May 6, 2025
Merged

Add a --dry-run flag to validate the config#331
F1bonacc1 merged 4 commits into
F1bonacc1:mainfrom
lopter:lo-config-check-command

Conversation

@lopter

@lopter lopter commented Apr 21, 2025

Copy link
Copy Markdown
Contributor

Hello,

Thanks for the project, it is very useful.

One thing I have been missing is the ability to validate a generated config without starting any processes. This is very useful in CI, or with Nixpkgs when the config is generated as a derivation (and can be validated in the check phase of the derivation).

This PR attempts to add that, and I run into a couple questions I left in the code. Can you help answer them, and tell me if the overall approach is good?

@F1bonacc1 F1bonacc1 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @lopter,
Thanks for the PR! I think this is a very useful feature to have, and your approach is valid.

I think there is a simpler and more user-friendly way to tackle this issue.
If you add a --dry-run flag to the up and root commands, it will:

  1. Consider additional (existing and future) flags when validating.
  2. Eliminate the need for some of the refactoring.

What do you think?

Comment thread src/types/process.go Outdated
Comment thread src/cmd/0-init.go Outdated
@lopter
lopter force-pushed the lo-config-check-command branch from b85f4ea to 3fec4c3 Compare April 22, 2025 00:32
@lopter

lopter commented Apr 22, 2025

Copy link
Copy Markdown
Contributor Author

Thanks for the quick feedback @F1bonacc1, no strong feelings there, and I reworked the PR to go with your approach.

I was wondering if --dry-run flag should imply is_struct: true?

Is there anything we can do regarding validation of the values? The config file uses a fair amount of enumerations that would be nice to validate as well.

@F1bonacc1 F1bonacc1 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @lopter, for the quick refactor.

Regarding values validation, I see 2 main approaches here:

  1. Maintain map[string]struct{} maps for all the valid values for each Key. This is a quick and simple approach, but can easily go out of sync.
  2. Add code generation that will be generating both the const strings and the validation maps from some yaml or json schema files. This sounds to me like not an easy task. But I had a short back and forth with Gemini about it, and it gave me a decent head start.

What do you think? Want to give it a try?

Comment thread shell.nix
@@ -0,0 +1,11 @@
{

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this part of the PR or an accidental inclusion?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not accidental, but probably belong into another PR: if you don't mind I would like to add this file and wire it up from flake.nix. With a shell.nix, and maybe an .envrc, when a Nix user cd into the project, it sources everything needed to work on the project (that is even if they don't have golang installed on their machine).

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, we can keep it.

Comment thread src/cmd/root.go Outdated
runner := getProjectRunner(args, *pcFlags.NoDependencies, "", []string{})
if *pcFlags.DryRun {
processNames, _ := runner.GetLexicographicProcessNames()
fmt.Printf("Loaded %d processes from %d config files.\n", len(processNames), len(opts.FileNames)+len(opts.EnvFileNames))

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that "Loaded" really reflects the intent of this feature?
Maybe something like "Successfully validated" will make more sense for the --dry-run flag?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I can do that.

@F1bonacc1

Copy link
Copy Markdown
Owner

I was wondering if --dry-run flag should imply is_struct: true?

Yes, I think this will be the right approach.

@lopter

lopter commented Apr 29, 2025

Copy link
Copy Markdown
Contributor Author

Great, I can set is_struct = true.

Regarding validating values, I see your two suggestions, and I am wondering if a third option could be to implement enums. This way, values would be validated when the config files are unmarshalled?

@lopter

lopter commented Apr 29, 2025

Copy link
Copy Markdown
Contributor Author

I see both yaml.v3 and yaml.v2 are used, is there a reason for that? Or could we move everything to yaml.v3?

@lopter
lopter force-pushed the lo-config-check-command branch from 34967ea to 6c74c74 Compare April 29, 2025 05:42
@lopter

lopter commented Apr 29, 2025

Copy link
Copy Markdown
Contributor Author

I did a quick test on one of the enums so that you can see what it would like, see: 6c74c74.

@F1bonacc1

Copy link
Copy Markdown
Owner

I see both yaml.v3 and yaml.v2 are used, is there a reason for that? Or could we move everything to yaml.v3?

Yes, I think everything can be yaml.v3, thanks for noticing that.

@F1bonacc1

Copy link
Copy Markdown
Owner

Great, I can set is_struct = true.

Regarding validating values, I see your two suggestions, and I am wondering if a third option could be to implement enums. This way, values would be validated when the config files are unmarshalled?

I like your suggestion even more.
Let's go with that then.

@lopter

lopter commented May 5, 2025

Copy link
Copy Markdown
Contributor Author

qq: is there actually other user-facing enums than ProcessCondition and RestartPolicy? Somehow I imagined there was more than that, but looks those are the only two.

With those two enums in place, is there anything else we can do to validate the config?

@F1bonacc1

Copy link
Copy Markdown
Owner

qq: is there actually other user-facing enums than ProcessCondition and RestartPolicy? Somehow I imagined there was more than that, but looks those are the only two.

With those two enums in place, is there anything else we can do to validate the config?

There is also the log level, but it is validated here:

lvl, err := zerolog.ParseLevel(p.LogLevel)

Other than that, I can't think of anything else.

This allows Nix users to run `nix-shell` from the project's directory
and bring in scope everything needed to use the Makefile.

And use `/usr/bin/env bash` instead of `/bin/bash` for portability on
Nix, and other OSes, where `bash` will not be installed in `/bin`.
@lopter
lopter force-pushed the lo-config-check-command branch from 8d69d08 to 9a2414f Compare May 5, 2025 21:21
@lopter

lopter commented May 5, 2025

Copy link
Copy Markdown
Contributor Author

Ok, I see it has UnmarshalText but not sure how you can use it.

I did some rebase/fixup/squash operation, looks like I introduced some issue and one of the test gets stuck.

@lopter
lopter force-pushed the lo-config-check-command branch from 9a2414f to 4cff3c6 Compare May 5, 2025 21:41
@lopter

lopter commented May 5, 2025

Copy link
Copy Markdown
Contributor Author

Test is fixed: I had to move RestartPolicyNo to be the zero (iota) / default value.

@lopter lopter changed the title WIP: Add a config check (sub)-sub-command to validate the config Add a --dry-run flag to validate the config May 5, 2025
@lopter

lopter commented May 5, 2025

Copy link
Copy Markdown
Contributor Author

I updated the PR title, and had one last question: Should we also allow dry-run to be set through an environment variable?

@F1bonacc1

Copy link
Copy Markdown
Owner

I updated the PR title, and had one last question: Should we also allow dry-run to be set through an environment variable?

I don't think so, at least not until someone will ask for it 😃

lopter added 3 commits May 5, 2025 22:09
Without starting any processes.

This is particularly useful in CI/CD scenarios.

This is implemented using enums.

`is_strict` is forced to true when `--dry-run` is used. The flag is set
to `LoaderOptions` in order to do that.
@lopter
lopter force-pushed the lo-config-check-command branch from 86da121 to 98ac7d0 Compare May 5, 2025 22:10
@sonarqubecloud

sonarqubecloud Bot commented May 5, 2025

Copy link
Copy Markdown

@lopter

lopter commented May 5, 2025

Copy link
Copy Markdown
Contributor Author

Alright, I don't have anything else then, this is ready to go for me :3

@F1bonacc1
F1bonacc1 merged commit fc52776 into F1bonacc1:main May 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants