Skip to content
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

Script to list recent changes to templates #1968

Merged
merged 2 commits into from
May 10, 2021

Conversation

pablobm
Copy link
Collaborator

@pablobm pablobm commented Apr 29, 2021

A first stab at a script to help with writing changelogs. Currently, it lists which template files have changed since the version given as an argument (actually a Git tag):

$ ./bin/changelog v0.15.0
The following templates have changed since v0.15.0:

  app/views/administrate/application/_navigation.html.erb
  app/views/fields/url/_index.html.erb
  app/views/fields/url/_show.html.erb

If your application overrides any of them, make sure to review your
custom templates to ensure that they remain compatible.

This was inspired by #1957, where a user observed that it would be worth mentioning these template updates in the changelog, as it's something that people need to look out for when upgrading Administrate.

Perhaps in the future we can add other capabilities to this script.

@nickcharlton
Copy link
Member

I used this for the 0.16.0 release and it worked well. So I'm going to merge it! Thank you!

@nickcharlton nickcharlton merged commit b56db23 into thoughtbot:main May 10, 2021
@pablobm pablobm deleted the changelog-script branch June 24, 2021 10:38
nickcharlton added a commit that referenced this pull request Apr 29, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates which had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft which needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

  The following templates have changed since v0.18.0:

    app/views/administrate/application/_collection.html.erb
    app/views/administrate/application/_index_header.html.erb

  If your application overrides any of them, make sure to review your
  custom templates to ensure that they remain compatible.

  * [] [#2367] Update to Ruby 3.2.2
  * [] [#2371] Adapt to deprecations in the Faker API
  * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
nickcharlton added a commit that referenced this pull request Apr 29, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates that had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft that needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

  The following templates have changed since v0.18.0:

    app/views/administrate/application/_collection.html.erb
    app/views/administrate/application/_index_header.html.erb

  If your application overrides any of them, make sure to review your
  custom templates to ensure that they remain compatible.

  * [] [#2367] Update to Ruby 3.2.2
  * [] [#2371] Adapt to deprecations in the Faker API
  * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
nickcharlton added a commit that referenced this pull request Apr 29, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates that had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft that needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

    The following templates have changed since v0.18.0:

      app/views/administrate/application/_collection.html.erb
      app/views/administrate/application/_index_header.html.erb

    If your application overrides any of them, make sure to review your
    custom templates to ensure that they remain compatible.

    * [] [#2367] Update to Ruby 3.2.2
    * [] [#2371] Adapt to deprecations in the Faker API
    * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
nickcharlton added a commit that referenced this pull request Apr 29, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates that had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft that needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

    The following templates have changed since v0.18.0:

      app/views/administrate/application/_collection.html.erb
      app/views/administrate/application/_index_header.html.erb

    If your application overrides any of them, make sure to review your
    custom templates to ensure that they remain compatible.

    * [] [#2367] Update to Ruby 3.2.2
    * [] [#2371] Adapt to deprecations in the Faker API
    * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
nickcharlton added a commit that referenced this pull request Jun 27, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates that had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft that needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

    The following templates have changed since v0.18.0:

      app/views/administrate/application/_collection.html.erb
      app/views/administrate/application/_index_header.html.erb

    If your application overrides any of them, make sure to review your
    custom templates to ensure that they remain compatible.

    * [] [#2367] Update to Ruby 3.2.2
    * [] [#2371] Adapt to deprecations in the Faker API
    * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
nickcharlton added a commit that referenced this pull request Jun 27, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates that had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft that needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

    The following templates have changed since v0.18.0:

      app/views/administrate/application/_collection.html.erb
      app/views/administrate/application/_index_header.html.erb

    If your application overrides any of them, make sure to review your
    custom templates to ensure that they remain compatible.

    * [] [#2367] Update to Ruby 3.2.2
    * [] [#2371] Adapt to deprecations in the Faker API
    * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
nickcharlton added a commit that referenced this pull request Jun 27, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates that had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft that needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

    The following templates have changed since v0.18.0:

      app/views/administrate/application/_collection.html.erb
      app/views/administrate/application/_index_header.html.erb

    If your application overrides any of them, make sure to review your
    custom templates to ensure that they remain compatible.

    * [] [#2367] Update to Ruby 3.2.2
    * [] [#2371] Adapt to deprecations in the Faker API
    * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
nickcharlton added a commit that referenced this pull request Jun 27, 2023
The majority of the effort in making a new release is in putting
together a good CHANGELOG. Back in #1968, we added a script to generate
a list of templates that had changed since the last (provided) tag.
This helped ensure we'd communicate any template changes, whilst
requiring little effort to do so.

The next step in assembling a CHANGELOG was to put together a list of
commits the release would include. By convention this has been:

    [KEY] [PR NUMBER] Commit Message

So far, this has required a lot of manual text manipulation, and when
the commit wasn't introduced via a squash on GitHub, the PR reference
needed to be tracked down (which could take some time).

This script attempts to automate the rest of this process by assembling
a draft that needs much less effort to publish. By using the GitHub
CLI, we're able to match commits back to the originating pull request
and then automate much of the text manipulation which was needed before.

We then pull over the template warning checker from before, but in
this implementation skip over the `spec` changes, as they shouldn't
matter to end users.

We can also assume we want changes since the last tag, to remove the
need to provide an argument.

An example run (trimmed):

    The following templates have changed since v0.18.0:

      app/views/administrate/application/_collection.html.erb
      app/views/administrate/application/_index_header.html.erb

    If your application overrides any of them, make sure to review your
    custom templates to ensure that they remain compatible.

    * [] [#2367] Update to Ruby 3.2.2
    * [] [#2371] Adapt to deprecations in the Faker API
    * [] [#2348] Field::Select to handle ActiveRecord enums correctly

https://cli.github.com/
https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-trailersoptions
https://stackoverflow.com/a/18558871
https://stackoverflow.com/a/30035045
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