Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

moncic-ci yaml parsing #26

Open
brancomat opened this issue Mar 15, 2022 · 2 comments
Open

moncic-ci yaml parsing #26

brancomat opened this issue Mar 15, 2022 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@brancomat
Copy link
Member

Our CI procedures (will) use .moncic-ci.yml files saved in various github projects, e.g.: https://github.com/ARPA-SIMC/moncic-ci/blob/main/.moncic-ci.yml:

version: 1
images:
 - name: fedora:34

version is mandatory, images is optional and defines the list of distro:version that the CI should build the project on. If omitted it implies "all of them", the full list is defined on the CI server.

The current CI procedure will then launch a parallel build for each distro/version, saving:

  • the complete build log
  • the exit status for each build
  • a global exit status (0 if every build succeeded)

As discussed earlier with @edigiacomo and @spanezz we could implement this behaviour directly in moncic-ci as a possible enhancement (in that case, moncic-ci yaml specifications should be documented somewhere in this repo)

@brancomat brancomat added the enhancement New feature or request label Mar 15, 2022
@edigiacomo
Copy link
Member

For each distro/version we should be able to set a timeout beyond which the single build must be terminated. We could have a default timeout value (like the list of images) and maybe a max value too: max value > yaml value > default value.

@spanezz
Copy link
Contributor

spanezz commented Sep 23, 2022

This is likely turning into a new option for moncic-ci, where it automates several build commands in parallel. I'd be tempted to rename the current ci in build, and implement this as ci.

This also means saving the logs of each builds separately in some destinations, and setting up builds differently depending on distributions (with the debian ones requiring a temporary merge with the debian/* or ubuntu/* branches).

I propose to specifiy the broader problem space into a practical config/implementation proposal, and then trying to implement it. I'd need your input in the proposal, since you're the Custodians of Use Cases

@spanezz spanezz added the help wanted Extra attention is needed label Sep 23, 2022
@spanezz spanezz removed their assignment Oct 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants