New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync with latest Fedora #637

Merged
merged 2 commits into from Nov 14, 2016

Conversation

Projects
None yet
3 participants
@praiskup
Member

praiskup commented Sep 8, 2016

No description provided.

@vlsi

This comment has been minimized.

Member

vlsi commented Sep 8, 2016

Can this be automatic?

@vlsi

This comment has been minimized.

Member

vlsi commented Sep 8, 2016

@praiskup

This comment has been minimized.

Member

praiskup commented Sep 8, 2016

Good point. I'll have a look.

@codecov-io

This comment has been minimized.

codecov-io commented Sep 8, 2016

Current coverage is 62.91% (diff: 100%)

Merging #637 into master will increase coverage by 0.92%

@@             master       #637   diff @@
==========================================
  Files           150        150           
  Lines         15145      16374   +1229   
  Methods           0          0           
  Messages          0          0           
  Branches       3045       3396    +351   
==========================================
+ Hits           9388      10301    +913   
- Misses         4510       4798    +288   
- Partials       1247       1275     +28   

Powered by Codecov. Last update b4604cd...dfad24f

@praiskup

This comment has been minimized.

Member

praiskup commented Sep 8, 2016

Argh! That's already automatic, I forgot about it --> I just tried to sync Fedora's package with upstream, but this is not needed at all.

@praiskup

This comment has been minimized.

Member

praiskup commented Sep 8, 2016

I was curious how that is possible that your builds in copr work... Anyway, I would specify some artificial parent version in spec template, to make clear that it is automatically bumped during CI build. WDYT?

@praiskup praiskup force-pushed the praiskup:fedora-update-parent-poms branch from adfde4c to 334dc42 Sep 8, 2016

@vlsi

This comment has been minimized.

Member

vlsi commented Sep 8, 2016

I would specify some artificial parent version in spec template, to make clear that it is automatically bumped during CI build. WDYT?

That makes sense.
If you incorporate "version sniffing" into the copr build, then Travis workaround could be removed.
Does that make sense?

@vlsi

This comment has been minimized.

Member

vlsi commented Sep 8, 2016

I just tried to sync Fedora's package with upstream, but this is not needed at all.

Did you just say "Fedora's package is already updated to 1210"?
That's impressive.

@praiskup

This comment has been minimized.

Member

praiskup commented Sep 8, 2016

@vlsi wrote

If you incorporate "version sniffing" into the copr build, then Travis workaround could be removed.
Does that make sense?

Yes, makes sense. I need to have a look at what is needed to realize this idea, in particular -- the docker image generating "source" RPM is pretty general-purpose and small (at least it is supposed to be) ... and there is no tooling for such java-related sniffing (similarly as there are no other-language specific things). On the other hand, travis has java tool-set ..

Allow me some time to have a deeper look, or if you have some concrete ideas? The CI here in pgjdbc is actually PoC that needs to be more popularized (on TODO), and simplified (on TODO too), and also I'd like to shape a clean concept.

Did you just say "Fedora's package is already updated to 1210"?

Yeah, but being a bit off-topic -- we usually have multiple versions (usually 2 stable versions, one "rolling" unstable version) of Fedora, and I've updated just the rolling one that becomes the stable at some point (that one which is protected by CI here upstream). So I just conform to our policies..
But yes, this was the smoothest update of pgjdbc in Fedora I have (and probably my predecessors) ever experienced... yey!

@vlsi vlsi force-pushed the pgjdbc:master branch 3 times, most recently from d1c9cd8 to 154c463 Sep 17, 2016

@vlsi vlsi force-pushed the pgjdbc:master branch 2 times, most recently from c8cebf6 to f52bf7f Oct 29, 2016

@praiskup praiskup force-pushed the praiskup:fedora-update-parent-poms branch from 334dc42 to 4cff7e5 Nov 3, 2016

@praiskup praiskup changed the title from chore: update parent version in *.spec to Sync with latest Fedora Nov 3, 2016

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 3, 2016

Yes, makes sense. I need to have a look at what is needed to realize this idea, in particular -- the docker image generating "source" RPM is pretty general-purpose and small (at least it is supposed to be) ... and there is no tooling for such java-related sniffing (similarly as there are no other-language specific things). On the other hand, travis has java tool-set ..

I've been thinking about this a bit, but it actually isn't IMO something which is worth doing. In particular, that's something what will never work in Fedora (we'll have always hardcoded version of java tarball inside specfile) and it looks like it is worth doing in travis, where's the necessary tooling. Unless this is somehow too burning issue, I would let it as is (version sniffed in travis) -- otherwise I would construct some pgjdbc-special container which would be able to sniff the version. But O:-) you know what I would prefer.

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 3, 2016

Otherwise, related to #664, I've built temporary the missing build dependency in Copr, thanks to @trepik we had source RPM that quickly. And it seems to build fine now.

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 3, 2016

IOW, I would like to let the travis detect the right PARENT_VERSION. That's chicken egg problem otherwise -> srpmgen utility needs to obtain source tarballs first. While to implement the PARENT_VERSION detction within container -> we would need to (a) obtain first source first, and then (b) detect the parent version, and (c) download the second source. That's hard to solve "declarative" way in .srpmgen.

I still changed the replaced strings in spec file template to 'GENERATED' to make it 100% obvious that those are not finite values. I also moved the string substitution into container explicitly (by passing env variable down to container) so I can do testing on my box too (by exporting copr token hash && PARENT_VERSION manually).

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 3, 2016

PTAL, @vlsi, and thanks for your time

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 3, 2016

Argh, I haven't pushed updated docker image :(, so the results from CI will be probably invalid.

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 3, 2016

@vlsi can you please restart pull request check?

@vlsi

This comment has been minimized.

Member

vlsi commented Nov 12, 2016

@praiskup , can you please try pushing to pgjdbc / fedora_ci branch so copr gets triggered?

@praiskup praiskup force-pushed the praiskup:fedora-update-parent-poms branch from 40d92ef to 8f70d6c Nov 14, 2016

make the 'rpm_ci' working outside from travis
- fix issues with umask 0077 Dockerfile
- export PARENT_VERSION in travis_build.sh, the substitution is
  now done in 'rpm_ci' itself
- add 'repo' feature into srpmgen (so we could potentially
  generate pgjdbc-parent-poms from git in future, too)
- use :Z flag for volume for docker run (SELinux)

@praiskup praiskup force-pushed the praiskup:fedora-update-parent-poms branch from 8f70d6c to dfad24f Nov 14, 2016

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 14, 2016

Sorry for the delay, I've stopped the /pr test (to not waste resources) and let the /push check finish -> and it succeeded.

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 14, 2016

I can "Squash and merge", but I'd like to have an ACK at least for the first time that I should not follow some formal "protocol".

@vlsi vlsi merged commit a29ad80 into pgjdbc:master Nov 14, 2016

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
codecov/project 62.91% (+0.92%) compared to b4604cd
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment