ci: initial sync with canonical/copilot-collections

[mr-cal]

Initial sync with canonical/copilot-collections.

Also adds a CI job from copilot-collections that runs once a week, checks for new releases, and creates a PR if there's been an update.

The .github/skills/ and .github/instructions/ are generated by copilot-collections. Feel free to read through them, but the contents shouldn't be modified here.

Q & A

Why Snapcraft?

Snapcraft is a good proving ground because it gets a fair amount of activity and I review most PRs.

Can I use these instructions locally?

Yes. For Copilot CLI, they're loaded automatically for Snapcraft.

If you want them to work for other projects, then ensure your local copy of Snapcraft has these instructions and run export COPILOT_CUSTOM_INSTRUCTIONS_DIRS=<path-to-snapcraft>.

/instructions in copilot CLI will show you what's been loaded.

Will we add this to all our repos?

Likely, depending on how this trial goes.

Does it improve the reviews?

I think so, but you can judge that yourself. Here's the same doc change with and without the instructions.

Copilot reviews on GH are a bit annoying because they only leave so many comments per review, so you have to do many iterations. They aren't that deterministic either.

Here are a few comments that are based on the custom instructions

---

• I've followed the contribution guidelines.
• I've signed the CLA.
• I've successfully run make lint && make test.
• I've added or updated any relevant documentation.
• In documents I changed, I added a meta description if one was missing.
• I've updated the relevant release notes.

[mr-cal]

I cheated a teeny bit and updated this applyTo manually before my upstream update landed 🤫

[medubelko]

As a heads-up, this will become obsolete by next week at the latest. I'll be updating it once the new standard is approved in the doc team and I get the skill working decently.

[mr-cal]

Instructions and skills serve different purposes, so a meta skill shouldn't make the meta instruction obsolete. The skill is used when invoking an agent to do explicitly do something, but the instruction is used as context when reviewing a PR.

[bepri]

Nice, looks good. One question -- how do I update these when I make an upstream change in the collections repo? Do I just run a script? Does the new workflow added here constantly keep us living on the edge, as it were?

[mr-cal]

how do I update these when I make an upstream change in the collections repo?

You land your upstream changes, ask for a new release, then run the workflow_dispatch on the new job. Or wait for the next Monday for the CI job to grab the release.

Do I just run a script?

If you wanted to update it yourself, bump the tag in .github/copilot-collections.yaml and run this in the snapcraft repo.

Does the new workflow added here constantly keep us living on the edge, as it were?

The workflow keeps us on the latest tagged release by updating this. So not quite "on the edge", but probably pretty close since I imagine updates will be frequent.

I'm not sure how this will play out if we have a weekly update in every repo. Probably like the renovate PRs to bump ruff in pre-commit.yaml (slightly annoying). I may drop it to a monthly update.

[bepri]

Thanks for the in-depth answer! That all sounds good to me.

[medubelko]

@mr-cal With the addition of all these files, will we want the full test suite running on any changes to the contents of .github? The workflow filter I'm adding this week disables the full suite when only .md files are changed.

[mr-cal]

@medubelko, I think that behavior is fine, we don't need to re-run the full suite when these files change.