damccorm commented on code in PR #27717: URL: https://github.com/apache/beam/pull/27717#discussion_r1276794123
########## .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: Related to comment thread above, lets consolidate there ########## .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. Review Comment: Oh, that's a good point; this isn't a workable flow for yaml changes, I guess we have to recommend the alternate flow unfortunately. Updated to do this ########## .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) + +If you'd like to update a workflow without creating a PR, you can use the following flow. It has several caveats mentioned below. + +1) Make your change on a development branch. +2) 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. Review Comment: This section will work fine on a fork, you just need to follow the notes mentioned below. ########## .github/workflows/README.md: ########## @@ -101,6 +120,10 @@ If you run into this issue, you can either: 2) Upload secrets to your repo mirroring the secrets used in the main Beam repo. 3) Wait until the changes are merged into Beam to test (this should only be done rarely). +Additionally, as mentioned above your fork likely will not have self-hosted runners set up. Review Comment: Same as above, lets consolidate to that thread -- 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]
