combine-prs-workflow
paths-filter
combine-prs-workflow | paths-filter | |
---|---|---|
3 | 8 | |
288 | 1,843 | |
-0.3% | - | |
2.1 | 6.0 | |
9 months ago | 8 days ago | |
TypeScript | ||
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
combine-prs-workflow
-
Keeping dependencies in your GitHub projects up-to-date with Dependabot
To address inefficiency caused by separate PRs, a workflow was designed to join them automatically into one big PR. However, it was unable to deal with lockfile conflicts. PRs that caused conflict in the Combine PRs job, were omitted and you had to add them manually anyway. It spared some time, but the developer experience was still far from being perfect.
-
GitHub Actions Pitfalls
Another pitfall I ran into recently with a workflow I've been working on [1]: Checks and CI that are made with GitHub Actions are reported to the new Checks API, while some (all?) external services report to their old Statuses API. This makes it needlessly difficult to ascertain whether a PR/branch is "green" or not. They finally decided to create a "statusRollUp" that combines the state of the two APIs, but it's not available in their REST api, only their GraphQL API.
[1] https://github.com/hrvey/combine-prs-workflow/
-
Awesome GitHub Actions
GitHub Actions can do some neat things. I got tired of waiting for Dependabot (tool that makes automatic PRs to update your middleware, acquired by GitHub) to add an option to group PRs together (it opens a separate PR for each dependency that can be updated, so merging and re-running CI can take a long time) so I scratched my own itch and made a workflow that merges their PRs together: https://github.com/hrvey/combine-prs-workflow Been running it for a year now, and still pretty happy with it.
paths-filter
-
How to commit part of file in Git
I also set up recently the policy to onl use merge commits on stable branch, as otherwise the path filter^1 in the workflows would not detect correctly which files changed in a PR.
[1] https://github.com/dorny/paths-filter
-
GitHub Actions as a time-sharing supercomputer
I truly don't understand why this isn't more widely discussed (I've seen several "GH Actions Gotchas" where this isn't mentioned). Many of the community actions also seem to be designed to run as short jobs to paper around missing features (for ex: https://github.com/dorny/paths-filter ), that end up eating up an enormous amount of your minutes budget.
-
Deploy Lambda only when there are code changes
If that isn’t sufficient, there are a number of third party workflow steps that enable conditional builds with extra flexibility like https://github.com/dorny/paths-filter
-
Is there a GitHub Actions equivalent to CircleCI dynamic config?
You can use paths-filter to give yourself a bunch of conditional outputs to test against for separate jobs.
-
Turborepo + GitHub Actions
That's brilliant. dorny/paths-filter looks like it can eliminate my enumerate job, and then I don't have to concern myself with all this data passing between jobs.
-
GitHub Actions Pitfalls
There’s an awkward gotcha/incompatibility between “Required status checks” and workflows that get skipped [1], eg due to setting a “paths” property of a push/pull_request workflow trigger [2].
The checks associated with the workflow don’t run and stay in a pending state, preventing the PR from being merged.
The only workaround I’m aware of is to use an action such as paths-filter [3] instead at the job level.
A further, related frustration/limitation - you can _only_ set the “paths” property [2] at the workflow level (i.e. not per-job), so those rules apply to all jobs in the workflow. Given that you can only build a DAG of jobs (ie “needs”) within a single workflow, it makes it quite difficult to do anything non trivial in a monorepo.
[1]: https://docs.github.com/en/repositories/configuring-branches...
[2]: https://docs.github.com/en/actions/using-workflows/workflow-...
[3]: https://github.com/dorny/paths-filter
-
Configuring python linting to be part of CI/CD using GitHub actions
We are interested in running a linter only against the modified files. Let's say, we take a look at the provided repo, if I update dags/dummy.py I don't want to waste time and resources running the linter against main.py. For this purpose we use Paths Filter GitHub Action, which is very flexible.
-
Introducing Gistblog 🎉: Blog your little ❤️ out using GitHub Gists
In the spirit of the #ActionsHackathon21, you can see I'm taking advantage of the checkout action GitHub provides and the Paths Filter action by dorny to create the desired workflow. I'm also using the Gistblog Action I created for this hackathon which handles managing all the blog posts as Gists. I'd like to explore Composite actions soon to see if I can reduce all of this to a single action making setup even easier.
What are some alternatives?
runner-images - GitHub Actions runner images
actionlint - :octocat: Static checker for GitHub Actions workflow files
changed-files - :octocat: Github action to retrieve all (added, copied, modified, deleted, renamed, type changed, unmerged, unknown) files and directories.
vitemadose - Détection de créneaux de vaccination disponibles pour l'outil ViteMaDose
test-reporter - Displays test results from popular testing frameworks directly in GitHub
gh-valet - Valet helps facilitate the migration of Azure DevOps, CircleCI, GitLab CI, Jenkins, and Travis CI pipelines to GitHub Actions.
travis-yml - Travis CI build config processing