-
Notifications
You must be signed in to change notification settings - Fork 104
Add rpkg/copr support #69
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
Open
jlelli
wants to merge
2
commits into
master
Choose a base branch
from
rpkg-support
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
AC_INIT([rt-app], [m4_esyscmd_s([git describe --tags HEAD])], [[email protected], [email protected]]) | ||
AC_INIT([rt-app], [1.0], [[email protected], [email protected]]) | ||
AC_COPYRIGHT([Copyright (C) 2009 Giacomo Bagnoli <[email protected]> | ||
Copyright (C) 2016 Juri Lelli <[email protected]> | ||
Copyright (C) 2016 Vincent Guittot <[email protected]>]) | ||
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,67 @@ | ||
# vim: syntax=spec | ||
|
||
Name: {{{ git_dir_name }}} | ||
|
||
Version: 1.0 | ||
|
||
Release: 1%{?dist} | ||
|
||
Summary: rt-app: simulate system load. | ||
|
||
License: GPLv2 | ||
|
||
URL: http://github.com/scheduler-tools/rt-app | ||
|
||
VCS: {{{ git_dir_vcs }}} | ||
|
||
# git_dir_pack macro places the repository content (the source files) into a tarball | ||
# and returns its filename. The tarball will be used to build the rpm. | ||
Source: {{{ git_dir_pack }}} | ||
|
||
Buildrequires: autoconf | ||
Buildrequires: automake | ||
Buildrequires: libtool | ||
Buildrequires: json-c-devel | ||
|
||
Requires: json-c | ||
|
||
# More detailed description of the package | ||
%description | ||
rt-app is a test application that starts multiple periodic threads in order to simulate a real-time periodic load. | ||
|
||
# Python permits the !/usr/bin/python shebang for scripts that are cross | ||
# compatible between python2 and python3, but Fedora 28 does not. Fedora | ||
# wants us to choose python3 for cross-compatible scripts. Since we want | ||
# to support python2 and python3 users, exclude our scripts from Fedora 28's | ||
# RPM build check, so that we don't get a bunch of build warnings. | ||
# | ||
# Taken from: https://github.com/zfsonlinux/zfs/issues/7360 | ||
# | ||
%global __brp_mangle_shebangs_exclude_from workgen | ||
|
||
# The following four sections already describe the rpm build process itself. | ||
# prep will extract the tarball defined as Source above and descend into it. | ||
%prep | ||
{{{ git_dir_setup_macro }}} | ||
|
||
# This will invoke `make` command in the directory with the extracted sources. | ||
%build | ||
autoreconf --install --symlink || exit 1 | ||
./configure --with-deadline | ||
make | ||
|
||
# This will copy the files generated by the `make` command above into | ||
# the installable rpm package. | ||
%install | ||
make install DESTDIR=%{buildroot} | ||
|
||
# This lists all the files that are included in the rpm package and that | ||
# are going to be installed into target system where the rpm is installed. | ||
%files | ||
/usr/local/bin/rt-app | ||
/usr/local/bin/workgen | ||
|
||
# Finally, changes from the latest release of your application are generated from | ||
# your project's Git history. It will be empty until you make first annotated Git tag. | ||
%changelog | ||
{{{ git_dir_changelog }}} |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding rpkg/copr is a good idea
but is there a way to keep both mechanism running correctly ?
It was convenient to get the sha1 for intermediate build to know which version a rt-app binary is based
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I'm pretty new to the rpkg/copr thing, but AFAIU the problem with calling git describe is that rpkg creates a temporary out-of-git-tree copy of the source to build them and create rpms. So git describe doesn't work in this case.
Now, I'm not sure if this is a problem for rpkg local only (I used that before creating the project on copr to test the build process) or also if copr would have problems with that.
In any case, I was wondering if we shouldn't actually "standardize" the release process. We are still at v1.0 and lot of stuff changed and was added after that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. We might need to tag a new version
And more generally speaking release some "stable" version more often
May be it's worth checking what the other package are doing in this area. Imean in order to get some details about sha1 when want to use "dev" branch
Ca, we consider that the rpkg/copr will be used only with tagged version ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me.
So we could
Do you think it might actually work? :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes that's seems to be a good way of working
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the past I've got a chance to use the "gitflow" branching model described here:
https://nvie.com/posts/a-successful-git-branching-model/
and I've found it quite useful. IMO it's pretty close to what @jlelli suggests and I think it could fit for an improved release process for rt-app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Yes this should work.
@vingu-linaro we might act on this by creating a PR that modifies README or points to a doc that states how development and release will be done from now on. Can do that.
Once we have that I can rebase this accordingly...
OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good for me