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

Tune Our GitHub Workflows #173

Merged
merged 30 commits into from
Dec 8, 2023
Merged

Tune Our GitHub Workflows #173

merged 30 commits into from
Dec 8, 2023

Conversation

mmichaelis
Copy link
Member

@mmichaelis mmichaelis commented Dec 7, 2023

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 with on_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 into release.yml.

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 mmichaelis marked this pull request as ready for review December 8, 2023 14:19
@mmichaelis mmichaelis merged commit c711162 into main Dec 8, 2023
28 checks passed
@mmichaelis mmichaelis deleted the refactor-github-workflows branch December 8, 2023 14:42
@mmichaelis 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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant