このgistは、Srgr0がjoinmisskey/misskey-tgaの使用についてGitHub Supportに問い合わせた際の記録となります。
記録内で確認している通り、この記録のmisskey-tgaのREADMEでの参照目的での使用(共有)については、サポート担当者より許可を得ております。
記録内にある通り、GitHub Supportの見解は問い合わせ時点でのワークフロー構成(here)に対するものであり、この構成が変更された場合には見解が当てはまらない可能性があることに留意してください。ここでの変更には、joinmisskey/misskey-tgaにおいて行われた変更も含まれます。
懸念点がある場合には、GitHub Supportに問い合わせることも可能です(有料アカウントが必要です)。
このgistの無断転載を固く禁じます。
リポジトリのIssueやブログ等でこの記録を提示する場合、引用は控え該当部分へのリンクを掲載してください。
Hi,
I'm developing a GitHub Actons Workflow called misskey-tga that supports the development of Misskey and its fork project.
In this workflow, you can temporarily build Misskey's server using the source code of the repository at runtime, and actually access it to see the changes. This allows developers to test from the same perspective as the actual user, making it possible to improve the efficiency of development.
This workflow includes the behavior of building a server and temporary waiting (this is for the developer to access the server and check the changes). The server's url is designed not to be published on the GitHub Actions log, preventing workflows from being used for purposes other than "developers testing changes."
I would like to see if this workflow is suitable for the following part of Actions - GitHub Terms for Additional Products and Features.
Additionally, regardless of whether an Action is using self-hosted runners, Actions should not be used for:
any activity that places a burden on our servers, where that burden is disproportionate to the benefits provided to users (for example, don't use Actions as a content delivery network or as part of a serverless application, but a low benefit Action could be ok if it’s also low burden);
Hi Srgr0,
Thanks for contacting GitHub Support and for checking in about this.
Based on the content of your workflow file for joinmisskey/misskey-tga and the only run of the workflow in your repository, your use of GitHub Actions looks fine and would comply with Actions - GitHub Terms for Additional Products and Features.
If you make any significant changes to this workflow or any other new ones you make and are unsure about whether the steps performed in the workflow would still comply with our terms, please let me know and I'd be happy to take another look for you.
Kind regards, *** | GitHub Support Engineer
Hello,
Thanks for your help.
This workflow can be configured to run automatically every time a push to a branch occurs based on the trigger of GitHub Actions. If you set it like this, the frequency of workflow execution will be higher in the repository where push occurs frequently like misskey-dev/misskey , should I avoid this? In other words, should it be run only when the developer explicitly needs it (should it be executed only in the workflow_dispatch event or pull_request comments)?
Best Regards,
Srgr0
In addition to the following contents:
Can I post the content of the reply on Readme for users who use misskey-tga ?
This is to avoid multiple inquiries to GitHub Support about this case. Of course, I'll remind you to check and comply with the Terms of GitHub Actions and not to execute more than necessary.
Best Regards,
Srgr0
Hi Srgr0,
You're welcome. Good questions.
You can run a workflow as frequently as you like, whether you use on: push:, on: pull_request, or workflow_dispatch trigger conditions, provided your Actions workflow runs comply with the terms of service you saw earlier. Rest assured that there are checks in place, such as API rate limits and run duration limits, so you'll get helpful warnings in the workflow run logs if something goes wrong before you get into any trouble. (See our documentation on Usage limits for more about that.)
And you're welcome to use the content of these replies as a reference in your README for your team; however, I should stress that if the repository has modifications or is part of a fork network, what I've said here might not hold true as it only applies to what I see in your current workflow configuration. So while it's fine to use it in the README, it would be important just to add that caveat for your team mates for if/when they make changes.
Sending through additional support inquiries is absolutely fine too if you need, provided that the user account is on a Pro plan or part of a paid organisation or enterprise (i.e. the only catch is that technical support is not available to free users.)
Hope that helps clear things up! *** | GitHub Support Engineer