[core] First iteration of gitStream configuration #10305
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,48 @@ | ||
| # -*- mode: yaml -*- | ||
| manifest: | ||
| version: 1.0 | ||
|
|
||
| automations: | ||
| # Enforces a certain format on PR titles | ||
| enforce_pr_title: | ||
| if: | ||
| - {{ pr.title | match(regex=titlePolicy.titleRegex) | nope }} | ||
|
Comment on lines
+8
to
+9
There was a problem hiding this comment.
There was a problem hiding this comment. Wouldn't this essentially fail all There was a problem hiding this comment. The dep, yes. For the release we can start doing There was a problem hiding this comment. fixed the regex for that. ### matching
v8.211.2
v1.2.3-alpha-release
Bump Package to v1.2.34
[pickers] Expressive PR summary
### not matching
.[pickers] Expressive PR summary
[pickers]Expressive PR summary
[] Expressive PR summary
(pickers) Expressive PR summary
[pickers]: Expressive PR summary
v1.2
release v1.2.3
v12.23.343434.3333There was a problem hiding this comment. We could change this to be Line 4 in 1e1c1cb We could also add No real preferences. There was a problem hiding this comment. If you want custom error messages for PR titles, you may be able to accomplish that with a custom expression like this: Then, you can use a for loop to iterate through each one of these to create a list of errors that can be posted as a comment. Lmk if you need help creating this. |
||
| run: | ||
| - action: request-changes@v1 | ||
| args: | ||
| comment: | | ||
| All PRs must be titled according to our semantic naming policy: `[primary-label] <short summary>` | ||
| # Add a label that indicates how many minutes it will take to review the PR. | ||
| estimated_time_to_review: | ||
| if: | ||
| - true | ||
| run: | ||
| - action: add-label@v1 | ||
| args: | ||
| label: "{{ calc.etr }} min review" | ||
LukasTy marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| color: {{ colors.error if (calc.etr >= 20) else (colors.warning if (calc.etr >= 5) else colors.success) }} | ||
| # Post a comment that lists the best experts for the files that were modified. | ||
| explain_code_experts: | ||
| if: | ||
| - { { pr.labels | match(term='Auto assign') | some } } | ||
|
There was a problem hiding this comment. Do you know if the reviewer would be assigned only from within the organization? It's not a blocker as this is an opt-in option, but just an idea if we ever want to enable this by default. 🤔 P.S. Correct me if I'm wrong, but would this action assign a reviewer? In one place it says that it does, in another, there is no mention of it... 🤷 There was a problem hiding this comment. Is there a way to configure load balancing of requests of reviews? I am afraid that we may end up with requesting review from only 2-3 team members (the ones that are working on the repository longest). Or can we have a max number of request of review someone can have at certain point. There was a problem hiding this comment. That's a great question and I definitely do not have an answer to that as of now. I will dig the docs to find out and contact the gitStream devs 👍🏼 There was a problem hiding this comment. As I understand gitStream, it doesn't support the auto-assign logic for issues? We might need to developer something custom for issues at which point we could reapply the same logic with PRs? There was a problem hiding this comment. There are lots of great questions in this thread, I'll try to answer all of them.
I will double-check on this, but I'm not sure if this is possible yet. If not, we may be able to prioritize adding this capability.
Generally speaking, yes, if you use the
This is correct, the current config we have here wouldn't assign a reviewer, but that's just a matter of using the
There are a few ways to handle this:
Correct, gitStream lacks any integrations with GitHub Issues. Its something we expect to add in the future, but have been waiting for an excuse to prioritize it. If you can share more details about this use case we can figure out what it would take to put this on the roadmap. |
||
| run: | ||
| - action: explain-code-experts@v1 | ||
| args: | ||
| gt: 10 | ||
|
|
||
| # The next function calculates the estimated time to review and makes it available in the automation above. | ||
| calc: | ||
| etr: {{ branch | estimatedReviewTime }} | ||
|
|
||
| # define some colors to be used in the labels | ||
| colors: | ||
| error: '#f44336' # mui palette error.main | ||
| warning: '#ffa726' # mui palette warning.main | ||
| success: '#66bb6a' # mui palette success.main | ||
| info: '#29b6f6' # mui palette info.main | ||
| primary: '#e3f2fd' # mui palette primary.main | ||
|
|
||
| # define the regex the PR title is tested against to enforce a title format | ||
| titlePolicy: | ||
| titleRegex: /^\[\w+\]\s*\w+.*/gm | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,51 @@ | ||
| # Code generated by gitStream GitHub app - DO NOT EDIT | ||
|
There was a problem hiding this comment. Fyi, I could be wrong, but I believe this file should end in .yml, not .yaml. |
||
|
|
||
| name: gitStream workflow automation | ||
| run-name: | | ||
| /:\ gitStream: PR #${{ fromJSON(fromJSON(github.event.inputs.client_payload)).pullRequestNumber }} from ${{ github.event.inputs.full_repository }} | ||
|
|
||
michelengelen marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| permissions: {} | ||
|
|
||
| on: | ||
| workflow_dispatch: | ||
| inputs: | ||
| client_payload: | ||
| description: The Client payload | ||
| required: true | ||
| full_repository: | ||
| description: the repository name include the owner in `owner/repo_name` format | ||
| required: true | ||
| head_ref: | ||
| description: the head sha | ||
| required: true | ||
| base_ref: | ||
| description: the base ref | ||
| required: true | ||
| installation_id: | ||
| description: the installation id | ||
| required: false | ||
| resolver_url: | ||
| description: the resolver url to pass results to | ||
| required: true | ||
| resolver_token: | ||
| description: Optional resolver token for resolver service | ||
| required: false | ||
| default: '' | ||
|
|
||
| jobs: | ||
| gitStream: | ||
| timeout-minutes: 5 | ||
| runs-on: ubuntu-latest | ||
| name: gitStream workflow automation | ||
|
There was a problem hiding this comment. Won't we need explicit There was a problem hiding this comment. good question ... I think the gitStream application that needs to be hooked to the org does have that permission (once approved and hooked) There was a problem hiding this comment. Why does it need to be installed on the GitHub organization? I had understood that gitstream can run directly in GitHub actions, from where it gains access to the required permission. There was a problem hiding this comment. Actually, I wonder, is gitStream open-source? As I understand https://linearb.io/pricing "gitStream Admin Users" we have to pay $50k/year (~100 unique contributors per month) which feels disconnected from the value. I mean, whatever we improve in X should very likely benefit the other repos, so I'm looking at the org in general. There was a problem hiding this comment. @oliviertassinari These are great questions, and we need to clarify the language on the pricing page about this. To that end, gitStream is completely free for GitHub, and doesn't require any subscription fees for your organization users or admins. It's not open source, but we believe that supporting the open source community will be critical to gitStream's long-term success, so we want to support communities like this one. LinearB pricing is independent from gitStream, so you only need to purchase the LinearB platform if you're interested in engineering productivity metrics, resource allocation, or project delivery tracking. You don't need to purchase these to use gitStream. Update: the line about gitStream admin users on the pricing page was based on outdated assumptions about how gitStream is designed. We removed this line from the pricing page. There was a problem hiding this comment. @BenLloydPearson thanks for the clarification. |
||
| steps: | ||
| - name: Evaluate Rules | ||
| uses: linear-b/gitstream-github-action@v1 | ||
| id: rules-engine | ||
| with: | ||
| full_repository: ${{ github.event.inputs.full_repository }} | ||
| head_ref: ${{ github.event.inputs.head_ref }} | ||
| base_ref: ${{ github.event.inputs.base_ref }} | ||
| client_payload: ${{ github.event.inputs.client_payload }} | ||
| installation_id: ${{ github.event.inputs.installation_id }} | ||
| resolver_url: ${{ github.event.inputs.resolver_url }} | ||
| resolver_token: ${{ github.event.inputs.resolver_token }} | ||
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.
Would it make sense to build GitHub Actions directly? It could look like in https://github.com/mnajdova/github-action-required-labels/blob/main/index.js or https://github.com/mui/mui-public/blob/master/.github/workflows/ensure-triage-label.yml#L21.
I mean, what's the need for an abstraction? Does GitHub Actions has a similar level of abstraction APIs but with one less layer of indirection?
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.
We could definitely build our own actions this way. gitStream does provide a few very unique features, but those could be replicated by a proprietary solution for sure
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.
the main benefit form gitStream is that it allows us to collect metrics from PRs.
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.
So it sound unrelated to the PR titles convention problem?
What I like about https://github.com/mnajdova/github-action-required-labels/blob/main/index.js#L39 is how the error messages are clear. The goal is so that the community doesn't struggle when it fails. If we can have a clear experience, great. If it's too much effort with gitstream, I think it shouldn't be implemented with it
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.
I love this feedback about using gitStream vs. GitHub Actions, we would love to hear anything else that you come across. I think you'll find gitStream to be significantly more flexible and easy to maintain vs. build separate GitHub Actions for each of the automations you need, but I want to know if this is not your experience. Related to this, we have a blog post that breaks down many of the use cases we share in common with GitHub Actions, so that might help you better understand how we stack up against them. We are also planning to create a more detailed feature breakdown to provide a better comparison.
This example might help with your evaluation for a required labels automation: Enforce Required Labels
It's also fairly easy to configure error messages using custom expressions. For example, here is an automation that detects the use of deprecated APIs and posts related information as a comment. You could adapt this to alert users about specific labels, PR title naming conventions, or anything else.