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

Prepare provider-ci for non-bridged providers #936

Open
danielrbradley opened this issue May 24, 2024 · 0 comments
Open

Prepare provider-ci for non-bridged providers #936

danielrbradley opened this issue May 24, 2024 · 0 comments
Assignees
Labels
kind/engineering Work that is not visible to an external user

Comments

@danielrbradley
Copy link
Member

danielrbradley commented May 24, 2024

Long term aims

  • Remove duplication of provider-ci and native-provider-ci
  • Reduce the cost & risk of changing CI.
  • Resolve fragmentation of CI & makefile features.

Refactoring goals

  • Re-use specific parts of the bridged-provider template.
  • Make templates composable - so bridged-provider or go-provider can be composed of smaller templates.

Clean-up

We can use github search to investigate which parts of the configuration actually get used: https://github.com/search?q=org%3Apulumi+path%3A.ci-mgmt.yaml&type=code

Simplify configuration

Remove default env configuration. Put the common keys into a splice instead of in the default config.

Remove tool versions from env

We're generating all the files ourselves, so there's no reason to push the version into the env just to be read out when installing each tool. We can just put the version numbers directly into step template.

Remove setupPulumi and setupGo actions from config

Turn these into splices as they shouldn't be customisable via config - only their desired version should be configuration.

The .actions section shouldonly be used for preBuild and preTest.

Make it simpler to run the provider-ci binary directly

Make the 4 required arguments to provider-ci optional:

  1. --config - default to .ci-mgmt.yaml.
  2. --out - default to the current directory ('.')
  3. --name - default to the config .provider field.
  4. --template - add template to the config file

This avoids the need to generate a makefile template to make it easier to run the tool to pull templates:

- go run github.com/pulumi/ci-mgmt/provider-ci@master generate \
-		--name pulumi/pulumi-$(PACK) \
-		--out . \
-		--template bridged-provider \
-		--config $<
+ go run github.com/pulumi/ci-mgmt/provider-ci@master generate

This requires unbundling the config parsing from the generate method so we can parse the config before calling generate.

Composable templates

Implement the top-level "template" names as a simple switch statement. Each of these just calls into the GeneratePackage method for each sub-template it wants to include. The unbundling of the config parsing in the previous step will make this easier.

Note: When splices are collected, their relative path doesn't matter - only their filename, but we don't fail on duplicate names.

Default Config

We should change the original design from having a default config per template to a single global default config. This is because:

  1. The config should be a minimal collection of possible keys.
  2. The config keys needs to not clash between different sub-templates.

Sub-templates

