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

ci: update workflow fork conditions to allow run on copies #6783

Merged
merged 5 commits into from
Jul 9, 2024

Conversation

damiannolan
Copy link
Member

@damiannolan damiannolan commented Jul 8, 2024

Description

Updates E2E fork conditions to allow e2e-fork to also run on copies.

See: https://github.com/damiannolan/ibc-go-test/pull/9


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against the correct branch (see CONTRIBUTING.md).
  • Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
  • Code follows the module structure standards and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/).
  • Added relevant godoc comments.
  • Provide a conventional commit message to follow the repository standards.
  • Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
  • Re-reviewed Files changed in the GitHub PR explorer.
  • Review SonarCloud Report in the comment section below once CI passes.

@damiannolan
Copy link
Member Author

damiannolan commented Jul 8, 2024

This PR is a test. Don't merge!

edit: It looks like this may be good to go! 🚀

@damiannolan
Copy link
Member Author

It appears that updating the concurrency:group options have fixed a problem that @chatton and I were seeing in the repo linked in the description.

image

The changes in this repo allows the e2e-fork workflow to run on both forks and copies of the repository.

Specifically, if we're running on cosmos/ibc-go then we are running e2e.yaml. If we are running on forks e.g. some-orgs/ibc-go or some-user/ibc-go then we will run e2e-fork.yaml. Similarly if we are running on cosmos/ibc-go-private or any other mirror of this repository, we will run the e2e-fork workflows.

@damiannolan damiannolan changed the title ci(test): update workflow fork conditions to allow run on copies ci: update workflow fork conditions to allow run on copies Jul 8, 2024
cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}

jobs:
# dynamically build a matrix of test/test suite pairs to run
build-test-matrix:
if: ${{ github.event.pull_request.head.repo.fork || github.actor == 'dependabot[bot]' || github.event_name == 'workflow_dispatch' }}
if: ${{ github.repository != 'cosmos/ibc-go' || github.actor == 'dependabot[bot]' || github.event_name == 'workflow_dispatch' }}
Copy link
Contributor

Choose a reason for hiding this comment

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

fine with either but is this required? I'd assume checking if it is/isn't a fork was the most general option?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, pretty much! It's a cute solution I think. With Github forks, they can't be private, you don't have the ability to change the visibility.
image

So to use something like a "private fork", it is not treated as an actual fork, and more like importing a particular git history into a new repository.

Copy link
Contributor

Choose a reason for hiding this comment

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

to use something like a "private fork", it is not treated as an actual fork

quirky af. Makes sense to me, want to add a small comment there explaining it? Can see this as being something someone would change in future w/o knowing why it was there.

Copy link
Contributor

@DimitrisJim DimitrisJim left a comment

Choose a reason for hiding this comment

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

lgtm considering it runs just fine on your fork. thanks for looking into github shenanigans!

@@ -11,13 +11,13 @@ on:

# cancel workflows if a new one is triggered on the same branch.
concurrency:
group: ${{ github.ref }}
group: ${{ github.workflow }}-${{ github.ref }}
Copy link
Contributor

Choose a reason for hiding this comment

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

do we want to amend similar line in e2e-wasm?

Copy link
Contributor

@chatton chatton left a comment

Choose a reason for hiding this comment

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

LGTM! Solution is a bit hacky but I think is actually not too bad working within the restraints we have for the triggers.

@damiannolan damiannolan enabled auto-merge July 9, 2024 15:13
@damiannolan damiannolan added this pull request to the merge queue Jul 9, 2024
Merged via the queue into main with commit 604031f Jul 9, 2024
75 checks passed
@damiannolan damiannolan deleted the damian/cian/fork-workflow-conditions branch July 9, 2024 15:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants