You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@beam.apache.org by "damccorm (via GitHub)" <gi...@apache.org> on 2023/07/27 18:22:06 UTC
[GitHub] [beam] damccorm opened a new pull request, #27717: Update instructions to account for self-hosted runners
damccorm opened a new pull request, #27717:
URL: https://github.com/apache/beam/pull/27717
The previous flow doesn't work with self hosted runners
------------------------
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
- [ ] Mention the appropriate issue in your description (for example: `addresses #123`), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment `fixes #<ISSUE NUMBER>` instead.
- [ ] Update `CHANGES.md` with noteworthy changes.
- [ ] If this contribution is large, please file an Apache [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
See the [Contributor Guide](https://beam.apache.org/contribute) for more tips on [how to make review process smoother](https://beam.apache.org/contribute/get-started-contributing/#make-the-reviewers-job-easier).
To check the build health, please visit [https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md](https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md)
GitHub Actions Tests Status (on master branch)
------------------------------------------------------------------------------------------------
[](https://github.com/apache/beam/actions?query=workflow%3A%22Build+python+source+distribution+and+wheels%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Python+Tests%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Java+Tests%22+branch%3Amaster+event%3Aschedule)
[](https://github.com/apache/beam/actions?query=workflow%3A%22Go+tests%22+branch%3Amaster+event%3Aschedule)
See [CI.md](https://github.com/apache/beam/blob/master/CI.md) for more information about GitHub Actions CI or the [workflows README](https://github.com/apache/beam/blob/master/.github/workflows/README.md) to see a list of phrases to trigger workflows.
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] tvalentyn commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "tvalentyn (via GitHub)" <gi...@apache.org>.
tvalentyn commented on code in PR #27717:
URL: https://github.com/apache/beam/pull/27717#discussion_r1276780131
##########
.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:
this would be a branch in users' repo though, so presumably not selectable?
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] damccorm commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "damccorm (via GitHub)" <gi...@apache.org>.
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] tvalentyn commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "tvalentyn (via GitHub)" <gi...@apache.org>.
tvalentyn commented on code in PR #27717:
URL: https://github.com/apache/beam/pull/27717#discussion_r1276865683
##########
.github/workflows/README.md:
##########
@@ -83,16 +83,22 @@ 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).
Review Comment:
```suggestion
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).
```
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] Abacn commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "Abacn (via GitHub)" <gi...@apache.org>.
Abacn commented on code in PR #27717:
URL: https://github.com/apache/beam/pull/27717#discussion_r1276741898
##########
.github/workflows/README.md:
##########
@@ -83,16 +83,34 @@ 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.
Review Comment:
... for example, changing `runs-on: [self-hosted, ubuntu-20.04, main]` to `runs-on: ubuntu-20.04`
may want to be specific if people not familiar with github actions
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] damccorm merged pull request #27717: Update instructions to account for self-hosted runners
Posted by "damccorm (via GitHub)" <gi...@apache.org>.
damccorm merged PR #27717:
URL: https://github.com/apache/beam/pull/27717
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] tvalentyn commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "tvalentyn (via GitHub)" <gi...@apache.org>.
tvalentyn commented on code in PR #27717:
URL: https://github.com/apache/beam/pull/27717#discussion_r1276785772
##########
.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:
> your fork's main branch is up to date with Beam's master branch.
this does not apply since this section assumes development on master repo.
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] github-actions[bot] commented on pull request #27717: Update instructions to account for self-hosted runners
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #27717:
URL: https://github.com/apache/beam/pull/27717#issuecomment-1654364604
Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] damccorm commented on pull request #27717: Update instructions to account for self-hosted runners
Posted by "damccorm (via GitHub)" <gi...@apache.org>.
damccorm commented on PR #27717:
URL: https://github.com/apache/beam/pull/27717#issuecomment-1654356417
R: @tvalentyn
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] tvalentyn commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "tvalentyn (via GitHub)" <gi...@apache.org>.
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] github-actions[bot] commented on pull request #27717: Update instructions to account for self-hosted runners
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #27717:
URL: https://github.com/apache/beam/pull/27717#issuecomment-1654259460
Assigning reviewers. If you would like to opt out of this review, comment `assign to next reviewer`:
R: @Abacn for label build.
Available commands:
- `stop reviewer notifications` - opt out of the automated review tooling
- `remind me after tests pass` - tag the comment author after tests pass
- `waiting on author` - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)
The PR bot will only process comments in the main thread (not review comments).
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] damccorm commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "damccorm (via GitHub)" <gi...@apache.org>.
damccorm commented on code in PR #27717:
URL: https://github.com/apache/beam/pull/27717#discussion_r1276746829
##########
.github/workflows/README.md:
##########
@@ -83,16 +83,34 @@ 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.
Review Comment:
good call - done
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] tvalentyn commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "tvalentyn (via GitHub)" <gi...@apache.org>.
tvalentyn commented on code in PR #27717:
URL: https://github.com/apache/beam/pull/27717#discussion_r1276780824
##########
.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:
or is it possible to specify sth like pull/$PR_NUMBER/head ?
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [beam] tvalentyn commented on a diff in pull request #27717: Update instructions to account for self-hosted runners
Posted by "tvalentyn (via GitHub)" <gi...@apache.org>.
tvalentyn commented on code in PR #27717:
URL: https://github.com/apache/beam/pull/27717#discussion_r1276786651
##########
.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 here, my understanding this section assumes branches on master.
##########
.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 here, my understanding this section assumes branches on apache/beam repo.
--
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: github-unsubscribe@beam.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org