Discussion: Release process

[emilecantin]

I'd like to start a discussion regarding the release process. I know we currently use the even=stable, odd=experimental convention, but is there a reason why all of them are marked as "pre-release"?

I think it'd be way easier to actually use that pre-release feature for experimental releases. That way, we could promote experimental features to stable once they've been tested; no need to cut an additional release.

It'd also make it easier to consume the list of releases from a script. I'll probably need this as I improve on the RPI image build.

[Orob-Maslow]

Perhaps it is a matter of definition. Only at 0.932 did the even odd thing start. I understand release to mean good for the general population while prerelease is not fully vetted... However rigorous that is. What would be a better description that should be used?

At what point does it move to 1.0?

[emilecantin]

No, I think that description is fine. It's just that when you go on the Releases page, everything there is labelled "pre-release", which is the default value for that flag. I think we should make use of that flag, instead of layering our own convention on top of it.

[Orob-Maslow]

Agree. Even or odd, if stable, it should be a release. If testing new or specialized features, then prerelease... is there also a major/minor release approach?

[madgrizzle]

I'm open to any option that works and prefer the "correct" way, whatever that is.

It was easy to implement the even-odd thing to solve the problem of releasing a release that breaks webcontrol.. including upgrade/downgrade. I wanted to make it so people could opt-in to testing and those that just want stability, don't even see releases that are not "tested".

As for the pre-release tag, I just never used it.. nothing against it.

[emilecantin]

As of right now, all the releases are marked as "pre-release". I think it wouldn't be too hard to go through them and remove the "pre-release" flag on the stable ones, as a first step.

The "isExperimental" method in the update code could then be updated to look at the prerelease flag instead of parsing the version number, and that would bring us to the exact behaviour we have today.

The main differences would be that it'd then be possible to "promote" a release as stable (or not, no obligation), and it'd be a bit clearer for people browsing the releases page what's what.

[madgrizzle]

Is there any real reason to keep all the old releases?

[emilecantin]

Not many. You mentioned the downgrade possibility earlier, and it could also help pinpoint when a possible regression was introduced.

Having the history that goes with the releases (the description of the changes on each release) is very valuable, though. I refer to it all the time in other open-source projects.

I don't think it's a significant cost to keep them, so I don't really see a great reason to get rid of them.

[madgrizzle]

I was just thinking of ease of moving forward using pre-release tag, but I'm sure we could just add another conditional to make sure the version number is greater than 0.9335 (or whatever) before tagging it in the release manager as an "experimental".

[emilecantin]

Not sure why you'd need to do that. What I had in mind was pre-release === experimental. No need to parse the version number or anything. The only prerequisite would be to manually go into the old releases and correct the flag for all of them. There's only 18 releases right now; shouldn't take very long. I can do it myself if you give me access.

[madgrizzle]

I went ahead and fixed it.

Regardless, you are a member of the organization, but don't have access to the WebControl repo, correct? When I brought the repo over, it brought over all the collaborators as well (which you weren't one of, I guess). Do I need to specifically add you to the WebControl repo? Or do we need to create a team or something for the organization? I'm new to all this.

[emilecantin]

Awesome, thank you.

And yes, that's right; I only have read access to the repo, and no, I wasn't a collaborator before (just now getting involved in this). I think creating a team would be the best approach for this.

[madgrizzle]

I'm creating a final release on the madgrizzle repo marked as stable (0.94, even digit). I did a PR to pull in all changes from my fork into this repo so they should be identical. I'd like to get the same release up on this repo as well and will work on modifying my build scripts to build and publish here. However, I'd like to discuss if there are alternative ways to do the builds.

