Skip to content

Conversation

@pquentin
Copy link
Member

@pquentin pquentin commented May 27, 2024

This is a common problem, see #2555 and #2577 for recent examples. But not that common, and I tend to forget about it after a few months. Indeed, the current condition does not actually skip validation, and we don't want that anyway: we want to fail when we should have run validation but could not do it. And explain why we failed.

If the pull request was from an Elastic employee (95% of cases), then they can reopen it from a branch. If it was community-contributed, we need to do it for them (without closing the original pull request, thus preserving attribution when merging).

From a branch, the build was correctly triggered: https://github.com/elastic/elasticsearch-specification/actions/runs/9250931808/job/25445405796?pr=2580 (and failed as expected due to the extra file I have now removed).

Copy link
Member

@flobernd flobernd left a comment

Choose a reason for hiding this comment

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

LGTM!

In the future, we could use the pull_request_target trigger instead.

This requires a little bit of extra work as we would have to check-out the user branch, copy only the specification (*.ts) files to the base branch and run the checks from here.

PRs that change the compiler itself can not be checked this way for security reasons, but it should be really really rare for an outside collaborator to change the compiler code.


steps:
- name: Check pull request was opened from branch
if: ${{ github.event.pull_request.head.repo.full_name != 'elastic/elasticsearch-specification' }}
Copy link
Member

Choose a reason for hiding this comment

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

I think you can omit the template syntax here. Just the condition without ${{}} should be fine.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, done in fea078b

This reverts commit 14bcc30.
@pquentin
Copy link
Member Author

pquentin commented May 27, 2024

I confirmed in #2582 that we now get a failure with the right message. And that from branches, validations does run. Merging.

image

@pquentin pquentin merged commit 2019a8a into main May 27, 2024
@pquentin pquentin deleted the explicit-fail-from-forks branch May 27, 2024 11:55
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