Learn more about these different git repos.
Other Git URLs
I am used to executing all configure scipt from different directory (subdirectory x86_64, bdir, ...). At the moment CI script have to be executed from sssd git root.
[user@host][/usr/src/sssd/x86_64]$../contrib/ci/run sed: can't read contrib/sssd.spec.in: No such file or directory error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: License field must be present in package: (main package) Traceback (most recent call last): File "/usr/src/sssd/contrib/ci/rpm-spec-builddeps", line 33, in <module> spec = rpm.spec(sys.argv[1]) ValueError: can't parse specfile
Fields changed
owner: somebody => nkondras
I'm not sure if it will make any sense fixing, as CI affects global state anyway by installing system packages, so it's not possible to contain it in the general sense.
Then, it runs autoreconf and that can only be done in the source directory. I'm not sure if there's anything to be done with that.
Lastly, it invokes configure from separate directories itself and .gitignore has entries for ignoring the artifacts.
Function reconfig from file contrib/fedora/bashrc_sssd calls autoreconf as well. Other dirty work is done in subdirectory "$SSS_ARCH". Such behaviour simplify rules for .gitignore or .git/info/exclude. CI script should not be exception.
I'm sorry, I don't understand what you're suggesting the CI script should do.
Requirements:
Note: autoreconf is the only exception. It must be executed from from sssd git root
Thank you. Could you please list practical benefits for this? Examples where this might be useful?
It is a part of sssd developers work flow to run everything in subdirectory.
We was forced to push your version of CI script into sssd upstream and file usability tickets. This is one of them.
I'm sorry, but this doesn't exactly answer my request.
I'll try to be a bit clearer.
Which practical inconveniences does the current CI behavior introduce for you? How implementing this will help you?
"We just do it this way" doesn't exactly answer these.
Replying to [comment:9 nkondras]:
I thought this is what Lukas tried to explain in the Description and in comment:7. Let us talk about it on our next meeting, discussing the developer workflows it affects.
cc: => mkosek
owner: nkondras => lslebodn patch: 0 => 1 status: new => assigned
milestone: NEEDS_TRIAGE => SSSD Continuous integration
component: SSSD => Continuous integration
rhbz: => 0
Metadata Update from @lslebodn: - Issue assigned to lslebodn - Issue set to the milestone: SSSD Continuous integration
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3471
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @pbrezina: - Issue close_status updated to: cloned-to-github - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.