Closed syuu1228 closed 1 month ago
And here's how it looks like on Actions page: https://github.com/syuu1228/scylla-jmx/actions/runs/9449470120
@avikivity Should we release Scylla-JMX
every time we release Scylladb? or should it be completely independent? Maybe we should just create a release for every push to branch-
?
We should also publish the release when we create a new tag, we should use maybe https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository?tool=cli ,
Implemented. It will be looks like: https://github.com/syuu1228/scylla-jmx/releases/tag/scylla-5.0.2
Note that this will provide .rpm/.deb package but not yum/apt repositories. If we want to provide repositories we cannot use Github release for the purpose. What we need to do is basically same as we do in Jenkins today, build repositories, upload it to some HTTP server like Github Pages or Amazon S3, and point repository URLs on the document.
Or, alternatively we may able to host repositories in Fedora Copr / Launchpad PPA, push source package from Action to Fedora Copr / Launchpad PPA.
@avikivity Should we release
Scylla-JMX
every time we release Scylladb? or should it be completely independent? Maybe we should just create a release for every push tobranch-
?
No. It should have its own independent release cycle. Realistically I expect one release and then nothing.
We should also publish the release when we create a new tag, we should use maybe https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository?tool=cli ,
Implemented. It will be looks like: https://github.com/syuu1228/scylla-jmx/releases/tag/scylla-5.0.2
Note that this will provide .rpm/.deb package but not yum/apt repositories. If we want to provide repositories we cannot use Github release for the purpose. What we need to do is basically same as we do in Jenkins today, build repositories, upload it to some HTTP server like Github Pages or Amazon S3, and point repository URLs on the document.
Or, alternatively we may able to host repositories in Fedora Copr / Launchpad PPA, push source package from Action to Fedora Copr / Launchpad PPA.
I think it's fine, we should document it so that if someone needs the latest release for Scylla-JMX it will use the GitHub repo to download the relevant package
We should also publish the release when we create a new tag, we should use maybe https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository?tool=cli ,
Implemented. It will be looks like: https://github.com/syuu1228/scylla-jmx/releases/tag/scylla-5.0.2
Note that this will provide .rpm/.deb package but not yum/apt repositories. If we want to provide repositories we cannot use Github release for the purpose. What we need to do is basically same as we do in Jenkins today, build repositories, upload it to some HTTP server like Github Pages or Amazon S3, and point repository URLs on the document.
Or, alternatively we may able to host repositories in Fedora Copr / Launchpad PPA, push source package from Action to Fedora Copr / Launchpad PPA.
Best would be to integrate it into the regular yum/apt repositories that contain scylla.rpm. Perhaps a separate task.
We should also publish the release when we create a new tag, we should use maybe https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository?tool=cli ,
Implemented. It will be looks like: https://github.com/syuu1228/scylla-jmx/releases/tag/scylla-5.0.2
Note that this will provide .rpm/.deb package but not yum/apt repositories. If we want to provide repositories we cannot use Github release for the purpose. What we need to do is basically same as we do in Jenkins today, build repositories, upload it to some HTTP server like Github Pages or Amazon S3, and point repository URLs on the document.
Or, alternatively we may able to host repositories in Fedora Copr / Launchpad PPA, push source package from Action to Fedora Copr / Launchpad PPA.
@syuu1228 The release should be only when we push tags not on every push, how is it implemented?
@syuu1228 The release should be only when we push tags not on every push, how is it implemented?
It is implemented as if condition on "Publish packages to release":
if: startsWith(github.ref, 'refs/tags/')
https://github.com/scylladb/scylla-jmx/blob/48b097129426840fdff9705a499f5008ae841281/.github/workflows/build.yml#L53C8-L53C49
Best would be to integrate it into the regular yum/apt repositories that contain scylla.rpm. Perhaps a separate task.
I guess we can append jmx repository on existing scylla .repo / .list something like this:
[scylla]
name=Scylla for Enterprise Linux $releasever - $basearch
baseurl=<URL>
enabled=1
gpgcheck=1
gpgkey=<GPG>
[scylla-generic]
name=Scylla for centos $releasever
baseurl=<URL>
enabled=1
gpgcheck=1
gpgkey=<GPG>
[scylla-jmx]
name=Scylla JMX
baseurl=<URL for JMX>
enabled=1
gpgcheck=1
gpgkey=<GPG for JMX>
But to do so we need construct yum/apt repository somewhere else as I commented above: https://github.com/scylladb/scylla-jmx/pull/238#issuecomment-2161824249 And I agree it should be separated task.
Best would be to integrate it into the regular yum/apt repositories that contain scylla.rpm. Perhaps a separate task.
I guess we can append jmx repository on existing scylla .repo / .list something like this:
[scylla] name=Scylla for Enterprise Linux $releasever - $basearch baseurl=<URL> enabled=1 gpgcheck=1 gpgkey=<GPG> [scylla-generic] name=Scylla for centos $releasever baseurl=<URL> enabled=1 gpgcheck=1 gpgkey=<GPG> [scylla-jmx] name=Scylla JMX baseurl=<URL for JMX> enabled=1 gpgcheck=1 gpgkey=<GPG for JMX>
But to do so we need construct yum/apt repository somewhere else as I commented above: #238 (comment) And I agree it should be separated task.
If we want to have it as part of Scylla.repo, we can do it in pkg (it's the same process we do for scylla-machine-image
@avikivity Can we please merge this?
Submodule update: scylladb/scylladb@2556e902b1c8fd0638a316c4ab5fc25e28a7011f.
Ammm @denesb Why should we update the submodule? we don't use it anymore, right?
Ammm @denesb Why should we update the submodule? we don't use it anymore, right?
or should we keep updating it until we remove it from Scylla?
Ammm @denesb Why should we update the submodule? we don't use it anymore, right?
or should we keep updating it until we remove it from Scylla?
Yes, I think so.
Support building packages in Github Actions. This includes to add support building in Ubuntu, since Github Actions only provides Ubuntu based image for Linux build.
Note that we don't use install-dependencies.sh on Github Actions, since we will use preinstalled Java to speed up installing dependencies.