Showing content from https://github.com/pmd/pmd/issues/4328 below:
[ci] Improve Github Actions Workflows · Issue #4328 · pmd/pmd · GitHub
Problem description:
Currently we have one big job, that does all the things. If something goes wrong, one needs to drill down to the logs to figure out when and what exactly has failed.
Also the big job runs very long, which means we get slow feedback.
Thoughts on improvements
- Have a first job, that just builds, to make the workflow fail fast. No need to run the workflows on other operating systems, if it fails already.
- Avoid to rebuild over and over again by using artifacts to exchange data between different jobs.
- The "regression tester run" should be a separate job. It should produce an artifact with the report, that can be downloaded from the run.
- The "dogfood run" should be a separate job.
- The pull request workflow should be restructured, so that we can make use of the full permissions. Currently we don't have access to the secrets, so we can do only limited things and basically need a public pmd-bot account, that comments the PR for us.
- The current CI solution is heavily using bash scripts from build-tools. Maybe this can be simplified. Ideally we are still able to run a build/create release even if github is down (beware of vendor lock in).
- For the release task, maybe skip the tests? The tests have been executed anyway before, the only change would be the version change...
- For every job, that builds PMD, publish the artifacts from pmd-dist as build outputs, so that one can download the PMD version with that change included - that could make it easier to test, etc.
- Ideally, the jobs are idempotent and can be run again without doing harm. E.g. it should be easy to rerun a release build, if e.g. some external service failed. Ideally only the parts, that weren't executed yet would be executed again.
- Get rid of the extra https://github.com/pmd-bot account
- These are only some vague ideas that need to be fleshed out in detail
Constraints:
- when changing the workflows, we need to make sure we are still able to release a new version and also release a bugfix version from a maintenance branch. This might mean, that we need to backport/cherry-pick the change into the maintenance branch (when needed).
Tasks:
Related issues:
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4