Trigger a rebuild of appcast.xml on release#290
Conversation
6fd29c1 to
ff6a3a9
Compare
|
I tested the usage of the variables |
ff6a3a9 to
f9304c6
Compare
|
I tested it with a release on my fork https://github.com/hannesa2/gitx/runs/5234832080?check_suite_focus=true |
f9304c6 to
03bc3a1
Compare
|
What do you know about the GITHUBTOKEN secret? Is it someone's personal access token, or is it different/special? My concern is that, if it's linked to a particular acct, then this might only work when GITHUB_ACTOR matches that account. If this is not the case and GITHUBTOKEN is not limited like that, then this looks totally good. If it is limited, then we might be able to use the built-in token available within actions, like here: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#example-2-calling-the-rest-api If I'm reading that correctly, then this could be changed like - run: curl -u $GITHUB_ACTOR:${{ secrets.GITHUBTOKEN }} -X POST https://api.github.com/repos/$GITHUB_REPOSITORY/pages/builds
+ run: curl --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' -X POST https://api.github.com/repos/$GITHUB_REPOSITORY/pages/builds(and BTW, once we get this working, we may be able to alter how we handle the page rebuild (again) in the repo settings. If we're able to rebuild on release, then we don't need to rebuild on every update to master. That means we could point the Pages branch back to |
It's my personal one. As long as nobody can read it, I've no problem with it.
Your doubts are absolute valid !
I've no strong opinion, what do you prefer ? I would leave it like it is, because the token works and it's the less work.
Any solution is not elegant, either having a second branch |
If it works, it works! (I had missed that it had been tested w/ |




It's about Sparkle update mechanism work #279 (comment)