Is there any way to get unreleased PR's?

[lucasgismondi-bitbuy]

Is it possible to get all PR's from the latest release tag to now?

I tried to use the commit sha from the latest release to the current commit sha but with no luck. Is there any way this can be achieved?

Thank you!

[mikepenz]

Hi @lucasgismondi-bitbuy

Thank you very much for the ticket.

Currently this action is focusing around merged PRs.

Could you may outline a bit on your usecase to understand better on this ask?

[lucasgismondi-bitbuy]

Hey @mikepenz, thanks for the reply.

Within our changelog we are looking to include PR's that are "unreleased" so that our QA and other internal teams can know exactly what is coming up and what has already been released to production.

It would still be getting merged PR's but it would be PR's from the latest release to now. Essentially the toTag would have no bound

[mikepenz]

That's an interesting usecase.

You outline the toTag to have no bound, but given the note you'd still like to have those in a unreleased section. would those be meant to follow a similar categorisation, or could it be a plain unreleased section with everything listed? Filtered by some label?

It's an interesting feature proposal, and I believe it could add further value to the action.

[lucasgismondi-bitbuy]

Yes, I would expect it to follow a similar categorization. If it can get a list of PR's that are "unreleased" then it should be able to read the labels on those PR's and sort them accordingly. I'm not sure if that is actually possible though on the actions side but that is what I would expect. If it's just easier to have a plain unreleased section with everything listed, that is still a viable solution.

Yeah, I think it's super interesting as well. It can help make the changelog the single source of truth instead of relying on other ticket management tools that require more manual work to keep things organized.

[mikepenz]

@lucasgismondi-bitbuy if you could please have a look at the following PR and maybe see if it matches your requirements: \

• Introduce new API to include open PRs within the generated changelog #726
  (at the time of writing docs are not yet updated, but I hope the testcases added can be a good starting point)

[lucasgismondi-bitbuy]

Hey @mikepenz thank you very much for your quick work on this. I may be misunderstanding but does this PR make it possible to get PR's that have been merged that are not part of a release tag yet? I'm only seeing that you can get PR's in open state.

[mikepenz]

@lucasgismondi-bitbuy as before those should be included if you use the latest commit hash (as toTag) on the branch those were merged into up until the tag which you want to use as fromTag.

[mikepenz]

Btw. if you want to quickly test and iterate on configurations. it is possible to run this action locally via npm on your computer towards any repo.

[lucasgismondi-bitbuy]

Ah ok, thanks for the tip. I'm new to actions. I will try that again and report back!

[mikepenz]

In a strongly simplified fashion the following should outline your usecase.

If you look at the config it refers the hash instead the tag.
and 1 open PR. (https://github.com/mikepenz/release-changelog-builder-action-playground/pulls)

using a special tag --rcba-open to add additional flexibility when configuring the sections you may want.

[lucasgismondi-bitbuy]

So my workflow step looks like this at the moment:

- name: Build Changelog
        id: build_changelog
        uses: mikepenz/release-changelog-builder-action@v1
        with:
          fromTag: "3.77.0"
          toTag: "${{ github.sha }}"
          configuration: "changelog_config.json"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

I also tried referencing an existing hash manually and I also tried using "v3.77.0" for the fromTag but I'm getting this:

Any ideas as to why this may be failing?

[mikepenz]

Could it be that the TOKEN is invalid?

Also it looks you are using v1 while we are already at v2.9.0 and the specific branch created for you with the new feature would have the SHA-1 (df9a355 - which you can use as version spec)

[lucasgismondi-bitbuy]

The token is definitely valid since it works very well between two releases. I tried using 2.9.0 and the new branch sha but neither of those worked. But before this PR was created, was it expected that you can get merged PR's between a release tag and any commit sha that came after that? If so, I'm not sure if the PR you linked is needed since we don't need to reference open PR's

[mikepenz]

You can enable debug logging which should give you additional details on the reason for the failure:
https://docs.github.com/en/github-ae@latest/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging
When you verify the sha used looks correct?
Other than that usual common causes for something like this may be wrong scope/permissions of the token.

Yes it is and was possible before this PR to retrieve merged PRs between 2 git hashes.
So that's great news of things already being available as needed prior to the PR.

---

I can assist to setup local debugging if you wish to iterate faster, or guide you in this direction.

[lucasgismondi-bitbuy]

Yes, the sha used is correct in both scenarios (using "${{ github.sha }}" or inserting manually)

Thank you very much for all the support you've provided. As of right now this action works very well for automating our changelog on release. I'm going to have to come back to this and iterate on this in the future.

[mikepenz]

@lucasgismondi-bitbuy thank you. So you found the cause for the HttpError: Not found issue? Maybe I missed you saying that this was resolved 🤔

[lucasgismondi-bitbuy]

No this issue hasn't been resolved yet. I will come back to this probably within a few weeks

[mikepenz]

Closing this issue due to inactivity. Please re-open with additional information so we can investigate further and resolve it :)

Given the error it looks that it is most likely an access issue

[dtcMLOps]

Hi @mikepenz @lucasgismondi-bitbuy, actually this is a great feature request. According to the best practices for changelogs having an Unreleased section would make sense.

Use "Unreleased" section to help users and project developers to stay informed on the upcoming changes. It also helps you at release time - just move changes from this section into the new version section.

I was trying to achieve this with the ${{OPEN_COUNT}}, but this retrieves the count of opened PRs, it would be nice to have the same structure as in the body categorize per features, bug fixes, etc in the unreleased section for opened PRs.

[mikepenz]

@dtcMLOps You can enable to includeOpen PRs by doing:

Which will result in open PRs being included for the changelog generation. (please note that they are included in the general set of PRs and are to be categorized with the category)

[dtcMLOps]

Hi @mikepenz, yes indeed I have set the includeOpen parameter and as you mentioned this will add the open PRs in the same changelog body, but according to the best practices for changelogs these opened PRs should be in an Unreleased section since it not make sense to have both release and unreleased changes in the same body.

[mikepenz]

@dtcMLOps I'll need to think of some additional APIs to make the category more flexible

[dtcMLOps]

@lucasgismondi-bitbuy this feature has been released in the latest version v3.6.0. #997

[lucasgismondi-bitbuy]

Awesome, thanks @dtcMLOps !