contrib/ci/run script: CI script cannot be executed from different directory.

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2429

• Created at 2014-09-03 16:59:08 by lslebodn
• Assigned to lslebodn

---

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

Comments

---

Comment from lslebodn at 2014-09-03 17:00:10

Fields changed

owner: somebody => nkondras

---

Comment from nkondras at 2014-09-03 17:09:57

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.

---

Comment from lslebodn at 2014-09-03 17:18:20

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.

---

Comment from nkondras at 2014-09-03 18:16:22

I'm sorry, I don't understand what you're suggesting the CI script should do.

---

Comment from lslebodn at 2014-09-04 09:18:51

Requirements:

• ci script must me able to work from different directory than sssd git root (e.g. subdirectory)
• all files generated by ci script should be stored in current directory or any subdirectories.

Note: autoreconf is the only exception. It must be executed from from sssd git root

---

Comment from nkondras at 2014-09-04 09:54:40

Thank you. Could you please list practical benefits for this? Examples where this might be useful?

---

Comment from lslebodn at 2014-09-04 11:33:13

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.

---

Comment from nkondras at 2014-09-04 11:34:55

I'm sorry, but this doesn't exactly answer my request.

---

Comment from nkondras at 2014-09-04 11:58:52

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.

---

Comment from mkosek at 2014-09-04 12:30:11

Replying to [comment:9 nkondras]:

Which practical inconveniences does the current CI behavior introduce for you? How implementing this will help you?

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

---

Comment from lslebodn at 2014-09-05 11:38:12

Fields changed

owner: nkondras => lslebodn
patch: 0 => 1
status: new => assigned

---

Comment from jhrozek at 2014-09-08 20:45:58

Fields changed

milestone: NEEDS_TRIAGE => SSSD Continuous integration

---

Comment from jhrozek at 2014-09-11 11:14:18

Fields changed

component: SSSD => Continuous integration

---

Comment from jhrozek at 2014-11-05 14:12:34

Fields changed

rhbz: => 0

---

Comment from lslebodn at 2017-02-24 14:49:36

Metadata Update from @lslebodn:

• Issue assigned to lslebodn
• Issue set to the milestone: SSSD Continuous integration

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards,
André Boscatto