Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Epic] Standardize on provider-ci for all providers #1101

Open
5 tasks
mjeffryes opened this issue Oct 12, 2024 · 4 comments
Open
5 tasks

[Epic] Standardize on provider-ci for all providers #1101

mjeffryes opened this issue Oct 12, 2024 · 4 comments
Assignees
Labels
kind/epic Large new features or investments

Comments

@mjeffryes
Copy link
Member

mjeffryes commented Oct 12, 2024

Overview

Only bridged providers benefit from the consistency and automatic rollout of workflows generated from provider-ci today. This creates a lot of work when we have to make a change to all providers. Native provider ci also helps automate changes for some non-bridged providers but has also varied in structure to provider-ci. We'd like to drive greater consistency for across the whole fleet for things like package publish to gain the benefits of investment here across the whole fleet.

Key KPIs

  • Number of implementations required to roll out a publishing change to all providers.
  • Number of duplicate implementations where behaviour is the same.

Key Stakeholders

  • Provider team
  • Community provider authors

Key Deliverables

  • New provider-ci templates for EKS, AWSx and API Gateway
  • Integrate provider-ci into boilerplates
  • Migrate native-provider-ci into provider-ci
  • Minimise duplication & fragmentation

References 📔

@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Oct 12, 2024
@guineveresaenger guineveresaenger removed the needs-triage Needs attention from the triage team label Oct 14, 2024
@t0yv0
Copy link
Member

t0yv0 commented Oct 15, 2024

Why does the title say Standardize on CI-mgmt for all providers and the overview says "Bridged providers currently display unusable or misleading results in pulumi preview." ?

@mjeffryes
Copy link
Member Author

Probably because I failed a copy-paste! thanks for the catch!

@mikhailshilkov mikhailshilkov added the kind/epic Large new features or investments label Oct 21, 2024
@danielrbradley
Copy link
Member

Looks like this probably supersedes:

Most of that issue is complete at this point. The only dangling issues are:

@danielrbradley danielrbradley changed the title [Epic] Standardize on CI-mgmt for all providers [Epic] Standardize on provider-ci for all providers Oct 30, 2024
@blampe
Copy link
Contributor

blampe commented Dec 13, 2024

This week we pulled most of the differences in the generic template into the bridged one #1140. In particular sharding and some workflow consolidation that makes subsequent changes easier.

We've also cleaned up a bunch of instances where providers had been using custom workflows:

In each case it's been relatively straightforward to translate the GH action into some additional test logic. This is not only simpler but it also moves us in a direction where things are more easily reproducible locally.

Remaining preTest steps seem to be mostly AWS login (easily handled in test_main.go) and make upstream (now handled automatically by make targets).

I think we're actually much closer to #936 now. There's still probably some need for the generic template, but there's definitely a path towards consolidating.

As a next step we need to rebase the generic template on top of all the recent work. We've onboarding the pulumiservice provider and can revisit EKS.

I'd also like to look into getting k8s onto it -- that has a number of exceptions (for example it spins up its own k8s cluster) which will need codifying, but I don't think it will be too bad.

github-merge-queue bot pushed a commit that referenced this issue Dec 20, 2024
)

In pulumi/pulumi-aws-native#1919 I want to run
an actual end-2-end test with `pulumitest` in AWS Native, which requires
AWS credentials. In understand that a larger consolidation may be coming
with #1101, but this change
would allow me to land my test ahead of that. Please let me know if
there is a better way of achieving the same outcome.
github-merge-queue bot pushed a commit that referenced this issue Dec 23, 2024
We have a problem right now where automated dependency upgrades can
change our generated code, and this causes tests to fail because we
expect no changes in CI.

The "right" way to do this is with a hermetic `make renovate` step which
can re-generate this code during the Renovate job, as @t0yv0 has started
doing for EKS (e.g. pulumi/pulumi-eks#1552). But
we don't have hermetic builds so we don't yet have an easy way to get
this to work across all providers.

This PR implements a suggestion from Daniel to help address the long
tail. Essentially right before we fail a build for containing SDK
changes, we will commit those changes and push them back to the PR --
_but only if it came from Renovate._ The build will still fail, but
tests will be re-tried against the updated SDK.

Renovate has already been configured to "ignore" updates from pulumi-bot
(pulumi/renovate-config@82931a6),
so if tests pass it will still automatically squash and merge.

Here's an example where I manually modified the SDK and the PR was
automatically corrected:


![image](https://github.com/user-attachments/assets/0f0f4912-5962-4cfc-b7b5-2e991334ea36)

Refs #1101
Refs #936
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/epic Large new features or investments
Projects
None yet
Development

No branches or pull requests

7 participants