70d1794916
* Automate setup-go-work as a dependency for Make targets (#35476) * automate setup-go-work It's all to easy to forget to `make setup-go-work`, only to run into mysterious build failures. Let's default to doing this automatically, unless `SKIP_SETUP_GO_WORK` is true (or the legacy `IGNORE_GO_WORK_IF_EXISTS`, which was oddly named, since we can't actually ignore it.) * Make setup-go-work recipe fail-fast with set -e * ci: post success to required e2e status contexts when no relevant changes (#35880) * ci: post correct skip status from within cypress/playwright reusable workflows The 'Required Status Checks' ruleset requires e2e-test/cypress-full/enterprise and e2e-test/playwright-full/enterprise on master and release-*.* branches. When a PR has no E2E-relevant changes, the jobs were silently skipped, leaving required statuses unset and the PR permanently blocked. Architecture fix: instead of a separate skip-e2e job in the caller that hardcodes status context names, the skip logic now lives inside the reusable workflows that already own and compute those context names. Changes: - e2e-tests-cypress.yml: add should_run input (default 'true') + skip job that uses the dynamically-computed context_name when should_run == 'false' - e2e-tests-playwright.yml: same pattern - e2e-tests-ci.yml: change e2e-cypress/e2e-playwright job conditions from should_run == 'true' to PR_NUMBER != '' (always run when there's a PR), pass should_run as input to both reusable workflows * Add E2E template workflows for Cypress and Playwright * Add check-e2e-test-only action for E2E workflow * Fix: Remove circular E2E workflow file check - skip tests when only CI files change * Add pull_request trigger to E2E workflow - run automatically on PR events * Fix resolve-pr to use github.event context for automatic pull_request trigger * Fix checkout condition to work with pull_request events * Fix: Remove orphaned fi statement in check-changes script --------- Co-authored-by: yasser khan <attitude3cena.yf@gmail.com>
Background
This document aims to explain the bunch of server and webapp yaml files and their functionality.
The context behind this complexity is that we want new pushes to PR branches to cancel older in-progress and pending CI runs, but we don't want that to happen in master branch. Unfortunately, there is no config knob to control pending workflows and if you set a concurrency group, then pending workflows will always be canceled. Refer to https://github.com/orgs/community/discussions/5435 for discussion.
Therefore, we have a template yaml file which is actually the main CI code. That is then imported by {server|webapp}-ci-master.yml and {server|webapp}-ci-pr.yml. The -master.yml files don't have any concurrency limits, but -pr.yml files do.
Folder structure
server-ci-pr | ---server-ci-template | ---server-test-template (common code for postgres and mysql tests)
server-ci-master | ---server-ci-template | ---server-test-template (common code for postgres and mysql tests)
webapp-ci-pr | ---webapp-ci-template
webapp-ci-master | ---webapp-ci-template