Conversation
Jarkko Sakkinen
jarkko
Edited 3 months ago
Containers cross-talk in standards and even share sub-projects. CI's don't.
I think we as an industry could take the quantum leap and define standard for something like ".runner-ci.yml", and when split to multiple files ".runner-ci.d/*.yml". Then, just define stages and tasks.
That would also fix migration between hosts for Git repositories. Also, in a private company internal CI and external CI can sometimes be different. Only way to address is to support both, which is redundant work.
I think we as an industry could take the quantum leap and define standard for something like ".runner-ci.yml", and when split to multiple files ".runner-ci.d/*.yml". Then, just define stages and tasks.
That would also fix migration between hosts for Git repositories. Also, in a private company internal CI and external CI can sometimes be different. Only way to address is to support both, which is redundant work.
1
1
1
Christian Holme
hcmh@ieji.de@jarkko Oh yes, that'd be such a blessing. Starting and tearing down so many containers for CI is a huge waste of time and resources. If containers could configured to be reused across stages instead, that'd be a lot better.
1
0
0
Jarkko Sakkinen
jarkko
@hcmh Also you have to seek a cli for running CI changes locally.
To make things worse, none of them are supported by the main project so you have to got to a treasure hunt in order find one.
Something like librunner-ci and runner-ci would be best I.e. runner services can call the API and runner-ci implement command -line application for running a CI job using librunner-ci, which has a dual function as a reference implemention for runner services adding heir adaptation.
To make things worse, none of them are supported by the main project so you have to got to a treasure hunt in order find one.
Something like librunner-ci and runner-ci would be best I.e. runner services can call the API and runner-ci implement command -line application for running a CI job using librunner-ci, which has a dual function as a reference implemention for runner services adding heir adaptation.
0
0
0