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

feat(pipeline): enable setting CodeBuild properties on FeatureBranch projects #544

Merged
merged 17 commits into from
Sep 8, 2023
Merged

feat(pipeline): enable setting CodeBuild properties on FeatureBranch projects #544

merged 17 commits into from
Sep 8, 2023

Conversation

jstrunk
Copy link
Contributor

@jstrunk jstrunk commented Aug 23, 2023

Apply the properties from the PDKPipeline codeBuildDefaults property to the CodeBuild project that creates feature branch pipelines. This enables configuration such as role policies, filesystems, and networking. The role policy is useful to enable access to private repos in CodeArtifact.

The feature branch CodeBuild project now defaults to the STANDARD_7_0 build image.

References #350

@agdimech
Copy link
Contributor

agdimech commented Sep 7, 2023

HI Jeff - this looks good although we should not mark this commit as a BREAKING CHANGE as we should only reserve this to when a backward-incompatible API change occurs. Please update your commit accordingly then happy to merge.

As always, thanks for your contribution!

jstrunk and others added 17 commits September 7, 2023 20:11
…projects

Apply the properties from the PDKPipeline `codeBuildDefaults` property to the CodeBuild project that
creates feature branch pipelines. This enables  configuration such as role policies, filesystems,
and networking. The role policy is useful to enable access to private repos in CodeArtifact.

The feature branch CodeBuild project now defaults to the `STANDARD_7_0` build
image.
This commit restructures the PDK as follows:

- Individual packages are now namespaced as @aws-pdk and are NOT published to npm/pypi/maven.
- A new aws-pdk package is created which creates a single distributable which IS published to npm/pypi/maven.
- Dependencies between packages is supported via @aws-pdk/XXX. When packaging into the aws-pdk, these imports are rewritten using a combination of tsconfig paths and tsc-alias.
- PDKProject has been refactored to pull out PDKRelease as this should now only happen in AwsPdkProject.
- Package tasks have been removed from individual packages as this now should only occur in aws-pdk.
- aws_arch and cdk_graph_plugin_diagram have been refactored slightly to ensure exported types make JSII happy.
- Overall DAG has been simplified and improvements to build times have been made ~8 mins
- docs has been pulled up to the root level
- private has been replaces by projenrc
- PDKPipelineXXProject has been removed from the pipeline package.
- Updated Monorepo to ensure NodeResolution is nodenext for TS projects
- Changed transient deps script to use shallowest transient dep version instead of greatest given we are now bundling everything together in one.
- Interfaces no longer expose required props when they aren't actually required.
- All TSProjects under a monorepo use tsconfig module reoslution settings of nodenext and target es2021
- Added a global pdk command which aliases underlying package manager command 🕺
- Added an API Explorer powered by SwaggerUI to the CloudscapeReactTsWebsite which allows you to make authenticated API requests
- Added an Infra package which allows you to create boilerplate CDK code for an API + Website. This means you can get a fully functioning website + API, with all Infra in < 70 LoC 👏

BREAKING CHANGES
- All imports will need to be changed to aws-pdk/<pkg>
- All dependencies on @aws-prototyping-sdk/* will need to be changed to a single dependency on aws-pdk
- Refactored CDKGraph & CdkGraphDiagramPlugin to poly friendly definitions which will break existing consumers in TS (Py and Java never worked).
- Removed PDKPipeline projen constructs.
- Renamed nx-monorepo to monorepo
- TypeSafeApi Python runtime moved to new python-nextgen OpenAPI generator, which means:
  - Properties of models can be referenced as attributes rather than dictionary syntax (eg .my_property rather than ["my_property"]).
  - Models are now serialised and deserialised using the .from_json and .to_json methods.
  - request_parameters and request_array_parameters are also models.
- TypeSafeApi Python handlers import location changed from <package>.apis.tags.default_api_operation_config to <package>.api.operation_config.
- TypeSafeApi Java classes for handlers/interceptors in runtime are no longer static subclasses of the Handlers class. The import location has changed from eg <package>.api.Handlers.SayHello to <package>.api.handlers.say_hello.SayHello.
Change name to @aws/pdk
… typescript (#551)

Previously request parameters were always strings no matter the type defined in the model. Now we
add code to the typescript lambda handler wrappers to convert to appropriate types. Supports the
Smithy supported request parameters number/string/bool/date and arrays of those. Responds with a 400
error if the wrong type is passed, and includes headers from any response header interceptors in
this validation response.

BREAKING CHANGE: Removed RequestArrayParameters from input and type signature of
handlers/interceptors. number/bool/date request parameters will be coerced to their type defined in
the model. useIntegerType: true is specified by default for smithy to openapi conversion as this is
recommended and more intuitive behaviour than the default (where integers are still represented as
doubles).
- tweak getting started docs
- update infra sample code to apply cognito authrole permissions to call deployed sample API
* feat(type-safe-api): coerce request parameters into defined types for java

Request parameters for java are now of the correct types declared in the model. Note that only
primitive types and single level arrays of primitives are supported (as per Smithy's supported types
for request parameters). OpenAPI allows you to define request parameters as objects with different
encoding strategies but these are not supported by type safe api. Adds validation to make sure that
the request parameters are of the supported types as part of the model build task. Also moves the
Smithy trait injection logic to the model build task such that traits are added to the .api.json
file produced by the model build, rather than as a preprocessing step each time code is generated.

BREAKING CHANGE: Removed RequestArrayParameters from handler inputs and folded them into
RequestParameters. Renamed CorsInterceptor to ResponseHeadersInterceptor. Validated to ensure only
primitives (or arrays of primitives) are used in request paramters (query/path/headers).
RequestParameters coerce string values into their appropriate types for the handler wrappers to
consume, and will respond with a 400 if request parameters are of the wrong type.

* feat(type-safe-api): coerce python request parameters into declared types

Removes request_array_parameters and folds all request parameters into input.request_parameters.
cors_interceptor.py is now response_headers.py for the cors interceptor.

BREAKING CHANGE: Removes request_array_parameters and folds all request parameters into
input.request_parameters. cors_interceptor.py is now response_headers.py for the cors interceptor.
* docs(type-safe-api): update docs and migration guide

Also enable push to github pages, and add missing webAclOptions property to generated java cdk
construct.

* fix: cleanup sections

---------

Co-authored-by: Adrian Dimech <dimecha@amazon.com>
* docs: update migration guide

* docs(type-safe-api): improve lambda handler docs

---------

Co-authored-by: 🚀 Jack <jacsteve@amazon.com>
… 100 percent (#564)

This change moves the installation of all dependencies for type-safe-api scripts into a central
~/.pdk directory, namespaced by the version and package manager used. This means we save the install
time for every script that runs, once the first script has run.
@agdimech agdimech merged commit 37d3150 into aws:mainline Sep 8, 2023
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants