Difficulty building from source, my RPMs

Development
21

@laurent Similarly, I am sure it could be largely automated, but the current process is not egregious. This is the general process:

Note, COPR is a Fedora Project -sponsored build system that properly isolates package builds (the build user doesn't have access to root, the system is a clean chroot, etc). You can even turn off your build's access to the internet, which if it were a truly proper build, that is what I would do, but ... nodejs makes that very challenging. OpenSUSE also has a similar build system available to the public which is very good.

If minor update: e.g., 2.2.6 to 2.2.7

  1. Bump the release in joplin.spec, but mark it as a test build.
  2. Update the release log in contributed org.joplinapp.joplin.metainfo.xml file. Reference my contribs here.
  3. Rebundle and commit the joplin-2.2-contrib.tar.gz to include that updated .metainfo.xml file.
  4. Upload .spec to COPR build system TEST repo, and press a button to build for CentOS (8, 9), RHEL (8), Fedora (33, 34, rawhide, and the upcoming 35), and then OpenSUSE (Leap 15.2, 15.3, and Tumbleweed).
  5. Resolve any failure ... there haven't been many until 2.3.3 when we now see a Python2 regressive requirement.
  6. Test drive Joplin test build on my own machine. I have reached out to the community to test on OpenSUSE in the past, but I haven't done that in awhile because ... it didn't need to be done.
  7. Passes testing, then I flip the testing bit to off in the .spec file.
  8. Upload .spec to COPR build system PRODUCTION repo and build to all those platforms (but a reduced set).
  9. Wait for any complaints from the community in case I broke something. This is rare but it happens quickly since the COPR repos automate delivery to everyone's desktops using their package managers. This is the whole reason I do this, so that folks can update their desktops and Joplin just shows up all properly packaged and tidy.

For major releases, e.g., 2.2.7 to 2.3.3, I only add more testing. And in this case (2.3.3 ad 2.3.5) I had to revamp the spec file to use the upstream binary pre-built AppImage as the "source", etc.

And it should be noted that I don't make unblessed tagged releases available to the general public, but I do like to test some pre-release builds and whatnot. Especially if it is a .Y release coming up.

If the upstream source is hunky-dorey, this process takes 15 minutes of manual labor, not including my testing. And probably an hour of actual time (waiting for the builds to complete, downloading, testing, and then once accepted, waiting for production builds to complete).

So ... can all this be automated? Hands-free? With the last year or so of builds, mostly. The last version of course not unless I accept pre-builds as the norm moving forward (I don't want to do that). The actual building process is not hard if running smoothly. But I do like to test before I hand packages to strangers. I have had ... "incidents" ... in my dark past where I broke people (only a couple minor moments with Joplin). A lot of people. I don't want to ever do that again. :slight_smile:

Just added this process to my github readme. And it should be noted that I am only building and packaging Joplin desktop. I don't test or build the CLI or server.