-
Notifications
You must be signed in to change notification settings - Fork 104
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
Automated build process generation exploration #859
Draft
danielrbradley
wants to merge
13
commits into
master
Choose a base branch
from
taskfile
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
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
- Don't need "generates" with checksums ... and the "generates" and "sources" is relative to the "dir". - Just use relative paths rather than messy `{{ .CWD }}`
We should still add "generates" because it will then run if the file is missing. It doesn't however fingerprint the generated files to detect manual changes - it's only to check for existence.
Use task namespaces to group provider tasks
Source excludes are not currently supported so we can't have everything except `bin` using something like `"!(bin)/*".
- Rename TS build to transpile.
Use `run: once` to avoid rebuild of shared dependencies. Pull build target and output into variables with defaults. Use multiple 'deps' to run provider-specific builds in parallel.
- Add clean task too to be able to quick perf testing. - Use variable overrides to pack each binary. - Use stub "dist-dir" target to ensure dist directory exists. - Use `--no-progress` for all yarn installs as this doesn't work well in parallel. - Set make default flags to mirror parallelism and provide additional warnings
- Create lightweight makefile model which is rendered at end. - Don't try to do everything make can, just model how we use it i.e. all VARS at top. - Write common target patterns as functions. - Explore using higher-level functions like `cwd(dir, ...cmds)` for expressiveness. - Allow dependencies to be a string or an instance of another target for briefness.
Dynamically building out full repeated steps rather than odd makefile hacks.
Use target property to generate .PHONY automatically
- makefile for the core model types and render function. - makefile-builders for the functions to build specific makefiles.
This now creates a valid makefile which completes the whole provider part of the build.
danielrbradley
changed the title
Taskfile exploration
Automated build process generation exploration
May 26, 2022
danielrbradley
added
the
impact/no-changelog-required
This issue doesn't require a CHANGELOG update
label
May 30, 2022
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.
This PR contains a comparible implementation of the file-target based makefile in taskfile. It also contains a prototype of how we could generate makefiles by building simple funtions (like we do for our yaml GH actions).
Considering the elements of cross-platform, up-to-date target tracking, the ability to centrally generate and parallelism; there's currently no selling point strong enough for us to shift away from make.
Make
The makefile in awsx is already in a very good place - it uses file targets which means it's trivial for make to optimize which targets need to run based on any file in the project changing. This gives us a good baseline to compare against taskfile.dev.
Taskfile
Overall, taskfile offers very similar features to make with a yaml based language which would be simpler to generate.
Factfile (true as of 3.12.1)
--touch
to track back through dependencies and mark as built.clean
to be run correctly in parallel at the same time as a build (unlike make).The lack of
--touch
alternative is a blocker for efficient (& correct) CI. When running in CI we want to:--touch
after restoring the artefacts so make will create stub files to make the dependencies appear up-to-dateAll targets always self-describe all prerequisites so In local situations where we don't use
--touch
dependencies will be followed as usual ensureing no internal knowledge of the build process for end-users.Makefile generation
If we can't use taskfile due to the CI limitations, we can instead just generate makefiles dynamically using a quick DSL (< 80 LOC).
Demo program:
Output: