-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Added ability to generate a log file #2
base: master
Are you sure you want to change the base?
feat: Added ability to generate a log file #2
Conversation
@SamuelJohnsonMedia Hi, Thanks for the contribution Correct me if I'm wrong, but I don't think the log file changes take effect unless they're committed. |
Yes; I didnt commit these files to git because there are other actions that can do that; but I would like to have only one action that does the two
Yeah sure, I will do that |
@ardalanamini Have now updated the PR to add the ability to commit the changelog or in fact any others like files updated with new version numbers. Hope its okay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SamuelJohnsonMedia Thanks for adding the functionality
I think compared to other similar actions this would have too many unnecessary options, also I'm trying to add as fewer dependencies as possible
I'd be more than happy to help make it ready to be merged and consume less of your time, cause I'm totally on board with adding this feature
so let me know if you're ok with me making the next changes in this PR and asking for your opinion at the end and bothering you less
README.md
Outdated
#### `generate` | ||
|
||
Generate or update a change log file. | ||
|
||
#### `path` | ||
|
||
If `generate` set, specifies the path of the change log file to update (default `./CHANGELOG.md`) | ||
|
||
#### `title` | ||
|
||
If `generate` set, specifies the markdown text to use as the file heading (default `# Changelog`) | ||
|
||
#### `section` | ||
|
||
If `generate` set, specifies the tagged markdown text to use for each release section (default `## Release {{ GITHUB_REF }}`) | ||
|
||
#### `files_to_commit` | ||
|
||
Commits any files, like the updated changelog file, to the repo on completion (comma separated). Does not commit anything by default. | ||
|
||
#### `commit_message` | ||
|
||
If `files_to_commit` contains any files to commit, this specifies the message to use (default `chore(pipeline updates): [skip ci]`) | ||
|
||
#### `author_name` | ||
|
||
If `files_to_commit` contains any files to commit, this specifies the Author Name to assign to the commit (required if files are being committed) | ||
|
||
#### `author_email` | ||
|
||
If `files_to_commit` contains any files to commit, this specifies the Author Email to assign to the commit (required if files are being committed) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we just add one option called file
or something and handle the rest on our own
And also modify the changelog file in a way that the user itself can modify the headers in separate commits if they want, and we just add the logs below the current headers and new ones upper the old logs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback, much appreciated.
The reason why I added some options was that every circumstance will be a bit different; I did think of using a special config file like .changelog
that could be created that would hold these options and that we defaulted with some reasonable defaults for everything else.
I would be happy to make changes to use such a file or remove them as you suggest; but if you would prefer zero configuration I would like your permission to fork and release an alternative action that does include these options as I sort of need them for my personal and private projects (I dont want to have to hand-edit files afterwards, I want it all automated) but totally understand that you would like your action not to do this.
For example, the defaults could be changed to be as follows, and the user can edit the file afterwards (as you suggest) if they wish to edit the section to include a version number and/or tag link:
- title =
# repository name
- section =
## Release 2020-10-17
(the current date) - commit_message =
chore(pipeline updates): [skip ci]
- files_to_commit =
./CHANGELOG.md
- author_name =
GitHub CI
- author_email =
no idea what to default this to
As above, there is no 'email' that can be determined in the pipeline to use for this; I guess we could take the email of the last commit but I dont know if that would be correct or useful and its not something that can be edited after the fact.
What are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SamuelJohnsonMedia I'm thinking like merging the three generate
, path
& files_to_commit
into one option like file
or something like that which would contain the CHANGELOG.md
or ./HISTORY.md
or whatever, which might be an empty string by default, if not then internally consider generate
to true & files_to_commit
to be the given value.
And for the author, we can use the committer of the tag or the action initiator if possible, maybe with some posix like - Auto-Changelog
or (Github CI)
, you get the idea.
And for the commit_message
I guess we can use something like chore: Update [the given file value here] [ignore]
?
This way the necessary options are reduced and there's more automation & hopefully satisfies your needs as well
Something like this, which is what I used as a reference
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also for the header file, I didn't mean it should be hand edited every time, what I meant was we would just create the file if it doesn't exist and set the title to # Changelog
by default and the version tags like ## tag (date)
and if the users want a different title like History
instead, or want to have some description before the logs they can create the file before or modify it whenever they want to make the said customizations and we would follow like this:
[Whatever user put here]
[The generated logs here]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand what you mean now with relation to the options; so I have modified the PR so its just a single file
option which, if it exists, will be the file that is updated or created.
I have also modified the file content modifier to locate the last 'release' that was made and insert the new content above it; this way the user can add whatever they want above without it being removed.
I didnt change the release heading to be the tag name as the tag wont have been created at the point this action is run; it will be run afterwards so that the changelog is included in the release.
Feel free to modify if you wish.
Removed options and used sensible defaults
I have updated with your suggestions; let me know what you think. |
Update from base
Removed options and used sensible defaults
…sonMedia/auto-changelog into generate-file-feature # Conflicts: # action/index.js # action/index.js.map
Specify a single option which is filename, if it exists the file is created or updated
Pull from master
ac73397
to
ef666fb
Compare
I would like to use this action and having the ability to commit the changes would be great. No movement in 6 months, is this still being worked on? |
@SamuelJohnsonMedia Sorry for not taking action on this PR for so long, if you're still willing, can you rebase and resolve the conflicts so that we can finalize and merge this feature? |
Added ability to update a change log file with the changes made.
I hope this PR conforms to your code style okay. Apologies for the failed builds in a test PR; it’s hard to test these things