feat: overhaul workflows to publish packages to new archive infra #38
Conversation
|
Hi @khos2ow , with 3.2 out the door the gates are open for the build refactor. Is this still WIP? |
|
That's great! Yes this is still WIP. I'm gonna start working on it again. |
khos2ow
force-pushed
the
migrate
branch
11 times, most recently
from
6f14094 to
dd2d0fa
Compare
khos2ow
force-pushed
the
migrate
branch
4 times, most recently
from
92b37dd to
272fc97
Compare
khos2ow
force-pushed
the
migrate
branch
5 times, most recently
from
819f1ca to
a2ecf79
Compare
khos2ow
force-pushed
the
migrate
branch
7 times, most recently
from
4e03790 to
0ea7bbc
Compare
khos2ow
force-pushed
the
migrate
branch
10 times, most recently
from
9395942 to
1749472
Compare
khos2ow
changed the title
| set -x | ||
|
|
||
| ssh-keyscan -H ${{ secrets.KAMATERA_HOSTNAME2 }} >> ~/.ssh/known_hosts | ||
| ssh root@${{ secrets.KAMATERA_HOSTNAME2 }} "publish-repos.sh \"${{ inputs.packages-path }}\" \"${{ inputs.only-distro }}\" \"${{ inputs.only-codename }}\" \"${{ inputs.only-component }}\"" |
There was a problem hiding this comment.
this makes sense, is obvious. I wonder if you considered running a gh runner on the repo host. Maybe a step in the wrong direction..
There was a problem hiding this comment.
I hadn't! That could be interesting. But immediately what I'm thinking is that don't put more things and more responsibility into a server which basically is only designed to "serve an http server."
Making that a runner adds a bit more complexity to this and for us to maintain yet one more thing for it.
There was a problem hiding this comment.
We can track it in #44 after getting this merged.
| } | ||
|
|
||
| archive_setup_scripts() { | ||
| # Following allows for internal dependencies |
There was a problem hiding this comment.
question: can you elaborate on this? What would qualify as an internal dependency?
There was a problem hiding this comment.
This part is equivalent of this which I moved from action file to here.
Not entirely sure if it is actually needed or not, but I think if a package that's being built relies on other packages that are maintained by Regolith (and basically only exists in archive.regolith-desktop.com and not Ubuntu or Debian public repos)
There was a problem hiding this comment.
It's actually needed 😄 . Presently we have one such case: sway-regolith depends on trawldb. The current approach is to break a build into two phases, for stages that doesn't already have some version of trawldb in the repo (for example, a new OS-codename being added) which result in commits like this and then a revert. Would be really nice to not have to deal with that sort of thing.
Does this mean that, for say an example where 3 packages need to be built, that each build runs in isolation (so that the dependencies are available), or something else? To contrast, the existing build system is kind of "one shot" meaning that any failure fails the whole build, and any dependency to a package build needs to already be available before the build starts. So, it's not possible to say "first build trawldb, then build sway-regolith" because, while it's possible to have trawldb build first, it is not ingested into the package repo until the end of the package build.
There was a problem hiding this comment.
That is a great point! I've also thinking about this and I think I might have a way forward to decentralize the process of building and publishing packages. If that works, then dependency management will ultimately boil down to "run the GitHub Action of the dependant package first and then run the Action of the other package."
We can track this further in #45 separately after getting this merged and get the ball rolling for unified archives in new server.
|
(still reading code. no concerns yet but need a bit more reading time) |
khos2ow
force-pushed
the
migrate
branch
2 times, most recently
from
f3b3b24 to
8329568
Compare
No description provided.