ci: deploy should be a manual action #577

New issue

Closed

opened 2024-08-12 00:47:18 +00:00 by forge · 2 comments

forge commented

2024-08-12 00:47:18 +00:00

Owner

It is currently impossible to generate action tokens, thus it is impossible to fetch artifacts from outside of the workflow.
This is necessary for issue_comment triggers, but since they run from the default repo they don't have access to those tokens
This also applies to manual triggers which do not operate from within PRs.

See https://dev.to/zirkelc/trigger-github-workflow-for-comment-on-pull-request-45l2 for an example of an implementation.

With the migration from Gitlab, it's become impossible to setup a manual trigger for the deploy workflow. Thus, instead, the deploy workflow always sends the built package to the repo, if the build completes. If the upstream file already exists, it deletes it and reuploads. I need to keep track of upstream changes, because (at least on Github), it should be possible to setup a /deploy comment trigger, but due to API limitations it is not currently possible. Notably: * It is currently impossible to generate action tokens, thus it is impossible to fetch artifacts from outside of the workflow. * This is necessary for `issue_comment` triggers, but since they run from the default repo they don't have access to those tokens * This also applies to manual triggers which do not operate from within PRs. See https://dev.to/zirkelc/trigger-github-workflow-for-comment-on-pull-request-45l2 for an example of an implementation.

forge commented

2024-08-23 03:53:49 +00:00

Author

Owner

I've figured out another approach. Forgejo has a WIP function which can be picked up in-workflow using curl -s $GITHUB_SERVER_URL/api/v1/repos/$GITHUB_REPOSITORY/pulls/${{ github.event.number }} | jq .draft. Logics can be put put into deploy.sh to deploy to a different repo when draft=true for testing. Ideally, it would upload as an artifact, similar to the workflow that I had with the Lab. Unfortunately, upload-artifact always zips the artifacts up, defeating that use-case. We could upload to our own repo, but perhaps in a test branch (i.e. v3.20/user-staging rather than v3.20/user).

It would be a good way to test things, and maybe some code could be figured out to clear *-staging whenever we're done.

I've figured out another approach. Forgejo has a WIP function which can be picked up in-workflow using `curl -s $GITHUB_SERVER_URL/api/v1/repos/$GITHUB_REPOSITORY/pulls/${{ github.event.number }} | jq .draft`. Logics can be put put into deploy.sh to deploy to a different repo when draft=true for testing. Ideally, it would upload as an artifact, similar to the workflow that I had with the Lab. Unfortunately, upload-artifact always zips the artifacts up, defeating that use-case. We could upload to our own repo, but perhaps in a test branch (i.e. v3.20/user-staging rather than v3.20/user). It would be a good way to test things, and maybe some code could be figured out to clear *-staging whenever we're done.

forge commented

2024-08-25 13:32:13 +00:00

Author

Owner

This is (somewhat) implemented through the WIP functionality. When deployment is done while WIP is in the title, the built artifacts get sent to *-testing rather than the targetted branch. To deploy to production branches, you just need to remove the WIP from title, and restart deploy step in CI.