changesgenerate rewrites a previous entry in default run mode

[k0da]

Changes generate doesn't use _service:blah.changes as a reference file, instead it looks for $name.spec, in case changesgenerate is set to enable $name.spec is not needed (not updated usually), hence we have here as a result: contents of $name.changes + generated.changes for current run

[aspiers]

I'm sorry, I'm sure you have a valid point here, but I can't understand it all. Please could you reword in more detail, giving a concrete example of the issue? Thanks.

[k0da]

Use case, sources are in git and I want to fill changes in to .chages file.

1. in case foo.changes doesn't exists: _service:tar_scm:foo.changes is not generated..
2. Ok so I created a dummy one: service run gets content of foo.changes, then generates changes from git and combines with foo.changes and writes _service:tar_scm:foo.changes on next run it takes foo.changes again (note: this file is mostly static)

imagine you have foo.changes with

header
------
initial package

then after service run you have _service:tar_scm:foo.changes:

header
------
git changes

header
------
initial package

after second service run it will look like:

header
------
more git changes

header
------
initial package

It seems to be that changes generate must look for _service:tar_scm:foo.changes as old changes file

[aspiers]

What mode do you have tar_scm set to? Most of us have it in disabled mode, and then foo.changes is updated correctly every time you run osc service disabledrun - in that case, _service:* files are only temporary and you should never see them unless the source service crashes or is killed before it cleans up temporary files. So it sounds to me like this issue stems from not using it in disabled mode. I could be wrong, but please provide the _service file you are using so we can try to reproduce your issue.

[k0da]

 <services>
   <service name="tar_scm">
     <param name="url">git://github.com/k0da/A.git</param>
     <param name="scm">git</param>
     <param name="exclude">.git</param>
     <param name="versionformat">1.0+git%cd.%h</param>
     <param name="revision">master</param>
     <param name="changesgenerate">enable</param>
     <param name="changesauthor">[email protected]</param>
   </service>
   <service name="recompress">
     <param name="file">*.tar</param>
     <param name="compression">bz2</param>
   </service>

   <service name="set_version">
   </service>
 </services>

[k0da]

trylocal mode works, default doesn't

[aspiers]

Try this:

<service name="tar_scm" mode="disabled">

[k0da]

It that case it won't run on the server side, so I can't use github service to to trigger on push.

trylocal actually doesn't work as well :(

[aspiers]

Most of us never use anything except disabled, since we don't want sources to magically change without our intervention - that sounds way too brittle to me. But if you have a good reason to do that, PRs to fix this issue are very welcome ;-)

[k0da]

git push is a magic? Huh.. but I understand that this is not covered by your usecase..

any way... I'll come up with PR once I'll figure out what is the best way to cover all the cases

[aspiers]

You can call it "non-deterministic" if you prefer that to the word "magic", but the point still remains that it's unpredictable and it allows the package to break at any moment that anyone upstream does a git push or clicks merge on a github button or whatever.

But yeah, just because most of the people I know prefer something safer, I don't rule out that there might be good reasons to adopt a risker approach. I guess you would prefer to always have packages of the latest bleeding edge code, even if it's broken, and that could make sense if you are involved in development and/or testing of that project. So it would be great if you could submit a PR. Thanks :-)

[seife]

Adam: this is not non-deterministic, as you have to enable this explicitly on github, by creating an API key and adding the github <--> obs hook. We want to use it like this:

• commit to github
  • triggers a build via service in foo:bar:testing project
• if foo:bar:testing is working fine, we submitrequest the package to production foo:bar project manually
• foo:bar:testing package is a link to foo:bar package, only :testing contains the _service file.

so we get "immediate build a package on each commit" for testing, and deterministic packages in production

[aspiers]

@seife Ah OK, I see now - thanks a lot for the explanation!

Yes, this makes a lot of sense, and when used like that, it's not risky like I originally thought. As I said, I am already in favour of supporting new use cases and will happily review PRs which add support for this.

[computersalat]

@aspiers running into same problem of rewriting an existing entry: _service:

<services>
  <service name="obs_scm">
    <param name="url">https://github....</param>
    <param name="scm">git</param>
    <param name="versionformat">@PARENT_TAG@</param>
    <param name="changesgenerate">enable</param>
    <param name="changesauthor">mail@recipient</param>
    <param name="extract">*.spec</param>
    <param name="revision">master</param>
  </service>
  <service mode="buildtime" name="tar" />
  <service mode="buildtime" name="set_version" />
</services>

1st run of _service obs_scm getting:

-------------------------------------------------------------------
Thu Jun 18 15:59:49 UTC 2020 - mail@recipient

- Update to version 0.0.1:
  * reset version to 0, will be set bei OBS_service
  * xxx-jenkins-docker-maintenance.spec
  * chmod 755 docker-cleanup.sh
  * xxx: removed path in .sh and removed network service in unit file as obsolet
  * apply some shellcheck, add mail body into var
  * make usedDocker less cost-intensive
  * 20200616_xxx_docker-cleanup-xxx-3700
  * ADD: docker-alert.timer
  * ADD: docker-alert.sh

-------------------------------------------------------------------
Thu Jun 18 15:37:28 UTC 2020 - mail@maintainer

- change _service to maintain spec also in SCM

-------------------------------------------------------------------
Tue Jun 16 14:40:21 UTC 2020 - mail@maintainer

- initial package 0.0.1

after doing some changes in git a trigger is needed and results in:

-------------------------------------------------------------------
Thu Jun 18 16:54:40 UTC 2020 - mail@recipient

- Update to version 0.0.1:
  * Update: spec Source to 'tar' as retrieved from obs _service
  * reset version to 0, will be set bei OBS_service
  * xxx-jenkins-docker-maintenance.spec
  * chmod 755 docker-cleanup.sh
  * xxx: removed path in .sh and removed network service in unit file as obsolet
  * apply some shellcheck, add mail body into var
  * make usedDocker less cost-intensive
  * 20200616_xxx_docker-cleanup-xxx-3700
  * ADD: docker-alert.timer

-------------------------------------------------------------------
Thu Jun 18 15:37:28 UTC 2020 - mail@maintainer

- change _service to maintain spec also in SCM

-------------------------------------------------------------------
Tue Jun 16 14:40:21 UTC 2020 - mail@maintainer

- initial package 0.0.1

as you can see the existing entry got Updated

• a line got added on top
• last line of previous entry got removed instead of getting:

-------------------------------------------------------------------
Thu Jun 18 16:54:40 UTC 2020 - mail@recipient

- Update to version 0.0.1:
  * Update: spec Source to 'tar' as retrieved from obs _service

-------------------------------------------------------------------
Thu Jun 18 15:59:49 UTC 2020 - mail@recipient

- Update to version 0.0.1:
  * reset version to 0, will be set bei OBS_service
  * xxx-jenkins-docker-maintenance.spec
  * chmod 755 docker-cleanup.sh
  * xxx: removed path in .sh and removed network service in unit file as obsolet
  * apply some shellcheck, add mail body into var
  * make usedDocker less cost-intensive
  * 20200616_xxx_docker-cleanup-xxx-3700
  * ADD: docker-alert.timer
  * ADD: docker-alert.sh

-------------------------------------------------------------------
Thu Jun 18 15:37:28 UTC 2020 - mail@maintainer

- change _service to maintain spec also in SCM

-------------------------------------------------------------------
Tue Jun 16 14:40:21 UTC 2020 - mail@maintainer

- initial package 0.0.1

why does changesgenerate not merge existing changes to changes file before updating and adding new changes ? osc service merge would do that but also deleting the _service file

[computersalat]

@aspiers to make it more clear ... changesgenerate is doing this

xxx@xxx:~/myGIT>diff -ruN .first .second
--- .first      2020-06-18 17:36:16.101995000 +0000
+++ .second     2020-06-18 17:38:34.326626000 +0000
@@ -1,16 +1,16 @@
 -------------------------------------------------------------------
-Thu Jun 18 15:59:49 UTC 2020 - mail@recipient
+Thu Jun 18 16:54:40 UTC 2020 - mail@recipient

 - Update to version 0.0.1:
+  * Update: spec Source to 'tar' as retrieved from obs _service
   * reset version to 0, will be set bei OBS_service
   * xxx-jenkins-docker-maintenance.spec
   * chmod 755 docker-cleanup.sh
   * xxx: removed path in .sh and removed network service in unit file as obsolet
   * apply some shellcheck, add mail body into var
   * make usedDocker less cost-intensive
   * 20200616_xxx_docker-cleanup-xxx-3700
   * ADD: docker-alert.timer
-  * ADD: docker-alert.sh

 -------------------------------------------------------------------
 Thu Jun 18 15:37:28 UTC 2020 - mail@maintainer

but changesgenerate should better do this (adding new changes on top):

xxx@xxx:~/myGIT>diff -ruN .first .correct
--- .first      2020-06-18 17:36:16.101995000 +0000
+++ .correct    2020-06-18 17:40:48.222348000 +0000
@@ -1,4 +1,10 @@
 -------------------------------------------------------------------
+Thu Jun 18 16:54:40 UTC 2020 - mail@recipient
+
+- Update to version 0.0.1:
+  * Update: spec Source to 'tar' as retrieved from obs _service
+
+-------------------------------------------------------------------
 Thu Jun 18 15:59:49 UTC 2020 - mail@recipient

 - Update to version 0.0.1:

[aspiers]

Thanks for the update. Please note I am no longer a maintainer of this project, but it is still maintained.

[computersalat]

and who is maintainer then ?

[aspiers]

Whoever is merging PRs :-)