| --- Log opened Sat Jan 18 00:00:24 2020 |
| 00:10 | | Kindamoody is now known as Kindamoody[zZz] |
| 00:53 | | celmin|away is now known as celticminstrel |
| 01:24 | | macdjord [macdjord@Nightstar-rslo4b.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 01:25 | | mac [macdjord@Nightstar-rslo4b.mc.videotron.ca] has joined #code |
| 01:25 | | mode/#code [+o mac] by ChanServ |
| 01:38 | | mac is now known as macdjord|slep |
| 04:20 | | Degi [Degi@Nightstar-on2q3i.dyn.telefonica.de] has quit [Operation timed out] |
| 04:22 | | Degi [Degi@Nightstar-8m3g66.dyn.telefonica.de] has joined #code |
| 05:04 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has joined #code |
| 05:04 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
| 08:39 | | celticminstrel [celticminst@Nightstar-0p84vo.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 09:46 | | macdjord|slep is now known as macdjord |
| 11:04 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 11:14 | | Kindamoody[zZz] is now known as Kindamoody |
| 14:54 | | Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Ping timeout: 121 seconds] |
| 15:13 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 15:13 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 15:28 | | Kimo|autojoin [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
| 15:28 | | mode/#code [+o Kimo|autojoin] by ChanServ |
| 15:38 | | Kimo|autojoin is now known as Kindamoody |
| 16:17 | <&[R]> | Looking for a recommended git branching guide, I have an idea for automation, I would have two additional branches "production" and testing, both would get pushed upstream, system would notice either of them and build the package and put it in the appropriate production repo or the testing repo depending on the branch. |
| 16:19 | | * [R] has not really done anything with branches before |
| 16:43 | <&jeroud> | "git flow" is a thing we used to use before simplifying back to what everyone uses. |
| 16:44 | <&[R]> | Hmm? |
| 16:46 | <&jeroud> | The common system is that master is your "integration" branch, all actual development happens in feature branches, and you either tag commits on master for release or have separate versioned release branches if you need to support more than one release. |
| 16:47 | <&[R]> | Okay, I was thinking of having a branch named after the package repository the git repo's package is supposed to go into |
| 16:47 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 16:47 | <&[R]> | Though I'm open to alternate means to communicate that |
| 16:48 | <&jeroud> | "git flow" is the name of a particular git workflow (which ended up being a bit heavyweight for us) and also a tool that automates the steps of that workflow. |
| 16:49 | <&jeroud> | Is your intention that everything in the production branch gets tested in staging first? |
| 16:49 | <&[R]> | Kind of yeah? |
| 16:50 | <&jeroud> | And do you want specific staging releases that aren't necessarily all commits to master or whatever? |
| 16:50 | <&[R]> | Right now all packages are in one giant repo, and there's no automation |
| 16:50 | <&[R]> | I'd like to fix two pain points here (and I'd also like to learn branching) |
| 16:50 | <&[R]> | 1) A bunch of my commits are "fixed XYZ PKGBUILD file to actually build" |
| 16:51 | <&[R]> | Such commits can be spammed in the testing branch IMO |
| 16:51 | <&[R]> | 2) Actually have one setup that is purpose built for building packages so I don't have too much tainting going on |
| 16:51 | <&jeroud> | Do you use feature branches? |
| 16:52 | <&[R]> | I don't use branches. At all. |
| 16:52 | <&jeroud> | Because that's probably step 1. |
| 16:52 | <&[R]> | I don't see feature branches getting much use in this case BTW |
| 16:52 | <&[R]> | I'm submitting build files, not code |
| 16:53 | <&[R]> | Most repos will be single files |
| 16:54 | <&jeroud> | The purpose of the feature branch is that you get a place to fiddle with and test each change, review what the final change is, and then merge that back into master. |
| 16:55 | <&[R]> | Right, which is what the testing branch would be, but it'd also build a functional package and put it into the testing package repository so I can test the package as well |
| 16:56 | <&jeroud> | Then you set up your build system to build and test on each commit/push (or if you're using github or whatever, per pull request). |
| 16:56 | <&[R]> | Okay |
| 16:57 | <&[R]> | Then I flag specific commits as for production somehow? |
| 16:58 | <&jeroud> | You can trigger your "push to testing repo" builds to run on every push to a pull request and your "push to prod repo" builds to run on commits that are tagged with a version number. |
| 16:59 | <&[R]> | Okay |
| 16:59 | <&jeroud> | https://github.com/praekeltfoundation/secret-sync-controller this is the project I set up for this stuff in the past week. |
| 17:00 | <&jeroud> | There are two YAML files in the .github/whatever dir. |
| 17:02 | <&jeroud> | One runs on every commit and also every PR to run our tests and such. (The push builds test the commit directly, the PR builds test the thing you get when you merge that commit into the merge target.) |
| 17:04 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 17:07 | <&jeroud> | The other is triggered on tag pushes that match a version regex, and those build and push the docker image. |
| 17:08 | <&jeroud> | If you want a neater commit history without all the mucking about, you can squash each feature branch into a single commit to master. |
| 17:10 | <&[R]> | https://gist.github.com/cf48ba62ead5bddf1b6f904577930c64 <-- workflow and additional question, just making sure I have the information right |
| 17:10 | <&jeroud> | (We don't do that because we like to have the history from each branch available later, but a lot of projects require squashing before merge.) |
| 17:13 | <&jeroud> | Give me a moment to set up my laptop now that I'm home. |
| 17:13 | <&[R]> | Sure |
| 17:13 | <&[R]> | Thanks for answering my questions |
| 17:16 | <&jerith> | My workflow is as follows: |
| 17:16 | <&jerith> | 1. git checkout -b branch-name |
| 17:17 | <&jerith> | 2. make a bunch of changes, push one or more commits |
| 17:17 | <&jerith> | 3. open a pull request from the branch to master |
| 17:17 | <&jerith> | 3a. check that builds/tests are all green |
| 17:18 | <&jerith> | 3b. have a colleague review the PR and approve the changes |
| 17:19 | <&jerith> | 4. git checkout master; git merge --no-ff branch-name (we want a merge commit even if fast-forward is possible) |
| 17:21 | <&jerith> | 5. (when we decide it's time for a release) git tag v1.2.3; git push --tags |
| 17:22 | <&jerith> | You don't ever want to have separate test and release branches with separate changes in them, because you'll end up with minor differences that grow and diverge over time. |
| 17:23 | <&[R]> | Yeah no, I'd be merging the test branch into the release branch just before every release |
| 17:26 | <&jerith> | Feature branches are basically a new test branch for every change. |
| 17:27 | <&[R]> | Yeah |
| 17:27 | <&[R]> | I updated my workflow, is that reasonable? |
| 17:28 | <&jerith> | "4b Fix the rel version" what does that involve? |
| 17:28 | <&jerith> | Is it just "bump the version number"? |
| 17:28 | <&[R]> | Changing the pkgrel number in the PKGBUILD file |
| 17:29 | <&[R]> | Likely the repeats of step 1 would've make the pkgrel jump pretty high |
| 17:29 | <&[R]> | Since it needs to go up for each successful build |
| 17:31 | <&jerith> | https://wiki.archlinux.org/index.php/PKGBUILD ? |
| 17:31 | <&[R]> | Yes |
| 17:31 | <&[R]> | And in many cases that'd be the only file in the repo |
| 17:32 | <&jerith> | There doesn't seem to be an option for "pre-release" versions there. :-( |
| 17:32 | <&[R]> | Yeah |
| 17:33 | <&[R]> | I could probably hack it in, since I'm already forking makepkg (the script that actually reads the PKGBUILD to do stuff) |
| 17:34 | <&jerith> | "In exceptional cases other formats can be found in use, such as major.minor." |
| 17:35 | <&jerith> | You don't want to end up with a situation where you need different number ranges for testing and for release. |
| 17:38 | <&jerith> | So you either want to build and test with the same pkgrel for every commit in your feature branch (which might be tricky) or you want to use something like XrcN as the pkgrel in the branch (if the tooling allows that) and switch to X as the last thing you do before squashing and merging. |
| 17:39 | <&jerith> | It might be worth asking in some arch-specific venue what the usual process for this sort of thing is. |
| 17:41 | <&[R]> | "build and test with the same pkgrel for every commit" <-- I'd have to nuke the VM each test iteration, or manually munge the local copies of the repos to make that not fail |
| 17:41 | <&[R]> | The XrcN would work |
| 17:42 | <&jerith> | At worst, you might have to increment pkgrel on each build and then only release the ones that work. You'd end with a sequence like 1-3-8-9-12 instead of 1-2-3-4-5, but that's fine. |
| 17:42 | <&[R]> | Yeah, I'd rather the XrcN, then I know specifically that any specific package is a testing package versus a release one |
| 17:44 | <&jerith> | If I were doing this process on a regular basis, I'd probably automate building a VM with the test package installed in it from a fresh per-build package repo or something. |
| 17:44 | <&[R]> | Yeah, that's the ultimate plan |
| 17:44 | <&[R]> | The build actually has to be done in a clean environment anyways |
| 17:44 | <&jerith> | But that might not be worth the effort if you're not doing this several times a day. |
| 17:45 | <&[R]> | I'd be doing this a few times in a single day, just not every day |
| 17:45 | <&jerith> | That would also guard against leftover state from broken versions interfering with later tests. |
| 17:45 | <&jerith> | Can the "test that this package works" process be automated? |
| 17:46 | <&[R]> | Not really |
| 17:46 | <&[R]> | Unless I want to write tests for every single program I build |
| 17:46 | <&jerith> | Yeah, that's a problem. |
| 17:47 | <&[R]> | Note: the PKGBUILD has a test section that will run unit tests |
| 17:47 | <&jerith> | Assuming the package provides them and that they're actually useful in practice. |
| 17:47 | <&[R]> | Yeah, they're run by default |
| 17:48 | <&[R]> | The VM test is to make sure I didn't do something silly that results in an empty package, or some file got put into the wrong place, or I forgot a configuration file |
| 17:48 | <&[R]> | IE: I'm testing the packaging process |
| 17:48 | <&jerith> | In my experience (in other environments, not arch) the first is rare and the second almost never happens. |
| 17:49 | <&[R]> | Yeah, I've done both |
| 17:49 | <&[R]> | A few times |
| 17:49 | <&[R]> | I'm packaging a mix of my own software and software that doesn't already exist in the repos, or software that wasn't built correctly from the official repos |
| 18:03 | <&jerith> | Have I answered all your questions? |
| 18:04 | <&[R]> | I think so |
| 18:04 | <&[R]> | I'm going to try and impliment this stuff, I'll ask some more if I'm missing stuff |
| 18:04 | <&jerith> | Cool. Nickping me if you have any others (although I'm unlikely to be the only person in here who can help) and I'll reply when I'm next around. |
| 18:05 | <&jerith> | (My notifications are muted overnight, so timezones aren't an issue.) |
| 18:54 | | celticminstrel [celticminst@Nightstar-0p84vo.dsl.bell.ca] has joined #code |
| 18:54 | | mode/#code [+o celticminstrel] by ChanServ |
| 20:04 | <&[R]> | `git cat-file --batch <<<HEAD:PKGBUILD | sed 1d | tac |sed 1d | tac` I ended up needing something like this. (Note if you can live with an extra newline the last three pipes aren't needed) |
| 20:05 | <&[R]> | That prints the entire contents of a single file from a bare repo |
| 21:44 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 21:45 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 23:39 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 23:42 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:42 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| --- Log closed Sun Jan 19 00:00:26 2020 |