You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is support for building different stategies. This is useful for long term work like PGO enablement, where we want to regularly build across weeks/months.
It would be very useful if we could also trigger a one-off build from a specific repo/branch. I think this will be especially important if we develop snapshots on rawhide.
For example, let's say we want to re-enable lldb tests. The way we would have done this in the past is to push something that works in local x86_64 tests, and then keep pushing fixes each day until everything works. This is acceptable for a separate branch, but I don't think it's acceptable for rawhide.
Instead, what I have in mind here, is that we would work on a branch and use manually triggered workflow_dispatch with an input field for the branch until all issues have been ironed out and we're ready to merge into rawhide.
I think it should be fairly easy to support triggering snapshot builds in this way, but if we also want to support the automatic issue tracking + tmt tests, that's probably trickier.
The text was updated successfully, but these errors were encountered:
@nikic you are right. Triggering builds this way is fairly straight-forward. The check-snapshots workflow only looks at the Copr repository and has nothing to do with git.
So in theory, there's nothing to do here for as long as you're happy to override the snapshot build for the current day in Copr with your one-off build and a given branch.
On the other hand, if you wish to build in a separate Copr project, we can implement some method that checks for a bunch of Copr projects on each run of the check-snapshots workflow. If we for example find a nikic/llvm-scratch-build-<YYYYMMDD>-<ARBITRARY-NAME> we're gonna analyze it and create issues for it and label it with strategy/scratch-build. The fedora-copr-build could create such a Copr project for you.
If possible, I would suggest to do scratch builds with a limited amount of build chroots.
Here's an idea for how this could look like. The nested loop at the bottom reflects what I mean.
sequenceDiagram
nikic->>+Github: Start one-off build<br/>from custom branch with <br />branch=foo<br/>copr-name=bar
Github->>+Copr: Create copr project<br/>nikic/llvm-scratch-build-20241028-bar
Copr->>-Github: Project created
Github->>-nikic: Workflow started
loop Periodically run check-snapshots workflow
loop go through stategies: big-merge, pgo
Github->>+Copr: Check for fedora-llvm-team/llvm-snapshots-<strategy>-YYYYMMDD
Github->>+Github: Update daily issue
end
loop go through list of devs: nikic, tstellar, tbaederr, kwk, ...
Github->>+Copr: Check for existence of <dev>/llvm-scratch-build-YYYYMMDD-* copr projects
Copr->>-Github: Found nikic/llvm-scratch-build-20241028-bar
Github->>+Github: Update daily issue for this project.
end
end
Currently, there is support for building different stategies. This is useful for long term work like PGO enablement, where we want to regularly build across weeks/months.
It would be very useful if we could also trigger a one-off build from a specific repo/branch. I think this will be especially important if we develop snapshots on rawhide.
For example, let's say we want to re-enable lldb tests. The way we would have done this in the past is to push something that works in local x86_64 tests, and then keep pushing fixes each day until everything works. This is acceptable for a separate branch, but I don't think it's acceptable for rawhide.
Instead, what I have in mind here, is that we would work on a branch and use manually triggered workflow_dispatch with an input field for the branch until all issues have been ironed out and we're ready to merge into rawhide.
I think it should be fairly easy to support triggering snapshot builds in this way, but if we also want to support the automatic issue tracking + tmt tests, that's probably trickier.
The text was updated successfully, but these errors were encountered: