Building custom products
No due date
64% complete
Right now it's counter-intuitive to build anything other than AlmaLinux with Build System. We want to remediate that.
We reach this milestone when:
Right now it's counter-intuitive to build anything other than AlmaLinux with Build System. We want to remediate that.
We reach this milestone when:
- User can create a custom product ✔️
- User can set up one or many repositories for it (#20)
- Several repos in one product
- User can set up certificate to sign packages with (#21) ✔️
- User can sign built packages with proper certificate (#21) ✔️
- Troubles in creating product sign keys - need to verify if it works (#288)
- User can update certificate. (Packages signed with old certificate can NOT be validated) (#36)
- User can set up their own sign node and use it to sign product packages
- This is a long-term idea
- In a short-term, we need to be able to limit some sign nodes to only certain products and vice versa
- MUST HAVE: limit some sign nodes to only certain products (#289)
- NICE TO HAVE: allow products to indicate which sign node they want to use for package signing
- User can assign
product_maintainer
role for this product to (him/her) self or to another user without external help (#37)- Assign user roles in product is already possible (see my comment). I'd say that the rest of the AC can be considered low priority.
- User can re-release package(s) into another one of their repositories (e.g. from "beta" to "stable")
- User can read straightforward, publicly available documentation on how to build custom products in ALBS (#292)
- Toggle in product "requires sign", overrides in release the "need to sign" requirement, if marked as such (#293)
- COPR - gpg check on vs off (#294)
- Access rights for new product are not sufficient for releases
- Bug when trying to add new members to product (#295)
- Manager should be able to assign roles to team members (It works) ✔️
- Prevent builds scheduler to not be overwhelmed by community builds (with configurable rate limits) (#296)
- This is about ensuring that there are always available builders for AlmaLinux
- Filter by product in build list (save to cookie) - "only my products"? (#297)
- This is about having a user preference (like
filterByProductId
) stored in the browser and is taken into account when listing builds
- This is about having a user preference (like
- UX: make it clear when you release something in product that is not built/added in product. You need to do it through "releases" menu (its about Add to product button).
- The only way to release stuff should be using the release interface
- Warn the person doing a release that what you're about to release does not belong to the product it was built for (if it's the case) (#299)
- UX: Creating new product is not really intuitive
- After we make the improvements around products, we need to update the product creation accordingly.
- Needs to be discussed, scoped and described in an issue after most of the items on this milestone are done
- UX: Creating release is not intuitive (need to hit "+" before hitting "submit")
- Andrew suggests that, when there's only one build, clicking submit should work. When several builds are involved, you need to click +.
- Vasily suggests to allow to just hit enter
Limitations:
- No rollout release capabilities for custom products - but we don't really think we need them in ALBS
Things to check:
- Ensure we sign COPR repodata - if not do it
- if we're re-signing the repo in case a COPR repo gets a new key, we can't forget repodata