Right now I build for RPI, linux, Win32 and Win64. The RPI build runs on a dedicated RPI. The Win64 build runs on a win64 computer and the linux and Win32 builds run in VMs on that same win64 computer. The linux machine builds the firmwares and then makes them available on its ftp server for the RPI, Win32, and Win64 machines to download them (so they don't have to build the firmwares). I don't launch the RPI, Win32, or Win64 build scripts until the linux build script has finished with the firmware compilations. After all the builds are completed, each machine uploads them via FTP to the linux machine's "release" directory. On the linux machine, I then run a script that creates a github release and uploads the builds. Finally, I edit the release via web to add a title and description.

Any idea on ways to improve this or maybe, possibly, put it all in the cloud? The builds are pyinstaller based. I'm not sure if there's a way to cross-compile, etc. so it runs on just one machine. Or do we need to maintain VMs and if so, is there a VM for an RPI?

[emilecantin]

I think the first step here would be to actually publish these scripts, so people could build releases on their own.

Then, we could look at integrating a continuous integration tool (like TravisCI); there are a handful out there that are free for open-source projects. This would be a "cloud build", in your words. They're usually able to build in a few different environments, Travis even has macOS environments available.

I'm not really familiar with pyinstaller, so I'm not sure what it actually needs to build natively; unless you wrote some native code yourself as part of WebControl, we can probably get away with just downloading pre-built versions of every dependency.

Compiling software for the Raspberry Pi is something that's pretty common; depending on our specific needs (again, need to research pyinstaller) we may have many options here. Worst case scenario would be to move all the dependency management to the pre-built image, might make things a lot simpler from the WebControl side.

For the firmware build, I think that should actually live under the firmware's repos; the release script would only download the latest release binary from the firmware repo directly. That might not be possible, however, as we might not have control over all versions (notably the stock one); in these cases I think we should either maintain a fork that has the CI integration, or put in a pull request for that to Bar so we can pull from the "true" source.

[madgrizzle]

I think the first step here would be to actually publish these scripts, so people could build releases on their own.

The .spec files to build the pyinstaller releases are already part of the repo. main.spec is the spec file for the singlefile variant and main-onedir.spec is for the singledirectory variant. I use the same spec files for each architecture and it seems to ignore the architecture-specific adds in them. The user will have to adjust the pathex within the file to make it work on their installation, but that should be simple enough to do.

What I haven't pushed is the scripts I used to semi-automate the process. That's because its specific to how my build environment is and secondary that it includes things like FTP passwords and such.

For the firmware build, I think that should actually live under the firmware's repos; the release script would only download the latest release binary from the firmware repo directly.

This is the challenge because the last release was nearly a year and a half ago. Only bar can make the releases, afaik.

in these cases I think we should either maintain a fork that has the CI integration, or put in a pull request for that to Bar so we can pull from the "true" source.

I really would like to see a single firmware that has both triangular calibration (i.e, stock) and holey calibration contained in one. If we do this, then I think we can convince bar to make it the official release if we demonstrate that it also works with ground control, which knows nothing of holey calibration. It's not impossible, or even hard, but its not trivial and will take time and testing.

[madgrizzle]

I'm not really familiar with pyinstaller, so I'm not sure what it actually needs to build natively; unless you wrote some native code yourself as part of WebControl, we can probably get away with just downloading pre-built versions of every dependency.

Afaik, you need a complete installation with all dependents installed on each architecture, to the extent that the program can actually run, in order to use pyinstaller to compile the program. I'm not sure how all this can be done in the cloud. Travis-CI is completely new to me. I understand what it does, but how to set it up is way beyond me.

[madgrizzle]

And so it dawned on me that I didn't create a development branch to put the recent changes into. So what's the "github" way of doing that. Just call it development, develop, devel, dev? What about the default tag? Does that make a difference. We want all PRs to be to the development branch, correct?

[emilecantin]

There are many philosophies on the "proper" way of branching; and it's a subject of continuous debate, mostly because everyone has slightly different requirements, so slight different definitions of "best".

One way to do this is to use git-flow, and I've used it before on very active projects, but I'd argue it's overkill for our needs. Unless you find yourself really needing it, I'd recommend keeping the master branch on the "bleeding edge" (all completed features / bugfixes), and having feature development / bug fixes in feature branches, which is already accomplished through the Pull Request workflow. More stable stuff would go in individual release branches / tags. The one thing that'd need to change in our existing workflow is that everyone, even maintainers, go through the Pull Request flow for all changes, except very trivial or urgent changes.

[emilecantin]

Also, I've managed to build something with pyinstaller, but I'm really not sure it's the right thing.

Care to share how you invoke it in your build scripts?

[madgrizzle]

This is all I do to build the single directory version, and create a new release file.. single file is the same, just different spec file and different renaming (there's probably a way in the spec file to get things named the proper way from the start, but this worked nevertheless).

pyinstaller main-onedir.spec cd dist/main mv main webcontrol cd .. mv main webcontrol cd webcontrol touch webcontrol-rpi-singledirectory.tar.gz tar -zcvf webcontrol-rpi-singledirectory.tar.gz --exclude=webcontrol-rpi-singledirectory.tar.gz .

[emilecantin]

Yeah, I've tried with the main-onedir.spec file, and I managed to build something that starts, at least. I didn't need to rename the executable, though, it came out as webcontrol right out of the gate. The folder is still named main, though.

Anyway, I'm trying to set up Travis in #149, but I need you to approve access to the organization (you should have an email about that).

[madgrizzle]

Done.. I think

[emilecantin]

Yeah, it's active, but only repo admins can add it (annoyingly). Can you add it here: https://travis-ci.org/github/WebControlCNC/WebControl ? Thanks!

[madgrizzle]

I logged in but says "You don't have sufficient rights to enable this repo on Travis. Please contact the admin to enable it or to receive admin rights yourself."

[emilecantin]

It's telling me the same thing, weird.

[madgrizzle]

Well, I went in and under my settings, I clicked on the webcontrolcnc organization and it showed two repos with switches.. i enabled the switches, but when I clicked settings, it says takes me to the travis repo and pops up an error message "Oh No! Your permissions are insufficient to access this repository's settings"

[emilecantin]

Okay, I don't know what changed, but I refreshed the page and I was able to trigger a build. Success!

[madgrizzle]

So, can this build win32 files? I assume arm (rpi) is not feasible.

[zaneclaes]

Fwiw, I run a BuildKite cluster already. It should be able to handle CI needs and I have plenty of experience implementing it..., if Travis becomes too much of a headache lmk.

On Fri, May 22, 2020 at 2:39 PM madgrizzle notifications@github.com wrote:

So, can this build win32 files? I assume arm (rpi) is not feasible.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WebControlCNC/WebControl/issues/139#issuecomment-632900594, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP47VP5NW2BPY54X3GOKC3RS3PHTANCNFSM4NENV64A .

[emilecantin]

@madgrizzle Win32 I'm not sure, but Win64 will very probably work, as well as macOS. I'm starting with the easiest part, Linux on amd64. Arm will probably work as well, depending on the specific version we need; I'll test that once I have the whole pipeline working with regular Linux.

[emilecantin]

Hey, looks like it's working! Off to test ARM now.

[emilecantin]

Yeah, looking into this, having to compile the firmware with the release is an additional complication; it'd be way easier if I could just download the binary firmware releases directly. @madgrizzle I opened a pull request on your firmware repo do do this; it'll need some configuration on the Travis side as well, which I can't do myself (as it's not in the WebControl org).

[madgrizzle]

If I move the repo here, would that solve it?

[emilecantin]

We'll need to do the same little dance we did earlier today to enable Travis on the repo as well (altough I'm not exactly sure what we did).

