cd: add package deploy workflow

[oleg-jukovec]

This workflow is intended to run on a tag push for creating and deploying module packages to S3 based repositories.

We don't have the tarantool-luatest package in any public repository for all supported distros. We have to skip the test step until the tarantool-luatest is built at least for S3 repository.

It also fixed tarantool-checks dependency for deb/rpm packages, decreases required tarantool-checks from 3.1 to 2.1.

See other similar pull requests:

tarantool/queue#157 , tarantool/http#164

Closes #43
Closes #124

[oleg-jukovec]

@LeonidVas , please add secrets.RWS_AUTH to the expirationd repository, as it is should be already done for https://github.com/tarantool/queue/ and https://github.com/tarantool/http/ . I don't have permission to do that.

I'll be waiting for approve from you here.

[LeonidVas]

Hi! Thank you for the patchset.
If it works fine I'm ok.
See sevearal comments bellow:

• packages: fix tarantool-checks dependency in commit body:because we because we are
• Do we need to downgrade checks if we don't have check < 3.0.0 in the repositories?
• ci: add package deploy workflow -> cd: ...
• check that all works fine by using https://rws-dev.tarantool.org/

[oleg-jukovec]

Thank you for the review!

* `packages: fix tarantool-checks dependency` in commit body:`because we because we are` 

Thank you, fixed!

* Do we need to downgrade `checks` if we don't have `check` < 3.0.0 in the repositories? 

I don't see any drawbacks, It will just install the >= 3.0.0 from a repo . But if the user needs to use the version 2.1 for some reason then he can do it. Also rocks repo has tarantool checks 2.1.

* `ci: add package deploy workflow` -> `cd: ...` 

We use ci: prefix in the repo.

$ git log | grep "ci\:" ci: add package deploy workflow ci: add a debug Tarantool build ci: fix rocks cache for builds with metrics ci: bump GitHub actions versions to v3 ci: use setup-tarantool for 2.10 ci: add optional metrics and cartridge installation ci: add reusable testing workflow ci: publish API documentation ci: installation, caching and running luatest ci: drop Travis CI integration ci: test and publish rocks using GitHub Actions travis-ci: remove Ubuntu Eoan travis-ci: update distros and repos travis-ci: deploy packages from tagged revisions travis-ci: update distros and repos 

* check that all works fine by using https://rws-dev.tarantool.org/ 

Is there any way to do it safely? It seems to me the safest way would be to wait for the next tag, so as not to overwrite artifacts on the current one. So my plan:

1. Merge the pull request.
2. A new tag and release.
3. Ensure that publishing to rws-dev.tarantool.org works. Fix it if not.

[LeonidVas]

Thank you for the review!

* `packages: fix tarantool-checks dependency` in commit body:`because we because we are` 

Thank you, fixed!

* Do we need to downgrade `checks` if we don't have `check` < 3.0.0 in the repositories? 

I don't see any drawbacks, It will just install the >= 3.0.0 from a repo . But if the user needs to use the version 2.1 for some reason then he can do it. Also rocks repo has tarantool checks 2.1.

While we are not testing it with checks 2.0.0 , we don't know when it will break. Up to you.

* `ci: add package deploy workflow` -> `cd: ...` 

We use ci: prefix in the repo.

It's not correct. Up to you.

$ git log | grep "ci\:" ci: add package deploy workflow ci: add a debug Tarantool build ci: fix rocks cache for builds with metrics ci: bump GitHub actions versions to v3 ci: use setup-tarantool for 2.10 ci: add optional metrics and cartridge installation ci: add reusable testing workflow ci: publish API documentation ci: installation, caching and running luatest ci: drop Travis CI integration ci: test and publish rocks using GitHub Actions travis-ci: remove Ubuntu Eoan travis-ci: update distros and repos travis-ci: deploy packages from tagged revisions travis-ci: update distros and repos 

* check that all works fine by using https://rws-dev.tarantool.org/ 

Is there any way to do it safely? It seems to me the safest way would be to wait for the next tag, so as not to overwrite artifacts on the current one. So my plan:

1. Merge the pull request.
2. A new tag and release.
3. Ensure that publishing to rws-dev.tarantool.org works. Fix it if not.

This is bad practice, and I see no reason to wait for releases in this case. For this purpose, https://rws-dev.tarantool.org was created.

• contact @artembo and ask if the actual version of RWS is deployed for testing
• change the URL
• change the condition to the workflow run every time the PR is updated
• update PR
• check that the CD works fine
• update PR back

If you don't understand how to test, ping me.

[oleg-jukovec]

This is bad practice, and I see no reason to wait for releases in this case. For this purpose, https://rws-dev.tarantool.org was created.

Oh, I got it. Thank you! I didn't pay attention to -dev in https://rws-dev.tarantool.org.

It works. There were two jobs (push + pull request), so duplication 17 + 18 is ok:
https://rws-dev.tarantool.org/release/modules/el/7/x86_64/Packages

[GRISHNOV]

Hi! LGTM