Changie new to not overwrite existing file
anuragagarwal561994 opened this issue · 13 comments
Is your feature request related to a problem? Please describe.
Changie new will overwrite existing unreleased file, we wanted to automate the process of creating unreleased files from commit messages and right now we are using {{now | unixEpoch}} as fragmentFileFormat but if we are running a loop there is still a chance that it might conflict with the exisiting files.
Describe the solution you'd like
A better aproach would have been to add a suffix like <timestamp>-1 if the file already exists, this may also be applicable for other use cases where we would like to highlight multiple changes from a single merge request.
Although this can also be solved with {{uuidv4}} but still it will be a good to have feature.
The default value of the fragment file uses a few values to prevent conflicts from a person hence why it uses only up until I believe seconds in the time format.
default:"{{.Project}}-{{.Component}}-{{.Kind}}-{{.Time.Format \"20060102-150405\"}}"
It would be possible to use more specific time formats down to I think nanoseconds. Or, you could use the random functions from sprig to add an extra level of uniqueness https://masterminds.github.io/sprig/strings.html ( changie includes sprig funcs ).
This default is good for human readble files but when they are auto generated lets say in a loop, it may repeat. That is why I started using uuid4
Right, sprig has some random functions in the string page for like alpha and numeric but if you are ok with uuid's its basically the same idea.
I would maybe do {{.Kind}}-{{uuidv4}} but yea up to you.
But isn't it better that instead of overwriting the existing file an indexed version is created? We can close the issue if doesn't make sense I think my usecase is more or less solved.
Hmm, I think having changie exit with an error on a duplicate file would be an ok change, maybe call it a bugfix. But that it is out of scope for changie to try and index the version as the general idea is that the fragment config should be written in such a way to create unique files all the time, hence the second level timestamp. Using a script to generate changie fragment files is basically an unsupported use case of the new command and thus its more of a user issue unfortunately.
I am curious why you are using a script to generate files from commit messages rather then as part of pull requests when the developer is working on the feature? Or is this when you generate the monthly releases you need the script for?
So our general workflow is that we create a feature MR from the main branch and then squash and merge the changes to the main branch, so basically each of the commits in the main branch can ideally a valid changelog entry, there would be very few exceptions where we would like to ignore these entries.
Instead of relying on the developers to generate a changelog file themselves, what we instead thought of would be a better approach is as follows:
- they merge their changes as is and it is not mandatory for them to include a fragment file in the MR
- if they include a fragment file it would be considered an additional changelog entry they would like to have
- if they don't want a MR to be included in the changelog they can prefix the title of the MR with
ignoreor something similar - while we are releasing the changes, we would get all the commits from the last deployed release and in the ci itself we would categories these commits (using some keywords) and create fragment files and then use batch to generate a version file which we will use as our release notes, hence automating the process and not relying on developers to mandatorily be bounded with a new tool
Another suggestion if possible would be to provide a filename when creating a fragment with changie new I think this should also work, because we will have more control now automating the process and indexing or anything can be left out of the scope of changie and can be handled by the ci while creating the fragment file
If you are just pulling merge request titles I am not sure the value of changie new. If you already have all the info you need, you can just generate your own yaml fragment files. The supported use case is for developers to use changie as part of their workflow. The issues you are running into are therefore outside that scope.
I, of course, recommend having developers install and use changie in the merge request.
Or, building your own fragments.
Sure will close the issue then
If you are just pulling merge request titles I am not sure the value of changie new. If you already have all the info you need, you can just generate your own yaml fragment files. The supported use case is for developers to use changie as part of their workflow. The issues you are running into are therefore outside that scope.
I, of course, recommend having developers install and use changie in the merge request. Or, building your own fragments.
I understand the scope of chanige, but I wanted to actually build a hybrid solution for my team, where individuals have the options to change and edit but at the same time they don't have to keep forgetting about not adding the changie files and we miss the changelog details, because that history for us can be important in identifying if something goes wrong, so we can't miss something. We just needed a way to organise stuff a bit.
If you are just pulling merge request titles I am not sure the value of changie new. If you already have all the info you need, you can just generate your own yaml fragment files. The supported use case is for developers to use changie as part of their workflow. The issues you are running into are therefore outside that scope.
I, of course, recommend having developers install and use changie in the merge request. Or, building your own fragments.
I understand the scope of chanige, but I wanted to actually build a hybrid solution for my team, where individuals have the options to change and edit but at the same time they don't have to keep forgetting about not adding the changie files and we miss the changelog details, because that history for us can be important in identifying if something goes wrong, so we can't miss something. We just needed a way to organise stuff a bit.
I am using a GitHub action to validate the PR has a changie fragment, unless told otherwise. This flips the check from users to CI but keeps the optional portion which I take advantage of for docs or ci updates.
We tried that approach as well, but then there are other bots and processes, for example we have renovate as our dependency updater. Now it generates 3-5 depenencies per week and it will be an additional chore to create the files manually here for the end user.
Secondly reverts can also be conflicting as the fragments are getting stored. But I believe both the approaches suits their needs