Hide/Group jobs in the status checks list

[donnacello]

Hi, we have cypress tests running end-to-end tests in parallel and it can be quite a lengthy list. Is there a way to hide these jobs or group them so the PR status check list doesn’t get too populated?

image860×322 42.2 KB

Below is a snippet of the workflow from cypress github action

name: Parallel Cypress Tests
on: [push]
jobs:
  test:
    name: Cypress run
    runs-on: ubuntu-16.04
    strategy:
      fail-fast: false
      matrix:
        # run 3 copies of the current job in parallel
        containers: [1, 2, 3]
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Cypress run
        uses: cypress-io/github-action@v2
        with:
          record: true
          parallel: true
          group: 'Actions example'

[mickeygousset]

Not that I can think of. Each job is going to show up as a check on the PR. You can click the “Hide All Checks” link to collapse it down, but that is about the best I can think of.

[leonard-henriquez]

Do you have any update on this topic? 🙂

[mickeygousset]

At this point I still don't see anything on the public roadmap for it.

[donnacello]

Thanks so much for your quick response!
Just curious: would this be something that could be easily supported? I imagine a lot of projects may have several jobs triggered per PR.

[mickeygousset]

I’m not sure how easily supported it would be, but my bigger question is why would you not want to see all the checks that apply to your PR? Are you asking to just have that area collapsed by default? Or for something else?

If I said “how would you like to see this feature implemented”, what would you tell me?

[basickarl]

An example I have is that I'm using dorny/paths-filter@v2, this just checks to see if files in specific directories have been altered, it's more of a utility job for the actual test jobs. This specific utility job is not prone to fail, ever, so I would also like to hide it or at least have it somewhere more out of view.

Example:

jobs:
  changes:
    name: Detect file changes
    runs-on: ubuntu-latest
    outputs:
      packages: ${{ steps.filter.outputs.packages }}
    steps:
    - uses: dorny/paths-filter@v2
      id: filter
      with:
        filters: |
          packages:
            - 'packages/**'

[jamesdh]

Same exact use-case here. This is a job whose sole purpose is to determine if some other jobs should be run. It never fails, and just creates noise by including it in the Progress Checks list.

[bsgrigorov]

same here

[donnacello]

why would you not want to see all the checks that apply to your PR?

In my team’s case, we have several parallelised tests that are all in the same group of tests (end-to-end tests). In that same group of tests, there is a separate job that runs before all the tests and it verifies if a review environment (created on each pr) is successfully deployed —otherwise the tests will not run. Not all of these necessarily need to show as they are all part of the end-to-end tests.

Are you asking to just have that area collapsed by default? Or for something else?

Collapsed by default actually sounds like a good idea!
If you look at what we see here (screenshot below), there are only 5 main “checks” we want to keep track of: unit tests, security tests, end-to-end tests, codeclimate, and review environment creation. However, because of the parallel tests you would not be able to see everything at a quick glance.

image861×317 40.5 KB

If I said “how would you like to see this feature implemented”, what would you tell me?

On top of your idea of some collapsible element, grouping/collapsing all related jobs into its workflow would be awesome. Maybe it’s something we can specify in the workflow file? (probably not a good solution but just want to throw some ideas in 😁 )

name: E2E Tests
on: [pull_request]
pr_check_view: collapsed  <--- [collapsed, hidden, display_all_jobs]
jobs: [...]

[mickeygousset]

This is good feedback. I’ll post it internally and maybe it will bubble up to the backlog.

[ATOM594]

Hi @mickeygousset 👋

How did it go?

[donnacello]

hi @mickeygousset , are you able to post any update here please? thank you!

[michaelhays]

Adding on that an option to group or even hide status checks for a given job would be extremely useful. We also run our Cypress end-to-end tests in parallel, so that they’re split across 8 machines:

image922×459 49.3 KB

GitHub automatically creates a new status check for each machine, but we’re really only interested in seeing whether all of the tests passed or failed. In our case, we have a status check set up directly with Cypress that links to the Cypress dashboard (that’s the “cypress: default-group — 2 tests failed” in the image), so the 8 checks created by that job aren’t useful to us.

I’d love to be able to hide (or group) these, e.g.:

jobs:
  e2e:
    name: Cypress end-to-end tests
    runs-on: ubuntu-latest
    checks: none  # or group, or all (default)
    ...

[ggbecker]

This is definitely something Github should look into it.

[chasemgray]

We have 80 parallel machines running, so showing each one in the github checks makes it very hard to use.

[tinu-doit-intl]

@mickeygousset any plans to add this feature? We are also facing the same issue when we run the e2e cypress tests in parallel.

[LeviPesin]

Would be great to see this implemented.

[rene-leanix]

Here's a quick & dirty bookmarklet to toggle successful or skipped checks in the list:

javascript:[...document.querySelectorAll('.merge-status-list .merge-status-item')].filter(el => el.querySelector('.octicon-check, .octicon-skip')).forEach(el => el.hidden = !el.hidden)

This may stop working anytime GitHub changes the layout or the CSS classes of that part of their app.

We're working in a mono-repo with 110 checks, so it's extremely frustrating having to scroll and look for the one failed check all the time. Time for this feature to get implemented, @github-staff!

[ui-kane-lin]

hi, rene. How to use this script?

[jamesdh]

We really need this. Any developer/team that readily takes advantage of GitHub Actions will encounter this problem eventually. The need for it is only going to grow.

[laeubi]

https://github.com/EnricoMi/publish-unit-test-result-action#support-fork-repositories-and-dependabot-branches requires to upload the event file, of course this is nothing we want/need to show to the user and is just confusing. So a simple flag on the job
show_status: true/false would be fine.

For Matrix jobs in general, it would be great if only one item is shown for all matrix elements and the can be expanded if needed e.g. lets say I have a Workflow name "Run Buld" with a matrix of jobs "java 8", "java 11", "java 17"

The Github could show one check ("Run Buld") that simply aggregates the status of all childs ("java 8", "java 11", "java 17"), and there is an icon to expand the childs (or one actually can just jump to the job itself)

[s0undt3ch]

We're also interested in something, preferably, grouping...

[magus424]

I'd also like a way to do this. I have a shared step in some workflows that just builds some values for use in later steps, so it isn't really a "check" on the PR. If one could set something like is_check: false or similar it would be handy.

[a8trejo]

At the very least for matrix strategies this should be an option, since they are the same job, 2024 and still waiting for this 🥲.

[scottwithbanner]

Same problem for my team — cypress run across a matrix job leaves us with 200+ checks in the PR. Would love to have an option to consolidate all the jobs from a workflow into a single check on the PR

[simplypixi]

Same issue here. Some jobs can be just utils jobs, so showing their result as an extra check is redundant.

[KevinMind]

Same issue. I agree that the basic use case is to ensure that jobs which run a matrix strategy should only display a single check in the checklist UI. You already have a component for it in showing the progress of a task list for an issue. This circle progress indicator would be perfect.

Next level UX would be to be able to expand the list if you wanted to see individual child jobs.. definitely not a need to have.

The details link can just link to the first job as you end up seeing all the jobs in the side bar anyway.

Who at github wants to give me a codespace to github's webapp and I can ship this in a week?

[BevanR]

This is probably our biggest pain-point with GHA. On one project we actually use a workflow_run trigger instead of a push trigger just to avoid the commit statuses of our Cypress parallel test workers showing up. The workflow has to jump through a lot of hoops to make that work. Grouping or omitting them would be so much easier.

1. They all have the same name format; "Cypress worker (1)" etc, so it wouldn't even need any config in GH; Just a check for jobs whose name starts with the same first ~10 chars would do.
2. Grouping matrix workers would also be fine; better perhaps.
3. Another simple solution would be a flag on the job in the workflow to indicate that the job status does not affect the commit status, and therefore omit it from the default view and commit status.

🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏 🙏

[bxt]

An alternative would be to show the failing matrix jobs on top, like it is done with normal status checks. I would love to see something implemented, as this means a lot of manual workflow calling instead of relying on the build-in functionality.

[ryan-mcginty-alation]

Would really love to see this feature as well

[rrlamichhane]

let's make this happen please

[solvingj]

@mickeygousset and/or @donnacello would you please consider marking this question as un-answered so that it is more easily found, and can be treated as an active request for a major new feature. All the context is here, evidence of people with the same problem needing the same features.

[lkfortuna]

Hi there from Actions team- there is a ship coming near the end of september from the Pull requests team for a new merge box that groups jobs together by status. Please stay tuned!

[solvingj]

That sounds like it would improve the situation a bit for some teams, and I'm glad to hear development is actually occurring.

However, this won't help unblock my team at all, and I suspect that's true for many others.

Can you try to suggest to that team that they read feedback left here in this thread, so the feature might be extended/improved further after this upcoming release? And maybe let us know if they say they will read posts here?

Specific request from our team:

1. For matrix builds and github checks

• make "group-github-checks-by" a configurable field
• the "group by status" sounds sensible for some teams
• we want to group our matrix builds by "job name", which also seems sensible
• i can imagine other ways people would want to group checks

2. Make Hide skipped checks a dedicated option

• Regardless of anything else, users will continue to request and ask for hiding skipped checks
• This applies to both checks skipped with "if" and with "on.push.paths"
• Whatever it takes, make it a workflow or job level checkbox so that these can be hidden from github checks

3. Other closely-related Github discussion

• This one is for sure similar https://github.com/orgs/community/discussions/4324
• Any development around Matrix builds and github checks should really be considering all related requests together
• https://github.com/orgs/community/discussions?discussions_q=is%3Aopen+matrix

[essen]

Looking forward to this update. We have close to 400 jobs, mostly due to heavy parallelization of tests. In general we don't care about successful jobs, we only care about the failed ones. But having the list of failed tests be grouped under their top-level job would be a plus for clarity.

A convenient link to the workflow(s) summary page would be enough to get more details if we need to check successful jobs as well.

[michaelhays]

Any update on that ship @lkfortuna?

[anikettt2499]

It would be a nice addition. Any updates?

[jandrade]

Do you have any updates on this release? this would be really helpful for similar reasons like the Cypress case described in this discussion.

[pgodinhofortis]

You can implement this in different ways:

• A call to GitHub API to delete the check
• A setting on the job for it not to be added as a check

I wish this was looked into with more care, it really bothers us when there are many checks.

[BevanR]

Which is the setting on the job that prevents it being added as a check?

[pgodinhofortis]

It doesn't exist 😢 I am suggesting simple ways this could be rolled out.

It is probably a week worth of work but will take years for the actions team to do it.

[BevanR]

Ah! I thought you were suggesting workarounds

[nickgovea]

Adding to this thread to keep it alive... Would love to see a feature for this implemented. Like some folks, we have Cypress tests that run across multiple machines, it would make more sense to show one parent job for matrix jobs in the Checks section rather than bloating it up with all the parallel jobs as there can be many.

[liambutler]

Doesn't just affect Cypress tests; I'm also seeing this repetitive job output with sharded Jest and Playwright tests. Commenting in the hope that more folks find this thread.

[ui-kane-lin]

We need this!