Describe the bug

(This should probably be 2 bugs but I have an example that shows both)

If the job fails, such as from a syntax error in the generated yaml file, it never reports back to the PR's actions that it failed and the icon stays spinning indefinitely (10d and counting here)

To Reproduce

There are a number of ways to reproduce this, I usually hit it when some of the dynamic content causes the error like with a multi-line description

Steps to reproduce the behavior:

1. Create an automation like so

  print_description:
    if:
      - true
    run:
      - action: add-comment@v1
        args:
          comment: |
            description: {{ pr.description }}

2. Set a single-line description, it should work
3. Set a multi-line description like this

Line 1

Line 2

4. You get an error like this:

2023-03-10T00:33:54.4061491Z /node_modules/js-yaml/lib/loader.js:187
2023-03-10T00:33:54.4061837Z   throw generateError(state, message);
2023-03-10T00:33:54.4062092Z   ^
2023-03-10T00:33:54.4099659Z YAMLException: end of the stream or a document separator is expected (50:1)
2023-03-10T00:33:54.4099950Z 
2023-03-10T00:33:54.4100698Z  48 |             description: Line 1 ...
2023-03-10T00:33:54.4100948Z  49 | 
2023-03-10T00:33:54.4101422Z  50 | Line 2 ...

Expected behavior

1. It should indent each line in the generated output

48 |             description: Line 1 ...
49 | 
50 |             Line 2 ...

2. If it does fail for any reason, it should report back to stop the spinner (I've had other failures from dynamic data but this is the easiest to demonstrate)

Screenshots

Included above.

Additional context

I had a slack chat with Ofer about this but recording it here too since the infinite spinner failure has come up a few times now that we have devs using it.

Describe the bug

gitStream is failing for all PRs with the following error:

To Reproduce

Steps to reproduce the behavior:

1. Open a PR in a repository with the default .github/workflows/gitstream.yml and .cm/gitstream.cm

Expected behavior

gitStream workflow should pass. 🙂

Describe the solution you'd like
A new action option to make curl requests

Additional context
Would give us the ability to call GitLabs API for example to be able to do a wide array of things.

Describe the bug

This happens after it worked perfectly then in action evaluating rules step it gets this error however it pass!
In the PR it hangs forever in add-reviewers part as queued and gitstream in progress!.

{ e: UndefinedParserError: No parser could be inferred for file: requirements.txt at normalize (/node_modules/prettier/index.js:7553:19) at formatWithCursor2 (/node_modules/prettier/index.js:8822:50) at /node_modules/prettier/index.js:37832:12 at Object.format (/node_modules/prettier/index.js:37846:12) at /node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1356:35 at Array.every (<anonymous>) at Context.parseIsFormattingChange (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1351:56) at eval (eval at _compile (/node_modules/nunjucks/src/environment.js:633:18), <anonymous>:50:69) at _callee$ (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1161:13) at tryCatch (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:97:17) }

Describe the bug

Running the github action produces the following error:

.cm/gitstream.cm
Missing automations keyword in *.cm

To Reproduce

Steps to reproduce the behavior:

1. The .cm automation file

# -*- mode: yaml -*-

manifest:
  version: 1.0

automations:
  estimated_time_to_review:
    if:
      - true
    run:
      - action: add-label@v1
        args:
          label: "{{ calc.etr }} min review"
          color: {{ 'E94637' if (calc.etr >= 20) else ('FBBD10' if (calc.etr >= 5) else '36A853') }}

  safe_changes:
    if:
      - {{ is.formatting or is.docs  }}
    run: 
      - action: add-label@v1
        args:
          label: 'safe-changes'
      - action: approve@v1

calc:
  etr: {{ branch | estimatedReviewTime }}
is:
  formatting: {{ source.diff.files | isFormattingChange }}
  docs: {{ files | allDocs }}

2. The PR URL (as it contains the repo and PR identifiers)
   https://github.com/Glossai/Production/pull/824

3. Describe your PR relevant content
   It happens in all of our PRs, this is just 1 example

4. Add relevant commit SHA

Expected behavior

We do have automations keyword so there just should not be an error

Screenshots

Support for global automation rules that are defined once and applies for all repositories.

Describe the bug

It is noticed the that sometimes gitstream fails with error "Failed to get PR context". I have seen this error on 2 PRs so far.
Please note that this is not always happening.

PRs URL for reference -
https://github.com/Hodes-Inc/Auth_0/pull/123
https://github.com/Hodes-Inc/Auth_0/pull/120

To Reproduce

Raise a PR, and wait for the gitstream check to execute.
The gitstream check fails sometimes.
Attaching gitstream.cm file for reference. The extension of the file is changed to .txt as GitHub was not allowing to upload of a .cm file.
gitstream.txt

Expected behavior

Gitstream checks should execute without failing its execution. It may fail if a rule fails but should not fail even to execute it.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

N/A

Describe the bug

See installation docs step 2

Most yaml formatting in this file is 2 spaces, but they keys {description,required,default} under on.workflow_dispatch.inputs are spaced with 4 spaces. This sets off our linter.

Please update the default workflow, the docs, and if the tool has actually generated this workflow then also please update gitStream's workflow generation logic.

Is your feature request related to a problem? Please describe.

  format_title_conventional_commits:
    if:
      - {{ [ pr.title ] | match(regex=r/^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\([a-z \-]+\))?!?: .+$/, ignoreWhiteSpaces=false) | nope }}
    run:
      - action: request-changes@v1
        args:
          comment: |
            PR title should match conventional commit format! https://www.conventionalcommits.org
            ex: `feat: [sc-1234] A shiny new feature`

Describe the solution you'd like
Would be nice for gitStream to re-run and pass it's check

Additional context
Now we manually have to dismiss its change request

Describe the bug

/bin/sh: syntax error: unterminated quoted string failures are being seen consistently by a user with a single quote in his last name, which exists in the payload being provided to the docker image.

Could it be that there's some escaping required that isn't happening?

To Reproduce

1. Submit a PR to a gitstream enabled repo or mimic in a shell with a payload that includes an author with a ' in the last name

Expected behavior

Gitstream works as expected

Screenshots

Describe the bug

With the referenced gitstream.cm file, at least one reviewer is expected to be added.

# -*- mode: yaml -*-

manifest:
  version: 1.0

config:
  ignore_files:
    - 'yarn.lock'
    - 'back-end/server/schema.prisma'
    - 'back-end/server/schema.graphql'
    - 'shared/graphql/generated-types.ts'
is:
  small_pr: '{ branch | estimatedReviewTime <= 5 and files | length <= 20 }'
  medium_or_large_pr: '{ branch | estimatedReviewTime > 5 or files | length > 20 }'

automations:
  single_reviewer:
    if:
      - '{ is.small_pr }'
    run:
      - action: set-required-approvals@v1
        args:
          approvals: 1
  multi_reviewer:
    if:
      - '{ is.medium_or_large_pr }'
    run:
      - action: set-required-approvals@v1
        args:
          approvals: 2

