chore/dedicated-trigger-of-downstream-jobs

[jimid27]

• Relates: https://github.com/PrefectHQ/platform/issues/6336
• Needs: Chore/remove downstream trigger steps actions-release-ui-components#12
• Needs: Create action actions-trigger-downstream-npm-package-updates#1
• Needs: chore: Upgrade latest eslint-config package upon upstream eslint update  vue-compositions#411, chore: Upgrade latest eslint-config package upon upstream eslint update vue-charts#341, chore: Upgrade latest eslint-config package upon upstream eslint update prefect-design#1174, chore: Upgrade latest eslint-config package upon upstream eslint update graphs#479
• Triggers all relevant downstream npm update jobs upon release of this package

[collincchoy]

hey FYI @jimid27 , this repo/package is a bit weird compared to the others. For example, there is no build script in here so npm run build fails. it's basically just a config file that's version controlled.

Interestingly in terms of impact, this is probably at the tippy top of the our dependency chain tho so it actually is the most friction to bump everywhere and it isn't bumped often.

[jimid27]

hey FYI @jimid27 , this repo/package is a bit weird compared to the others. For example, there is no build script in here so npm run build fails. it's basically just a config file that's version controlled.

Interestingly in terms of impact, this is probably at the tippy top of the our dependency chain tho so it actually is the most friction to bump everywhere and it isn't bumped often.

Ah ok good intel! What does the "preferred" release strategy look like for this repo, if any?

[collincchoy]

I think the workflow used to just be a straight publish. There are definitely other upstream npm package dependencies here too so i'd guess like, setup node -> npm ci -> publish is fine.

i see that you're breaking out the upstream version bumps from the shared action which I imagine should make having a little custom gha workflow here easier? so we could just fallback to a previous version of the release workflow that's just a "basic checkout -> setup node -> install deps -> publish package" -> fan out trigger downstream version bumping jobs?

we could instead try to tweak the shared action to effectively skip the build step - i don't feel strongly on which direction to take but I'd imagine it just adds a weird, maybe-unnecessary layer of complexity into that action to be like "skip_build=true" 🤷 .

[jimid27]

I think the workflow used to just be a straight publish. There are definitely other upstream npm package dependencies here too so i'd guess like, setup node -> npm ci -> publish is fine.

i see that you're breaking out the upstream version bumps from the shared action which I imagine should make having a little custom gha workflow here easier? so we could just fallback to a previous version of the release workflow that's just a "basic checkout -> setup node -> install deps -> publish package" -> fan out trigger downstream version bumping jobs?

we could instead try to tweak the shared action to effectively skip the build step - i don't feel strongly on which direction to take but I'd imagine it just adds a weird, maybe-unnecessary layer of complexity into that action to be like "skip_build=true" 🤷 .

I think just adding a skip build input that defaults to false is the cleanest solution here! And we can just set it to true for eslint-config

[collincchoy]

Is this action at a point that we could plop in all of the other downstream packages (pretty much all of our npm packages use this) so

• prefect-design
• prefect-ui-library
• graphs
• vue-compositions

or do we also need separate secrets for each still?

(😅 - i'd like to cut a new version of this "soon". suuuuuper no rush tho. "soon" could be really whenever, but it'd be neat to test all of this out with the next version bump)

[jimid27]

We would need to create GH secrets still but I can get that done today/monday!

[collincchoy]

that would be dope!

will save me so many button clicks!!!