Proposal for git hook to update version information on tag creation

Hi all,
One of the issues that has plagued me when trying to build tagged releases is that the build always winds up with a version number of xx.0.0, which never matches the tagged version number I’ve checked out. For example, if I check out and build v19.1.2, all commands return 19.0.0, pbs_version in $PBS_HOME says 19.0.0, and any RPMs I build are versioned at 19.0.0.

I propose we automate the process with a git hook that will update all of the appropriate files (configure.ac, pbspro.spec, etc.) when a new tag is added. The hook could also be expanded to do other things as well if you are manually doing things from tag release to tag release, such as building and updating binaries for download on pbspro.org.

I realize after digging through the files that you can override the version number with a configure option (./configure PBS_VERSION=19.1.2) but that is only documented in one place that I’ve found - configure.ac. Neither confluence nor pbspro/INSTALL document it. In any case, I would expect that overriding what is in configure.ac should be the exception in order to test or do a custom build, and not the rule.

1 Like

Hey Josh,

Great suggestion. I think we only need to update configure.ac since pbspro.spec is generated based on pbspro.spec.in when configure is run. We also have to be careful not to break compatibility with OpenHPC. We have a different spec file in their repo that we maintain that hardcodes the version, so I don’t think it will cause problems.

Thanks,

Mike

Thanks for the proposal, I find the version numbers quite annoying as well, so it would be great to have a git hook to update the version numbers.
Having said that, I’m not sure how git hooks work, so I wanted to clarify, will the edits to configure.ac create a new commit that will get checked into the branch? Will the Github account of the user creating the tag be used to check that commit in? Do you know how this will work?

Hi Mike!

  • I have a different opinion about
    we only need to update configure.ac since pbspro.spec is generated based on pbspro.spec.in when configure is run.

  • Because rpmbuild with -ta option sees SPEC file in SPEC directory even we do not extract explicitly,
    appropriate pbspro.spec before configure is run is helpful.

  • 18.1.4, 18.1.3 and so on are with appropriate configure.ac and pbspro.spec.

  • For unknown reason,
    pbspro.spec files do not include ./autogen.sh

  • With ./autogen.sh in %build Section of pbspro.spec,
    we can build RPMs like rpmbuild -ta SOURCES/pbspro-19.1.1.tar.gz
    where
    pbspro-19.1.1.tar.gz is source code
    whose URL is https://github.com/PBSPro/pbspro/archive/v19.1.1.tar.gz
    rather than partially processed file set named as pbspro-19.1.1.tar.gz

test01@cent7-16 pbspro-19.1.1]$ diff configure.ac{,.orig}
43c43
< [19.1.1],

[19.0.0],
[test01@cent7-16 pbspro-19.1.1]$ diff -c configure.ac{,.orig}
*** configure.ac 2019-06-07 16:32:57.000000000 +0900
— configure.ac.orig 2019-01-28 16:59:08.000000000 +0900


*** 40,46 ****

Use PBS_VERSION to override the version statically defined here. For example:

./configure PBS_VERSION=19.1.2 --prefix=/opt/pbs

AC_INIT([PBS Professional],
! [19.1.1],
[pbssupport@altair.com],
[pbspro],
[http://www.pbspro.org/])
— 40,46 ----

Use PBS_VERSION to override the version statically defined here. For example:

./configure PBS_VERSION=19.1.2 --prefix=/opt/pbs

AC_INIT([PBS Professional],
! [19.0.0],
[pbssupport@altair.com],
[pbspro],
[http://www.pbspro.org/])
[test01@cent7-16 pbspro-19.1.1]$ diff -c pbspro.spec{,.orig}
*** pbspro.spec 2019-06-07 16:34:28.000000000 +0900
— pbspro.spec.orig 2019-01-28 16:59:08.000000000 +0900


*** 41,47 ****
%endif

%if !%{defined pbs_version}
! %define pbs_version 19.1.1
%endif

%if !%{defined pbs_release}
— 41,47 ----
%endif

%if !%{defined pbs_version}
! %define pbs_version 19.0.0
%endif

%if !%{defined pbs_release}


*** 268,274 ****
%setup

%build

  • ./autogen.sh
    [ -d build ] && rm -rf build
    mkdir build
    cd build
    — 268,273 ----

thank you
go

Greetings @sstcdev,

I think perhaps some of the output you provided was interpreted as markup, making your example difficult to follow. If you add three back ticks (```) before and after your example, it will become pre-formatted text.

Preformatted text

I don’t claim to be an expert with GNU autotools, and would be happy to consider your suggested changes. I just want to make sure I clearly understand what you are proposing.

Thanks,

Mike