| *** amccarthy is now known as Guest930 | 00:58 | |
| *** amccarthy_ is now known as amccarthy | 00:58 | |
| Kabouik | Thanks for the explanation Thaodan. Hopefully I'll get used to it! | 03:17 |
|---|---|---|
| Kabouik | I haven't found how to tag multiple commits with the same tag but I didn't look much yet. | 03:17 |
| Thaodan | Kabouik: Why would you want to do that? | 08:04 |
| *** hummer12007_ is now known as hummer12007 | 11:07 | |
| *** retropikzel_ is now known as retropikzel | 11:07 | |
| Kabouik | Thaodan I'm trying to add a feature which, to me, would deserve a new tag, but it's devel so there are several iterations before I get what I want, and I would have wanted all these iterations to be called 0.7+githash by OBS. | 12:51 |
| Kabouik | But I assume this is not the way tags should be used | 12:51 |
| Thaodan | Kabouik: It is not. | 13:32 |
| Thaodan | You should edit the service file manually | 13:32 |
| Thaodan | if you are using webhook you can tag different version of that change in a feature branch | 13:32 |
| Thaodan | E.g. have a webhook that listens to branch feature-foobar and then create tag like 1.0+feature-fobar<change number> | 13:33 |
| Kabouik | Probably I do edit the service file manually when I want to rebuild. But let's say I tagged commit aaa as 0.7, then find a bug, fix it (or so do I think), commit, change the hash in _service and rebuild, that build will be back to 0.6 instead of 0.7. 0.6 is the last release I made, maybe it uses that as default? | 13:36 |
| Kabouik | The only way I found for the rpm with commit bbb in it to be called 0.7 is to delete tag 0.7 from local and remote, tag commit bbb, and repush tags. | 13:37 |
| Kabouik | s/Probably// | 13:37 |
| Thaodan | Kabouik: If you just use tar_git you always have to manually edit | 13:48 |
| Thaodan | with webhooks the webhook will do that for you | 13:49 |
| Thaodan | If you create a new tag it updates to the latest tagged ref. | 13:49 |
| Kabouik | I use tar_git yes, I'm happy with manually editing. My issue is more about which tag name tar_git picks for commits later than the latest tag. Somehow it always go back to 0.6 instead of 0.7 (my latest tag), which perhaps is due to my latest release being 0.6. | 13:50 |
| Thaodan | It doesn't pick any tag that you haven't set in revision. | 13:51 |
| Thaodan | E.g. see line 9 in my _service file here https://build.merproject.org/package/view_file/nemo:testing:hw:sony:kumano:4.4.0.68/droid-config-j9110/_service?expand=1 | 13:52 |
| Kabouik | https://build.merproject.org/package/view_file/home:kabouik/harbour-containers/_service?expand=1 revision is my commit hash here. But for this to be named harbour-containers-0.7-*.rpm, I had to delete my previous 0.7 tag which was assigned to an earlier commit, so that I could use it on that commit instead. Which adds like 3 or 4 git commands every time. I'm probably missing something. I would want later commits to inherit | 13:53 |
| Kabouik | the tag of previous commits, unless assigned to a new tag. | 13:53 |
| Kabouik | I already have that in line 6 in mine | 13:53 |
| Thaodan | You can also see the webhook in place here were you can forget about trigering builds manually | 13:53 |
| Thaodan | https://docs.sailfishos.org/Services/Development/Webhooks/ | 13:53 |
| Thaodan | It takes the latest commit on that branch | 13:54 |
| Kabouik | I have one package with a webhook, but I don't want that here. I'm happy with triggering a build only when I change the hash manually in the _service. The way the resulting rpms are named is my only issue (which I work around by deleting tag from previous commit, and reassigning it to new commit). | 13:54 |
| Thaodan | if you have a feature branc don't tag a new version since it still just development | 13:55 |
| Kabouik | But if I don't it automatically gets named 0.6, which is misleading. Not sure why it does that. | 13:55 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!