paths-filter VS aws-extensions-for-dotnet-cli

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

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.

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

You can use paths-filter to give yourself a bunch of conditional outputs to test against for separate jobs.

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.

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

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.

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.

The problem is this issue. lambda package command does not stripe timestamps from the archive, therefore this archive has a different hash each time.

Here’s the deploy-serverless source code which shows tags as a CommandOption. This other class appears to show available command options. I haven’t tested using the tags option since I’m posting from my phone but it looks like there is a way. Hope that helps.

What's your thoughts on AWS Lambda for microservices? Long story short, I'm debating converting an app I originally built in asp.net core to AWS Lambda to save money. It's currently running in a container on ECS Fargate. AWS offers a dotnet cli extension that allows me to pretty much bootstrap my api to run on Lambda while keeping the asp.net core framework: https://github.com/aws/aws-extensions-for-dotnet-cli. Honestly, the only reason I'm considering doing this is cost ... as this is a side project that I someday plan to make public. I started rewriting the api in pure NodeJS with Typescript to run on AWS Lambda and I really miss the built in functionality I get with asp.net core framework and beauty of dotnet.

Some are deployed using Terraform, some using Serverless framework (which uses CloudFormation under the hood), and some using AWS Extensions for .NET CLI.