To Reproduce

Steps to reproduce the behavior:
It's a private repo so cannot reference PRs or hashes.

Expected behavior

With the created PR, which contains only the changes included in the gitstream.cm file, the check should fail as there are no approvals

Screenshots

Describe the bug

gitStream is failing for all PRs with the following error:

To Reproduce

Steps to reproduce the behavior:

1. Open a PR for in a repository with the default .github/workflows/gitstream.yml and .cm/gitstream.cm

Expected behavior

gitStream workflow should pass. 🙂

Is your feature request related to a problem? Please describe.
We have 20+ repos that would like to share a core set of gitstream automations, but certain repos may not need one or two or may need some of them configured slightly differently.

It would be awesome if in addition to the built-in config properties if custom properties could also be supported

Describe the solution you'd like
I think an easy and flexible solution would be to parse out the cm repo's gitstream.cm file and then merge it with the local repo's gitstream.cm file - so same-named keys would replace each other and arrays would concat together

ex:

# cm/.cm/gitstream.cm

automations:
  label_new_contributors:
    if:
      - {{ repo.author_age < setting.new_contributor_days and (repo.age - repo.author_age) >= setting.new_contributor_days }}
    run:
      - action: add-label@v1
        args:
          label: 'new-contibutor'
          color: {{ color.purple }}

color:
  purple: FF00FF

setting:
  new_contributor_days: 14

# myrepo/.cm/gitstream.cm

automations:
  assign_team_members:
    if:
      - {{ not pr.draft }}
    run:
      - action: add-reviewers@v1
        args:
          team_reviewers: {{ pr.author_teams }}

setting:
  new_contributor_days: 30

would result in processing this:

automations:
  label_new_contributors:
    if:
      - {{ repo.author_age < setting.new_contributor_days and (repo.age - repo.author_age) >= setting.new_contributor_days }}
    run:
      - action: add-label@v1
        args:
          label: 'new-contibutor'
          color: {{ color.purple }}
  assign_team_members:
    if:
      - {{ not pr.draft }}
    run:
      - action: add-reviewers@v1
        args:
          team_reviewers: {{ pr.author_teams }}

color:
  purple: FF00FF

setting:
  new_contributor_days: 30

Describe alternatives you've considered
maybe there could be a special config.custom key and only that's copied over if it's easier

config:
  custom:
    color:
      purple: FF00FF
    new_contributor_days: 30

Ofer also mentioned the cm repo could do something with repo.name to define per-repo customizations in there - that's an okay solution too. It would probably get complex if 20 different repos all needed their own different value

setting:
  new_contributor_days: {{ 30 if repo.name === 'myrepo' else 14 }}

Additional context
This could get complex when dealing with multiple *.cm files and how to match up what goes where - I'm not sure I entirely understand the need/purpose of multiples. It might also be nice though if just all cm files were combined together so someone could define each automation in its own .cm file and then have another file that's just the custom configuration for all of them. And it could error if the same thing is defined in 2 places in the same repo.

Describe the bug

I can't find any documentation explaining what the calc object that is used in calc.etr is, or what other properties it contains. I'm only able to assume that ETR is "estimated time (to) review" but I can't find that in documentation anywhere either. Maybe I'm missing something obvious! 😅

Describe the bug

Gitstream fails with fatal: bad revision but the check never completes and stays in the running/in progress state.

To Reproduce
Create a fatal: bad revision error

Expected behavior
If a fatal: bad revision error occurs, the gitstream check fails

Screenshots

Additional context

Error: {"message":" \n Git command failed. reason: Command failed: cd repo && git diff sc-52094/25-message-details-total-revenue-card'...'marketing-overview-file-refactor' -- .cm/*.cm\nfatal: bad revision 'sc-52094/25-message-details-total-revenue-card...marketing-overview-file-refactor'\n"}

Error: Process completed with exit code 67.

Add any other context about the problem here.

Just some questions about this bad revision error, and it might be silly but

• is there a best way to avoid this when it seems fine locally and in github but then gitstream is throwing the error?
• it seems to mostly (maybe only) occur when a feature branch is pointing at another feature branch, rather than develop
  • it still seems to occur on these PRs even after the base automatically changes to develop

Feel free to close this if it will be covered by #62 - seems like it might be but wanted to make sure and also ask my questions about the bad revision error in case I can get some clarity on it

Describe the bug

seeing exactly the same issue as #30

To Reproduce

Steps to reproduce the behavior:

1. The .cm automation file
2. The PR URL (as it contains the repo and PR identifiers)
3. Describe your PR relevant content
4. Add relevant commit SHA

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

some logs

docker.io/gitstream/rules-engine:latest

> [email protected] start
> node src/app.js

Running tag v1.151
PR: REDACTED/pull/5923
commit: 9791e680a4076d5f3cfc4249c71a10ae58d00d4f
fatal: bad revision 'development-3.0...feature/BLC-14644'
node:child_process:826
    err = new Error(msg);
          ^

