This post has on­ly one ob­jec­tive. The next per­son who wants to run the tests on his Python project host­ed on GitHub should be able to read it and get his tests run­ning in 15 min­utes or less us­ing GitHub Ac­tion­s.

So, con­cept­s:

• Github Ac­tion­s: A free (most­ly) con­tin­u­ous in­te­gra­tion thing GitHub gives you so you can run your tests au­to­mat­i­cal­ly, so peo­ple know your project kin­da work­s.
• Test­s: you should have them.

This as­sumes your project is "mod­ern" in that it us­es Po­et­ry for de­pen­den­cy man­age­ment and pack­ag­ing. Of course maybe it does­n't, but don't wor­ry, that on­ly is im­por­tant for maybe 3 lines of YAM­L.

So, Github Actions runs what's called "workflows". You define these in YAML files in .github/workflows/whatever.yml in your repo.

Here's the orig­i­nal ver­sion of the work­flow we'll be study­ing to­day: test.yml

Don't wor­ry about the project it's in, it re­al­ly does­n't mat­ter.

Now, let's ex­am­ine that file bit by bit with ex­pla­na­tion­s, so you can see if some­thing needs chang­ing for you.

name: CI

on:
  [push, pull_request]

This work­flow is called "CI" and it runs on ev­ery push to any branch.

jobs:
  build:
    strategy:
      matrix:
        python-version: ["3.10"]
    runs-on: ubuntu-latest

Put all the versions of Python you want to test in python-versions. This will run the tests in Ubuntu.

    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
          
      - name: Switch to Current Branch
        run: git checkout ${{ env.BRANCH }}

Check­out this re­po we are test­ing, go to the right branch.

      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v1
        with:
          python-version: ${{ matrix.python-version }}

In­stall what­ev­er Python ver­sion we are test­ing.

      - name: Install dependencies
        run: |
          pip install poetry
          poetry install

In­stall what­ev­er you need. Since this project us­es po­et­ry, I in­stall po­et­ry and then use po­et­ry to set­up things. If you are us­ing some­thing else, then change it ac­cord­ing­ly.

      - name: Run unit tests
        run: |
          poetry run pytest

Run the tests in what­ev­er way they need to run. Again, since I am us­ing po­et­ry, this work­s. If you are not, then change this as need­ed.

So, put this file in .github/workflows/test.yml, modify as needed. Commit. Push. Now your tests run on every push.

And that's it. If your project us­es po­et­ry, then this work­flow may work un­changed (ex­cept maybe for Python ver­sion­s?)

Good luck!

Vi al­go en twit­ter, eso me hi­zo googlear, llegué a http­s://ob­spro­jec­t.­com/­fo­rum/thread­s/180-de­gree-live-­fisheye-dis­tor­tion-­cor­rec­tion.100214/ y ... ter­miné ha­cien­do este video, que ex­pli­ca co­mo hac­er dos cosas, una útil, la otra ... no tan­to (aunque es medio pare­ci­do a al­go que ap­ple mostró en WWD­C!)

Sospe­cho que la úni­ca man­era de que ha­ga videos es que sean cosas así, espon­táneas, sin mu­cho laburo atrás porque es­toy ha­cien­do muchas cosas y no ten­go tiem­po.

Intro

This is a sto­ry about hav­ing your own web app serv­er in the cheap­est, sim­plest, func­tion­al man­ner.

Let's as­sume that for what­ev­er rea­son you have some apps you want to use. Me, I have two:

• Gitea: sort of your own GitHub. Why? Be­­cause own­ing your own da­­ta is OK, I think. So I want the POS­SI­­BIL­I­­TY of hav­ing my own serv­er. You can still clone the re­­pos to GitHub so you lose noth­ing.

• My own site: Be­­cause, again, what I write is mine, and why not host it my­­self in­­stead of up­­load­­ing to Medi­um or some oth­­er sim­i­lar­­ly ma­lig­­nant pus­­tule of a site. Be­­sides, I've been do­ing it for over 20 years, so why stop now.

It could be any­thing! Some app you are de­vel­op­ing, some­thing you want to try, Own­Cloud or what­ev­er, if you are the sort of nerd that wants his own ap­p/site ... it's doable.

So let's con­fig­ure, from scratch, ev­ery­thing you need to ac­cess those sites/app­s.

Level 1: self hosting

For your own app­s, you will need your own hard­ware in which they can run. Let's con­sid­er the cheap­est gen­er­al use com­put­er you can buy that has some sort of net­work sup­port?

A Rasp­ber­ry Pi Ze­ro W ... 10 bucks if you could buy one. But hey, I have one or six of them, the one I'll use is called pinky.

If you don't have or don't want one of those, any­thing that can run Lin­ux is prob­a­bly OK. Or win­dows. Or Ma­cOS, but this guide as­sumes Lin­ux, so I rec­om­mend that for now. The hard­ware can prob­a­bly by any work­ing com­put­er, there is prob­a­bly no com­put­er too slow for this.

Or rather, it de­pends on what you want to run in it, so YM­MV.

I won't go in­to de­tail­s, but in­stall what­ev­er you want to run, and make it work lo­cal­ly. In my case that mean­s:

