-
|
Hi, it's me again. I have a few more questions about your template. I hope the questions make sense. I'm just learning about GitHub Actions. It looks like I create .github/worflows and each yml file is a GitHub Action that gets triggered on certain events or can be run manually.
It looks like the conditions on which the installers are built are when a push or a pull is done to main branch. My question here is probably due to my ignorance of Git and GitHub, but only one of these makes sense. If I'm ready for a release, I would merge the selected branches to main, test things out locally, and push it to GitHub. If I read this right, this would run the actions. But I don't understand triggering on a pull request. The Linux version has yet another trigger called workflow_dispatch. I don't know what that is, but why is it only for Linux? I see that the end result is you wind up with assets in the Releases area. I don't understand what controls that bit of magic; how does GitHub know that the installer is an asset? Even more mysterious is how the workflows are tied to a release. I though they were triggered by a push or a pull request. Is it the release process that merges a branch into main and that causes the push or pull? I think I'm missing a lot of conventions that probably explain how all the magic works. Thanks for your patience. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
Yup, all of that is GitHub Actions, you can find the docs with Google etc. Look at the "on" section for triggers, you can comment them out with a # character. The workflow_dispatch enables a button to trigger them in the GitHub UI. Just didn't bother putting it on the other jobs yet. You can and should absolutely tweak the jobs to do what you want. RIght out of the gate, you may run out of minutes quickly if you are using a paid plan with a private repo. The release is done via the Update Automatic Release step, with the marvinpinto/action-automatic-releases@latest action. That's what copies the final files to the releases section. All of this is GitHub Actions. All I do in the template is try to show that a) it's possible and b) as a starting place for whatever configuration you want. I'm going to be posting some updates, esp. for adding macOS signing, hopefully this week. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, I have been chasing down GitHub Actions on Google. However, using Google to try to answer "Why did wiverson put 'on: push: branches [main]' and 'on: pull_request: branches: [main]'" can be trickier than you might imagine. On the other hand, I don't expect you to explain all of Git and GitHub to me, either. I wasn't reading the yml file right. I was thinking it was a GitHub action, rather than that it's a workflow that uses actions. Mentioning the marvinpinto automatic-releases action fixed that. There's still I a lot I don't know about doing releases on GitHub, but that's not your problem. As long as I'm the one doing the releases, it looks like I might only need a GitHub action to produce the Linux installer, so let's see how far I can get on that. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW the Linux installer stuff is the stuff I've tested the least - I have easy access to and use macOS and Windows all the time, but I only use Linux for server-side stuff w/o a GUI. If you find any Linux issues LMK. |
Beta Was this translation helpful? Give feedback.
-
|
Will do! |
Beta Was this translation helpful? Give feedback.
-
|
I finally managed to create a release with Windows and Linux (no Mac yet). My first attempt tried to use your maven-build-installer-unix.yml. It failed with an obscure error. It turned out to be a typo in my linux-jpackage.txt file, but it quickly became evident that using a runner to debug the build process wasn't going to fly. I wound up eventually building in on Ubuntu running on VirtualBox. It's good I did. Java's motto was "write once, run anywhere". Nope. I have a few important platform dependencies that caused the Linux version to fail. One of them was in the Desktop class you had mentioned. Even after checking that Desktop is supported and that the BROWSE action is supported, Desktop.getDesktop().browse() causes Linux programs to hang. I also made a few changes to my linux-jpackage.txt based on the things I learned by actually installing the application. The moral of the story is that you can't really expect to release anything on a platform where the software and the installation are not tested. But if I have access to all the platforms I support, then I don't need GitHub runners. They might be convenient for simple programs or if changes are deemed unlikely to have platform dependencies (you're always taking a chance). If I don't build and test on a Mac, it's unlikely my software will work, so I'm not sure what I'll do. I do provide a "universal" tar.gz file, but that won't resolve platform problems. I didn't want to have builds automatically triggered by push/pull requests and I only wanted one release with all the different installers as assets. I'm not using the actions, but I did make them all so they were manually triggered (it seems you might have done the same recently). If I ever go down that route, I'll probably build using actions, download and test the resulting installers and then manually attach them to a release. While the GitHub actions haven't yet proved useful, all your work with the maven/jpackage integration certainly has. If you have any interest in the changes I've made in the pom.xml or the packaging files, everything has been uploaded to my GitHub project, https://github.com/freixas/gamma. |
Beta Was this translation helpful? Give feedback.
-
|
RE: "write once, run anywhere" ... yeah, that basically fell by the wayside a long time ago in practice. At a minimum it's write once, test everywhere. There are a bunch of Linux-only hangs I've seen in various Java Desktop APIs that make me pretty nervous. That's part of why I don't officially support Linux personally - if someone wants to come along and throw some $ at me to support it, sure, but it's very, very challenging to support as a unfunded side project. Just trying to pick a distro + a single version doesn't seem like it would be helpful, and there are a million versions of Linux floating around out there. The nice thing about the actions is that they do a lot of boilerplate work that, once done, is nice to have repeated every time without having to maintain a dedicated CI server. If you add more automated tests, if you work in a team, etc. it becomes more and more useful. It's not a replacement for manual smoke testing. It is nice to be able to just do a commit on, say, my macOS laptop and then download the Windows build directly to my Windows machine for testing. If you want to maintain your own servers, go for it! :) Everyone has their own preferred process - this is just really intended to be a template for people to grab, tweak, learn from, etc. I'll take a look at your project - thanks for posting it. |
Beta Was this translation helpful? Give feedback.
Yup, all of that is GitHub Actions, you can find the docs with Google etc.
Look at the "on" section for triggers, you can comment them out with a # character. The workflow_dispatch enables a button to trigger them in the GitHub UI. Just didn't bother putting it on the other jobs yet.
You can and should absolutely tweak the jobs to do what you want. RIght out of the gate, you may run out of minutes quickly if you are using a paid plan with a private repo.
The release is done via the Update Automatic Release step, with the marvinpinto/action-automatic-releases@latest action. That's what copies the final files to the releases section.
All of this is GitHub Actions. All I do in the template i…