Error: Command failed: cd repo && git diff 'development-3.0'...'feature/BLC-14644' -- .cm/*.cm
fatal: bad revision 'development-3.0...feature/BLC-14644'

    at checkExecSyncError (node:child_process:826:11)
    at execSync (node:child_process:900:15)
    at executeGitCommand (file:///src/utils/git.service.js:15:23)
    at isCmChanged (file:///src/utils/git.service.js:155:18)
    at getCMChanged (file:///src/utils/ruleParser.js:113:21)
    at file:///src/app.js:34:33
    at ModuleJob.run (node:internal/modules/esm/module_job:185:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24)
    at async loadESM (node:internal/process/esm_loader:88:5) {
  status: 128,
  signal: null,
  output: [
    null,
    Buffer(0) [Uint8Array] [],
    Buffer(58) [Uint8Array] [
      102,  97, 116,  97, 108,  58,  32,  98,  97, 100,  32,
      114, 101, 118, 105, 115, 105, 111, 110,  32,  39, 100,
      101, 118, 101, 108, 111, 112, 109, 101, 110, 116,  45,
       51,  46,  48,  46,  46,  46, 102, 101,  97, 116, 117,
      114, 101,  47,  66,  76,  67,  45,  49,  52,  54,  52,
       52,  39,  10
    ]
  ],
  pid: 30,
  stdout: Buffer(0) [Uint8Array] [],
  stderr: Buffer(58) [Uint8Array] [
    102,  97, 116,  97, 108,  58,  32,  98,  97, 100,  32,
    114, 101, 118, 105, 115, 105, 111, 110,  32,  39, 100,
    101, 118, 101, 108, 111, 112, 109, 101, 110, 116,  45,
     51,  46,  48,  46,  46,  46, 102, 101,  97, 116, 117,
    114, 101,  47,  66,  76,  67,  45,  49,  52,  54,  52,
     52,  39,  10
  ]
}

Describe the bug
A clear and concise description of what the bug is.

Workflow will fail sometimes fail due to files cached on the runner. The odd part is my workflow will run and perform the automations, but then rescind the auto-approval and dismiss a stale review a minute or so later. On subsequent commits, the check will display gitstream workflow not found.

To Reproduce
Steps to reproduce the behavior:
This is happening in a private repo, but my gitstream.cm is just a loose adaption of the example.

Expected behavior
A clear and concise description of what you expected to happen.
The auto-approval should stay valid

Screenshots
If applicable, add screenshots to help explain your problem.

Stale Review

GitHub Actions log

Git provider
The Git provider been used

Additional context
Add any other context about the problem here.

Describe the bug

Since 12/30/22 at 12:49pm CST the gitStream action has consistently failed with the following error message: (unknown path) TypeError: arr.map is not a function using a .cm config which hasn't changed since 12/6/22.

To Reproduce

Use the match() function with any input (string, array, or regex) in your .cm config file, see included config below.

The action succeeds after removing all uses of match(). We had to remove our no_tests automation and supplement safe_changes by using isTests() in the below config.

Screenshots

ERROR:  Template render error: (unknown path)
  TypeError: arr.map is not a function
    at Object._prettifyError (/node_modules/nunjucks/src/lib.js:36:11)
    at /node_modules/nunjucks/src/environment.js:563:19
    at Template.root [as rootRenderFunc] (eval at _compile (/node_modules/nunjucks/src/environment.js:633:18), <anonymous>:36:3)
    at Template.render (/node_modules/nunjucks/src/environment.js:552:10)
    at Environment.renderString (/node_modules/nunjucks/src/environment.js:380:17)
    at /node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1259:45
    at new Promise (<anonymous>)
    at _loop$ (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1258:32)
    at tryCatch (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:96:17)
    at Generator._invoke (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:76:24)
Error: (unknown path)
  TypeError: arr.map is not a function
Error: Process completed with exit code 60.

Additional context

Original config:

# -*- mode: yaml -*-

manifest:
    version: 1.0

automations:
    estimated_time_to_review:
        if:
            - true
        run:
            -   action: add-label@v1
                args:
                    label: "{{ calc.etr }} min review"
                    color: {{'E94637' if (calc.etr >= 20) else ('FBBD10' if (calc.etr >= 5) else '36A853')}}

    safe_changes:
        if:
            - {{is.formatting or is.docs or is.tests}}
        run:
            -   action: add-label@v1
                args:
                    label: 'safe-changes'
            -   action: approve@v1

    no_tests:
        if:
            - {{is.formatting or is.docs | nope}}
            - {{files | match(regex=r/tests\//) | nope}}
        run:
            -   action: add-label@v1
                args:
                    label: 'missing-tests'
                    color: '#E94637'

calc:
    etr: {{branch | estimatedReviewTime}}
is:
    formatting: {{source.diff.files | isFormattingChange}}
    docs: {{files | allDocs}}
    tests: {{files | match(regex=r/tests\//) | every}}

Side note

I noticed that there were a few discrepancies on regex syntax and escaping characters in some spots on the gitStream docs.

Describe the bug
Every time a PR is synchronised (via rebase or new commits), the gitStream workflow is triggered via the GitHub app (bot) more than once.
As we we have multiple PRs open in parallel, the gitStream workflow executions fill the "Actions" tab and also consume more GitHub actions minutes.

To Reproduce

Steps to reproduce the behavior:

1. Open a new PR.
2. Synchronise it (via rebase or new commits).

Expected behavior
The gitStream workflow should be triggered only once per synchronise event.

Screenshots
I selected the gitStream workflow specifically in the "Actions" tab in order to show duplicate triggers in the same time:

Additional context
N/A

Is your feature request related to a problem? Please describe.
We have built a github action to automatically merge the main branch into any open PR's to keep PR's up to date. When this action runs, the gitstream automations are run again which prompts email notifications from github as well as to the Slack channel we setup for notifications. This could happen many times on an open PR before it is tested/merged so we have temporarily disabled the gitstream actions to avoid the excessive notifications until a solution is found.

Describe the solution you'd like
A way to prevent the gitstream actions from running when a github action (workflow) makes a change to the PR.

Describe alternatives you've considered
We have tried to define the workflow to prevent gitStream actions from running but have been unsuccessful.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug

Installation doesn't successfully finish and errors out after clicking GitLab Install.

However, application shows in user settings, and webhook appears in project.

Yet, webhook fails on testing with the following information.

To Reproduce

Follow the instructions to install into gitlab and setup per instructions.

Expected behavior

It should work.

Additional context

Response
404

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot POST /webhooks/gitlab</pre>
</body>
</html>
Headers
Date: Thu, 26 Jan 2023 13:44:51 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 155
Connection: close
X-Amzn-Requestid: 7f041c37-82a0-431d-abd8-ea3b71ee8198
X-Amzn-Remapped-Content-Length: 155
Content-Security-Policy: default-src 'none'
X-Amz-Apigw-Id: fWmJBF4LSK4FWjg=
X-Content-Type-Options: nosniff
X-Powered-By: Express
X-Amzn-Trace-Id: Root=1-63d283d3-41181d251c7d071114b00f07;Sampled=0

Request

{
  "object_kind": "push",
  "event_name": "push",
  "before": "e879e16a42ac12fec44bc0d3e6f3ea5852ff3693",
  "after": "5e86fc3ed85e52ebd9a63e0a3c272b00143d58ba",
  "ref": "refs/heads/dev",
  "checkout_sha": "5e86fc3ed85e52ebd9a63e0a3c272b00143d58ba",
  "message": null,
  "user_id": 10782021,
  "user_name": "name",
  "user_username": "@username",
  "user_email": "",
  "user_avatar": "https://gitlab.com/uploads/-/system/user/avatar/10782021/avatar.png",
  "project_id": 41932020,
  "project": {
    "id": 41932020,
    "name": "hopup",
    "description": null,
    "web_url": "https://gitlab.com/hoppr/hopup",
    "avatar_url": null,
    "git_ssh_url": "[email protected]:hoppr/hopup.git",
    "git_http_url": "https://gitlab.com/hoppr/hopup.git",
    "namespace": "hoppr",
    "visibility_level": 20,
    "path_with_namespace": "hoppr/hopup",
    "default_branch": "dev",
    "ci_config_path": "",
    "homepage": "https://gitlab.com/hoppr/hopup",
    "url": "[email protected]:hoppr/hopup.git",
    "ssh_url": "[email protected]:hoppr/hopup.git",
    "http_url": "https://gitlab.com/hoppr/hopup.git"
  },
  "commits": [
    {
      "id": "5e86fc3ed85e52ebd9a63e0a3c272b00143d58ba",
      "message": "chore(release): 0.0.2-dev.8\n\n## [0.0.2-dev.8](https://gitlab.com/hoppr/hopup/compare/v0.0.2-dev.7...v0.0.2-dev.8) (2023-01-26)\n\n### Bug Fixes\n\n* Run MR Pipelines ([65e2da0](https://gitlab.com/hoppr/hopup/commit/65e2da02ee7eec4f5d3970cbdf9f1a22c4f90870))\n",
      "title": "chore(release): 0.0.2-dev.8",
      "timestamp": "2023-01-26T13:31:35+00:00",
      "url": "https://gitlab.com/hoppr/hopup/-/commit/5e86fc3ed85e52ebd9a63e0a3c272b00143d58ba",
      "author": {
        "name": "@username",
        "email": "[REDACTED]"
      },
      "added": [

      ],
      "modified": [
        "docs/CHANGELOG.md"
      ],
      "removed": [

      ]
    },
    {
      "id": "65e2da02ee7eec4f5d3970cbdf9f1a22c4f90870",
      "message": "fix: Run MR Pipelines\n\nSigned-off-by: Heck, Jerod <[email protected]>\n",
      "title": "fix: Run MR Pipelines",
      "timestamp": "2023-01-26T08:26:05-05:00",
      "url": "https://gitlab.com/hoppr/hopup/-/commit/65e2da02ee7eec4f5d3970cbdf9f1a22c4f90870",
      "author": {
        "name": "Name, Name",
        "email": "[REDACTED]"
      },
      "added": [

      ],
      "modified": [
        ".gitlab-ci.yml"
      ],
      "removed": [

      ]
    },
    {
      "id": "e879e16a42ac12fec44bc0d3e6f3ea5852ff3693",
      "message": "chore(release): 0.0.2-dev.7\n\n## [0.0.2-dev.7](https://gitlab.com/hoppr/hopup/compare/v0.0.2-dev.6...v0.0.2-dev.7) (2023-01-26)\n\n### Bug Fixes\n\n* Add in gitstream ([f5b0412](https://gitlab.com/hoppr/hopup/commit/f5b0412c071a3a630f1d132d849a326c783ca189))\n* Correct the stage ([5c467c6](https://gitlab.com/hoppr/hopup/commit/5c467c64097fb4825c3afd017a2163ad7ef73bfc))\n",
      "title": "chore(release): 0.0.2-dev.7",
      "timestamp": "2023-01-26T13:10:54+00:00",
      "url": "https://gitlab.com/hoppr/hopup/-/commit/e879e16a42ac12fec44bc0d3e6f3ea5852ff3693",
      "author": {
        "name": "@username",
        "email": "[REDACTED]"
      },
      "added": [

      ],
      "modified": [
        "docs/CHANGELOG.md"
      ],
      "removed": [

      ]
    }
  ],
  "total_commits_count": 3,
  "push_options": {
  },
  "repository": {
    "name": "hopup",
    "url": "[email protected]:hoppr/hopup.git",
    "description": null,
    "homepage": "https://gitlab.com/hoppr/hopup",
    "git_http_url": "https://gitlab.com/hoppr/hopup.git",
    "git_ssh_url": "[email protected]:hoppr/hopup.git",
    "visibility_level": 20
  }
}

Headers

Content-Type: application/json
User-Agent: GitLab/15.9.0-pre
X-Gitlab-Event: Push Hook
X-Gitlab-Instance: https://gitlab.com
X-Gitlab-Token: [REDACTED]
X-Gitlab-Event-UUID: e0b72ede-fa73-45d8-b97d-b1ecaea6ae9b

Describe the bug

I made a change to my project's .cm/gitstream.cm file, and created a PR to try it out. I think it should be running dry run mode, but I can't tell. 17 hours later, the check still hasn't completed, and there is no log output to give me any clue about why.

The only feedback I see in the PR is this:

gitStream.cm / gitStream.cm
Started 16h 59m 5s ago
[View more details on gitStream.cm](https://docs.gitstream.cm/examples/)

Viewing more details doesn't really help, because it just leads me to the example document.

And there are no log messages at all to tell me what has or hasn't happened in the past 17 hours.

To Reproduce

First, here is my .cm file (with comments stripped, for brevity):

# -*- mode: yaml -*-

manifest:
  version: 1.0

automations:
  estimated_time_to_review:
    if:
      - true
    run:
      - action: add-label@v1
        args:
          label: "{{ calc.etr }} min review"
          color: {{ 'E94637' if (calc.etr >= 20) else ('FBBD10' if (calc.etr >= 5) else '36A853') }}

  safe_changes:
    if:
      - {{ is.formatting or is.docs or is.renovate_config }}
    run:
      - action: add-label@v1
        args:
          label: 'safe-changes'
      - action: approve@v1

  github_teams_changes:
    if:
      - {{ files | match(regex=r/\.github\/teams.yml/) | every }}
    run:
      - action: add-label@v1
        args:
          label: 'safe-changes'
      - action: approve@v1

calc:
  etr: {{ branch | estimatedReviewTime }}
is:
  formatting: {{ source.diff.files | isFormattingChange }}
  docs: {{ files | match(regex=r/\.md$|\.rst$/) | every }}
  renovate_config: {{ files | match(regex=r/renovate.json5/) | every }}

The PR URL: (removed for security reasons)

Describe your PR relevant content: This PR has two changes. First is the .cm file shown above. Second is adding a file called documentation/source/bar.md as a test.

Add relevant commit SHA: I don't know how this will help you, because it's not a public repo, but the commit SHA is 464acdb4b7db3788b45cd2518e05eb0dcc6df114

Expected behavior

I expected two things:

• gitstream should approve the PR
• gitstream should add dry run comments to the PR to explain what it's doing

Screenshots

Additional context

(I can't think of anything relevant)

Is your feature request related to a problem? Please describe.
We always open our PRs in draft to make sure all checks pass. Since gitstream will be one of these checks, it'll cause frustration for our flow if we have to get all other checks (unit tests, builds, etc) to pass separately and then might need to handle any gitstream failures after marking it ready for review, which is the same point reviewers then get assigned but might do reviews before the gitstream fixes are then made.

Additionally when testing new gitstream changes, if the review has to be marked ready for review then reviewers will be assigned while we're actively working on making changes to .cm files to test things out in dry run mode. So this should also work from a Draft PR.

Describe the solution you'd like
Have gitstream run as normal for Draft PRs too rather than skipping itself.

Describe alternatives you've considered
We could change our process but I think there are clear downsides to that and friction with people reviewing things that aren't finished yet.

Additional context
Having it as a setting would be fine if there's a reason someone wouldn't want it to run on drafts.
As-is, it's also a little confusing that there's a {{ pr.draft }} variable since it'll never run when that's true - and that seems like a perfect use case to instead always run gitstream but allow each automation to do if: {{ not pr.draft }} if it doesn't want something to run on a draft

Describe the bug

When Require approval of the most recent push is set as a branch protection, gitStream does not re-approve the PR if a previous commit already triggered the approbal

To Reproduce

Steps to reproduce the behavior:

1. The .cm automation file

# -*- mode: yaml -*-

manifest:
  version: 1.0

automations:
  welcome_message:
    if:
      - {{ repo.contributors | isFirstCommit(branch.author) }}
    run:
      - action: add-comment@v1
        args:
          comment: |
            Welcome @{{ pr.author }}!

  admin_autoapprove:
    if:
      - {{ is.admin }}
    run:
      - action: approve@v1

  review_cicd:
    if:
      - {{ files | match(regex=r/.github\/workflows\/.*\.yml/) | some }}
    run:
      - action: add-reviewers@v1
        args:
          team_reviewers: [infrastructure]

  aws_changes:
    if:
      - {{ is.aws and not is.admin }}
    run:
      - action: add-label@v1
        args:
          label: 'aws'
      - action: add-reviewers@v1
        args:
          team_reviewers: [aws-infrastructure]

  snowflake_changes:
    if:
      - {{ is.snowflake and not is.admin }}
    run:
      - action: add-label@v1
        args:
          label: 'snowflake'
      - action: add-reviewers@v1
        args:
          team_reviewers: [snowflake-infrastructure]
is:

  admin: {{ pr.author | includes(list=['ianwesleyarmstrong']) }}

3. The PR URL (as it contains the repo and PR identifiers)
4. N/A
5. 28d2c2254fa046dee6c1367c46a1c6c74485e90c

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

Describe the bug

gitStream checks seem to fail on PRs that contained any added/modified files with spaces and return an exit code of 40.

To Reproduce

Have an added/modified file in a PR with a path that contains spaces. For example: xxxx/yyyy/zzzz/firstname lastname.html.

We would see an error in the action log like so:

fatal: path 'xxxx/yyyy/zzzz/firstname' does not exist in `corresponding commit hash`
fatal: path 'xxxx/yyyy/zzzz/firstname' does not exist in `corresponding commit branch`
fatal: path 'xxxx/yyyy/zzzz/firstname' exists on disk, but not in 'master'
Error: Failed getting PR context.
Error: Process completed with exit code 40.

I'm not sure if this is a feature request or just a documentation request. I'm hoping it's already possible and I just need to know how.

Is your feature request related to a problem? Please describe.
As much as I would love GitHub "team reviews" to work well, they just don't. If I want to just get two reviews from any of my seven team members, I can add the team to the PR and require two reviewers. Great, but the first person from that team that reviews, will eliminate the team from the requested reviewers, and the PR will stop showing up in requested reviews for all of the members. So, I need an option where I can just assign all the people from the team individually and require two reviews, but then not have to store their actual names in the .cm file because that sucks.

Describe the solution you'd like
I would like to access Github Actions Variables from within GitStream, such that I can store useful configuration in a place that exists outside of the source. Then I can just put a list of reviewers in one of those variables, and use it as the source of reviewers for GitStream.

Describe alternatives you've considered
The only other thing I can think to do, is make a number of Git Team (like 10) and add all of them. Then if team members change, you could just change who is in those teams. That really sucks though. That might be worse than usernames in the source.

Additional context
Here is a screen shot of what this might look like in Github Action Variables.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce

1. Using this automation in a repo

automations:
  PR_title_must_contain_jira_id:
    if:
      - {{ pr.general_comments | length == 0 }}
    run:
      - action: add-comment@v1 
        args:
          comment: |
            WELCOME!

2. Open a new PR
3. Add a comment using the GitHub web editor
4. gitStream doesn't trigger

Expected behavior
I expected gitStream to trigger and to add a comment WELCOME as a result

Screenshots

Git provider
GitHub cloud

Additional context
None

Describe the bug

There's an extra backtick here:

which misformats here

it should render like this

• to add the following reviewers johnlock

To Reproduce

Steps to reproduce the behavior:

• I'm using this automation

  assign_previous_contributors:
    if:
      - {{ not pr.draft }}
    run:
      - action: add-comment@v1
        args:
          comment: |
            {{ repo | explainRankByGitBlame(gt=25) | dump | safe }}
      - action: add-reviewers@v1
        args:
          reviewers: {{ repo | rankByGitBlame(gt=25) }}

• and then running it in dry mode

Expected behavior

it should output without the extra backtick so it renders like this

• to add the following reviewers johnlock

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Afer looking more closely, this happens anytime using add-comment@v1 cause it seems to assume a short single-line comment like

• add comment foo bar baz

but if you do a multi-line comment, like the explainRankByGitBlame dump, then you get a leading backtick as well before the comment and that tailing one causing mis-formatting

can see the leading one here:

it would probably be better to have add-comment@v1 start the comment on the next line and not add any of its own formatting in dry run

Is your feature request related to a problem? Please describe.

I'm using the following command add-reviewers@v1, as below:

  ui_review:
    if:
      - {{ files | match(regex='ui\\/') | some }}
    run:
      - action: add-reviewers@v1
        args:
          reviewers: [MishaKav]

Describe the solution you'd like

• After PR is open, check if it has conflicts, is so, don't ask for review (I don't want to bother people if my PR is still not ready)
• Add reviewer only after all checks are passed (I don't want to bother people if my PR is still not ready, and some of my tests are still fail)

Describe alternatives you've considered

• For now, I'm waiting for gitstream to finish, remove the reviewers manually, fix my PR, push and wait again.

Additional context
It may be done via additional properties (maybe names may be better), or should be as default IMHO.

  ui_review:
    if:
      - {{ files | match(regex='ui\\/') | some }}
    run:
      - action: add-reviewers@v1
        args:
          reviewers: [MishaKav]
          pass-all-checks: true
          has-no-conflicts: true

I'm having an issue with a workflow setup in which I'm trying to set the number of reviewers on a PR. Here's the gitstream file:

# -*- mode: yaml -*-

manifest:
  version: 1.0

config:
  ignore_files:
    - 'yarn.lock'
    - 'back-end/server/schema.prisma'
    - 'back-end/server/schema.graphql'
    - 'shared/graphql/generated-types.ts'
is:
  small_pr: '{ branch | estimatedReviewTime <= 5 and files | length <= 20 }'
  medium_or_large_pr: '{ branch | estimatedReviewTime > 5 or files | length > 20 }'

automations:
  single_reviewer:
    if:
      - '{ is.small_pr }'
    run:
      - action: set-required-approvals@v1
        args:
          approvals: 1
  multi_reviewer:
    if:
      - '{ is.medium_or_large_pr }'
    run:
      - action: set-required-approvals@v1
        args:
          approvals: 2

This PR with only 1 file and only a few lines of code removed still requires 2 approvals.

Looking into the logs of the run, under the Evaluate Rules section, I see the following, which shows that both mutually exclusive rules have passed:

{
  "automations": 
  { 
    "gitstream/single_reviewer": 
    { 
      "if": [
        { 
          "passed": "{ is.small_pr }"
        }
      ], 
      "run": 
      [
        { "action": "set-required-approvals@v1", "args": { "approvals": 1 } }
      ], 
      "passed": true 
    },
    "gitstream/multi_reviewer":
    { 
      "if": [
        { "passed": "{ is.medium_or_large_pr }" }
      ], 
      "run": [
        { "action": "set-required-approvals@v1", "args": { "approvals": 2 } }
      ], 
      "passed": true 
    } 
  }
}

Shoudn't only one of them pass, given my config? Or is there something wrong with the way I have setup the is: checks?

Describe the bug

I defined under the config.user_mapping at .cm/gitstream.cm mapping for some of the users who are no longer defined as contributors for the repository with a value of null (as suggested here).
Unfortunately, the gitstream-cm bot still lists those users in the suggested reviewers list as part of the PR comment.

To Reproduce

Steps to reproduce the behavior:

1. Add the following section to the .cm/gitstream.cm in the default branch (on top the initial file provided as part of the instructions here):

   config:
     user_mapping:
       - 'Invalid User <[email protected]>': 'InvalidUser'
       - 'InvalidUser <[email protected]>': 'InvalidUser'
       - 'InvalidUser': null
       - 'Invalid User2 <[email protected]>': 'InvalidUser2'
       - 'InvalidUser2': null

2. Open a PR for a new feature branch which includes at least one file modified by one of the users (or more) mentioned in step 1 above.
3. Required job gitstream-cm is executed for the PR successfully.

Expected behavior

Required job gitstream-cm is executed successfully and a comment is added to the PR with suggested reviewers that do NOT include the invalid users mapped to null value above.

** Actual behavior **

Required job gitstream-cm is executed successfully and a comment is added to the PR with the following content:

 👋  **Suggested reviewers: ValidUser2**
 
They contributed more than 25% of the lines on pre-existing files:

`path/to/file1` 
ValidUser1: 44% 
ValidUser3: 18% 
ValidUser2: 12% 
ValidUser4: 11% 
ValidUser5: 3% 
ValidUser6: 3% 
ValidUser7: 2% 
ValidUser8: 1% 
ValidUser9: 1% 
ValidUser10: 0% 

`path/to/file2` 
ValidUser2: 45% 
ValidUser1: 15% 
ValidUser3: 10% 
ValidUser4: 7% 
ValidUser5: 7% 
ValidUser6: 4% 
InvalidUser: 3% 
ValidUser7: 2% 
InvalidUser2: 0% 
ValidUser8: 0% 
ValidUser9: 0% 
ValidUser10: 0% 
ValidUser11: 0% 

 
To learn more about /:\ gitStream - [Visit our Docs](https://docs.gitstream.cm/) 

InvalidUser and InvalidUser2 are listed as part of the contributors to path/to/file2 (we expect them to be filtered out).

Additional context

The repository on which gitstream was enabled is a private repository (so, the real data had to be redacted).
In addition, I tried to change the order of the entries in config.user_mapping, but, unfortunately, I still got the same results.

Is your feature request related to a problem? Please describe.
After submitting a review, I was thinking that gitstream would be re-triggered but that doesn't seem to be the case.

Describe the solution you'd like
After I submit a review, then gitstream should be re-triggered

Describe alternatives you've considered
I've looked at the other actions but I don't think they'll help me/I'd run in to a similar issue

Additional context
My use case for above was specifically for when a review is submitted with requested changes, I wanted an automation to run to add a "requested changes" label

Below is what I am trying to use but after submitting my review, I didn't see gitstream run again

requested_changes:
    if:
      - {{ pr.status | includes(term='requested-changes') }}
    run:
      - action: add-label@v1
        args:
          label: '🚨 Changes requested'
          color: '#EC560D'

Describe the bug
We defined in .cm/gitstream.cm a section with config.user_mapping as described here.
Unfortunately, gitStream still tried to add users mapped to null as reviewers.
As those users are no longer in the organization, add-reviewers job fails (which blocks the PR from being merged). 🙁

To Reproduce

Steps to reproduce the behavior:

1. At the bottom of .cm/gitstream.cm add the following (replace the user mapped to null with a real user):

config:
  user_mapping:
    - 'Popeye Man <[email protected]>': 'popeye-the-salyor-man'
    - 'Popeye Man <[email protected]>': 'popeye-the-salyor-man'
    - 'Popeye': null

2. Create a PR for a files added/modified by the user mapped to null.
3. gitStream workflow should start running.

Expected behavior
add-reviewers job should pass.

Screenshots

Additional context
The add-reviewers job should NOT attempt to add any other user mapped to null as a reviewer.

Is your feature request related to a problem? Please describe.
It would be good to be able to get the line numbers of each changed line, be able to process the changes, and have an action available to add comments associated with a specific line to a PR.

For instance, if a PR includes a line like TODO:, I'd like to have gitStream automatically add a comment on that line in the PR saying "TODO found, did you mean to address this now?"

Describe the solution you'd like
Add line number information to the FileDiff context variable. Provide a add-comment@v2 that allows for supplying a line number argument. Associate the comment with those line numbers.

Describe alternatives you've considered
Adding comments without line numbers. Adding the content of the diff to the comment. These are not as helpful.

Describe the bug

In one of the PR, gitStream seems to be stuck. We tried even with multiple commits so that the check could restart, but there was still no success & it remains in "In progress — This check has started...." state
PR URL - https://github.com/Hodes-Inc/XCloud.JEE6.CoreAPIs/pull/7201

To Reproduce

Steps to reproduce the behavior:
Raise a PR and wait for the gitstream checks to finish.
Notice that the gitStream status is shown as "In progress for hours" in the pr, but if we check inside Actions list of the repo it will shown as failed.
The actions displays the error as - "The job running on runner Hosted Agent has exceeded the maximum execution time of 5 minutes."

Expected behavior

The gitstream should not be failed with message "The job running on runner Hosted Agent has exceeded the maximum execution time of 5 minutes."
The gitStream checks should be executed and get finished in a reasonable time.
If the gitstream check has failed, it should be reflected in the PR status check sections as well.

Screenshots

Additional context

This issue has been noticed for this one particular pr only.

Describe the bug

Please add/fix support for regex in deprecated apis.
I attached the example when the first line of regex is working, but the second is not working.

To Reproduce

automations:
  {% for item in deprecated %}
  catch_deprecated_components_{{ loop.index }}:
    if:
      - {{ source.diff.files | matchDiffLines(regex=item.regex) | some }}
    run:
      - action: add-label@v1
        args:
          label: 'deprecated-component'
      - action: request-changes@v1
        args:
          comment: |
            `{{ item.regex }}` is deprecated, use `EventType` from `constants.py/constants.ts[js]`
  {% endfor %}

deprecated:
  - regex: r/^[+].*Types.EVENT_REQUESTED/
  - regex: r/^[+].*eventRequested\/v1/

Expected behavior

the current snippet should run as valid.

Screenshots

Is your feature request related to a problem? Please describe.
We have Git LFS in our repo, and you recently added support for GitLFS which is great. The problem is that it consumes all of our bandwidth, because it pulls all of our repo on every call to gitStream.

Describe the solution you'd like
It would be great to have a flag to allow us to disable git LFS pull, assuming we don't wish any of the cm logic to apply of changed LFS files. Another option is do not pull them by default.

Is your feature request related to a problem? Please describe.
When making changes to some files it is occasionally missed that they didn't also update code in another file. We would like to automate and prevent the merge request from going through until they make sure the files are missed and automate doing so.

Describe the solution you'd like
We would like to create threads in GitLab (they block merge requests) when a user makes changes to certain files so it can be used like a task/checklist item.

Is your feature request related to a problem? Please describe.

GitHub provides contributors an option to auto-merge when all merge requirements are met (e.g., At least X approvals, no unresolved conversations, all checks passed, etc).
However, anyone opening a PR must actively enable the option to auto-merge a PR.
Chasing developers to make sure they enabled auto-merge on their PRs can be very frustrating. 😠

Describe the solution you'd like

We would like an option add a comment in the PR reminding the developer to enable auto-merge only if it is not already enabled.
It would be nice if the pr context variable will have a boolean member called auto_merge.
This way we can create a new automation as follows:

automations:
  enable_auto_merge:
    if: 
      - {{ not pr.auto_merge }}
    run:
      - action: add-comment@v1
        args:
          comment: |
            Don't forget to enable auto-merge.

Describe alternatives you've considered

We thought about creating workflow that is triggered on PR synchronize event to add this comment when auto-merge is disabled for the PR in context.
But, that would spam the PR with the same comment multiple times (every time it is synchronized). 🙁

Is your feature request related to a problem? Please describe.
As an organization, we have multiple GitHub teams that are responsible for various repositories. These teams are not necessarily fixed, so members split out into new teams and so forth. We handle this in technical terms by placing them on new GH teams.

The issue is that they are still contributors to the codebase, and they're still a part of the organization, which means that they'll likely to be assigned as code reviewers for teams they're no longer part of. Today's solution needs us to manually map their GH users to "null", but that means we have to go through our repositories and maintain that list. This can quickly become tedious when one works with a solution that has a ton of repositories while allowing teams to be a little dynamic.

Describe the solution you'd like
I would like to be able to filter reviewers based on their team.

Describe alternatives you've considered
Right now, the only other option I can think of is either to maintain the team member list for every repo, or have a script that updates every repo as time changes.

Is your feature request related to a problem? Please describe.
Yes, when we rolled gitstream out our devs were creating PR's against stale source branches that didn't have the gitstream file. This will be a recurring issues as we roll out new versions of the gitstream file as well. We would like to start depending on gitstream to enforce certain behaviors, but we need to be able to depend on it. This would be a healthy behavior to start with I think.

Describe the solution you'd like
At the time a dev pushes and update to or creates a PR, if their branch isn't up to date with the source branch, simply fail and don't even look for the gitstream file with an appropriate message. Thus ensuring the most update to date gitstream file is always used.

Describe alternatives you've considered
The only other alternative I found was requiring fast forward merging in github, but this has the downside that devs have to constantly merge the last from the source branch to be able to merge.

Additional context
I feel like this feature would be a require fast forward merging "lite" where it only enforces it at the time of the push, but anything merged after that point to the source branch wouldn't block from merging unless there were conflicts.

Describe the bug

gitStream job is hanging although it appears the job has failed.

To Reproduce

We added gitStream to the repo according to instructions earlier in the day. This PR was a typical change to the repo involving business logic.

1. .cm file:

# -*- mode: yaml -*-

manifest:
  version: 1.0

automations:
  estimated_time_to_review:
    if:
      - true
    run:
      - action: add-label@v1
        args:
          label: "~{{ calc.etr }} min review"
          color: {{ 'E94637' if (calc.etr >= 20) else ('FBBD10' if (calc.etr >= 5) else '36A853') }}

calc:
  etr: {{ branch | estimatedReviewTime }}
is:
  formatting: {{ source.diff.files | isFormattingChange }}
  docs: {{ files | allDocs }}
  tests: {{ files | allTests }}

2. PR url: https://github.com/Popmenu/popship/pull/153
3. There are no changes relevant to gitStream
4. 0acbaad346ddf08ba2638f5ef032648d60d19d34

Expected behavior

Success or failure are reported for the gitStream job.

Screenshots

Additional context

It is possible that this build was happening during the setup of gitStream for the same repo.

Is your feature request related to a problem? Please describe.

In certain organizations it's preferred to self-host an instance with fine-grained permissions and use a custom GitHub App to grant permissions accordingly to the repository. This could be also a stance that is enforced due to security where exfiltration of data is a concern and/or unauthorised access.

Describe the solution you'd like

I'd like to propose running this as a self-hosted instance similar to how Renovate allows you to configure it as a self-hosted GH action and BYO Github App. https://github.com/renovatebot/github-action

Describe alternatives you've considered

Currently using bespoke solution.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug

I confignured everything exactly like in the GitHub Installation Guide and I am getting the following error:

Rule file not found
Error: Process completed with exit code 70.

Expected behavior

It should work

Screenshots
Adding log file from github actions
logs_10.zip

Additional context

I will mention we have lfs, and it seems as though your docker image doesn't. Not sure it should make any difference.

Describe the bug

Changes to documentation in asciidoc format are not caught by the allDocs filter.

To Reproduce

Steps to reproduce the behavior:

1. Add an automation that is meant to trigger if files | allDocs
2. Add or change a documentation file with an .adoc extension
3. The automation does not trigger

Expected behavior

The automation should trigger. Asciidoctor is a popular format for writing documentation.

Additional context

Some way to configure what types of files are considered documentation (either on a particular allDocs usage, or globally, would be very helpful. There are sure to be other types of documentation in use not in the current list.

Describe the bug

The codeExperts filter keeps re-posting comments, despite no changes to the files in the PR.

To Reproduce

Steps to reproduce the behavior:
See the PR here: gradle/gradle#24804.
The automation file is here: https://github.com/gradle/gradle/blob/386278ba2ea9e29597714ae3175bff4d7601ee6a/.cm/code_experts.cm

Expected behavior

The code experts comment should only have been added once.

Describe the bug

Intermittently seeing this issue on one repo.

To Reproduce

Steps to reproduce the behavior:

1. The .cm automation file
   no real change

# -*- mode: yaml -*-

manifest:
version: 1.0

automations:
estimated_time_to_review:
  if:
    - true
  run:
    - action: add-label@v1
      args:
        label: "{{ calc.etr }} min review"
        color: {{ 'E94637' if (calc.etr >= 20) else ('FBBD10' if (calc.etr >= 5) else '36A853') }}

safe_changes:
  if:
    - {{ is.formatting or is.docs or is.tests }}
  run:
    - action: add-label@v1
      args:
        label: 'safe-changes'
calc:
etr: {{ branch | estimatedReviewTime }}
is:
formatting: {{ source.diff.files | isFormattingChange }}
docs: {{ files | allDocs }}
tests: {{ files | allTests }}

2. Describe your PR relevant content - this happens on some PRs and not others, and only in this repo. we have other repos with the same gitream.cm file and the checks have no issues

Expected behavior

To have consistent runs.

Output

This is copied output from the action that failed with the mentioned error. In the Evaluate Rules stage.

...
From https://github.com/<org>/<repo>
 * branch              dev        -> FETCH_HEAD
 * [new branch]        dev        -> origin/dev
Switched to a new branch 'dev'
branch 'dev' set up to track 'origin/dev'.
Switched to branch 'branch-to-merge'
Your branch is up to date with 'origin/branch-to-merge'.
From https://github.com/<org>/<repo>
 * branch              branch-to-merge -> FETCH_HEAD

latest: Pulling from gitstream/rules-engine
59bf1c3509f3: Pulling fs layer
b616ac4a64bf: Pulling fs layer
3b9e1e8ab9ce: Pulling fs layer
3507ddbf3909: Pulling fs layer
f0ad28c522fc: Pulling fs layer
893f905b8c89: Pulling fs layer
2f083e44ca6f: Pulling fs layer
91b037256d6e: Pulling fs layer
d51b06a31021: Pulling fs layer
4ecd0e153a1f: Pulling fs layer
3507ddbf3909: Waiting
2f083e44ca6f: Waiting
f0ad28c[522](https://github.com/<org>/<repo>/actions/runs/4046369097/jobs/6959067838#step:2:535)fc: Waiting
91b037256d6e: Waiting
d51b06a31021: Waiting
893f905b8c89: Waiting
4ecd0e153a1f: Waiting
59bf1c3509f3: Verifying Checksum
59bf1c3509f3: Download complete
3b9e1e8ab9ce: Verifying Checksum
3b9e1e8ab9ce: Download complete
3507ddbf3909: Verifying Checksum
3507ddbf3909: Download complete
893f905b8c89: Verifying Checksum
893f905b8c89: Download complete
b616ac4a64bf: Verifying Checksum
b616ac4a64bf: Download complete
f0ad28c522fc: Verifying Checksum
f0ad28c522fc: Download complete
91b037256d6e: Verifying Checksum
91b037256d6e: Download complete
59bf1c3509f3: Pull complete
4ecd0e153a1f: Verifying Checksum
4ecd0e153a1f: Download complete
2f083e44ca6f: Verifying Checksum
2f083e44ca6f: Download complete
d51b06a31021: Verifying Checksum
d51b06a31021: Download complete
b616ac4a64bf: Pull complete
3b9e1e8ab9ce: Pull complete
3507ddbf3909: Pull complete
f0ad28c522fc: Pull complete
893f905b8c89: Pull complete
2f083e44ca6f: Pull complete
91b037256d6e: Pull complete
d51b06a31021: Pull complete
4ecd0e153a1f: Pull complete
Digest: sha256:c0b9f90ae380846d33e7fd077f6ad0b3058a8de86d64b33fb8bc67053cf81abf
Status: Downloaded newer image for gitstream/rules-engine:latest
docker.io/gitstream/rules-engine:latest

> [email protected] start
> node src/app.js

Running tag v1.91
Switched to branch 'dev'
Switched to branch 'branch-to-merge'
grep: unrecognized option: global
BusyBox v1.34.1 (2021-11-23 00:57:35 UTC) multi-call binary.

Usage: grep [-HhnlLoqvsrRiwFE] [-m N] [-A|B|C N] { PATTERN | -e PATTERN... | -f FILE... } [FILE]...

Search for PATTERN in FILEs (or stdin)

	-H	Add 'filename:' prefix
	-h	Do not add 'filename:' prefix
	-n	Add 'line_no:' prefix
	-l	Show only names of files that match
	-L	Show only names of files that don't match
	-c	Show only count of matching lines
	-o	Show only the matching part of line
	-q	Quiet. Return 0 if PATTERN is found, 1 otherwise
	-v	Select non-matching lines
	-s	Suppress open and read errors
	-r	Recurse
	-R	Recurse and dereference symlinks
	-i	Ignore case
	-w	Match whole words only
	-x	Match whole lines only
	-F	PATTERN is a literal (not regexp)
	-E	PATTERN is an extended regexp
	-m N	Match up to N times per file
	-A N	Print N lines of trailing context
	-B N	Print N lines of leading context
	-C N	Same as '-A N -B N'
	-e PTRN	Pattern to match
	-f FILE	Read pattern from file
Error: Failed getting PR context.
Error: Process completed with exit code 40.

Screenshot

Additional context

all failures are the same, Failed to get PR context.

Is your feature request related to a problem? Please describe.
Currently context variables under PR does not have assignee option.
This is a common piece in our development flow and would like to have some automation on it.

Describe the solution you'd like
Adding that var, probably an easy addition.

Additional context

Describe the bug

Nothing prevents you from declaring a variable with a same name as the existing gitStream context variables have and one could accidentally do that, yet this isn't a supported thing.

• Allow existing variables' extension,
• Or make it explicitly prohibited.

To Reproduce

Steps to reproduce the behavior:

1. Use files context variable in your automation, e.g.

   {{ files | extensions | match(regex=r/^sql\s*$/) | some }}
   

2. Introduce a custom variable named source, e.g.

   source:
     isHotfix: {{ branch.name | includes(regex=r/^hotfix.+$/) }}
   

3. gitStream will fail with not that clear error

   error: TypeError: Cannot read properties of undefined (reading 'map')
       at Context.parseMatchDiffLines (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1412:30)
       at eval (eval at _compile (/node_modules/nunjucks/src/environment.js:633:18), <anonymous>:26:101)
       at _callee3$ (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1265:13)
       at tryCatch (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:97:17)
       at Generator._invoke (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:77:24)
       at Generator.next (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:128:21)
       at asyncGeneratorStep (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:361:24)
       at _next (/node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:383:9)
       at processTicksAndRejections (node:internal/process/task_queues:96:5)
   /node_modules/@linearb/gitstream-rule-parser/dist/gitstream-rule-parser.cjs.development.js:1412
     return !regex ? [] : files.map(function (_ref3) {
   

Expected behavior

• No errors, core source variable is extended with new members from your custom variable,
• Or clear error message saying that one can't use a variable named source, as it's a reserved name.