ack @mbland and thanks for reviving this project, very much appreciated.

A package built from the above .spec is available here (built on CentOS 7) if anyone needs/wants to test it.
http://rpmbuild.pixeldrift.net/bats-core/el7/noarch/Packages/

This package upgrades cleanly from the older bats version that currently ships in EPEL.

I don't know the rpm spec format, though everything seems in order. 🤷‍♂️

I'm not terribly excited about having yet another copy of the changelog, though. If/when we extract that to its own file, I'm assuming we can just reference the file instead of duplicating its contents into the rpm spec?

Understand the concern. As an end user it's nice to have the changelog represented in the spec because it makes it visible through the package manager to the end user.

I guess the changelog's generation could be scripted/extracted from the main changelog if the main changelog maintained a consistent parseable format.

Alternatively, drop the changelog and keep the spec without it, for use as a basic template.

Before I forget: this PR is germane to #103.

I imagine changelog dissemination must be a solved problem for other projects that are packaged via multiple mechanisms... Created #112 to track this.

Right after creating this, I discovered (quoted from #112 (comment)):

Also, note that https://rpm-packaging-guide.github.io/ mentions listing a ChangeLog in %files, and that the %changelog directive is for packaging changes, not software changes.

So @pixdrift, perhaps you can update the %changelog to reflect the packaging changes instead? @jasonkarns any concerns/objections once that's done?

@mbland nope, with that I'd be 👍

@mbland, the github packaging guide is similar to the Fedora packaging guidelines on changelog:
https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs

Happy to update it, but it will still need bumping when versions are released. I can write a CI test for this as I have done elsewhere, eg.
https://github.com/projectatomic/buildah/blob/master/tests/version.bats#L11-L22

Is package.json the best source for version?

This would result in CI tests failing unless the spec file was also up to date (version at top of spec, and latest changelog line), in line with the package.json. Would that be OK? Or would you prefer to avoid this burden?

PR updated. Linked compiled packages above have also been updated (if anyone wants to test).

Can add the tests to the PR, let me know how you would like to handle it. 👍

Maybe I'm just tired, but that Fedora %changelog advice does seem to contradict the RHEL advice from the guide I dug up. Weird.

I'm OK getting this in for now, and considering the automation to keep version numbers in sync later, as that's probably we can include within the scope of #112 as well.

BTW, what would we need to do to make sure that new RPMs are built from the spec as new versions become available?

@mbland, not too much. Now that a spec is in the repo, you can trigger a build process for each commit potentially.

I set up similar for my own use for buildah, resulting packages are here:
http://rpmbuild.pixeldrift.net/projectatomic/el7/x86_64/Packages/

This builds (in a container) on every commit to the repo to speed up my own testing/validation. Source is here:
https://gitlab.com/pixdrift/buildah-scripts/blob/master/el7.buildah.rpmbuild.sh

Oh, I was thinking this was for including them in the RHEL and/or Fedora distributions. Guess it's a necessary first step, at least.

Dumb question from an RPM newbie desperately trying to get this fork of bats into our internal yum repos: How am I supposed to build an RPM with this? 😅

$ rpmdev-setuptree
$ rpmbuild -v -bb contrib/rpm/bats.spec 
error: File /home/user/rpmbuild/SOURCES/v1.1.0.tar.gz: No such file or directory

Do I need to stage something locally before running rpmbuild? I don't understand why rpmbuild is even looking for a file there since there is a github URL in the Source0 field. 😕

I'm running RHEL 7.7.

@okorz001 try with the following:
rpmbuild --undefine=_disable_source_fetch -ba bats.spec

rpmbuild doesn't have a native way to validate the source download, so fetching sources is disabled by default. The above enables source fetching with an override which should only be overridden in situations where you trust the network/source.

There is also a tool called spectool which can download missing sources defined in the .spec

Sorry I didn't see your message earlier, don't look in old PR's too often 😄