Reset switch in .flux.yaml

[squaremo]

Briefly: let people reset the processing rules in .flux.yaml, so you can have a .flux.yaml at the top of the git repo, but switch that off for a particular --git-path.

(At present this is branched from another PR, because I will need to write a bit of documentation about this new thing, and better to do so in revised docs)

[2opremio]

Shouldn't we bump the version?

[squaremo]

Why? No-one has used this yet.

[2opremio]

But we are changing the file format

[squaremo]

Versioning here is to prevent misunderstandings about what the file means; in particular, to make sure that you aren't giving fluxd an instruction it doesn't know how to carry out.

Can you think of a potential mistake that would be avoided by bumping the version here?

[squaremo]

I am not absolutely against it, but it does mean writing code that would discriminate between the two versions (assuming we'd want to not invalidate everyone's config immediately.)

[2opremio]

Can you think of a potential mistake that would be avoided by bumping the version here?

No, not really.

I am not absolutely against it, but it does mean writing code that would discriminate between the two versions (assuming we'd want to not invalidate everyone's config immediately.)

Yeah, that's a pain.

I think that, technically, we should bump the version number but I am not sure it's worth the pain.

Maybe we could use minor version numbers for backward-compatible syntax changes (without needing to handle it differently in the code). Or maybe we can just leave it at version 1 .

[2opremio]

Can you extend the .flux.yaml documentation with the additional syntax?

[squaremo]

Now I'm writing some docs, it occurs to me that this:

version: 1
files: {}

looks like it says "include the following files (none)". The map value {} is just to have a value for the field, and it's a map because maybe we want to add more stuff there later, and otherwise any value would do.

Thinking thinking thinking ...

[squaremo]

Now I'm writing some docs, it occurs to me that this:

version: 1
files: {}

looks like it says "include the following files (none)".

Use another word:

version: 1
plainFilesMode: {}

• doesn't look like it's supposed to be including or excluding specific files

Use another, constant value:

version: 1
files: true

• it's obvious that it's a toggle (although what is the meaning of files: false?)
• adding more configs means a breaking schema change

Of these I think I prefer the first.

[2opremio]

how about something a bit more descriptive

version: 1
scanThisDirForManifestFiles: true

[stefanprodan]

I like files: {}, it gives us the the possibility to add glob filters later on, something like:

version: 1
files:
 include: "*prod.yaml"
 exclude: "crd*"

[squaremo]

I like files: {}, it gives us the the possibility to add glob filters later on

Yeah I like it for that reason too; it's just that the empty value (for now, the only possible value) gives the wrong impression.

[squaremo]

Replaced files: {} with scanForFiles: {}, which I think is descriptive enough, and avoids the ambiguity. Possibly.

[squaremo]

Merge it while it's hot!

Thanks @2opremio and @stefanprodan for reviews and comments.