Skip to content
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.

Sign up for GitHub

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

Jump to bottom

rpm creation enhancements #44

Closed
jacobsalmela opened this issue Oct 27, 2021 · 3 comments · Fixed by #184
Closed

rpm creation enhancements #44

jacobsalmela opened this issue Oct 27, 2021 · 3 comments · Fixed by #184
Assignees
@rustydb
Labels
priority enhancement Mission Critical Requirement

Comments

@jacobsalmela
Copy link
Collaborator

The rpm built from this repo should:

  1. build in jenkins
  2. appear on the Github Releases page as a downloadable artifact
  3. not overwrite user config when installed/upgrade
@jacobsalmela jacobsalmela added the priority enhancement Mission Critical Requirement label Oct 27, 2021
@jacobsalmela jacobsalmela self-assigned this Oct 27, 2021
@rustydb rustydb self-assigned this Dec 1, 2021
@rustydb
Copy link
Contributor

rustydb commented Dec 1, 2021

Also removing requirements*.txt files and building a python wheel instead to make things simpler.

@rustydb rustydb mentioned this issue Jan 27, 2022
Closed
7 tasks
@rustydb
Copy link
Contributor

rustydb commented May 27, 2022

I think we should skip number 2, we could but don't need to build an RPM and push to GitHub release. We want that RPM to live with the other CSM-RPMs, that repo is public.

@rustydb
Copy link
Contributor

rustydb commented May 27, 2022

Translating number 1 to "we should build within the spec file."

Number 3 means marking generated files as %conf but we might not have expected names for those files.. I'll look into it.

This was referenced Jun 30, 2022
Closed
Merged
rustydb added a commit that referenced this issue Oct 13, 2022
@rustydb
Fixes #44 and #182 Build Once and Use Git-Tags
8df52bc 
This removes the `.version` files and uses git-tags. `canu` now versions
itself within `setup.py` based on `git describe --tags`.

This also builds canu inside of the RPM `specfile` using `pyinstaller`
and no longer uses a special `pyinstaller` image.

The spec file will create a `canu` user.

All of the `requirements` files were converted into `setup.py`, this
tidies up the repository by using less files.

All references to the `.version` files were replaced by leveraging the
`pkg_resources` module to fetch the version from the module `PKG_INFO`.

This also breaks apart the GitHub actions for lint, docs, and tests into
their own workflows allowing for more parallelization.
rustydb added a commit that referenced this issue Oct 13, 2022
@rustydb
Fixes #44 and #182 Build Once and Use Git-Tags
49cea0b 
This removes the `.version` files and uses git-tags. `canu` now versions
itself within `setup.py` based on `git describe --tags`.

This also builds canu inside of the RPM `specfile` using `pyinstaller`
and no longer uses a special `pyinstaller` image.

The spec file will create a `canu` user.

All of the `requirements` files were converted into `setup.py`, this
tidies up the repository by using less files.

All references to the `.version` files were replaced by leveraging the
`pkg_resources` module to fetch the version from the module `PKG_INFO`.

This also breaks apart the GitHub actions for lint, docs, and tests into
their own workflows allowing for more parallelization.
rustydb added a commit that referenced this issue Oct 14, 2022
@rustydb
Fixes #44 and #182 Build Once and Use Git-Tags
20e62bf 
This removes the `.version` files and uses git-tags. `canu` now versions
itself within `setup.py` based on `git describe --tags`.

This also builds canu inside of the RPM `specfile` using `pyinstaller`
and no longer uses a special `pyinstaller` image.

The spec file will create a `canu` user.

All of the `requirements` files were converted into `setup.py`, this
tidies up the repository by using less files.

All references to the `.version` files were replaced by leveraging the
`pkg_resources` module to fetch the version from the module `PKG_INFO`.

This also breaks apart the GitHub actions for lint, docs, and tests into
their own workflows allowing for more parallelization.
rustydb added a commit that referenced this issue Oct 14, 2022
@rustydb
Fixes #44 and #182 Build Once and Use Git-Tags
f148f40 
This removes the `.version` files and uses git-tags. `canu` now versions
itself within `setup.py` based on `git describe --tags`.

This also builds canu inside of the RPM `specfile` using `pyinstaller`
and no longer uses a special `pyinstaller` image.

