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

Create a generic template #1132

Open
blampe opened this issue Nov 7, 2024 · 3 comments
Open

Create a generic template #1132

blampe opened this issue Nov 7, 2024 · 3 comments
Assignees
Labels
kind/engineering Work that is not visible to an external user
Milestone

Comments

@blampe
Copy link
Contributor

blampe commented Nov 7, 2024

We should create a new workflow template which does not assume anything about the underlying provider.

The contract between CI and the provider should be driven entirely by make targets. make is not necessarily the best task runner for this purpose, but it's the one we use most widely right now so we should start there.

As we build this template, keep in mind that it should eventually be able to work equally well with native providers, component providers, or bridged providers. However our initial goal is to use it with providers not currently managed by ci-mgmt.

We should use the existing bridged provider template as a starting point as this is already quite battle-tested.

Changes we should consider making to the bridged template:

  • We should not assume anything about an "upstream".
  • We should try to eliminate as many customization options as possible in conjunction with Allow make target customization #1131. Concretely, this means if a provider previously needed a separate action to perform e.g. some setup, we should instead try to do that as part of a make target override or we should do it inside the test itself. This is a good practice in general as it makes things easier to reproduce locally. Examples of options we likely don't need:
    • setupScript
    • docsCmd
    • preTests and extraTests
    • sshPrivateKey
  • We should consolidate test steps into a reusable action.
  • We should enable the lint action by default.
  • generate_coverage_data should be replaced by Codecov.
  • We should stop using gotestfmt.
  • We should stop sharding on language (Invert build tags to improve DX #676).
@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Nov 7, 2024
@guineveresaenger guineveresaenger removed the needs-triage Needs attention from the triage team label Nov 7, 2024
@mikhailshilkov mikhailshilkov added the kind/engineering Work that is not visible to an external user label Nov 18, 2024
@mjeffryes mjeffryes added this to the 0.114 milestone Dec 3, 2024
@mjeffryes mjeffryes assigned t0yv0 and unassigned blampe Jan 4, 2025
@t0yv0
Copy link
Member

t0yv0 commented Jan 14, 2025

generate_coverage_data should be replaced by Codecov: actually this will destroy our system of tracking the bridged example conversion data quality (what generate_coverage_data) does, and I do not think this is advisable as no equivalent exists in codecov.

@t0yv0
Copy link
Member

t0yv0 commented Jan 16, 2025

Couple more notes here. I think we should close this as won't fix in favor of onboarding the remaining providers onto a modified version of the bridged workflow, as done for awsx and continuing two api-gateway and eks. The bridge workflow automatically satisfies:

  • We should consolidate test steps into a reusable action.
  • We should stop using gotestfmt.
  • We should consolidate test steps into a reusable action.

In addition to this some work has been done to cover:

  • We should not assume anything about an "upstream".
  • We should stop sharding on language - there is now an option to do this for the bridged/generic template

Remainders, it appears these are more nice to have:

@t0yv0
Copy link
Member

t0yv0 commented Jan 16, 2025

On #1131 we decided with @danielrbradley not to go as written but introduce some simpler form of configuration-driven script entry point overrides. This seems good enough to support AWSX, and I am following up to remove all custom make commands from the repos that had them. Make in particular make --touch that we seem to be using is hard to reason about in presence of these customizations. I think the chosen approach will work well enough for now.

Not planning to do anything else here for this iteration.

@mjeffryes mjeffryes modified the milestones: 0.114, 0.115 Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/engineering Work that is not visible to an external user
Projects
None yet
Development

No branches or pull requests

6 participants