Bringing changes from sidekiq-alive-next

[arturictus]

This change adds the following:

• sidekiq 7 support
• Updates to CI to test using multiple sidekiq versions
• Custom callback to run on shitdown (can be used to clean the queues)
• Some minor tweaks and refactors

[arturictus]

Hi @andrcuns, I'm bringing all the goodies that I found in your master branch. I let you as reviewer in the GitHub actions, we can talk about it if you are interested into getting access to this repo.

[andrcuns]

Hi @andrcuns, I'm bringing all the goodies that I found in your master branch. I let you as reviewer in the GitHub actions, we can talk about it if you are interested into getting access to this repo.

@arturictus thanks, that would be cool to release these under this gem for everyone else to use. Though since I mostly did the changes for my own usecase, some of them probably should be changed a bit, like:

• Changes for sidekiq >= 7 are not backwards compatible and it's probably best to hold off the rack upgrade to v3 as it's not actually currently compatible with latest Rails version.

I can try and help out in some capacity with maintaining this project at some capacity given I extensively use it in on of my other projects and it has been very helpful.

[arturictus]

Hi @andrcuns, In my case I'm not using much this gem any more and I'm missing the feedback of using it in production. Would be nice to have some help from someone that is using it live in production. do you want me to give you access to the repo?

[andrcuns]

@arturictus Sure! Then I can try and update this branch to be a bit more backwards compatible sometime next week.

[arturictus]

@arturictus Sure! Then I can try and update this branch to be a bit more backwards compatible sometime next week.

Cool!!, I give you access :)

[arturictus]

Hey @andrcuns, this looks great! I added the secret: GEM_HOST_API_KEY What is the RELEASE_SSH_KEY? do we need it to publish the gem or it's for the release commit?

[andrcuns]

Hey @andrcuns, this looks great! I added the secret: GEM_HOST_API_KEY What is the RELEASE_SSH_KEY? do we need it to publish the gem or it's for the release commit?

It is used for the manual release action in the step which automatically updates the version number, creates a tag and then pushed it back to repo:

-
        name: Update version
        run: |
          git config user.name github-actions
          git config user.email github-actions@github.com
          bundle config unset deployment
          bundle exec rake "version[${{ inputs.version }}]" && git push
      -
        name: Create tag and push to rubygems
        run: bundle exec rake release
        env:
          GEM_HOST_API_KEY: ${{ secrets.GEM_HOST_API_KEY }}

Basically it's ssh key that has access to push to repo.

It doesn't have to be your personal key. The way I did it, generated new key-pair and added public key as deploy key under security settings:

and added private key as secret:

It's not strictly necessary but it's nice to be able to have a full new version release cycle implemented via github actions

[arturictus]

Hey @andrcuns, this looks great! I added the secret: GEM_HOST_API_KEY What is the RELEASE_SSH_KEY? do we need it to publish the gem or it's for the release commit?

It is used for the manual release action in the step which automatically updates the version number, creates a tag and then pushed it back to repo:

-
        name: Update version
        run: |
          git config user.name github-actions
          git config user.email github-actions@github.com
          bundle config unset deployment
          bundle exec rake "version[${{ inputs.version }}]" && git push
      -
        name: Create tag and push to rubygems
        run: bundle exec rake release
        env:
          GEM_HOST_API_KEY: ${{ secrets.GEM_HOST_API_KEY }}

Basically it's ssh key that has access to push to repo.

It doesn't have to be your personal key. The way I did it, generated new key-pair and added public key as deploy key under security settings: and added private key as secret:

It's not strictly necessary but it's nice to be able to have a full new version release cycle implemented via github actions

Done and Done

[arturictus]

Added the secrets. @andrcuns all ready to press merge. do you wanna do the honors?

[andrcuns]

Added the secrets. @andrcuns all ready to press merge. do you wanna do the honors?

Awesome, let's do it 🚀

[andrcuns]

@arturictus What do You think about testing the release flow and releasing a new version?

It's a pretty substantial change, while there should be no breaking changes, not sure if it should be a minor or major release. Probably still minor, since it basically just expands support and refactors some things.

[arturictus]

@andrcuns I think we can do a minor, let's try the releases 🤞

[benlangfeld]

https://github.com/arturictus/sidekiq_alive/pull/80 fixes a bug that is present in the Sidekiq 7 compatibility here.