Combine upstream check & upgrade workflows #1110
Conversation
danielrbradley
force-pushed
the
combine-upstream-workflows
branch
from
b3708ec to
17ebab6
Compare
|
Attempting to test this on the xyz provider: https://github.com/pulumi/pulumi-xyz/actions/runs/11556612896/job/32164701827 This fails due to the upstream provider having no published stable versions. |
Remove the chain of dependencies where we create issues then trigger the actual upgrade from the issue creation. We previously had to filter the triggered issue opening to a specific bot user to stop other issues created by external users from triggering the workflow. Instead, we'll check for new versions then attempt the upgrade in a single run, as well as allowing the execution of a specific version upgrade via workflow_dispatch. Scenarios: - If the cron triggers or a user runs the workflow without a version, it'll ensure an issue exists for the latest pending version and return the latest pending version in the `latest_version` output. - If `latest_version` is unset then we don't need to run the upgrade as there's no pending version. - If `latest_version` is set then we'll specifically attempt an upgrade to that version. - If a user runs the workflow with a version input, we'll skip creating issues and just attempt the upgrade. This builds on the work in pulumi/upgrade-provider#282
danielrbradley
force-pushed
the
combine-upstream-workflows
branch
from
983fec9 to
52deb35
Compare
There was a problem hiding this comment.
Looks sensible. Can we test the workflow where there is an upstream provider upgrade available somewhere? Ideally we should make sure not to miss any of the upgrade issues as they are essential for visibility, reporting etc.
To make sure i understand the change - the upstream upgrade no longer depend on the upgrade issue, is that correct? Instead the upgrade issue is now purely informational but is still opened if the workflow is run via a cron job, right?
Was testing this on OCI but Ian was too speedy getting the release done. It was looking mostly fine though having fixed up one bug in upgrade-provider.
Yup - any time the workflow is run without an explicit version input (including when run on a cron) it will open any required issues, then attempt to upgrade to the latest version. |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
provider-ci/internal/pkg/templates/bridged-provider/.github/workflows/upgrade-provider.yml
Outdated
Show resolved
Hide resolved
Co-authored-by: Ian Wahbe <[email protected]>
danielrbradley
force-pushed
the
combine-upstream-workflows
branch
from
90812c5 to
f88d7a8
Compare
This flag controls whether we generate the upgrade-provider Workflow. Some providers cannot currently be upgraded automatically, either because they are archived upstream, or because their licensing conflicts with ours. Followup for some logic that was lost in #1110.
This flag controls whether we generate the upgrade-provider Workflow. Some providers cannot currently be upgraded automatically, either because they are archived upstream, or because their licensing conflicts with ours. Followup for some logic that was lost in #1110.
Remove the chain of dependencies where we create issues then trigger the actual upgrade from the issue creation. We previously had to filter the triggered issue opening to a specific bot user to stop other issues created by external users from triggering the workflow.
Instead, we'll check for new versions then attempt the upgrade in a single run, as well as allowing the execution of a specific version upgrade via workflow_dispatch.
Scenarios:
latest_versionoutput.latest_versionis unset then we don't need to run the upgrade as there's no pending version.latest_versionis set then we'll specifically attempt an upgrade to that version.This builds on the work in pulumi/upgrade-provider#282
Fixes #1108
Example run with no new changes: https://github.com/pulumi/pulumi-azure/actions/runs/11608904415/job/32325098437