Percy workflow selectivity improvements

[jmuzina]

Done

• Percy tests no longer run against draft PRs.
• Percy tests no longer run against PRs that don't modify examples files or scss files.
• The above can be circumvented by applying the Review: Percy needed label. All commits to PRs with the Percy review needed label will be tested.
  • Note that name of this label is not stored in code; rather we will use a Github Repo variable to define it in one place. It must match the name of a label on our repo that we want to use for requesting Percy testing. I have defined it as "Review: Percy needed".
• Some minor tweaks to the data passing between privileged/nonprivileged workflows to stop unnecessarily compressing the artifact twice.
• Some preparation work for WD-11227: we are now passing PR numbers into Percy builds, which should enable the Percy integration to create status checks on our PRs once that is set up by IS.
• The "Percy Prepare" workflow was made into a reusable workflow so that it can be called by both the labeling workflow and the on-push workflow without reusing code.

Closes WD-11405

QA

• Review comments & workflows on testing PR.
  • Note that in my fork, the Percy label is "Percy test requested" rather than "Review: Percy needed". Do not worry about this; the name of the label is fetched from a repo variable and in the Canonical repo it will listen for "Review: Percy needed".

Check if PR is ready for release

If this PR contains Vanilla SCSS code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention:
  • if CSS class names are not changed it can be bugfix relesase (x.x.X)
  • if CSS class names are changed/added/removed it should be minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) should be listed on the what's new page.

[webteam-app]

Demo

Jenkins

demos.haus

[bartaz]

The name of the workflow and job show up in the listing, it would be nice to make them a bit less detailed. We can keep details in comments in the files if needed.

[bartaz]

Small naming adjustments please.

[bartaz]

That's weird, I thought I commented on this already.

I meant for the workflow to be Percy [labeled], and for the job to be Prepare build, as now we still have a long and unnecessarily detailed "Copy changed files to GHA artifact" as status name on PR.

Suggested change

	name: "Percy [labeled] / Prepare build"
	name: "Percy [labeled]"

[jmuzina]

Ah I misunderstood your original comment and named the entire workflow that; this has been revised!

[pastelcyborg]

High-level comment: I tend to prefer when workflows/actions are divided into their own directories, as done here:

https://github.com/pastelcyborg/vanilla-web-scanner/tree/main/.github

The primary reason for this (atop the structure being a bit clearer) is that it prevents us from having multiple files in the repo called "action.yml," assuming we add other Actions in the future. Every file would then go in one of these two parent directories. Open to other thoughts, though.

[jmuzina]

Making that naming change to the workflows seems to have upset the workflow run trigger... investigating, standby

[jmuzina]

High-level comment: I tend to prefer when workflows/actions are divided into their own directories, as done here:

https://github.com/pastelcyborg/vanilla-web-scanner/tree/main/.github

The primary reason for this (atop the structure being a bit clearer) is that it prevents us from having multiple files in the repo called "action.yml," assuming we add other Actions in the future. Every file would then go in one of these two parent directories. Open to other thoughts, though.

@pastelcyborg
I like this approach. If I understood it correctly, I've made the change to this PR to implement it (moved percy-snapshot action into .github/actions)

[bartaz]

Is it a workflow, or an action?

It doesn't seem to be triggered via PR events, but reused in workflows as if it was an action, right?

[bartaz]

It would be good to have a comment on top what the workflow does, and when it's supposed to be triggered, to have a better understanding of the flow.

As now it's getting complicated with multiple conditional workflows.

[jmuzina]

@bartaz

Is it a workflow, or an action?

It is a reusable workflow.

It doesn't seem to be triggered via PR events, but reused in workflows as if it was an action, right?

Yes, it's triggered by the snapshot & label workflows - the workflow runs at job level whereas the action runs at the step level

[jmuzina]

It would be good to have a comment on top what the workflow does, and when it's supposed to be triggered, to have a better understanding of the flow.

As now it's getting complicated with multiple conditional workflows.

Agreed, I'll add a note to the workflow momentarily

[bartaz]

LGTM, let's see how that works in practice!