Skip to content

Conversation

@daniellacosse
Copy link
Contributor

@daniellacosse daniellacosse commented Feb 20, 2025

Screenshot 2025-03-06 at 2 43 06 PM

@daniellacosse daniellacosse added the needs test Pull requests that require tests label Feb 20, 2025
@daniellacosse daniellacosse marked this pull request as ready for review February 21, 2025 04:59
@daniellacosse daniellacosse requested a review from a team as a code owner February 21, 2025 04:59
Copy link
Collaborator

@fortuna fortuna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What action do we expect from the user? Servers are auto-updated, even the ones installed with the script.

@daniellacosse
Copy link
Contributor Author

What action do we expect from the user? Servers are auto-updated, even the ones installed with the script.

Somebody (hopefully not @sbruens) is going to write an article that this will link to.

@fortuna
Copy link
Collaborator

fortuna commented Feb 21, 2025

An article to do what? The provider doesn’t need (or should) manually upgrade the server, unless they used outline-ss-server directly, in which case they don’t use the manager.

Am I missing anything?
Having this message will be confusing and may lead to providers shooting themselves in the foot. We should probably revert this.

@daniellacosse daniellacosse enabled auto-merge (squash) February 21, 2025 17:56
@daniellacosse daniellacosse removed the needs test Pull requests that require tests label Mar 6, 2025
@daniellacosse daniellacosse requested review from fortuna and sbruens March 6, 2025 19:19
@github-actions github-actions bot added size/M and removed size/S labels Mar 6, 2025
Copy link
Contributor

@sbruens sbruens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main comment I have is on building in a delay for these notifications. Watchtower updates check every hour IIRC, and for users on auto-update (the majority of users) there is actually nothing they should do. I don't think those users should ever see this notification because it will create confusion. The only way I think we can detect that (without adding the check to the server side) is by adding in some delay.

@daniellacosse
Copy link
Contributor Author

The main comment I have is on building in a delay for these notifications. Watchtower updates check every hour IIRC, and for users on auto-update (the majority of users) there is actually nothing they should do. I don't think those users should ever see this notification because it will create confusion. The only way I think we can detect that (without adding the check to the server side) is by adding in some delay.

So you're saying we should wait until every hour on the hour before making this check? Or maybe on the quarter hour?

@sbruens
Copy link
Contributor

sbruens commented Mar 6, 2025

The main comment I have is on building in a delay for these notifications. Watchtower updates check every hour IIRC, and for users on auto-update (the majority of users) there is actually nothing they should do. I don't think those users should ever see this notification because it will create confusion. The only way I think we can detect that (without adding the check to the server side) is by adding in some delay.

So you're saying we should wait until every hour on the hour before making this check? Or maybe on the quarter hour?

It's not necessarily on the hour, but it just polls every hour (see https://containrrr.dev/watchtower/arguments/#poll_interval). I think there should just be a delay. If we check now and the server requires an update, we should try again in at least an hour and if it's still required, then auto-update through watchtower didn't upgrade the image. We can be more liberal and maybe make it a few hours.

@sbruens
Copy link
Contributor

sbruens commented Mar 6, 2025

Or check the image information from quay.io to see how old the image is and base it on that timestamp, if that's easier. Again, if it's a few hours old, then we know there wasn't an auto-update. That might actually be easier to implement.

@github-actions github-actions bot added size/L and removed size/M labels Mar 7, 2025
@daniellacosse daniellacosse requested a review from sbruens March 7, 2025 18:17
@daniellacosse daniellacosse requested a review from sbruens March 7, 2025 22:20
);

if (!(response.status === 200 && response.ok)) {
return Promise.reject(response.statusText);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me set this up in ESLint.

}

// A tag indicating a version of the server code
export interface VersionTag {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove duplicate interface?

async getLatestAvailableUpdate(): Promise<server.VersionTag> {
const recentVersionTags = await fetchRecentShadowboxVersionTags();

const latestVersionTag = recentVersionTags.find(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the quay documentation, I'm not sure we want to just blindly grab the latest numbered version. It assumes the latest version is good. That could be a problem if the highest version is not stable, e.g. in the event of a rollback.

It would be slightly better to have the logic look at the active stable tag and find the version name for that one, which you can cross-reference by manifest_digest. For example, from this query you can see that the latest stable version is 1.12.3.

$ curl -s "https://quay.io/api/v1/repository/outline/shadowbox/tag/?onlyActiveTags=true" | jq -r '.tags[] | "\(.manifest_digest) \(.name)"'
sha256:545c6f7c7261bb30ae1dffe24a6fca5f8512f5d17c72cfb9e410e7e655444e62 stable
sha256:545c6f7c7261bb30ae1dffe24a6fca5f8512f5d17c72cfb9e410e7e655444e62 v1.12.3
sha256:545c6f7c7261bb30ae1dffe24a6fca5f8512f5d17c72cfb9e410e7e655444e62 canary
sha256:545c6f7c7261bb30ae1dffe24a6fca5f8512f5d17c72cfb9e410e7e655444e62 v1.12.3-rc1
sha256:6f430dcce690684085e9445421146e8622c48bb9d3b0dec3c8bd9bbfad6daf01 v1.12.2
sha256:6f430dcce690684085e9445421146e8622c48bb9d3b0dec3c8bd9bbfad6daf01 v1.12.2-rc2
sha256:6cf1296d4d3ac715c530868e351e474cd302a1e56b55aacf14f1d5ee02a44f2d v1.12.2-rc1
...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yeah I was worried about that. Let me think about the best way to do this, as per @fortuna's suggestion.

getAccessKey(accessKeyId: AccessKeyId): Promise<AccessKey>;

// Return version tag of latest available update
getLatestAvailableUpdate?: () => Promise<VersionTag>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this optional? This can start making the interface complex. I'd rather make all properties required. Alternatively (and perhaps preferably), declare it only on the ManualServer interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I was being lazy. I'll make it required.

Copy link
Collaborator

@fortuna fortuna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is adding a fresh new dependency to Quay.io, which goes against our goal to not be tied to them.

I recommend against using their api. Use the docker api instead.

Alternatively, we could publish the latest somewhere that we can simply fetch with https.

daniellacosse and others added 2 commits March 13, 2025 12:51
Co-authored-by: Sander Bruens <sbruens@users.noreply.github.com>
Co-authored-by: Sander Bruens <sbruens@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants