docker-flask-example VS act

I've been maintaining my Build a SAAS App with Flask video course[0] for 8 years. It has gone from pre-1.0 to 2.3 and has been recorded twice with tons of incremental updates added over the years to keep things current.

In my opinion tutorial creators should pin their versions so that anyone taking the course or going through the tutorial will have a working version that matches the video or written material.

I'm all for keeping things up to date and do update things every few months but rolling updates don't tend to work well for tutorials because sometimes a minor version requires a code change or covering new concepts. As a tutorial consumer it's frustrating when the content doesn't match the source code unless it's nothing but a version bump.

I've held off upgrading Flask to 3.0 and Python 3.12 due to these open issues with 3rd party dependencies https://github.com/nickjj/docker-flask-example/issues/17.

[0]: https://buildasaasappwithflask.com/

I usually end up with project specific "run" scripts which are just shell scripts so I can do things like `./run shell` to drop into the shell of a container, or `./run rails db:migrate` to run a command in a container.

Here's a few project specific examples. They all have similar run scripts:

    - https://github.com/nickjj/docker-flask-example

There's a lot of "tool" selections in that repo.

If anyone is looking for ready to go web app examples aimed at both development and production, I maintain:

    - https://github.com/nickjj/docker-flask-example

Personally I maintain https://github.com/nickjj/docker-flask-example. There's also https://github.com/nickjj/build-a-saas-app-with-flask if you want more opinions.

This is what I do except I use a shell script instead of a Makefile.

A working example of this is at: https://github.com/nickjj/docker-flask-example/blob/912388f3...

Those ./run ci:XXX commands are in: https://github.com/nickjj/docker-flask-example/blob/912388f3...

I like it because if CI ever happens to be down I can still run that shell script locally.

> I've encountered a code written in the 12factor style of using environment variables for configuration, and in that particular case there was no validation nor documentation of the configuration options. Is this typical?

I don't know about typical, it comes down to how your team values the code they write.

You can have a .env.example file commit to version control which explains every option in as much or as little detail as you'd like. For my own personal projects, I tend to document this file like this https://github.com/nickjj/docker-flask-example/blob/main/.en....

I did this for a while but make isn't well suited for this use case. What I end up doing is have a shell script with a bunch of functions in it. Functions automatically becomes a callable a command (with a way to make private functions if you want) with pretty much no boiler plate.

The benefit of this is it's just shell scripting so you can use shell features like $@ to pass args to another command or easily source and deal with env vars.

I've written about this process at https://nickjanetakis.com/blog/replacing-make-with-a-shell-s... and an example file is here https://github.com/nickjj/docker-flask-example/blob/main/run.

There's: https://github.com/nickjj/docker-flask-example

When it comes to the alternatives to tmate, there is another great debugging tool that you could check out. It is called act and it allows you to run GitHub Actions code on your local machine making debugging even easier. It has its own limitations and some learning curve but overall it is another tool you should use if you can’t fix the CI bugs by connecting directly into the running action with the tmate.

Link: https://github.com/nektos/act

Could you upload your build of GitHub's runner image to Docker Hub?

This would be quite useful for users of other GitHub Actions clones like act [0].

[0]: https://github.com/nektos/act

> These kinds of commit messages are typically an indicator of a broken process where somebody needs to commit to see something happen, like a deployment or build process, and aren't able to assert that stuff works locally.

This is one of my biggest pet peeves with services like github actions. Something running locally like "act" [1] isn't sufficient because it doesn't have everything github has and is extra friction anyway to get everyone to use it for testing.

[1] https://github.com/nektos/act

View on GitHub

If you use Github actions, act is incredibly useful. It can be used to test your GH actions, but also serves as an interface for running tasks locally.

That's something that often is difficult or basically impossible. Except for maybe GitHub actions through Act (https://github.com/nektos/act). I'd still lean to something in the yaml sphere if it eventually would be used in deployment pipelines and such. For example a solution incorporating ansible.

It also seems to me that the argument you make is mostly focused on the building step? Earthly certainly seems focused on that aspect.

I feel I'm being trolled, but I'll bite and accept the resulting downvotes

I don't think treating every mention of act as an opportunity for airing of personal grievances is helpful in a discussion when there's already ample reports of people's concrete issues with it, had one looked at the 800 issues in its repo https://github.com/nektos/act/issues?q=is%3Aissue or the 239 from gitea's for https://gitea.com/gitea/act_runner/issues or whatever is going on with Forgejo's fork https://code.forgejo.org/forgejo/act .

But, as for me specifically, there are two and a half answers: I wanted to run VSCodium's build locally, which act for sure puked about. Then, while trying to troubleshoot that, I thought I'd try something simpler and have it run the lint job from act's own repo <https://github.com/nektos/act/blob/1252e551b8672b1e16dc8835d...> to rule out "you're holding it wrong" type junk. It died with

  [checks/lint]     Failure - Main actions/setup-go@v3

https://twitter.com/mitsuhiko/status/1720410479141487099 :

> GitHub Actions currently charges $0.16 per minute* for the macOS M1 Runners. That comes out to $84,096 for 1 machine year*

GitHub Runner is written in Go; it fetches tasks from GitHub Actions and posts the results back to the Pull Request that spawned the build.

nektos/act is how Gitea Actions builds GitHub Actions workflow YAML build definition documents. https://github.com/nektos/act

https://twitter.com/MatthewCroughan/status/17200423527675700... :

> This is the macOS Ventura installer running in 30 VMs, in 30 #nix derivations at once. It gets the installer from Apple, automates the installation using Tesseract OCR and TCL Expect scripts. This is to test the repeatability. A single function call `makeDarwinImage`.

With a Multi-Stage Dockerfile/Containerfild, you can have a dev environment like xcode or gcc+make in the first stage that builds the package, and then the second stage the package is installed and tested, and then the package is signed and published to a package repo / app store / OCI container image repository.

SLSA now specifies builders for signing things correctly in CI builds with keys in RAM on the build workers.

"Build your own SLSA 3+ provenance builder on GitHub Actions" https://slsa.dev/blog/2023/08/bring-your-own-builder-github