-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move Browserstack into a seperate workflow #1126
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
frederikprijck
temporarily deployed
to
internal
August 26, 2023 17:15
— with
GitHub Actions
Inactive
frederikprijck
temporarily deployed
to
internal
August 26, 2023 17:15
— with
GitHub Actions
Inactive
LGTM! Makes perfect sense to split things up this way. A few thoughts:
|
frederikprijck
temporarily deployed
to
internal
August 29, 2023 08:12
— with
GitHub Actions
Inactive
frederikprijck
temporarily deployed
to
internal
August 29, 2023 08:12
— with
GitHub Actions
Inactive
frederikprijck
temporarily deployed
to
internal
August 29, 2023 08:14
— with
GitHub Actions
Inactive
Thanks, I made the changes you mentioned @evansims . Please take another look. |
frederikprijck
temporarily deployed
to
internal
August 29, 2023 08:19
— with
GitHub Actions
Inactive
frederikprijck
temporarily deployed
to
internal
August 29, 2023 08:29
— with
GitHub Actions
Inactive
frederikprijck
temporarily deployed
to
internal
August 29, 2023 08:29
— with
GitHub Actions
Inactive
frederikprijck
temporarily deployed
to
internal
August 29, 2023 08:32
— with
GitHub Actions
Inactive
evansims
approved these changes
Aug 29, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome — LGTM!
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
Opening this PR as draft as a discussion starter to see if what I'm doing here makes sense and would be something we would want.
The PR separates Browserstack into its own workflow, doing that removes the need for using the
pull_request_target
trigger on theBuild and Test
workflow, making it easier to make modifications to that workflow file when needed.It does keep the
pull_request_target
andauthorize
step for the Browserstack workflow to guarantee our secrets are protected by the means of a manual approval step.Why?
Using
pull_request_target
does not run workflow changes on PRs as it ensures it always runs in the context of the target branch. For example, I opened a PR to update the NODE_VERSION to 20, but you will notice that it still uses node 18 to execute the PR's workflow. This means that we will only know if it works with node20 on GitHub Actions after merging it to master.However, the only reason we use
pull_request_target
is for Browserstack. If we separate Browserstack into its own workflow, we no longer needpull_request_target
on our mainBuild and Test
workflow, meaning in that case, the PR I opened would run against node 20 on the PR level, and not after merging.I'm not yet sure if and how this will work for automating our release, as I know it becomes really complicated when u have separate workflows. But we already have the publish in a separate workflow anyway, so adding a 3rd one doesn't necessarily add additional complexity, I think.
Unrelated, but also Drops --include=dev from npm ci, as we don't need that. But same goes for changes like this. We have no way to identify this works before merging this PR, because of the usage of
pull_request_target
, which (as mentioned above) is not needed to build our SDK and run its tests.Checklist