A check for updates has not been performed lately. Ensure sidekiq is running

A check for updates has not been performed lately. Ensure sidekiq is running.

I tried this

and it didn’t work any help would be appreciated!

What do you mean it didn’t work? That command will upgrade your site.

It won’t repair a broken sidekiq/setup.

How did you install Discourse? Is this a Docker-based standard install?

Turns out all I had to do was wait 12 hours or so and it worked :sweat_smile:

I have a standard / local / dev install. What’s the procedure to update?

If you have a dev install, pull the repository, run migrations and restart the server. These steps are very similar to the initial installation.

Note that a dev install should not be used in production. If the instance is publicly accessible, the proper upgrade procedure is to take a backup, install using these instructions, and restore the backup :slight_smile:

Ah, yes, of course. Did not even think of that since we were targeting a certain release we are about to install on our production system vs. whatever happens to be the Github master right now.

But, it looks as if the currently recommended update, 2.3.0.beta2 is what you get with the current master, correct?

You should never install master directly. Always use tests-passed, the default; beta, for a more regular release cadence (every few weeks) with no changes in-between; or stable, if you absolutely require minimal changes between rarer, larger releases and are willing to live with only security and major bugfixes in between.

Thanks for being so helpful, @fefrei! So beta is about 10 commits past v2.3.0.beta2, which ends on this commit?

0e8dbbd8e48363e4a771de1c65dc5c8b4cdf282b 

You recommend pulling beta to a local beta branch, resetting the branch to the above commit, and … working with that, or merging that into my master?

I’m trying to get a sandbox of v2.3.0.beta2 to test on before installing that version on our live system. Eager to learn the best practice here :smiley: .

I’d just do a normal Docker-based install locally. The closer you are to your production install, the less surprises when moving to production :grinning_face:

Right, I wondered about that in hindsight, but I’m also developing a couple plugins … will I find it annoying being in a Docker Container?

Je rencontre ce problème maintenant en tant que demandeur initial. J’ai installé la branche tests-passed.
J’ai lancé sidekiq avec bundle exec sidekiq, puis redémarré le serveur Rails pendant que sidekiq était en cours d’exécution, mais cela n’a pas résolu le problème.

Je pense que cela est lié à l’erreur que je rencontre avec un plugin, où lors du démarrage du serveur, j’obtiens l’erreur :

Constante non initialisée Jobs:: Jobs::Scheduled
Voulez-vous dire ? Scheduler (NameError)

** PLUGIN INCOMPATIBLE **