starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Automatically check for new releases #576

New Issue
Closed
opened 2025-12-29 16:23:25 +01:00 by adam · 10 comments
adam commented 2025-12-29 16:23:25 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Dec 9, 2016).

NetBox should periodically check for a new release and inform the user if one exists. PR #737 was submitted to introduce this feature, but I'd like to see a more efficient approach. This will require implementing a database model to store temporary configuration information. We'll also need to introduce a permanent configuration variable which allows a user to disable this feature.

Originally created by @jeremystretch on GitHub (Dec 9, 2016). NetBox should periodically check for a new release and inform the user if one exists. PR #737 was submitted to introduce this feature, but I'd like to see a more efficient approach. This will require implementing a database model to store temporary configuration information. We'll also need to introduce a permanent configuration variable which allows a user to disable this feature.
adam added the status: accepted label 2025-12-29 16:23:25 +01:00
adam closed this issue 2025-12-29 16:23:25 +01:00
adam commented 2025-12-29 16:23:26 +01:00
Author
Owner
Copy Link

@aoyawale commented on GitHub (Jan 13, 2017):

can the link be changed to where it gets the new releases? our servers do not have internet connection and I was thinking I can put it in a webserver or our gitlab server.

@aoyawale commented on GitHub (Jan 13, 2017): can the link be changed to where it gets the new releases? our servers do not have internet connection and I was thinking I can put it in a webserver or our gitlab server.
adam commented 2025-12-29 16:23:26 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Aug 24, 2017):

Could we use a browser cookie to store the running version and release date, compare against github and provide notice?

This way you only call to github if the cookie doesn't exist and then it doesn't check again until the cookie expires and you don't need to touch PG.

For those who are running offline versions simply offer "its been X days since your version was released, please check for an update" after the cookie expires and the option to permanently suppress that message.

Detecting a user offline is easy and if you want something drop in, JS and is only ~9kb minified:
https://github.com/hubspot/offline

@bellwood commented on GitHub (Aug 24, 2017): Could we use a browser cookie to store the running version and release date, compare against github and provide notice? This way you only call to github if the cookie doesn't exist and then it doesn't check again until the cookie expires and you don't need to touch PG. For those who are running offline versions simply offer "its been X days since your version was released, please check for an update" after the cookie expires and the option to permanently suppress that message. Detecting a user offline is easy and if you want something drop in, JS and is only ~9kb minified: https://github.com/hubspot/offline
adam commented 2025-12-29 16:23:26 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Aug 24, 2017):

Information about the latest release is conveniently provided by Github through it's API:
https://developer.github.com/v3/repos/releases/#get-the-latest-release

@cimnine commented on GitHub (Aug 24, 2017): Information about the latest release is conveniently provided by Github through it's API: https://developer.github.com/v3/repos/releases/#get-the-latest-release
adam commented 2025-12-29 16:23:26 +01:00
Author
Owner
Copy Link

@lae commented on GitHub (Sep 11, 2017):

I don't think this should be implemented using the GitHub API as it restricts the usage of forks, whether offline or online, and that may or may not be hosted on GitHub (e.g. gitlab as mentioned above).

An implementation that periodically checks a git repo with something like:

git ls-remote --tags https://github.com/digitalocean/netbox.git

would work I think (with a sort/etc to determine latest version), allowing the repo URI to be configured, but not sure if this fits stretch's idea of an efficient approach.

@lae commented on GitHub (Sep 11, 2017): I don't think this should be implemented using the GitHub API as it restricts the usage of forks, whether offline or online, and that may or may not be hosted on GitHub (e.g. gitlab as mentioned above). An implementation that periodically checks a git repo with something like: git ls-remote --tags https://github.com/digitalocean/netbox.git would work I think (with a sort/etc to determine latest version), allowing the repo URI to be configured, but not sure if this fits stretch's idea of an efficient approach.
adam commented 2025-12-29 16:23:26 +01:00
Author
Owner
Copy Link

@MarcHagen commented on GitHub (Dec 29, 2018):

Small footer label? It's a nice issue to figure out.
image

@MarcHagen commented on GitHub (Dec 29, 2018): Small footer label? It's a nice issue to figure out. ![image](https://user-images.githubusercontent.com/980978/50542707-56d7f580-0bc4-11e9-95d9-614668a0f90f.png)
adam commented 2025-12-29 16:23:27 +01:00
Author
Owner
Copy Link

@kobayashi commented on GitHub (Oct 10, 2019):

I think the easiest way is to retrieve from github when opening the page and set label like @MarcHagen shows above.

Just access to the following to get latest release information through github api.
https://api.github.com/repos/netbox-community/netbox/releases/latest

@kobayashi commented on GitHub (Oct 10, 2019): I think the easiest way is to retrieve from github when opening the page and set label like @MarcHagen shows above. Just access to the following to get latest release information through github api. https://api.github.com/repos/netbox-community/netbox/releases/latest
adam commented 2025-12-29 16:23:27 +01:00
Author
Owner
Copy Link

@LBegnaud commented on GitHub (Oct 10, 2019):

I like the idea of supporting forks and thus using the git remote settings, but that doesn't solve the problem of people who download the release zip and follow the docs for updating. Also @kobayashi it was mentioned that netbox team doesn't want an external call on every page load, so it needs to perhaps be a self-contained logic that looks for a git remote, then defaults to this github repo if none found. Then separately have a config option to determine if the background refresh runs or not, and if so then do what Jeremy is suggesting with updating a new db table with the data.

@LBegnaud commented on GitHub (Oct 10, 2019): I like the idea of supporting forks and thus using the git remote settings, but that doesn't solve the problem of people who download the release zip and follow the docs for updating. Also @kobayashi it was mentioned that netbox team doesn't want an external call on every page load, so it needs to perhaps be a self-contained logic that looks for a git remote, then defaults to this github repo if none found. Then separately have a config option to determine if the background refresh runs or not, and if so then do what Jeremy is suggesting with updating a new db table with the data.
adam commented 2025-12-29 16:23:27 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 10, 2019):

Just access to the following to get latest release information through github api.
https://api.github.com/repos/netbox-community/netbox/releases/latest

To address @LBegnaud's concern, introduce a new variable that allows you to re-target to the forked repo.

Something like: REPO="netbox-community/netbox"

Throw it into the javascript instead of the python code to solve issues with it potentially slowing down execution and have a new endpoint for both the UI and the API that returns the status.

@DanSheps commented on GitHub (Oct 10, 2019): > Just access to the following to get latest release information through github api. > https://api.github.com/repos/netbox-community/netbox/releases/latest To address @LBegnaud's concern, introduce a new variable that allows you to re-target to the forked repo. Something like: `REPO="netbox-community/netbox"` Throw it into the javascript instead of the python code to solve issues with it potentially slowing down execution and have a new endpoint for both the UI and the API that returns the status.
adam commented 2025-12-29 16:23:27 +01:00
Author
Owner
Copy Link

@kobayashi commented on GitHub (Oct 11, 2019):

Oh overlooked, thanks to the comment.

@kobayashi commented on GitHub (Oct 11, 2019): Oh overlooked, thanks to the comment.
adam commented 2025-12-29 16:23:27 +01:00
Author
Owner
Copy Link

@LBegnaud commented on GitHub (Oct 11, 2019):

small downside to updating the DB via javascript is that you have to be logged in to do the update check, but i suppose that's not a huge deal and you can still display the cached data before login.

@LBegnaud commented on GitHub (Oct 11, 2019): small downside to updating the DB via javascript is that you have to be logged in to do the update check, but i suppose that's not a huge deal and you can still display the cached data before login.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#576
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?