-
Notifications
You must be signed in to change notification settings - Fork 2
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
Tune Our GitHub Workflows #173
Merged
Merged
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
Using "package-listing" as "Playground" as the deprecated action is not required anymore.
And add to sandbox for testing.
We do not want to get quotes around our engine versions as we cannot use them within configuration for pnpm/setup-node action.
Trying not to use `.npmrc` but environment variables instead.
Seems the environment way is not going to work. Fall back to already working temporary `.npmrc` pattern.
Linting does not require much, not even to build anything. Thus, we can just start the linter with a minimal setup.
We require build artifacts for linting. Unless we identified how to share built artifacts between jobs/workflows, we use parameters instead. This would allow some outer workflow to run all these in parallel, with some extra build effort, though, as some steps need to be repeated.
* Adding a run-name. * Always set name for reusable workflow calls for better display in the workflow overview.
Also building the documentation requires a build. Thus, moving this also to the build job. Generating documentation is more of a "probe that it works", as the documentation is not published.
We do not need more. It is a debugging-only artifact anyway.
Using "delegate" semantic, so that we can shape the triggers in an extra workflow.
No need for a simple get-engines workflow to use an extra job for output. Just was an experiment, we drop now.
Make it easier to identify workflows, that have no workflow_dispatch trigger, by using the name prefix "On".
Any other tries do not (always) provide the expected result.
mmichaelis
added
type:improvement
Request for an Improvement
ignore-for-release
Don't automatically add pull request's information to generated release notes
labels
Jan 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
ignore-for-release
Don't automatically add pull request's information to generated release notes
type:improvement
Request for an Improvement
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.
Applying some refactorings. Goal: Reduce complexity of a single workflow definition and possibly speed up processes.
Current state is more or less a draft, yet to be finished.
The idea is to create a
release.yml
, that may create any of the different release types. But: It is always only invoked manually or via an extra trigger-workflow (as demonstrated withon_pull_request_push.yml
).The script
get-version.yml
can be used to retrieve the version (and use this external process instead of "baking" the logic intorelease.yml
.