The current CI runs on individual patches. Sometimes it can become a problem since it forces the contributor to merge the complete changes in a single patch.
For example, for ticket #167 the pkispawn needs to be renamed into pkispawn.py and moved into Python library folder. The file actually contains pylint issues, but it was not known before the move because of another bug in the pylint script.
Naturally, the contributor will create a patch for the rename/move first, because that's the main goal. Then when build fails he/she will create another patch to fix the pylint issue. These patches should have been easy to review because the first one only contains a rename operation with no content change, and the second patch only contains pylint changes.
However, CI will fail on the first patch because it exposes the pylint issue. To avoid CI failure, the patches have to be merged. However, the merged patch will be much bigger since the pkispawn.py is considered a new file that also contains pylint changes. It more difficult to review because the file has to be diff-ed manually against the old one.
One solution is to fix pylint issues before the rename/move, but that will require the contributor to reconstruct the patches.
Ideally the CI should only run when it receives the entire patch set so it will have the complete changes. Also, it will be more efficient since the CI will only need to run once. Keeping the patches small will make it easier to review and also help during cherry-pick/rebase since git can trace rename/move operations in the history and adjust the patch automatically.
Metadata Update from @mharmsen: - Custom field component adjusted to None - Custom field feature adjusted to None - Custom field origin adjusted to None - Custom field proposedmilestone adjusted to None - Custom field proposedpriority adjusted to None - Custom field reviewer adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 0.0 NEEDS_TRIAGE
FYI, GitHub runs the CI on each push, not on each patch. So if there are multiple patches submitted in a single push, CI will only run once with all patches included.
Per PKI Team Meeting of 20180109: FUTURE
Metadata Update from @mharmsen: - Issue set to the milestone: FUTURE (was: 0.0 NEEDS_TRIAGE)
When multiple patches are submitted at the same time, sometimes it fails with the following error:
$ git clone --depth=50 --branch=bot_20180226-154228_361 https://github.com/pki-jenkins-bot/pki.git pki-jenkins-bot/pki Cloning into 'pki-jenkins-bot/pki'... warning: Could not find remote branch bot_20180226-154228_361 to clone. fatal: Remote branch bot_20180226-154228_361 not found in upstream origin
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2995
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.