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")
  • Need to figure out how to implement this (#290)
  • Need an endpoint (or any machinery) in which we can create new distros on beholder side to monitor, so beholder helps on dealing with these and match packages in product from several repos (#291)
• 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
• 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