{"thread":{"id":"56976","subject":"[PATCH] githubci: add a workflow for creating GitHub release notes","startedAt":"2021-11-25T11:41:51Z","lastAt":"2021-12-07T00:06:06Z","messageCount":11,"participants":["Mahdi Hosseinzadeh via GitGitGadget","Matthias Aßhauer","Johannes Schindelin","Ævar Arnfjörð Bjarmason","Junio C Hamano","Fabian Stelzer"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"442300","messageId":"pull.1146.git.git.1637840216877.gitgitgadget@gmail.com","threadId":"56976","inReplyTo":null,"subject":"[PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Mahdi Hosseinzadeh via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-11-25T11:36:56Z","receivedAt":"2021-11-25T11:41:51Z","isPatch":true,"sender":{"key":"name:Mahdi Hosseinzadeh","avatar":null},"body":"From: Mahdi Hosseinzadeh <mdihosseinzadeh@gmail.com>\n\nGitHub now allows users to subscribe only to\n\"release\" notifications of a repository.\nSo, users can be notified of new releases and their\nchangelog/release notes automatically.\n\nThis workflow works whenever:\n    a new version tag\n    (with the format following the regex \"v\\d+\\..*\")\n    is pushed to the repository\nAND\n    the commit that the tag points to, created/modified\n    a release notes file from Doumentation/RelNotes/ directory.\n\nThe script for generating the temporary changelog file is\nwritten in Kotlin language which can be a much better alternative\nto shell scripts in terms of features and readability\n(it is like a python script but with static typing support).\nThe Kotlin runner is pre-installed in GitHub Actions environments;\nfor more information see\n    https://github.com/actions/virtual-environments/\n    https://stackoverflow.com/a/69116750/8583692\n\nThe \"Release Notes (yyyy-MM-dd)\" link in https://git-scm.com/\nwebsite can also link to these GitHub release pages instead of\nto the raw .txt release note file in the repository.\n\nSee the issue related to GitHub release notifications:\nhttps://github.com/isaacs/github/issues/410\n\nAlso see GitHub announcement for this feature:\nhttps://github.blog/changelog/2018-11-27-watch-releases/\n\nSigned-off-by: Mahdi Hosseinzadeh <mdihosseinzadeh@gmail.com>\n---\n    Add a workflow for creating GitHub release notes\n    \n    Because this is not directly the git code and is related to GitHub CI, I\n    post it here.\n    \n    This pull request adds a new GitHub Actions workflow that automatically\n    creates releases on GitHub repository when pushing a new tag to the\n    repository.\n    \n    GitHub now allows users to subscribe only to \"release\" notifications of\n    a repository. So, users can be notified of new releases and their\n    changelog/release notes automatically.\n    \n    This workflow works whenever: a new version tag (with the format\n    following the regex v\\d+\\..*) is pushed to the repository AND the commit\n    that the tag points to, created/modified a release notes file from\n    Doumentation/RelNotes/ directory.\n    \n    The script for generating the temporary changelog file is written in\n    Kotlin language [https://kotlinlang.org/] which can be a better\n    alternative to shell scripts in terms of features and readability (it is\n    like a python script but with static typing support). The Kotlin runner\n    is pre-installed in GitHub Actions environments; for more information\n    see https://github.com/actions/virtual-environments/\n    https://stackoverflow.com/a/69116750/8583692\n    \n    The Release Notes (yyyy-MM-dd) link in https://git-scm.com/ website can\n    also link to these GitHub release pages instead of to the raw .txt\n    release note file in the repository.\n    \n    See the issue related to GitHub release notifications:\n    https://github.com/isaacs/github/issues/410\n    \n    Also see GitHub announcement for this feature:\n    https://github.blog/changelog/2018-11-27-watch-releases/\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1146%2Fmahozad%2Fadd-github-releases-workflow-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1146/mahozad/add-github-releases-workflow-v1\nPull-Request: https://github.com/git/git/pull/1146\n\n .../generate-github-changelog.main.kts        | 21 ++++++++++\n .github/workflows/create-release.yml          | 40 +++++++++++++++++++\n 2 files changed, 61 insertions(+)\n create mode 100644 .github/scripts/generate-github-changelog.main.kts\n create mode 100644 .github/workflows/create-release.yml\n\ndiff --git a/.github/scripts/generate-github-changelog.main.kts b/.github/scripts/generate-github-changelog.main.kts\nnew file mode 100644\nindex 00000000000..e57fd2a6ae5\n--- /dev/null\n+++ b/.github/scripts/generate-github-changelog.main.kts\n@@ -0,0 +1,21 @@\n+#!/usr/bin/env kotlin\n+\n+/**\n+ * Copies contents of the release notes file created/modified\n+ * in this commit to a new file to be used by the workflow.\n+ */\n+\n+import java.io.File\n+\n+println(\"Files modified in this commit:\")\n+args.forEachIndexed { index, name ->\n+    println(\"\\t${index + 1}- $name\")\n+}\n+\n+val notesFile = args\n+    .map(::File)\n+    .singleOrNull { \"RelNotes\" in it.parent }\n+\n+notesFile\n+    ?.copyTo(File(\"changelog.txt\"))\n+    ?: println(\"No release notes file modified in this commit\")\ndiff --git a/.github/workflows/create-release.yml b/.github/workflows/create-release.yml\nnew file mode 100644\nindex 00000000000..711ba105e42\n--- /dev/null\n+++ b/.github/workflows/create-release.yml\n@@ -0,0 +1,40 @@\n+name: Create GH release\n+\n+# Create a GitHub release for each new tag.\n+# The release notes are taken from the release notes file\n+# modified in that commit located in Documentation/RelNotes directory.\n+\n+on:\n+  push:\n+    tags:\n+      - v[0-9]+.*\n+\n+permissions:\n+  contents: write\n+\n+jobs:\n+  create-gh-release:\n+    name: Create a new release or update an existing release in the GitHub repository\n+    runs-on: ubuntu-latest\n+    steps:\n+      - name: Checkout the repository\n+        uses: actions/checkout@v2\n+        with:\n+          fetch-depth: 2  # OR '0' To retrieve all preceding commit.\n+      - name: Get changed files\n+        uses: tj-actions/changed-files@v11.7\n+        id: changed-files\n+        with:\n+          separator: ' '\n+      - name: Generate the changelog\n+        run: kotlin .github/scripts/generate-github-changelog.main.kts ${{ steps.changed-files.outputs.all_changed_and_modified_files }}\n+      - name: Create the release\n+        uses: actions/create-release@v1\n+        env:\n+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n+        with:\n+          tag_name: ${{ github.ref_name }}\n+          release_name: ${{ github.ref_name }}\n+          body_path: changelog.txt\n+          draft: false\n+          prerelease: false\n\nbase-commit: 5f439a0ecfb4657100ec1e56ef9c6eca963b5a94\n-- \ngitgitgadget\n"},{"id":"442322","messageId":"AM0PR04MB60196EFE984652ECCBD591A8A5629@AM0PR04MB6019.eurprd04.prod.outlook.com","threadId":"56976","inReplyTo":"pull.1146.git.git.1637840216877.gitgitgadget@gmail.com","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Matthias Aßhauer","fromEmail":"mha1993@live.de","sentAt":"2021-11-25T20:57:13Z","receivedAt":"2021-11-25T20:59:22Z","isPatch":true,"sender":{"key":"mha1993@live.de","avatar":"https://avatars.githubusercontent.com/u/6178234?v=4"},"body":"\nHi Mahdi,\n\nI've already written up these concerns on GitHub [1] and you've replied \nthere, but Johannes asked me to also send this to the mailing list, so \nplease bear with me for mostly repeating the same points.\n\nOn Thu, 25 Nov 2021, Mahdi Hosseinzadeh via GitGitGadget wrote:\n\n> From: Mahdi Hosseinzadeh <mdihosseinzadeh@gmail.com>\n>\n> GitHub now allows users to subscribe only to\n> \"release\" notifications of a repository.\n> So, users can be notified of new releases and their\n> changelog/release notes automatically.\n>\n> This workflow works whenever:\n>    a new version tag\n>    (with the format following the regex \"v\\d+\\..*\")\n>    is pushed to the repository\n> AND\n>    the commit that the tag points to, created/modified\n>    a release notes file from Doumentation/RelNotes/ directory.\n>\n> The script for generating the temporary changelog file is\n> written in Kotlin language which can be a much better alternative\n> to shell scripts in terms of features and readability\n> (it is like a python script but with static typing support).\n> The Kotlin runner is pre-installed in GitHub Actions environments;\n> for more information see\n>    https://github.com/actions/virtual-environments/\n>    https://stackoverflow.com/a/69116750/8583692\n>\n> The \"Release Notes (yyyy-MM-dd)\" link in https://git-scm.com/\n> website can also link to these GitHub release pages instead of\n> to the raw .txt release note file in the repository.\n>\n> See the issue related to GitHub release notifications:\n> https://github.com/isaacs/github/issues/410\n>\n> Also see GitHub announcement for this feature:\n> https://github.blog/changelog/2018-11-27-watch-releases/\n\nNit: \"Github now allows users\" sounds like a new feature, not one that's \nthree years old.\n\n>\n> Signed-off-by: Mahdi Hosseinzadeh <mdihosseinzadeh@gmail.com>\n> ---\n>    Add a workflow for creating GitHub release notes\n>\n>    Because this is not directly the git code and is related to GitHub CI, I\n>    post it here.\n>\n>    This pull request adds a new GitHub Actions workflow that automatically\n>    creates releases on GitHub repository when pushing a new tag to the\n>    repository.\n>\n>    GitHub now allows users to subscribe only to \"release\" notifications of\n>    a repository. So, users can be notified of new releases and their\n>    changelog/release notes automatically.\n>\n>    This workflow works whenever: a new version tag (with the format\n>    following the regex v\\d+\\..*) is pushed to the repository AND the commit\n>    that the tag points to, created/modified a release notes file from\n>    Doumentation/RelNotes/ directory.\n>\n>    The script for generating the temporary changelog file is written in\n>    Kotlin language [https://kotlinlang.org/] which can be a better\n>    alternative to shell scripts in terms of features and readability (it is\n>    like a python script but with static typing support). The Kotlin runner\n>    is pre-installed in GitHub Actions environments; for more information\n>    see https://github.com/actions/virtual-environments/\n>    https://stackoverflow.com/a/69116750/8583692\n>\n>    The Release Notes (yyyy-MM-dd) link in https://git-scm.com/ website can\n>    also link to these GitHub release pages instead of to the raw .txt\n>    release note file in the repository.\n>\n>    See the issue related to GitHub release notifications:\n>    https://github.com/isaacs/github/issues/410\n>\n>    Also see GitHub announcement for this feature:\n>    https://github.blog/changelog/2018-11-27-watch-releases/\n>\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1146%2Fmahozad%2Fadd-github-releases-workflow-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1146/mahozad/add-github-releases-workflow-v1\n> Pull-Request: https://github.com/git/git/pull/1146\n>\n> .../generate-github-changelog.main.kts        | 21 ++++++++++\n> .github/workflows/create-release.yml          | 40 +++++++++++++++++++\n> 2 files changed, 61 insertions(+)\n> create mode 100644 .github/scripts/generate-github-changelog.main.kts\n> create mode 100644 .github/workflows/create-release.yml\n>\n> diff --git a/.github/scripts/generate-github-changelog.main.kts b/.github/scripts/generate-github-changelog.main.kts\n> new file mode 100644\n> index 00000000000..e57fd2a6ae5\n> --- /dev/null\n> +++ b/.github/scripts/generate-github-changelog.main.kts\n> @@ -0,0 +1,21 @@\n> +#!/usr/bin/env kotlin\n> +\n> +/**\n> + * Copies contents of the release notes file created/modified\n> + * in this commit to a new file to be used by the workflow.\n> + */\n> +\n> +import java.io.File\n> +\n> +println(\"Files modified in this commit:\")\n> +args.forEachIndexed { index, name ->\n> +    println(\"\\t${index + 1}- $name\")\n> +}\n> +\n> +val notesFile = args\n> +    .map(::File)\n> +    .singleOrNull { \"RelNotes\" in it.parent }\n> +\n> +notesFile\n> +    ?.copyTo(File(\"changelog.txt\"))\n> +    ?: println(\"No release notes file modified in this commit\")\n\nWe need to spin up a JVM for 21 lines of code just to copy a single \nfile. I think a single call of `cp` is faster and more readable than that.\n\n> diff --git a/.github/workflows/create-release.yml b/.github/workflows/create-release.yml\n> new file mode 100644\n> index 00000000000..711ba105e42\n> --- /dev/null\n> +++ b/.github/workflows/create-release.yml\n> @@ -0,0 +1,40 @@\n> +name: Create GH release\n> +\n> +# Create a GitHub release for each new tag.\n> +# The release notes are taken from the release notes file\n> +# modified in that commit located in Documentation/RelNotes directory.\n> +\n> +on:\n> +  push:\n> +    tags:\n> +      - v[0-9]+.*\n\nI think we should probably exclude the release candidates from this. As \nJohhannes pointed out[2], marking them as full releases would \nperiodically cause https://github.com/git/git/releases/latest to point\nto a pre-release instead of the latest full release.\n\n> +\n> +permissions:\n> +  contents: write\n> +\n> +jobs:\n> +  create-gh-release:\n> +    name: Create a new release or update an existing release in the GitHub repository\n> +    runs-on: ubuntu-latest\n> +    steps:\n> +      - name: Checkout the repository\n> +        uses: actions/checkout@v2\n> +        with:\n> +          fetch-depth: 2  # OR '0' To retrieve all preceding commit.\n\nThe value 2 seems pretty arbitrary and the comment adds nothing.\n\n> +      - name: Get changed files\n> +        uses: tj-actions/changed-files@v11.7\n> +        id: changed-files\n\nYou've replied on Github that you need the last two commits for this \naction [3], but I don't think we care about wether or not the release \nnotes where changed in the last commit. We only need the version number \n(from the pushed tag) to determine the correct release notes file.\n\n> +        with:\n> +          separator: ' '\n> +      - name: Generate the changelog\n> +        run: kotlin .github/scripts/generate-github-changelog.main.kts ${{ steps.changed-files.outputs.all_changed_and_modified_files }}\n> +      - name: Create the release\n> +        uses: actions/create-release@v1\n> +        env:\n> +          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n> +        with:\n> +          tag_name: ${{ github.ref_name }}\n> +          release_name: ${{ github.ref_name }}\n> +          body_path: changelog.txt\n\nIf we just use the file directly we don't even need to copy the file to \nchangelog.txt\n\n> +          draft: false\n> +          prerelease: false\n\nIf we don't exclude release candidates, we should set prelease to true for \nthose tags.\n\n>\n> base-commit: 5f439a0ecfb4657100ec1e56ef9c6eca963b5a94\n> -- \n> gitgitgadget\n>\n\nAll in all I think this is too convoluted for what it's trying to \nachieve. I think we should be able to achieve the same result with \nsomething like this:\n\n  .github/workflows/create-release.yml | 37 ++++++++++++++++++++++++++++\n  1 file changed, 37 insertions(+)\n  create mode 100644 .github/workflows/create-release.yml\n\ndiff --git a/.github/workflows/create-release.yml \nb/.github/workflows/create-release.yml\nnew file mode 100644\nindex 0000000000..5b9fdf0372\n--- /dev/null\n+++ b/.github/workflows/create-release.yml\n@@ -0,0 +1,37 @@\n+name: Create GH release\n+\n+# Create a GitHub release for each new tag.\n+# The release notes are taken from the release notes file\n+# modified in that commit located in Documentation/RelNotes directory.\n+\n+on:\n+  push:\n+    tags:\n+      - v[0-9]+.[0-9]+.[0-9]+\n+\n+permissions:\n+  contents: write\n+\n+jobs:\n+  create-gh-release:\n+    name: Create a new release or update an existing release in the \nGitHub repository\n+    runs-on: ubuntu-latest\n+    steps:\n+      - name: Checkout the repository\n+        uses: actions/checkout@v2\n+        with:\n+          fetch-depth: 1\n+      - name: Get version number\n+        shell: bash\n+        run: |\n+          echo GIT_VERSION=${GITHUB_REF#refs/tags/v} >> $GITHUB_ENV\n+      - name: Create the release\n+        uses: actions/create-release@v1\n+        env:\n+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n+        with:\n+          tag_name: ${{ github.ref_name }}\n+          release_name: ${{ github.ref_name }}\n+          body_path: Documentation/RelNotes/${{ env.GIT_VERSION }}.txt\n+          draft: false\n+          prerelease: false\n-- \n2.25.1\n\nAn example of the result this reduced action produces can be found at [4] \n(release notes for v2.34.1, but the tagged commit isn't v2.34.1).\n\nBest regards\n\nMatthias\n\n[1] https://github.com/git/git/pull/1146\n[2] https://github.com/git/git/pull/1146#discussion_r756854259\n[3] https://github.com/git/git/pull/1146#discussion_r756845042\n[4] https://github.com/rimrul/git/releases/tag/v2.34.1\n"},{"id":"442364","messageId":"nycvar.QRO.7.76.6.2111261455590.63@tvgsbejvaqbjf.bet","threadId":"56976","inReplyTo":"AM0PR04MB60196EFE984652ECCBD591A8A5629@AM0PR04MB6019.eurprd04.prod.outlook.com","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-11-26T13:59:07Z","receivedAt":"2021-11-26T14:01:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Nov 2021, Matthias Aßhauer wrote:\n\n> On Thu, 25 Nov 2021, Mahdi Hosseinzadeh via GitGitGadget wrote:\n>\n> > diff --git a/.github/workflows/create-release.yml\n> > b/.github/workflows/create-release.yml\n> > new file mode 100644\n> > index 00000000000..711ba105e42\n> > --- /dev/null\n> > +++ b/.github/workflows/create-release.yml\n> > @@ -0,0 +1,40 @@\n> > +name: Create GH release\n> > +\n> > +# Create a GitHub release for each new tag.\n> > +# The release notes are taken from the release notes file\n> > +# modified in that commit located in Documentation/RelNotes directory.\n> > +\n> > +on:\n> > +  push:\n> > +    tags:\n> > +      - v[0-9]+.*\n> > [...]\n>\n> All in all I think this is too convoluted for what it's trying to\n> achieve. I think we should be able to achieve the same result with\n> something like this:\n>\n>  .github/workflows/create-release.yml | 37 ++++++++++++++++++++++++++++\n>  1 file changed, 37 insertions(+)\n>  create mode 100644 .github/workflows/create-release.yml\n>\n> diff --git a/.github/workflows/create-release.yml\n> b/.github/workflows/create-release.yml\n> new file mode 100644\n> index 0000000000..5b9fdf0372\n> --- /dev/null\n> +++ b/.github/workflows/create-release.yml\n> @@ -0,0 +1,37 @@\n> +name: Create GH release\n> +\n> +# Create a GitHub release for each new tag.\n> +# The release notes are taken from the release notes file\n> +# modified in that commit located in Documentation/RelNotes directory.\n> +\n> +on:\n> +  push:\n> +    tags:\n> +      - v[0-9]+.[0-9]+.[0-9]+\n> +\n> +permissions:\n> +  contents: write\n> +\n> +jobs:\n> +  create-gh-release:\n> +    name: Create a new release or update an existing release in the GitHub\n> repository\n> +    runs-on: ubuntu-latest\n> +    steps:\n> +      - name: Checkout the repository\n> +        uses: actions/checkout@v2\n> +        with:\n> +          fetch-depth: 1\n> +      - name: Get version number\n> +        shell: bash\n> +        run: |\n> +          echo GIT_VERSION=${GITHUB_REF#refs/tags/v} >> $GITHUB_ENV\n> +      - name: Create the release\n> +        uses: actions/create-release@v1\n> +        env:\n> +          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n> +        with:\n> +          tag_name: ${{ github.ref_name }}\n> +          release_name: ${{ github.ref_name }}\n> +          body_path: Documentation/RelNotes/${{ env.GIT_VERSION }}.txt\n> +          draft: false\n> +          prerelease: false\n> --\n> 2.25.1\n>\n> An example of the result this reduced action produces can be found at [4]\n> (release notes for v2.34.1, but the tagged commit isn't v2.34.1).\n>\n> Best regards\n>\n> Matthias\n>\n> [1] https://github.com/git/git/pull/1146\n> [2] https://github.com/git/git/pull/1146#discussion_r756854259\n> [3] https://github.com/git/git/pull/1146#discussion_r756845042\n> [4] https://github.com/rimrul/git/releases/tag/v2.34.1\n\nOne thing I had not thought of earlier: do we really want to do this in\nevery fork of git/git? I know for a fact that microsoft/git has a very\ndifferent workflow upon pushing a tag.\n\nSo maybe we need something like this, too:\n\n   create-gh-release:\n+    if: github.repository == 'git/git'\n     name: Create a new release or update an existing release in the GitHub repository\n\nCiao,\nDscho\n"},{"id":"442367","messageId":"AM0PR04MB601972377B5CC2E24B6BA1DFA5639@AM0PR04MB6019.eurprd04.prod.outlook.com","threadId":"56976","inReplyTo":"nycvar.QRO.7.76.6.2111261455590.63@tvgsbejvaqbjf.bet","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Matthias Aßhauer","fromEmail":"mha1993@live.de","sentAt":"2021-11-26T17:37:04Z","receivedAt":"2021-11-26T17:39:09Z","isPatch":true,"sender":{"key":"mha1993@live.de","avatar":"https://avatars.githubusercontent.com/u/6178234?v=4"},"body":"\n\nOn Fri, 26 Nov 2021, Johannes Schindelin wrote:\n\n> Hi,\n>\n\n[...]\n\n> One thing I had not thought of earlier: do we really want to do this in\n> every fork of git/git? I know for a fact that microsoft/git has a very\n> different workflow upon pushing a tag.\n>\n> So maybe we need something like this, too:\n>\n>   create-gh-release:\n> +    if: github.repository == 'git/git'\n>     name: Create a new release or update an existing release in the GitHub repository\n\nI think you're right. This would have unidesirable side effects if it ran \nin forks.\n\n>\n> Ciao,\n> Dscho\n>\n\nBest regards\n\nMatthias\n"},{"id":"442440","messageId":"211129.86k0grf7lj.gmgdl@evledraar.gmail.com","threadId":"56976","inReplyTo":"AM0PR04MB601972377B5CC2E24B6BA1DFA5639@AM0PR04MB6019.eurprd04.prod.outlook.com","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-29T12:49:20Z","receivedAt":"2021-11-29T14:14:26Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Nov 26 2021, Matthias Aßhauer wrote:\n\n> On Fri, 26 Nov 2021, Johannes Schindelin wrote:\n>\n>> Hi,\n>>\n>\n> [...]\n>\n>> One thing I had not thought of earlier: do we really want to do this in\n>> every fork of git/git? I know for a fact that microsoft/git has a very\n>> different workflow upon pushing a tag.\n>>\n>> So maybe we need something like this, too:\n>>\n>>   create-gh-release:\n>> +    if: github.repository == 'git/git'\n>>     name: Create a new release or update an existing release in the GitHub repository\n>\n> I think you're right. This would have unidesirable side effects if it\n> ran in forks.\n\nRather than hardcode given repositories, which e.g. for testing the CI\nitself can be bothersome, perhaps a better thing is to put this into the\nexisting ci-config? I.e. git/git.git could opt itself in to behavior\nthat would be off by default?\n\nI don't know how much that matters in this case, but I don't see why\nwe'd hardcode repository paths in general since we've got the ci-config.\n"},{"id":"442627","messageId":"nycvar.QRO.7.76.6.2111301239480.63@tvgsbejvaqbjf.bet","threadId":"56976","inReplyTo":"211129.86k0grf7lj.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-11-30T11:46:02Z","receivedAt":"2021-11-30T11:46:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Mon, 29 Nov 2021, Ævar Arnfjörð Bjarmason wrote:\n\n> On Fri, Nov 26 2021, Matthias Aßhauer wrote:\n>\n> > On Fri, 26 Nov 2021, Johannes Schindelin wrote:\n> >\n> >> Hi,\n> >>\n> >\n> > [...]\n> >\n> >> One thing I had not thought of earlier: do we really want to do this in\n> >> every fork of git/git? I know for a fact that microsoft/git has a very\n> >> different workflow upon pushing a tag.\n> >>\n> >> So maybe we need something like this, too:\n> >>\n> >>   create-gh-release:\n> >> +    if: github.repository == 'git/git'\n> >>     name: Create a new release or update an existing release in the GitHub repository\n> >\n> > I think you're right. This would have unidesirable side effects if it\n> > ran in forks.\n>\n> Rather than hardcode given repositories, which e.g. for testing the CI\n> itself can be bothersome, perhaps a better thing is to put this into the\n> existing ci-config? I.e. git/git.git could opt itself in to behavior\n> that would be off by default?\n\nYou probably missed that the purpose of this workflow is something that\ndoes not make sense in the forks of git.git.\n\nIts purpose is to create releases for all tags that are pushed to the\nrepository. Most forks of git.git have no business creating releases, and\nthose that do already have their own processes in place.\n\nAs such, the situation is very different from the CI/PR runs that some\ncontributors might want to restrict to only certain branches in their\nforks.\n\n> I don't know how much that matters in this case, but I don't see why\n> we'd hardcode repository paths in general since we've got the ci-config.\n\nIntegrating it into `ci-config` is not even possible in this instance\nbecause the newly-introduced workflows should only ever run on tags, while\nthe `ci-config` step is part of a workflow that needs to run on every new\npush and PR.\n\nThose are two very, very different things. So even if it would have made\nsense to use `ci-config` in the workflow under discussion, it is not\napplicable because that step lives in a different workflow that is\ntriggered for a different set of events.\n\nCiao,\nJohannes\n"},{"id":"442909","messageId":"xmqqy252u8t7.fsf@gitster.g","threadId":"56976","inReplyTo":"nycvar.QRO.7.76.6.2111301239480.63@tvgsbejvaqbjf.bet","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-02T19:05:08Z","receivedAt":"2021-12-02T19:05:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> Rather than hardcode given repositories, which e.g. for testing the CI\n>> itself can be bothersome, perhaps a better thing is to put this into the\n>> existing ci-config? I.e. git/git.git could opt itself in to behavior\n>> that would be off by default?\n>\n> You probably missed that the purpose of this workflow is something that\n> does not make sense in the forks of git.git.\n>\n> Its purpose is to create releases for all tags that are pushed to the\n> repository. Most forks of git.git have no business creating releases, and\n> those that do already have their own processes in place.\n>\n> As such, the situation is very different from the CI/PR runs that some\n> contributors might want to restrict to only certain branches in their\n> forks.\n\nAll true.  But https://github.com/git/git/ itself has no business\ncreating releases, as we already have the release process that\npushes the release material to kernel.org to be distributed from\nthere.\n\nSo... do we still need to discuss this patch?  In other words,\nwhat's the benefit of creating \"releases for all tags that are\npushed to the repository\" there?  Does it give us redundancy in case\nkernel.org goes down?  Does it risk confusing users having to wonder\nrelease materials from which source is more \"genuine\"?\n\n\n"},{"id":"442949","messageId":"20211203083334.tziwuhbg2u4lsslt@fs","threadId":"56976","inReplyTo":"xmqqy252u8t7.fsf@gitster.g","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-03T08:33:34Z","receivedAt":"2021-12-03T08:33:40Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 02.12.2021 11:05, Junio C Hamano wrote:\n>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n>>> Rather than hardcode given repositories, which e.g. for testing the CI\n>>> itself can be bothersome, perhaps a better thing is to put this into the\n>>> existing ci-config? I.e. git/git.git could opt itself in to behavior\n>>> that would be off by default?\n>>\n>> You probably missed that the purpose of this workflow is something that\n>> does not make sense in the forks of git.git.\n>>\n>> Its purpose is to create releases for all tags that are pushed to the\n>> repository. Most forks of git.git have no business creating releases, and\n>> those that do already have their own processes in place.\n>>\n>> As such, the situation is very different from the CI/PR runs that some\n>> contributors might want to restrict to only certain branches in their\n>> forks.\n>\n>All true.  But https://github.com/git/git/ itself has no business\n>creating releases, as we already have the release process that\n>pushes the release material to kernel.org to be distributed from\n>there.\n>\n>So... do we still need to discuss this patch?  In other words,\n>what's the benefit of creating \"releases for all tags that are\n>pushed to the repository\" there?  Does it give us redundancy in case\n>kernel.org goes down?  Does it risk confusing users having to wonder\n>release materials from which source is more \"genuine\"?\n>\n\nOne benefit that I see is that github offers APIs & Notifications around \nreleases and lots of CI integration already exist for it. If my (non github) \nCI includes building the git source then i can easily trigger when upstream \nreleases a new version. Just pulling the repo and watching for the tag works \njust as well of course.\n\nHowever the \"which source is genuine\" is a valid objection. You certainly \ndon't want the CI to accidentally create a new release that does not exist \non kernel.org (yet).\n"},{"id":"443097","messageId":"xmqqo85vonba.fsf@gitster.g","threadId":"56976","inReplyTo":"20211203083334.tziwuhbg2u4lsslt@fs","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-05T01:25:13Z","receivedAt":"2021-12-05T01:25:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fabian Stelzer <fs@gigacodes.de> writes:\n\n> One benefit that I see is that github offers APIs & Notifications\n> around releases and lots of CI integration already exist for it. If my\n> (non github) CI includes building the git source then i can easily\n> trigger when upstream releases a new version. Just pulling the repo\n> and watching for the tag works just as well of course.\n\nAhh, thanks.\n\nIf some sort of \"push\" notification is available only for \"there is\na new release\" but not for \"there is a new tag\", then I can sort of\nsee why having a \"release\" would be nice.  Listening to notifications\nand acting on them is more pleasant than having to poll.\n\nDo I understand what you said correctly?\n\n"},{"id":"443105","messageId":"20211205105441.vsgyef3njcggbzku@fs","threadId":"56976","inReplyTo":"xmqqo85vonba.fsf@gitster.g","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-05T10:54:41Z","receivedAt":"2021-12-05T10:54:47Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 04.12.2021 17:25, Junio C Hamano wrote:\n>Fabian Stelzer <fs@gigacodes.de> writes:\n>\n>> One benefit that I see is that github offers APIs & Notifications\n>> around releases and lots of CI integration already exist for it. If my\n>> (non github) CI includes building the git source then i can easily\n>> trigger when upstream releases a new version. Just pulling the repo\n>> and watching for the tag works just as well of course.\n>\n>Ahh, thanks.\n>\n>If some sort of \"push\" notification is available only for \"there is\n>a new release\" but not for \"there is a new tag\", then I can sort of\n>see why having a \"release\" would be nice.  Listening to notifications\n>and acting on them is more pleasant than having to poll.\n>\n>Do I understand what you said correctly?\n>\n\nYes, thats correct. \n\nGithub has a webhook for releases:\nhttps://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#release\n\nGetting tags means listening to every push and filtering yourself:\nhttps://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#push\n\nStill, if this gets added to git/git I think the risk of users considering \nthe github release to be the primary source is quite high since lots of \ntools and CI integrations use them. I'm not a fan of depending on github for \neverything, but as long as the kernel.org releases don't go away I don't \nthink this is a big deal.\n"},{"id":"443215","messageId":"xmqqwnkhb7o8.fsf@gitster.g","threadId":"56976","inReplyTo":"20211205105441.vsgyef3njcggbzku@fs","subject":"Re: [PATCH] githubci: add a workflow for creating GitHub release notes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-07T00:05:59Z","receivedAt":"2021-12-07T00:06:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fabian Stelzer <fs@gigacodes.de> writes:\n\n> Still, if this gets added to git/git I think the risk of users\n> considering the github release to be the primary source is quite high\n> since lots of tools and CI integrations use them.\n\nThat's a bit of downside.  I guess not using this patch then would\nmake our life simpler, then.\n"}]}