Support multiple projects per change

[fsmaia]

Closes #571

Check the following

• Keep 100% code coverage
• Be properly formatted
• Documentation changes are included
• Include a change file if expected

Additional context
Converting the project flag from StringVarP to StringSliceVarP on the new cmd kept the backward compatibility

[fsmaia]

So far I managed to update the new command properly, and now I'm dealing with an unexpected side effect on the batch command.

Scenario:

1. Configure two projects on the config file
2. Create a change (using new) that affects both projects
3. Run batch command for the first project

Expected behavior: the change should remain unreleased on the second project

Actual behavior: the change is dropped from unreleased as soon as it is released by the first project

[fsmaia]

@miniscruff, I fixed the side effect on the batch command with the following behavior: when running the batch command for a project, the project entry will be removed from unreleased files. If the unreleased entry contains only one project, the unreleased file will be removed (because the change will be released for all the projects on it).

Because of this, I had to increase the complexity lint rule from 16 to 17, is that ok?
I couldn't find a way of refactoring without changing the batch command too much.

[miniscruff]

@miniscruff, I fixed the side effect on the batch command with the following behavior: when running the batch command for a project, the project entry will be removed from unreleased files. If the unreleased entry contains only one project, the unreleased file will be removed (because the change will be released for all the projects on it).

Because of this, I had to increase the complexity lint rule from 16 to 17, is that ok?
I couldn't find a way of refactoring without changing the batch command too much.

Oh, yea I wouldn't change the change struct, I would create a separate file for each project. That should have the least issues with batching.

[fsmaia]

I prefer the implemented way for some reasons:

• The unreleased change file gets more idiomatic and concise because it states that a change may have multiple projects, instead of duplicating all its content
• The prompt belongs to a change (change.AskForPrompts), and refactoring the prompt to produce several changes would produce a huge change in the code

If you still prefer producing a change for each project, let me know, and then I can update the pull request.

[miniscruff]

I prefer the implemented way for some reasons:

• The unreleased change file gets more idiomatic and concise because it states that a change may have multiple projects, instead of duplicating all its content
• The prompt belongs to a change (change.AskForPrompts), and refactoring the prompt to produce several changes would produce a huge change in the code

If you still prefer producing a change for each project, let me know, and then I can update the pull request.

While I do agree with you, by keeping one file to one change per project it allows us to keep the only two operations as read the whole file and deleting it, no edits. Yes, it is maybe a little weird creating multiple files, but by keeping each project separate we can release them using PRs that for sure won't conflict. If we had to edit a file that would create an issue that changie aims to solve via files.

The internal yaml files, although can be changed, they should sort of be treated as hidden system files, so whether or not we create many or one file shouldn't be an issue.

[fsmaia]

Yep, I agree with the importance of having changes as atomic as possible.

Conceptually, the new command creates a change, which has validations and prompts within it.

For me, it's not clear how the New.Run should behave.

It seems to me that the unreleased file should have only one project, but I would keep a project list on the Change structure since it is a business rules structure, and not only the file representation.

[fsmaia]

To implement this, we should move the AskPrompts method to a new structure, and then we should collect the result of promptForProjects for generating multiple changes with the same configuration.

Do you see another way around this?

[fsmaia]

I just managed a way to move the prompt to another structure that accepts multiple projects, so far called PromptChange.
Could you check if the implementation is okay?

PS.: some tests are still broken, I'll be able to fix them on Monday.

[miniscruff]

The code in this PR doesn't seem wrong, I will have to try it out myself to be sure. But it is quite a bit of changes and I just want to give it a try myself before merging. I will try and get to it this weekend, I may create my own PR or edit this one, not sure yet.

One thing is your change from change to prompt.go is a fairly large change and I want to make sure I fully understand it. Thanks for the work though this is a big help for sure.

[fsmaia]

Yep, besides being a big change, I don't think that the "prompt change" is the correct abstraction, btw it's hard to find the proper naming for the layer between the new command and the atomic change itself.

Personally I would try to avoid moving all of it to the cmd package.

Definitely, feel free to update this PR or open a new one, I'm still here if any help is needed!

Thank you!!

[fsmaia]

@miniscruff any news on this?

[miniscruff]

@miniscruff any news on this?

Sorry I am away on a trip this week, still on my list of todos.

[miniscruff]

Ok, going to tackle this today, finally able to get time to figure this out.

[miniscruff]

Closing in favor of #579, I did take a bit of inspiration from your work with a few tweaks.
Thanks again @fsmaia