Goal: On push to master, if there are changes to /docs, automatically run :docs:orchidDeploy -PorchidEnvironment=prod.
Approach: GitHub actions; this also allows storing the required githubToken environment variable as an encrypted secret. (Additionally, the built-in variable GITHUB_TOKEN seems to work as well, so there's no need to create a personal access token.)
are encrypted secrets a good choice here? Perhaps I overlooked something that makes them unsuitable for this use case.
If this is added, I think it's a good idea to also mention that you should make sure the gradle-wrapper.jar is added to version control, as it seems to be common to have *.jar on the .gitignore. (!gradle/wrapper/gradle-wrapper.jar)
Personally, I'm interested in whether there's an intended way of doing this and in how others dealt with this?
Goal: On push to master, if there are changes to /docs, automatically run
:docs:orchidDeploy -PorchidEnvironment=prod
. Approach: GitHub actions; this also allows storing the requiredgithubToken
environment variable as an encrypted secret. (Additionally, the built-in variableGITHUB_TOKEN
seems to work as well, so there's no need to create a personal access token.)In the hope that other beginners like me will not have to deal with this themselves, I propose to add a short section on the pages OrchidGithub and How to document a Kotlin project/Deploy on GitHub pages about how to achieve this goal.
What the workflow could look like: https://github.com/nee/neebt/blob/master/.github/workflows/deploy-docs.yml
I'm unsure about the following points:
./gradlew ...
enough?If this is added, I think it's a good idea to also mention that you should make sure the gradle-wrapper.jar is added to version control, as it seems to be common to have *.jar on the .gitignore. (
!gradle/wrapper/gradle-wrapper.jar
)Personally, I'm interested in whether there's an intended way of doing this and in how others dealt with this?