[emilecantin]

And while I'm looking into it, it looks like we're building a pretty old version for the stock firmware (jan 2019); there are some commits on master from this week...

EDIT: Nevermind, just looked at the releases; we're still building the latest.

[madgrizzle]

My firmware repo has been moved. I 'enabled' it in Travis

[emilecantin]

Can you also set the same permissions for this one, please?

[madgrizzle]

We are building specific points.. There's lots of commits that have been made, but none have made it into an official release. Bar hasn't built a release since Jan '19.

These are the sha's for the branches being built:

holey: 950fb23396171cbd456c2d4149455cc45f5e6bc3 (madgrizzle/Firmware - holey branch) stock: e1e0d020fff1f4f7c6b403a26a85a16546b7e15b (MaslowCNC/Firmware - master branch) custom: bf4350ffd9bc154832505fc0125abd2c4c04dba7 (madgrizzle/Firmware - don't recall precisely branch)

I think the sha's represent a point in time as I believe they change after a commit?

We can do away with the custom in reality since I've stopped work on it.

[madgrizzle]

Doh.. that explains why still having issues with fake_servo. I didn't update the sha for the latest commit. holey should be: e9cc445cfdfddcee4da97617e9d407cdc52d29b7

[emilecantin]

Yes, I saw that. I think the approach I'm going to take to build these different versions is the following:

• Merge the changes from upstream (and try to keep up from time to time in the future)
• Create "release" branches on these 3 specific commits
• Build these 3 branches in the Travis build, and upload the hex files in an actual release

Then I'll able to simply fetch the latest release (or even a specific one) when building WebControl.

[madgrizzle]

and stock is based on Jan 23, 2019 commit.. wee-bit behind.

[emilecantin]

No, we're using the actual commit on which the release is based.

[madgrizzle]

don't worry about the custom branch.. just build what's there until we pull it out of webcontrol entirely.

I still want to see a unified firmware though :)

[emilecantin]

It's really no additional effort to include that one; I'll need write access to the repo, though. It doesn't seem to have the same permissions as the WebControl one.

[madgrizzle]

Should be fixed now.

[emilecantin]

Okay, we should now be synced up with the upstream repo. master on the firmware repo should always track master on maslowcnc/firmware; that'll make it way easier. I moved your previous changes on master to the develop/madgrizzle branch, if you're looking for them.

[emilecantin]

@madgrizzle if you're still here, I have one issue: I can't manage the build settings anymore, but I need to add a Github token in order to create a release from the build. (it can wait, it's getting late around here anyway).

[madgrizzle]

Late here as well (east coast) you may need to talk me through it. I'm going out of town tomorrow, but not sure what time I'm leaving or (after arriving) when I'll be able to get on my laptop.

[emilecantin]

East coast here as well! Québec, Canada.

Go here, and create a token with the following permissions: repo, write:packages (read:packages will be added automatically). Once saved, you'll get back to the list of tokens, and the newly created one will appear in green. There's a long hexadecimal string, that's the token. Copy it.

Now go here, and in the "Environment Variables" section, add one with the name GITHUB_TOKEN and paste your token as the value. Click "add", and it should be good. Let me know when it's done, and I'll trigger another build to test.

[madgrizzle]

Done.. why does this need to be done for the firmware, but not the other two?

[madgrizzle]

And how did I manage to 'assign' this to @zaneclaes ? I don't recall doing so..