Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: overhaul workflows to publish packages to new archive infra #38
feat: overhaul workflows to publish packages to new archive infra #38
Changes from all commits
cb8d6da
b13314b
22a22b4
60be3e0
80b0d0f
ad4a55a
7ac2ce4
691746c
6b83419
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: can you explain what
SUITE
models? How is it different than stage?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SUITE
is introduced to be able to support multiple Regolith version per releaseSTAGE
. Suite is, very loosely, the same as Stage with one big difference. Stage is release stage from the SDLC point of view, but Suite is from the point of view of the published debian package archives.The corresponding values and mappings are as follow:
experimental
experimental
main
unstable
unstable
main
testing
testing
main
release-current
stable
main
release-3_2
stable
v3.2
release-3_1
stable
v3.1
Or in other words, in the scope of deb config line:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LMK if this is not the case:
SUITE
is a debian repo concept. We would not necessarily use or need it for other packaging systems.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: can you elaborate on this? What would qualify as an internal dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually needed 😄 . Presently we have one such case:
sway-regolith
depends ontrawldb
. The current approach is to break a build into two phases, for stages that doesn't already have some version oftrawldb
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.