Fix release workflow to trigger changelog workflow

[kwankyu]

Fixes #39024 (comment). For why, see #39024 (comment)

To see if this works well, after merged, we can just watch

https://github.com/sagemath/website/actions/workflows/generate_changelog.yml

after the next stable release.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[tobiasdiez]

Maybe it's easier to just put the content of changelog_trigger.yml in dist.yml, as a new step after the release is created. Then you don't need to play ping pong around 4 corners.

[tobiasdiez]

How is the PAT created (eg is it's Volkers)? Will it expire?

[kwankyu]

It is mine. No expiration.

[tobiasdiez]

Okay. If I understand it correctly, then the releases would be then associated to your account. I don't have a very strong opinion about this, but prefer how it's currently says "github-actions" as the creator - makes it very clear that the release was automatically created.

[user202729]

actually if you mean the committer in https://github.com/sagemath/website/commits/master/ , it's set in the workflow rather than by the owner of the token. So this change wouldn't affect the committer.

[tobiasdiez]

With these changes the releases created in https://github.com/sagemath/sage/releases will appear as if they were created manually by @kwankyu.

I still don't get why it's not better to simple put the script that triggers the website update here in the dist workflow.

[user202729]

actually, maybe you're right. I don't think it's an issue though.

[kwankyu]

With these changes the releases created in https://github.com/sagemath/sage/releases will appear as if they were created manually by @kwankyu.

@vbraun You may set your own PAT (Personal Access Token) to the "RELEASE_CREATION_TOKEN" secret, any time before the next stable release.

(but if we ever worry a leak of PAT, then putting my PAT is less destructive than one of the repo owners.)

I still don't get why it's not better to simple put the script that triggers the website update here in the dist workflow.

Perhaps we may need some time delay between "releasing" and "creating changelogs". And triggering the website update seems to be out of concern of the "dist" workflow.

But I have no strong opinion. You may experiment your idea after we check that the change of the present PR works well on the next release.

[tobiasdiez]

(but if we ever worry a leak of PAT, then putting my PAT is less destructive than one of the repo owners.)

Just to check, do you actually have the rights to create a new release? (I.e. can you do this manually?)

[kwankyu]

Yes. I have "admin" role.

[github-actions]

Documentation preview for this PR (built with commit a1f1b1f; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[kwankyu]

Maybe it's easier to just put the content of changelog_trigger.yml in dist.yml, as a new step after the release is created. Then you don't need to play ping pong around 4 corners.

For now, this fix is easiest. The priority is to have working code. We will see at the next stable release.

[user202729]

weird bug, but understandable. I've never looked at this workflow though.

note that there's some risk of secret leak from malicious workflow or something. I hope if it is leaked there isn't any particularly bad consequences? (i.e. the access token is created with restricted privileges?)

Also from the linked issue,

Yes. Though I don't remember clearly, I must have also tested it successfully on my own repo. Strange..

why does it make a difference when you test it on your repository? (because when you test it on your repository you use a personal access token generated by you, so happens to bypass the issue, I guess?)

@vbraun any other comment?

[user202729]

okay, looks fine. Worst that can happen is

• the script doesn't work and need to be ran/triggered manually (i.e. status quo), or
• the token get leaked (already discussed above).

[kwankyu]

note that there's some risk of secret leak from malicious workflow or something. I hope if it is leaked there isn't any particularly bad consequences?

I guess that if it was leaked to a bad guy, it would have bad consequences. But in the present particular case, I don't see any reason to worry of a leak.

(i.e. the access token is created with restricted privileges?)

It is created with "repo scope".

Also from the linked issue,

Yes. Though I don't remember clearly, I must have also tested it successfully on my own repo. Strange..

why does it make a difference when you test it on your repository? (because when you test it on your repository you use a personal access token generated by you, so happens to bypass the issue, I guess?)

Yes, I guess so too.

Thanks for the review!