Skip to content
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

Beta / preview images #6

Closed
ian-h-chamberlain opened this issue Sep 21, 2023 · 4 comments
Closed

Beta / preview images #6

ian-h-chamberlain opened this issue Sep 21, 2023 · 4 comments

Comments

@ian-h-chamberlain
Copy link

I realize there may not be a ton of demand for these, as mentioned in #4 (comment) but admittedly, part of the reason I started working on #5 was because I actually wanted to build myself a 3.5 image to start developing in it.

I've gotten a proof of concept building in my fork, and I'm happy to work on upstreaming it if that's something that would be considered useful. There are a couple of considerations I'd like to ask about or at least mention, though:

  • The package list looks different between different release branches, so there would be some additional maintenance there. Right now I have a removed-beta.txt, removed-release.txt and removed-packages.txt (common to both) in my implementation, does that seem like a reasonable approach?

  • Is it worth also having a separate preview (or bc) build? At the moment, it seems like 3.5.0 is the current version for both beta and bc, so maybe just having a single beta is simpler (at least for the time being)?

  • Does the variant for the base image need to be snapshot? I'm a bit confused overall about how Valve's release process works, from looking around on https://steamdeck-atomupd.steamos.cloud/meta/steamos/amd64/ I have gathered a couple things, but since y'all set up this image maybe you understand / can explain it better:

    • snapshot represents Arch packages captured at some date in time (date becomes the buildid, before the . ?)
    • images' variant goes roughly from steamdeck-main -> steamdeck-bc -> steamdeck-beta -> steamdeck. Not sure where steamdeck-staging fits in
    • During a version's lifetime its base snapshot (and buildid) may be updated as it travels through the stabilization process
    • download.sh looks for variant=steamdeck (stable) packages with version=snapshot starting from some base buildid to get the most snapshot used for the most latest stable image

Does that all sound right? For my beta version, I swapped to variant=steamdeck-beta but kept version=snapshot and the same base build, but in the response the version isn't a snapshot:

{
  "minor": {
    "release": "holo",
    "candidates": [
      {
        "image": {
          "product": "steamos",
          "release": "holo",
          "variant": "steamdeck-beta",
          "arch": "amd64",
          "version": "3.5.0",
          "buildid": "20230915.100",
          "checkpoint": false,
          "estimated_size": 0
        },
        "update_path": "steamdeck/20230915.100/steamdeck-20230915.100-3.5.0.raucb"
      }
    ]
  }
}

compare this to the stable version, which is a snapshot:

{
  "minor": {
    "release": "holo",
    "candidates": [
      {
        "image": {
          "product": "steamos",
          "release": "holo",
          "variant": "steamdeck",
          "arch": "amd64",
          "version": "snapshot",
          "buildid": "20230831.1",
          "checkpoint": false,
          "estimated_size": 0
        },
        "update_path": "steamdeck/20230831.1/steamdeck-20230831.1-snapshot.raucb"
      }
    ]
  }
}

It doesn't seem to be a problem but I was just curious if this looks "correct" based on the build process for the stable versions or not.


Phew, that was a lot more writing than I thought this issue would be! Long story short, if you'll take it, I'm happy to take a stab at building beta packages and opening a PR to implement it. If not, I can probably make do on my fork in the meantime. Thanks!

@AAGaming00
Copy link
Member

AAGaming00 commented Sep 22, 2023

I'm a bit confused overall about how Valve's release process works, from looking around on

While you can do it that way, if you want to guarantee you get the exact same data the steam deck updater dameon works then you should look at how download.sh implements it. you need to provide a correct version that was released on the branch you choose for it to work correctly.
nvm I misunderstood

you have to pass in a previous version for your selected channel as "buildid" for it to work. it's a diff based system, so you get nothing if you pass the current version.

@AAGaming00
Copy link
Member

And yes we are interested in Beta images, maybe Main too

@ian-h-chamberlain
Copy link
Author

Just for posterity I did a bit of digging into how updates are fetched and posted my findings here: #5 (comment)

From what I can tell it seems like snapshot is the default used for patch updates, even on stable, which is a bit confusing/surprising but at least I think we should be able to use the same value when looking for any variant, beta, stable or main.

@TrainDoctor
Copy link
Member

For now we are not planning on producing beta or preview images as an option right now just due to the complexity. If there is further interest expressed then it's definitely possible but it just wouldn't be of much benefit to us right now.

@TrainDoctor TrainDoctor closed this as not planned Won't fix, can't repro, duplicate, stale Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants