Created a smoke test workflow that installs IIAB with Calibre-Web - #324
Conversation
|
Looks great! So it appears (Does that mean root has an unusual umask within GitHub Actions — instead of the usual 022 ?) |
That's correct, for whatever reason it is 777.
At this moment I cannot confirm, but the result seems to suggest that the umask for root within a GitHub actions runner (VM) is 000 |
Strange, as umask 000 is normally considered very dangerous! (I'd love to understand how it ends up this way, if we can poke at it a bit more and/or find GitHub Actions docs explaining the situation?) |
|
FWIW this is confusing, as a quick Google search claims: "GitHub Actions runners use a default umask of 0022" |
|
ASIDE:
|
|
@Akatama thanks for pointing out this critical issue when we talked earlier today: (that we'd overlooked earlier!)
|
Hopefully smoke-test.yml (renamed as appropriate) can fix this by forcibly appending |
|
@holta Results from umask testing Result from running Result of running This is the same perms as 777 Result of running Based on this, I think the issue is |
|
Even with This is still 777. So we really need to set the perms to 755 or something lower. |
…ow I can get the info I need to install the right version of calibre-web through IIAB
No worries, regular Ubuntu behaves the same way: (REASON: umask is a "shell builtin command") Running Running TAKEAWAYS:
|
|
@holta I think I got calibreweb_repo_url and calibreweb_version set to the correct info. However, we do seem to have a problem. Let's look at what local_vars.yml looks like on the smoke-test branch on my fork: # LAST UPDATED: October 10, 2024
# USAGE: https://github.com/iiab/calibre-web/wiki#wrench-installation
runcmd:
- mkdir -p /etc/iiab
- |
cat >> /etc/iiab/local_vars.yml << EOF
calibreweb_install: True
calibreweb_enabled: True
nodocs: True
kolibri_install: False
kolibri_enabled: False
kiwix_install: False
kiwix_enabled: False
osm_vector_maps_install: False
awstats_install: False
awstats_enabled: False
matomo_install: False
matomo_enabled: False
captiveportal_install: False
network_install: False
network_enabled: False
admin_console_install: False
admin_console_enabled: False
EOF
- curl iiab.io/risky.txt | bash &
calibreweb_repo_url: https://github.com/Akatama/calibre-web
calibreweb_version: smoke-testSo I was able to get the URL for my repo and the name of my branch. However, the run failed on main because the smoke-test branch does not exist on iiab/callibre-web: # LAST UPDATED: October 10, 2024
# USAGE: https://github.com/iiab/calibre-web/wiki#wrench-installation
runcmd:
- mkdir -p /etc/iiab
- |
cat >> /etc/iiab/local_vars.yml << EOF
calibreweb_install: True
calibreweb_enabled: True
nodocs: True
kolibri_install: False
kolibri_enabled: False
kiwix_install: False
kiwix_enabled: False
osm_vector_maps_install: False
awstats_install: False
awstats_enabled: False
matomo_install: False
matomo_enabled: False
captiveportal_install: False
network_install: False
network_enabled: False
admin_console_install: False
admin_console_enabled: False
EOF
- curl iiab.io/risky.txt | bash &
calibreweb_repo_url: https://github.com/iiab/calibre-web
calibreweb_version: smoke-test |
|
Right! We don't need all of omg.yml — all we really need is this part... |
|
@Akatama maybe try pasting those 20 lines (essentially) directly into your (In the "Set up /etc/iiab/local_vars.yml" section!) |
Sure, but that's not going to fix the problem that iiab/calibre-web doesn't have a smoke-test branch (or whatever branch exists on someone else's fork) |
|
To be clear, this is the fatal error from the workflow run on iiab/calibre-web: |
|
@holta Most recent run on iiab/calibre-web failed for the same reason. I have to get to bed, and I am not sure I will have the energy to work on this tomorrow as I will be throwing my daughter Chloe her 4th birthday party. Here is the error again, just so you can see it hasn't change since I updated local_vars.yml: |
|
@Akatama when you get to it! Here are GitHub Actions variables that capture the true {OWNER, REPO and BRANCH} from any commit — even if the commit is not part of a PR: Good enough❓❗ A few other GitHub Actions vars FWIW: |
So be it for now! (The root cause would appear to be GitHub Actions' choice to set unusual permissions for |
|
@Akatama no rush — but later this weekend I'd be curious if you think we really need to use EthanSK/git-branch-name-action@v1 to kick off these GitHub Actions? My guess is that GitHub Actions's own variables are sufficient for our needs — ~4 years after EthanSK created the above (but I could be wrong!) |
I was searching for how to grab the branch name, and this was the first answer I found that seemed like it could work. In another comment you are suggesting $GITHUB_REF_NAME, so I can take a look at using that. If it still says smoke-test, we will still have the same problem. |
|
|
@holta This is what the last two lines of local_vars.yml looks like on the run from the PR: calibreweb_repo_url: https://github.com/iiab/calibre-web
calibreweb_version: 324/mergeCompared to the run from my fork, I think this means it may work! calibreweb_repo_url: https://github.com/Akatama/calibre-web
calibreweb_version: smoke-test |
|
Ah well! (It failed but I'll dig further later today...)
PS after we get this right, later on I'd personally suggest we tighten up a bit, by dumping all ~20 lines directly into /etc/iiab/local_vars.yml using 1 single "heredoc". |
|
@holta It looks like git would use something like this to pull from a PR: I am hoping if we convert 324/merge to pull/324/head then we can get this working. There may be an easier way to go about it, but to be clear about what I think we would need to do if we followed this idea. Check $GITHUB_REF_NAME
|
…, this is just a test
|
@Akatama check this out which seems to work well — for both event "pull_request" and event "push":
PS We should get to know (or at least learn something about) GitHub Action contexts at some point 💫 |
|
@holta Take a look, I took a lot from your branch. Thanks for doing that, if I didn't have two big events this last weekend I would've done that research. I removed some comments, and I tested the workflow_dispatch for this workflow on the master branch of my fork - it works flawlessly. Let me know if you see any more adjustments that are needed. |
(Great idea, wow!) We should merge this later today I think. I can do that when I have a bit more time PM. Feel free to add any fine-tuning or explanation. e.g. if this can be a model for other future workflows validating more specific functionality. |
|
Maybe its worth it to run the tests we have now after install. Just to be sure Calibre-Web is reachable. In the future, if our tests take up significant time, we may want to have this workflow just run the most basic ones and have another workflow that does the install and runs them all. |
|
|
@thotmx that's a great question:
@Akatama might have other suggestions! e.g. he mentioned possible ways we might want to lay this out + evolve this going forward:
|
3 participants
Pretty much what the title says. Since this is a new workflow it is not changing the original one we have.
@holta