• Gitea: it's work­ing and vis­i­ble at http://pinky.lo­cal:3000
• My site: work­ing and vis­i­ble at http://pinky.lo­cal:8000

How? Look it up for what­ev­er thing you are try­ing to make work dude!

As long as it's not work­ing and ac­ces­si­ble in your lo­cal net­wor? Good, Lev­el Up!

Level 2: remote access

What about us­ing that site when you are not on the same lo­cal net­work?

Well, that won't work. Of course http://pinky.lo­cal:3000 on­ly works lo­cal­ly, so let's fix that.

There are many ways, but this is one: tailscale, specif­i­cal­ly the free one-per­son ver­sion.

What's tailscale? It's a VP­N.

It's a per­son­al VP­N. If you reg­is­ter and in­stall it in at least a cou­ple of ma­chines it will cre­ate a net­work con­nect­ing all ma­chines to each oth­er even when they are not in the same lo­cal net­work.

So if you in­stall tailscale on a serv­er (pinky in my case) and in the note­book you nor­mal­ly use (in this case salma) those ma­chines can al­ways see each oth­er us­ing some spe­cial names tailscale gives them.

Click­ing on one of the ma­chines gives de­tails about it:

As you can see pinky now is al­so known as pinky.ralsi­na.github.­be­ta.­tailscale.net thanks to tailscale.

Don't both­er try­ing to ac­cess that be­cause it on­ly works if you are mem­bers of my VPN and you ain't gonna.

But I can!

Maybe this is all you need. Right now you can ac­cess your servers from any­where as long as you are logged in­to the tailscale VP­N. Nice!

But what about oth­er peo­ple? Then you need to Lev­el UP!

Level 3: Ingress Rules

Again there are many ways to give oth­ers ac­cess to your server, but this is one I like: fly­.io

Fly is a com­pa­ny that gives you the abil­i­ty to run "stuff" on "free" vir­tu­al ma­chi­nes, with­in cer­tain lim­it­s. For ex­am­ple, not more than 160GB of out­go­ing da­ta a mon­th, more than that and they start charg­ing.

So, how about run­ning one of those VMs and con­nect­ing it to our tailscale VP­N? And then run there a re­verse proxy in it so it's an in­ter­me­di­ary that al­lows third par­ties ac­cess to our server­s? Right?

Well, this is the doc­u­men­ta­tion you need to con­nect a Fly VM to a Tailscale VP­N.

And here's a slight mod­i­fi­ca­tion of those files, so the VM runs Ng­inx

Mod­i­fy ng­inx.­conf as need­ed to route con­nec­tions where you wan­t.

At this point you can probably not use two hostnames (later we can) and server_name should be the public name Fly gave you, in my case white-wave-7409.fly.dev

Once you do that, you should be able to ac­cess some­thing us­ing that host­name:

As you can see it's us­ing HTTP­S, be­cause Fly al­so pro­vides an "outer" re­verse proxy that's do­ing HTTPS ter­mi­na­tion, so no need to cre­ate cer­tifi­cates or any­thing.

And now we have a web­site, ac­ces­si­ble from any de­vice with an in­ter­net con­nec­tion, for free (up to 160G­B) ... mis­sion ac­com­plished!

Ex­cept ... that URL is ug­ly. I would rather have Gitea use some­thing like git.ralsi­na.me and my home­-host­ed site at home­.ralsi­na.me, right?

Well, we need to Lev­el UP again!

Level 4: Custom DNS

There are in­fi­nite ways to do this but this is the one I used.

Cloud­flare works as a free DNS serv­er. If you al­ready have a do­main, con­fig­ure it, or use your own DNS server, or what­ev­er.

If you don't own a do­main buy or bor­row one, use google, fig­ure it out.

Once you have Cloud­flare or what­ev­er DNS work­ing, con­fig­ure CNAME records for each host you wan­t. I did two:

Both are point­ed to the name Fly gave me, so they re­solve llike this:

> host git.ralsina.me
git.ralsina.me is an alias for white-wave-7409.fly.dev.
white-wave-7409.fly.dev has address 37.16.0.181
white-wave-7409.fly.dev has IPv6 address 2a09:8280:1::6:3716

If you are us­ing cloud­flare they must be con­fig­ured as "DNS On­ly".

The last step is telling Fly that we use those CNAMEs so we need to cre­ate and reg­is­ter SSL cer­tifi­cates for them. Luck­i­ly that's easy, just run these com­mands in the ma­chine where you are man­ag­ing your Fly ap­p:

> flyctl certs create git.ralsina.me
> flyctl certs create home.ralsina.me

Again fix ng­inx con­fig so it us­es the host­names to route re­quests wher­ev­er they should go and ev­ery­thing should "Just Work".

What have we achieved?

• Servers ac­ces­si­ble from any­where: Gitea and My site
• Which are run­ning in the cheap­est pos­si­ble serv­er
• With nice URLs
• For free
• With­out hav­ing to make holes and re­con­fig­ure fire­wall­s.

I have not seen a guide that ex­plains this all the way, so hope­ful­ly it will be use­ful for some­one!