feat: standard build #1201
Merged
feat: standard build #1201
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Define a common build process for all projects which includes a set of standard phases that can be used for extensibility. The idea is that components and project types will have a solid foundation for build extensions instead of ad-hoc set of tasks for each project. The `build` task now spawns a set of standard build phase tasks: - `default` (synthesize project runs - executes your projenrc). - `precompile` - `compile` - `postcompile` - `test` - `package` The `Project` base class now has a set of properties that can be used to access these tasks. For example, `project.postcompileTask` will return the `Task` that’s executed after compilation. The method `task.lock()` can now be used to lock a task for mutations. The `build` task is now locked, which means that any modifications to it will throw an exception. This change also includes some logging improvements and cleanups. This is an attempt to create generic build model for all project types. We shall see if this holds water. BREAKING CHANGE: It is now impossible to modify the `build` task. Instead, extend one of the specific build phases (`precompile`, `compile`, `post compile`, `test` and `package`). To access these tasks use `project.xxxTask`. * The `compileBeforeTest` option in `TypeScriptProject` is not supported any more. Tests are always executed _after_ compilation.
Codecov Report
@@ Coverage Diff @@
## main #1201 +/- ##
==========================================
+ Coverage 78.46% 87.45% +8.98%
==========================================
Files 88 126 +38
Lines 3181 4773 +1592
Branches 809 1247 +438
==========================================
+ Hits 2496 4174 +1678
+ Misses 683 561 -122
- Partials 2 38 +36
Continue to review full report at Codecov.
|
iliapolo
reviewed
Nov 3, 2021
Chriscbr
reviewed
Nov 4, 2021
There was a problem hiding this comment.
Cool stuff! I'm curious to see if this holds water as well.
Thinking about the task system more broadly, I think our current model still leaves us open for adding features like parallel tasks, or task arguments, etc. down the line, which is good.
While reviewing this I also had an idea about whether we might want to specify tasks/commands within the build steps that should only run when in a CI environment like GitHub actions. Requires some more thought...
Upgrades project dependencies. See details in [workflow run]. [Workflow Run]: https://github.com/projen/projen/actions/runs/1419236426 ------ *Automatically created by projen via the "upgrade-main" workflow*
Upgrades project dependencies. See details in [workflow run]. [Workflow Run]: https://github.com/projen/projen/actions/runs/1423753266 ------ *Automatically created by projen via the "upgrade-main" workflow*
Adds `mergifyOptions` as a field for `GitHub` so it can now be configured like so:
```ts
const project = new TypeScriptProject({
// ...
githubOptions: {
mergifyOptions: {
// rules: ...
},
},
});
```
Moves the (deprecated) `mergifyOptions` from `NodeProject` to `GitHubProject`.
---
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Upgrades project dependencies. See details in [workflow run]. [Workflow Run]: https://github.com/projen/projen/actions/runs/1427850443 ------ *Automatically created by projen via the "upgrade-main" workflow*
Upgrades project dependencies. See details in [workflow run]. [Workflow Run]: https://github.com/projen/projen/actions/runs/1430259554 ------ *Automatically created by projen via the "upgrade-main" workflow*
But still expose properties at the Project level for discoverability and easy access.
Chriscbr
approved these changes
Nov 7, 2021
njlynch
added a commit
to cdklabs/construct-hub-webapp
that referenced
this pull request
Nov 8, 2021
A recent feature to projen (projen/projen#1201) changed the way that build tasks work. This breaks the upgrade workflow for this (and several other projects).
mergify bot
pushed a commit
to cdklabs/construct-hub-webapp
that referenced
this pull request
Nov 8, 2021
A recent feature to projen (projen/projen#1201) changed the way that build tasks work. This breaks the upgrade workflow for this (and several other projects).
njlynch
added a commit
to cdklabs/publib
that referenced
this pull request
Nov 8, 2021
A recent feature to projen (projen/projen#1201) changed the way that build tasks work. This breaks the upgrade workflow for this (and several other projects).
mergify bot
pushed a commit
to cdklabs/publib
that referenced
this pull request
Nov 8, 2021
A recent feature to projen (projen/projen#1201) changed the way that build tasks work. This breaks the upgrade workflow for this (and several other projects).
|
@eladb im having an issue after removing no projenDuringBuild. Basically I have a bunch of projen projects inside a yarn2 workspace, and I can't be running Is there a way to re-enable this? |
|
I suppose I can still use PROJEN_DISABLE_POST=1, but that seems not ideal |
|
@alexforsyth Can you try |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Define a common build process for all projects which includes a set of standard phases that can be used for extensibility. The idea is that components and project types will have a solid foundation for build extensions instead of ad-hoc set of tasks for each project.
The
buildtask now spawns a set of standard build phase tasks:default(synthesize project - executes your projenrc).pre-compilecompilepost-compiletestpackageThe
Projectbase class now has a set of properties that can be used to access these tasks. For example,project.postcompileTaskwill return theTaskthat’s executed after compilation.The method
task.lock()can now be used to lock a task for mutations. Thebuildtask is now locked, which means that any modifications to it will throw an exception.This change also includes some logging improvements and cleanups.
This is an attempt to create generic build model for all project types. We shall see if this holds water.
BREAKING CHANGE: It is now impossible to modify the
buildtask. Instead, extend one of the specific build phases (precompile,compile,post compile,testandpackage). To access these tasks useproject.xxxTask.compileBeforeTestoption inTypeScriptProjectis not supported any more. Tests are always executed after compilation.projenDuringBuildis no longer supported. Let us know if you have a use case for it that we are not aware of.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.