Skip to content
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

chore(ci): Set up a separate workflow for flaky tests #1922

Merged
merged 18 commits into from
Jan 8, 2024
Merged

Conversation

flub
Copy link
Contributor

@flub flub commented Dec 22, 2023

Description

This sets up a separate workflow which runs all tests, including flaky ones. It can be triggered by setting the "flaky-test" label on a PR, which will disable most of the normal CI workflow and instead run just the tests including flaky ones.

The flaky workflow can also be manually triggered on a specific branch.

Notes & open questions

  • The flaky workflow only runs the tests, none of the other jobs.
  • Cross-compiled jobs aren't even included. Maybe they should be but right now they don't run tests at all so is pointless.
  • On any labelling change for the PR the jobs in the workflows will be cancelled if they're still running. I don't think we generally label PRs so that's probably fine.
  • Flaky tests are going to be carnage for a while!
  • We have no notification for the cron job results yet. Not sure how to approach this. I'd be fine doing this later.
  • The workflow_dispatch version (aka manual trigger) is untested, I think we have to wait until it is merged to main to be able to test that?
  • The UI will now always show all jobs: the skipped flaky jobs on normal PRs and the missing normal jobs on flaky PRs. That's probably fine? A bit noisier though.
  • The set of "required jobs" has changed again and will need patching up in branch protection.

This implements the bulk of #1919

Change checklist

  • Self-review.
  • Documentation updates if relevant.
  • Tests if relevant.

flub added 3 commits December 22, 2023 11:34
This sets up a separate workflow which runs all tests, including flaky
ones.  It can be triggered by setting the "flaky" label on a PR, which
will disable the normal CI workflow as well.  It can also be manually
triggered on a branch.
flub added 3 commits December 22, 2023 11:46
because github UI does not make it obvious which workflow
you're looking at
They are on hosted runners anyway
@flub
Copy link
Contributor Author

flub commented Dec 22, 2023

@Arqu could you have an initial look at this and point out all silly things I did the hard way? I think this is remarkably close already.

If you have any ideas on notifications for the cron job I'd be happy as well.

@flub
Copy link
Contributor Author

flub commented Dec 22, 2023

Since the tests run in the flaky workflow are so similar to the tests in normal CI, maybe we should check if this is doable with a reusable-workflow instead? It could take inputs for the few differences (if conditions and test args).

@flub
Copy link
Contributor Author

flub commented Dec 22, 2023

I rather like this workflow_call version.

But now it opens the door to only having a single ci workflow instead of a separate flaky workflow.

Upsides:

  • There would only be one entry in the "Actions" list for workflows for a PR. Might be simpler?

Downsides:

  • The ci action would have a bunch of inputs with defaults. manually triggering could be a bit weird.
  • The ci action would be cancelled on every label change.

@flub flub removed the flaky-test label Dec 22, 2023
if only americans could spell labelled.

Without this when you remove the flaky-test label your PR is stuck in
a weird state until you push something again.  I think not having that
confusion trumps cancelling jobs on labelling changes.  Also, I don't
think we currently label PRs?
@flub flub marked this pull request as ready for review December 22, 2023 14:26
@flub flub requested a review from Arqu December 22, 2023 14:26
@Arqu
Copy link
Collaborator

Arqu commented Dec 22, 2023

Will take a look tonight.

.github/workflows/flaky.yaml Outdated Show resolved Hide resolved
@@ -0,0 +1,182 @@
# Run all tests, with or without flaky tests.

name: Tests
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice.

esac

- name: check features
if: ${{ ! inputs.flaky }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is inputs.xyz the correct syntax here. Afaik these should be subclassed to github.event.inputs or github.inputs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I used to think it was always scoped to the github context.

env:
RUST_LOG: "TRACE"
tests:
if: "! contains(github.event.pull_request.labels.*.name, 'flaky-test')"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will fail outside of a PR context as the github.event.pull_request object will be null.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

made it so they always run outside of PR context

@@ -2,6 +2,7 @@ name: CI

on:
pull_request:
types: [ 'labeled', 'opened', 'synchronize', 'reopened' ]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice idea to use labels to control flow. We could do a no-netsim flag to skip netsim for in progress PRs later.

@flub flub added the flaky-test label Jan 5, 2024
@flub
Copy link
Contributor Author

flub commented Jan 5, 2024

@Arqu PTAL, thanks for the suggestions

@Arqu
Copy link
Collaborator

Arqu commented Jan 5, 2024

LGTM now. I guess we need to rebase this and then align branch protections.

@flub flub added flaky-test and removed flaky-test labels Jan 5, 2024
@flub flub removed the flaky-test label Jan 5, 2024
@flub flub added flaky-test and removed flaky-test labels Jan 5, 2024
@flub
Copy link
Contributor Author

flub commented Jan 5, 2024

@Arqu merged master (and fixed another bug...)

should be good to merge and adjust the branch protections

@flub
Copy link
Contributor Author

flub commented Jan 5, 2024

I've also made /~https://github.com/n0-computer/iroh/wiki/Flaky-Tests as a reference for how this is to be used.

@Arqu Arqu merged commit 940b78d into main Jan 8, 2024
27 checks passed
@Arqu Arqu deleted the flub/flaky-ci branch January 8, 2024 11:32
fubuloubu pushed a commit to ApeWorX/iroh that referenced this pull request Feb 21, 2024
## Description

This sets up a separate workflow which runs all tests, including flaky
ones. It can be triggered by setting the "flaky-test" label on a PR,
which will disable most of the normal CI workflow and instead run just
the tests including flaky ones.

The flaky workflow can also be manually triggered on a specific branch.

## Notes & open questions

- The flaky workflow only runs the tests, none of the other jobs.
- Cross-compiled jobs aren't even included. Maybe they should be but
right now they don't run tests at all so is pointless.
- On any labelling change for the PR the jobs in the workflows will be
cancelled if they're still running. I don't think we generally label PRs
so that's probably fine.
- Flaky tests are going to be carnage for a while!
- We have no notification for the cron job results yet. Not sure how to
approach this. I'd be fine doing this later.
- The `workflow_dispatch` version (aka manual trigger) is untested, I
think we have to wait until it is merged to main to be able to test
that?
- The UI will now always show all jobs: the skipped flaky jobs on normal
PRs and the missing normal jobs on flaky PRs. That's probably fine? A
bit noisier though.
- The set of "required jobs" has changed again and will need patching up
in branch protection.

This implements the bulk of
n0-computer#1919

## Change checklist

- [x] Self-review.
- [x] Documentation updates if relevant.
- [x] Tests if relevant.

---------

Co-authored-by: Asmir Avdicevic <asmir.avdicevic64@gmail.com>
matheus23 pushed a commit that referenced this pull request Nov 14, 2024
## Description

This sets up a separate workflow which runs all tests, including flaky
ones. It can be triggered by setting the "flaky-test" label on a PR,
which will disable most of the normal CI workflow and instead run just
the tests including flaky ones.

The flaky workflow can also be manually triggered on a specific branch.

## Notes & open questions

- The flaky workflow only runs the tests, none of the other jobs.
- Cross-compiled jobs aren't even included. Maybe they should be but
right now they don't run tests at all so is pointless.
- On any labelling change for the PR the jobs in the workflows will be
cancelled if they're still running. I don't think we generally label PRs
so that's probably fine.
- Flaky tests are going to be carnage for a while!
- We have no notification for the cron job results yet. Not sure how to
approach this. I'd be fine doing this later.
- The `workflow_dispatch` version (aka manual trigger) is untested, I
think we have to wait until it is merged to main to be able to test
that?
- The UI will now always show all jobs: the skipped flaky jobs on normal
PRs and the missing normal jobs on flaky PRs. That's probably fine? A
bit noisier though.
- The set of "required jobs" has changed again and will need patching up
in branch protection.

This implements the bulk of
#1919

## Change checklist

- [x] Self-review.
- [x] Documentation updates if relevant.
- [x] Tests if relevant.

---------

Co-authored-by: Asmir Avdicevic <asmir.avdicevic64@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants