Drop all STI references, update pipeline page, drop obsolete pages #95
No reviewers
lecris
Labels
No labels
Standard Test Interface
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Status/Blocked
Status/Discuss
Type
Bug
Type
Feature
Type
Task
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ci/docs!95
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "adamwill/ci-docs:drop-sti"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This drops all references to STI, updates the pipeline page to
cover what pipelines we still have and what they really do, and
drops several pages that are now obsolete. The nav sidebar and
index page are updated appropriately for the changes. We also
correct the pipeline section on the index page, cover Packit
there, and de-emphasize some Pagure stuff because there is no
pagure.io any more (while keeping bits that are relevant to
dist-git Pagure).
Signed-off-by: Adam Williamson awilliam@redhat.com
Note: this removes the Testing Tests section from the Share Test Code page entirely at present. The existing example is STI-specific and broken. Ideally we would replace it with a TMT-based example that works, though, rather than deleting it. If someone can give me some references I'll try and improve that.
f119787b2bc3b2876e3cc3b2876e3cfeb40086ccfeb40086ccb7a9b53623I added a few more commits with more spring cleaning and modernizations.
LGTM as a first cleanup step. I suspect we need a bit more cleanups after glancing that
onboarding-of-a-ci-system@ -182,3 +99,1 @@# fmf ls --filter "tier: 1 | component: checkpolicy"/selinux-policy/policy-rpm-macros/checkpolicy/sedispol# fmf ls --filter "tier: 1 | component: libsepol"Probably would be a good time to document the user to use
instead. But the current works just as good
Do you want me to change this?
If you find a a way to squeeze it in sure, otherwise, it's not a blocker.
hmm, it doesn't really fit in this doc, I don't think, as this is an example of tests shared between multiple packages, and we're specifically showing how to find exactly the tests from the shared repo that would be run with a specific filter config in the package repo, right? i.e. what we're doing here is showing how to figure out exactly what tests from the shared repo are run when the package repo has the filter
tier: 1 | component: libsepol. It doesn't seem liketmt run discoverreally shows you that? It probably belongs on a different page...maybe the tmt page?tmt run discoveris more explicit in showing the exact tests that would be run including whatever filters were applied (this bit), accounting for context manipulation (e.g. disabled tests), funky handling of refs (sometimes you tell it to checkout a ref, finds a file, and checkout another ref 🙈).The
fmffilter does cover 90% of the cases, but it does not separate tmt tests from plans. I thinktmt tests lsdoes accept filters to at least add that bit of separation as well.But anyway that's going into the weeds, will improve that bit later when some ideas of how to reorganize the whole section strikes
ok, you clearly know how it works better than me, please fix it however you like :D just try to keep with the overall intent of the doc.
@ -23,3 +23,3 @@Tests used across multiple components or OS releases can be stored in the *dist git test namespace* to share the test code and minimize maintenance.Fetching tests from an *upstream project git* is also possible and supported by standard-test-roles (source role).Fetching tests from an *upstream project git* is also possible and supported by TMT.In order to prevent unexpected test failures caused by upstream changes it is sometimes better to reference a specific commit rather then branch.The specific commit has not been adopted, maybe we can just drop. The rest down is even less adopted.
@ -5,3 +5,2 @@Gating of packages based on test results is currently enabled on demand.If you want to turn the gating on for your component create a new file `gating.yaml` in the root of the package dist git directory with the following content:The https://forge.fedoraproject.org/infra/ansible/src/branch/main/roles/openshift-apps/greenwave/templates/fedora.yaml.j2[Fedora greenwave configuration] enforces some distribution-wide gating policies. Updates in most critical path groups (not the ones for non-release-blocking desktops) are gated on subsets of the https://fedoraproject.org/wiki/OpenQA[Fedora openQA] update test suite depending on which group(s) they are in. This gating is not optional and cannot be disabled.Thanks for this update 🙂.
Just minor note, I think the style guide is to split at new sentence?
I'm never totally sure where to split :D I can tweak this, though.
Me neither, I had to check that this one follows that. I know the other pages like the packaging guideline a consistent like that at the very least
@ -69,0 +76,4 @@Publishing results to the production ResultsDB instance requires authentication. You will need to ask the Infrastructure team for credentials for this. It is a good idea to test your reporting code against a local ResultsDB instance first.CI systems may also publish standardized CI messages so the progress of the testing can be observed and the results can be acted upon by other services in the Fedora infrastructure.There is a https://forge.fedoraproject.org/apps/ci-resultsdb-listener[system] that automatically forwards CI messages in certain formats to ResultsDB, so you may be able to avoid having explicit result reporting code.Aren't we killing this one?
We're aiming to, but we didn't yet. I figured it's best to document what exists now, not what we hope to change it to, in case we don't get around to it or it turns out to be a bad idea...
Can put a note pointing to the deprecation ticket at least?
Done.
f680209e783f3dcc41c53f3dcc41c5b9a737a769