Package and publish an RPM file as well as debian #49
Conversation
orenbm
force-pushed
the
package-rpm
branch
3 times, most recently
from
f0c2e21 to
5e3c41b
Compare
We would like to offer the packages also to Linux-based machines that run RPM
There was a problem hiding this comment.
@orenbm looks very good. Added one question and two comments.
Also one general comment: I think it would be good to add something small in the README of the repo that explains that now Debify doesn't just create deb packages. The name used to be self explanatory but now it's not anymore, so further explanation could help.
| Given I successfully run `env DEBUG=true GLI_DEBUG=true debify package -d ../../example -v 0.0.1 example -- --post-install /distrib/postinstall.sh` | ||
| # We use version 0.0.1-suffix to verify that RPM converts dashes to underscores | ||
| # in the version as we expect | ||
| Given I successfully run `env DEBUG=true GLI_DEBUG=true debify package -d ../../example -v 0.0.1-suffix example -- --post-install /distrib/postinstall.sh` |
There was a problem hiding this comment.
What is the adding of suffix needed for?
There was a problem hiding this comment.
please read the comment i wrote above :)
| Conjur::Debify::Utils.copy_from_container container, "/src/#{package_name}" | ||
| puts "#{package_name}" | ||
| begin | ||
| Conjur::Debify::Utils.copy_from_container container, "/dev-pkg/#{dev_package_name}" |
There was a problem hiding this comment.
I don't think it's critical, but what do you think about this suggestion:
The logic of copy_packages_from_container could perform a copy of a single package. You will have four calls to this function instead of two. The calls will be for rpm dev, rpm, deb dev, deb. The calls for deb dev and rpm dev, will be wrapped with the rescue statement. This way the function is more generic, it just copies packages name from a given location. The logic on how to handle the copy is up to the caller, that knows what type of package it copies and if a failure is accepted or not.
There was a problem hiding this comment.
i don't think that this will simplify the code. the current one is good and will be called once for each file type. i don't expect that we'll need the extra generic level and adding it will add redundant complexity.
lib/conjur/fpm/package.sh
Outdated
| -t $file_type \ | ||
| -n conjur-$project_name-dev \ | ||
| -v $version \ | ||
| -C . \ | ||
| --maintainer "Conjur Inc." \ |
There was a problem hiding this comment.
Maybe it's worth changing Conjur Inc. to CyberArk? Don't want to increase your scope, only if you feel comfortable doing that.
Same with the url, from https://www.conjur.net to https://www.cyberark.com
There was a problem hiding this comment.
what should we do with this?
spec.authors = ["Kevin Gilpin"]
spec.email = ["[email protected]"]
@izgeri do you have a suggestion?
There was a problem hiding this comment.
oof let's definitely update this
authors: CyberArk Software, Inc.
email: [email protected]
| fpm -s dir -t deb -n conjur-$project_name -v $version -C . \ | ||
| --maintainer "Conjur Inc." \ | ||
| --vendor "Conjur Inc." \ | ||
| for file_type in deb rpm |
There was a problem hiding this comment.
why does this appear twice? line 70 and again in 33?
There was a problem hiding this comment.
once for the dev package and one for the prod. this logic was here before my change.
README.md
Outdated
| @@ -1,5 +1,10 @@ | |||
| # Debify | |||
|
|
|||
| Debify is a tool used for building and testing Conjur appliance packages. | |||
There was a problem hiding this comment.
| Debify is a tool used for building and testing Conjur appliance packages. | |
| Debify is a tool used for building and testing DAP appliance packages. |
Semantics, but I'd love to see us start to remove "Conjur" when talking about DAP components.
The description now explains that alongside the debian file we also create an RPM one.
|
@jvanderhoof can you please re-review? Are you reviewing the PR on behalf of core-team or would you like someone else to do that? |
there's no real usage really. When you run the project it will now package and publish an RPM package alongside the debian one. So the usage hasn't changed, just the impact. |
Resolves conjurinc/AAM#319
We would like to offer the packages also to Linux-based machines that run RPM. Thus, we need to package and publish the components as RPM files in addition to debians.
Once this PR is merged, projects that will run
debifywill publish an RPM file to our redhat repo in artifactory.An example can be seen in this build of evoke that uses the
debifydocker image created by this side-branch.Note: Every run of debify will package and publish also an RPM package. While this is needed for
conjur-ui,possumandevoke, it is not needed forconjur-ldap-syncas that RPM will not be used in the dockerless image. So the artifcatory repo will have unused packages ofconjur-ldap-sync.