These requirements are no longer needed. Move pytest and munch to devel reqs,
because they are only needed for tests.
Related: #306
Co-authored-by: Kamil Páral <kparal@redhat.com>
Changes:
- Convert to a single job where linter step fails the job
- Use ./run script to run tests and linters the same way as a developer does
- Use `set -e` to fail for any failed command, not just the last one
- Install only requirements-development.txt (already includes requirements.txt)
- Formatting improvements
Fixes: #315
Related: #306
Co-authored-by: Jaroslav Groman <jgroman@redhat.com>
Every web request triggers a db query to preload app header data. In case of health checks
we do not need to preload anything and can safely skip the @app.before_request.
Fixes#310
- Fix problem with proposed bugs with different milestones of the same release creating two different tickets
- Add tests covering this usecase
Fixes#304
Assisted-By: Claude Code
This drops Pagure integration for creating and processing blocker discussion
tickets and replaces it with a Fedora Forge (Forgejo) integration.
Additional related changes are:
- Testing is now performed through containers (Forgejo is one of those
containers now)
- docs/source/blockerbugs-workflow.md is added for a quick architecture overview
for people and AI
- docs/source/usage.md is added for a similar purpose documenting usage hints
- docs/source/blockerbugscli.rst is extended for all commands
- development setup instructions changed, using a different DB container with
different variables
- pytest configuration was moved from setup.cfg to pyproject.toml due to syntax
escaping issues
- a new pyforgejo dependency is added
Related #296
Merges #299
Assisted-By: Claude Code
CI is a bit tricky because the requirement files are designed
to match the rather odd environment we deploy blockerbugs in in
production: Python 3.11 on RHEL 9 with almost all dependencies
installed via pip. This includes compiling gssapi and krb5. So
instead of my usual "just throw tox at it" approach, this
replicates that same environment: we use an Alma 9 container,
install the Python bits and the necessary compiler and devel
dependencies, then use pip to install all the deps. Then we run
the linters and the tests (not using `run` because this ancient
pip on this ancient Python on this ancient RHEL doesn't install
the binaries, you have to use `python -m`).
The linters fail at present because there are lots of real
problems; I assume nobody ran these checks for a while. I included
a fix for the biggest flood of mypy issues, but otherwise I
figured to leave the problems alone because I don't want to
cause conflicts with the forgejo port PR. I figure once we get
that PR merged we can then fix up the linting issues. But at least
we'll have tests and AI review run on that PR while we work on
it.
Closes#300
Signed-off-by: Adam Williamson <awilliam@redhat.com>
See https://github.com/pallets-eco/flask-sqlalchemy/issues/1327 .
Basically, due to a fundamental incompatibility between how
Flask-SQLAlchemy works and how typing is meant to work, if you
use Flask-SQLAlchemy as documented (like we're doing here), you
get typing errors.
I tried the "Declaring a type for db.Model" workaround, but for
me - as for the issue author - it didn't work, I got the same
"Incompatible types in assignment" errors. So let's just go with
disabling the name-defined error on the files affected by this.
Closes#300
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The test suite was crashing, caused by old Werkzeug. Flask needs to updated
with it. Upgrade both to latest versions.
(The "match production" comment needs to re-evaluated, tbd later).
This code will create duplicate entries when handling a bug
with multiple tracker types that does not currently exist. On
each trip through the `for tracker in trackers:` loop we create
a new bug.
Instead of using `oldbug` and `newbug` to refer to (respectively)
a db bug entry that existed before the function ran and one that
is being created by the function, let's use `dbbug` for both,
which solves the problem because on any loop iteration after the
first has created the db bug entry, `dbbug` will exist and we
will go down the other branch, where we update it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
For third-party libraries, just use a blanket ignore for all DeprecationWarning
in that library. There seems to be no benefit in explicitly listing them in
setup.cfg.
The host system tools are often at a different version, which can present issues
when dumping or restoring the database (e.g. unknown option errors). Change
the docs to always use postgresql tools from the container.
Versioneer was failing because git now checks for user ownership on a git folder
and refuses to work if the ownership isn't correct. This file definitely
shouldn't be in the source repo, but at this moment, we're not sure how to make
it part of the deployment scripts (Frantisek promises to look at it really
soon(tm)).