The spec file will create a `canu` user.

All of the `requirements` files were converted into `setup.py`, this
tidies up the repository by using less files.

All references to the `.version` files were replaced by leveraging the
`pkg_resources` module to fetch the version from the module `PKG_INFO`.

This also breaks apart the GitHub actions for lint, docs, and tests into
their own workflows allowing for more parallelization.

Lastly this adds an automated, weekly dependabot scan for making PRs to
update dependencies.
trad511 added a commit that referenced this issue Oct 21, 2022
@trad511
Fixes #44 and #182 Build Once and Remove .version (#184)
819c745
rustydb added a commit that referenced this issue Nov 1, 2022
@rustydb
Relates to #44 - Fixes stable RPM's
afa0f5a 
Stable builds of `canu` are reporting a version string with `dev1`
appended to the end, this implies the build was done with a dirty repo
(uncommitted changes). This occurs because the CSM metadata we add to
the spec file causes the repo to become dirty. This change tells Git to
assume that the `.spec` file is clean, thus preventing git from
identifying the repo as dirty during the build.
@rustydb rustydb mentioned this issue Nov 1, 2022
Merged
6 tasks
trad511 added a commit that referenced this issue Nov 1, 2022
@trad511
Relates to #44 - Fixes stable RPM's (#228)
c28118a
rustydb added a commit that referenced this issue Nov 2, 2022
@rustydb
Relates to #44 - Fix stable Docker images
f3e08c5 
Stable Docker images (ones built from git-tags, previously from `main`)
were failing due to the Zypper GPG checks. The GPG checks do not have
the public key from our repository necessary for accepting signed RPMs.

This bypasses those checks, allowing stable Docker builds to work.
@rustydb rustydb mentioned this issue Nov 2, 2022
Merged
6 tasks
rustydb added a commit that referenced this issue Nov 4, 2022
@rustydb
Relates to #44 - Fix stable Docker images (#229)
d86a760
lukebates123 pushed a commit that referenced this issue Apr 8, 2024
@rustydb
Fixes #44 and #182 Build Once and Use Git-Tags
916f4de 
This removes the `.version` files and uses git-tags. `canu` now versions
itself within `setup.py` based on `git describe --tags`.

This also builds canu inside of the RPM `specfile` using `pyinstaller`
and no longer uses a special `pyinstaller` image.

The spec file will create a `canu` user.

All of the `requirements` files were converted into `setup.py`, this
tidies up the repository by using less files.

All references to the `.version` files were replaced by leveraging the
`pkg_resources` module to fetch the version from the module `PKG_INFO`.

This also breaks apart the GitHub actions for lint, docs, and tests into
their own workflows allowing for more parallelization.

Lastly this adds an automated, weekly dependabot scan for making PRs to
update dependencies.
lukebates123 pushed a commit that referenced this issue Apr 8, 2024
@trad511
Fixes #44 and #182 Build Once and Remove .version (#184)
6c89184
lukebates123 pushed a commit that referenced this issue Apr 8, 2024
@rustydb
Relates to #44 - Fixes stable RPM's
389349c 
Stable builds of `canu` are reporting a version string with `dev1`
appended to the end, this implies the build was done with a dirty repo
(uncommitted changes). This occurs because the CSM metadata we add to
the spec file causes the repo to become dirty. This change tells Git to
assume that the `.spec` file is clean, thus preventing git from
identifying the repo as dirty during the build.
lukebates123 pushed a commit that referenced this issue Apr 8, 2024
@trad511
Relates to #44 - Fixes stable RPM's (#228)
ac07806
lukebates123 pushed a commit that referenced this issue Apr 8, 2024
@rustydb
Relates to #44 - Fix stable Docker images
966d476 
Stable Docker images (ones built from git-tags, previously from `main`)
were failing due to the Zypper GPG checks. The GPG checks do not have
the public key from our repository necessary for accepting signed RPMs.

This bypasses those checks, allowing stable Docker builds to work.
lukebates123 pushed a commit that referenced this issue Apr 8, 2024
@rustydb
Relates to #44 - Fix stable Docker images (#229)
e4a2cd0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rustydb rustydb

Labels
priority enhancement Mission Critical Requirement
Projects
None yet
Milestone
No milestone
2 participants
@jacobsalmela @rustydb