Initially, the bridged-workflow template can be split up into the following parts each containing the listed files:

  • config: .gitattributes & .golangci.yml
  • devcontainer: devbox.* & .devcontainer/**
  • bridged-build: Makefile, goreleaser.*, scripts/*
  • bridged-workflows: .github/**

From this point, we should be able to generalise more of the bridged-workflows to be usable by other providers and moved into a general workflows template, while we also introduce new templates and sub-templates for native-workflows and go-provider-workflows and component-workflows where needed.

@danielrbradley danielrbradley added the kind/engineering Work that is not visible to an external user label May 24, 2024
@danielrbradley danielrbradley self-assigned this May 24, 2024
danielrbradley added a commit that referenced this issue May 29, 2024
Related to #936 - this is a
pre-cursor to building out composable templates.

## Unbundle the config parsing from the generate method

We need to parse the config before calling generate.

## Make it simpler to run the provider-ci binary directly

Make the 4 required arguments to `provider-ci` optional:

```
Usage:
  provider-ci generate [flags]

Flags:
  -c, --config string     local config file to use (default ".ci-mgmt.yaml")
  -h, --help              help for generate
  -n, --name string       repository name to generate (default "{config.repository}" or otherwise "pulumi/pulumi-{config.provider}")
  -o, --out string        directory to write generate files to (default ".")
  -t, --template string   template name to generate (default "{config.template}" or otherwise "bridged-provider")
```

This avoids the need to generate a makefile template to make it easier
to run the tool to pull templates:

```diff
- go run github.com/pulumi/ci-mgmt/provider-ci@master generate \
-		--name pulumi/pulumi-$(PACK) \
-		--out . \
-		--template bridged-provider \
-		--config $<
+ go run github.com/pulumi/ci-mgmt/provider-ci@master generate
```

Existing providers have all the required information available except
for the `template` field.
danielrbradley added a commit that referenced this issue Jun 5, 2024
See commits for impact of individual changes.

Part of #936 - attempting to
simplify our shared config ahead of onboarding native providers with the
same shared config but different templates.

## Remove `actions.setupGo` and `actions.setupPulumi` from the default
config

These are never overridden by providers, we were only using the config
file for templating. This makes these two actions match with how we
write all the other `setupX` actions - inline, with config variables for
the action version and tool version.

This helps reduce the number of possible configuration variations we
need to consider when making changes.

## Remove tool versions from ENV

We only set them as ENV vars to be able to access them as variables in
the GH action script. Now we're templating everything, we can just set
these values inline to remove a layer of indirection and reduce the
number of global mutable variables which can be hard to trace how
they're used.

## Remove PROVIDER env

Similar to the tool versions above, this was only used in the templates,
not as actual ENV vars. In addition, this is confusing because the
makefile also has a variable called PROVIDER which shadows this ENV var,
but contains the name of the provider binary. There's no other obvious
references to this ENV variable.

## Remove TRAVIS_OS_NAME env

This was previously used by the [pulumi/scripts publish-tfgen-package
script](https://github.com/pulumi/scripts/blob/9aeffd86afa793846dc4f001a6f374b3f135bfef/ci/publish-tfgen-package#L29)

We now use the https://github.com/pulumi/pulumi-package-publisher action
which does not require this variable to be set.
danielrbradley added a commit that referenced this issue Jun 11, 2024
Part of #936 

- Reduce duplication in rendered workflows.
- Splices are not composable (can't call one splice from another) so
don't form good building blocks.

---------

Co-authored-by: Ian Wahbe <ian@wahbe.com>
danielrbradley added a commit that referenced this issue Jun 24, 2024
Separate the concept of a template package from the template directories
it's going to render.

A template is formed of one or more directories. Each template directory
be rendered into the same output directory.

This forms part of #936 where we
want to be able to share some parts of the current bridged provider
template with non-bridged provider repos.
danielrbradley added a commit that referenced this issue Jun 24, 2024
Part of #936

Extract more generally re-usable parts of the bridged-provider template
for use independently.

Available templates:
- `provider`: the main template for any provider repository
- `bridged-provider`: a template for a provider repository that uses
tf-bridge & follows the boilerplate structure.
- `dev-container`: a dev-container setup for any pulumi related project.
@mjeffryes mjeffryes modified the milestones: 0.108, 0.107 Jul 24, 2024
danielrbradley added a commit that referenced this issue Jul 24, 2024
This will allow us to remove all of our `preTest` hooks in provider
ci-mgmt configs - which we'd like to get rid of to avoid arbitary code
injection into workflows which make them fragile and hard to refactor.
See also #1037

Related to #936

## Add standalone option for running provider integration tests

Set `integrationTestProvider: true` to run `go test [...] -tags=${{
matrix.language }}` in the `provider` directory.

Example of existing preTest usage:
https://github.com/pulumi/pulumi-gcp/blob/92b64b51bfb05fc0d2d7b9c1cbcafe7de8a6f7f3/.ci-mgmt.yaml#L43

### Always prepare upstream before testing

This step is safe to run, as we already do before the Go build steps
elsewhere. The upstream target is always there but might be a no-op.

## Add SSH setup option

Set `sshPrivateKey: ${{ secrets.PRIVATE_SSH_KEY_FOR_DIGITALOCEAN }}` to
set up SSH for testing.

Example of docker use of preTest:
https://github.com/pulumi/pulumi-docker/blob/fc1d68f823c34cef72e34e060b093230e21fc636/.ci-mgmt.yaml#L35

# Migration

1. Merge this PR with intent-focused config options
2. Open PRs to the ~28 providers to replace the `preTest` hook with
alternative settings
- Set `integrationTestProvider: true` on all providers which run
integration tests via the provider module
   - Use `setup-script` for arbitrary bash commands before tests 
- Set `sshPrivateKey: ${{ secrets.PRIVATE_SSH_KEY_FOR_DIGITALOCEAN }}`
for docker
4. Remove the `actions` config completely

Existing usage of `actions` hooks (there is no use of `preBuild` - only
`preTest`):
https://github.com/search?q=org%3Apulumi+path%3A.ci-mgmt.yaml+%22actions%3A%22&type=code
@mjeffryes mjeffryes modified the milestones: 0.108, 0.109 Aug 19, 2024
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

2 participants