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

installation
1

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!

1 Like
2

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

It won’t repair a broken sidekiq/setup.

1 Like
3

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

4

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

1 Like
5

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

6

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:

2 Likes
7

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?

https://github.com/discourse/discourse/releases

8

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.

4 Likes
9

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: .

10

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:

2 Likes
11

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?

12

I’m getting this issue now as the OP. I installed the tests-passed branch.
I started up sidekiq with bundle exec sidekiq then restarted the rails server while sidekiq was running, and that didn’t solve it.

I’m thinking this is related to the issue I’m getting with a plugin where when I run the server I received the error:

uninitialized constant Jobs:: Jobs::Scheduled
Did you mean? Scheduler (NameError)

** INCOMPATIBLE PLUGIN **

2 Likes