tvalentyn commented on code in PR #27717: URL: https://github.com/apache/beam/pull/27717#discussion_r1276788395
########## .github/workflows/README.md: ########## @@ -83,16 +83,35 @@ To test new workflows, we recommend the following pattern: 1) Fork the Beam repo 2) Add your proposed workflow to the main branch of your fork. -3) Run the workflow in the [Actions tab](https://github.com/apache/beam/actions) of your fork using the `Run workflow` button +3) Run the workflow in the [Actions tab](https://github.com/apache/beam/actions) of your fork using the `Run workflow` button. + +Note: most workflows use [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) +with the main and ubuntu labels to execute ([example](https://github.com/apache/beam/blob/5a54ee6ddd8cb8444c41802929a364fe2561001e/.github/workflows/beam_PostCommit_Go_Dataflow_ARM.yml#L41)). +If you are testing on a fork, you likely will not have self-hosted runners set up. +To work around this, you can start using hosted runners and then switch over when you're ready to create a PR. +You can do this by changing runs-on: [self-hosted, ubuntu-20.04, main] (self-hosted, use in your PR) to runs-on: ubuntu-20.04 (GitHub hosted, use for local testing). ## Testing Workflow Updates If you need to make more changes to the workflow yaml file after it has been added to the repo, you can develop normally on a branch (using your fork or the main Beam repo if you are a committer). To do so: 1) Make your change on a development branch. -3) Navigate to your workflow in the [Actions tab](https://github.com/apache/beam/actions). If your changes are on a fork, navigate to the fork's Actions tab instead. If you don't see the correct action, make sure that your fork's main branch is up to date with Beam's master branch. -4) Click run workflow. Before clicking submit, update to run on your branch. +2) Open a PR. This may automatically kick off a run of your job using the old yaml config, so any results should be ignored. +3) Ask a committer to kick off a manual run of your updated action workflow. + +Committers can kick off runs of updated yaml workflow files by: +1) Validating that the yaml files don't contain any malicious code. +2) Navigating to the correct workflow in the [Actions tab](https://github.com/apache/beam/actions). +3) Clicking run workflow. Before clicking submit, update to run on the correct branch. + +### Alternate flow: developing without creating a PR (not recommended for non-committers or anyone working on a fork) Review Comment: Would this be a better heading: ``` ### Alternate flow: Test from development branch in apache/beam repo (for committers only). ``` ########## .github/workflows/README.md: ########## @@ -83,16 +83,35 @@ To test new workflows, we recommend the following pattern: 1) Fork the Beam repo 2) Add your proposed workflow to the main branch of your fork. -3) Run the workflow in the [Actions tab](https://github.com/apache/beam/actions) of your fork using the `Run workflow` button +3) Run the workflow in the [Actions tab](https://github.com/apache/beam/actions) of your fork using the `Run workflow` button. + +Note: most workflows use [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) +with the main and ubuntu labels to execute ([example](https://github.com/apache/beam/blob/5a54ee6ddd8cb8444c41802929a364fe2561001e/.github/workflows/beam_PostCommit_Go_Dataflow_ARM.yml#L41)). +If you are testing on a fork, you likely will not have self-hosted runners set up. +To work around this, you can start using hosted runners and then switch over when you're ready to create a PR. +You can do this by changing runs-on: [self-hosted, ubuntu-20.04, main] (self-hosted, use in your PR) to runs-on: ubuntu-20.04 (GitHub hosted, use for local testing). ## Testing Workflow Updates If you need to make more changes to the workflow yaml file after it has been added to the repo, you can develop normally on a branch (using your fork or the main Beam repo if you are a committer). To do so: 1) Make your change on a development branch. -3) Navigate to your workflow in the [Actions tab](https://github.com/apache/beam/actions). If your changes are on a fork, navigate to the fork's Actions tab instead. If you don't see the correct action, make sure that your fork's main branch is up to date with Beam's master branch. -4) Click run workflow. Before clicking submit, update to run on your branch. +2) Open a PR. This may automatically kick off a run of your job using the old yaml config, so any results should be ignored. +3) Ask a committer to kick off a manual run of your updated action workflow. + +Committers can kick off runs of updated yaml workflow files by: +1) Validating that the yaml files don't contain any malicious code. +2) Navigating to the correct workflow in the [Actions tab](https://github.com/apache/beam/actions). +3) Clicking run workflow. Before clicking submit, update to run on the correct branch. + +### Alternate flow: developing without creating a PR (not recommended for non-committers or anyone working on a fork) Review Comment: Would this be a better heading: ``` ### Alternate flow: Test from a development branch in apache/beam repo (for committers only). ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
