Why rultor use .rultor.yml from base branch and not use it from branch inside pull request

[Slach]

see Slach/test_tasks#5 (comment)
i added sudo to my rultor.yml
but when rulton run install
he used old instruction without sudo
why?

[0crat]

@yegor256 please, pay attention to this issue

[driver733]

@Slach rultor uses .rultor.yml only from master branch, so in order to get rultor to behave differently you have to manually commit and push a new (corrected) version of .rultor.yml file to the master branch.
@yegor256 I think this should be mentioned in the rultor's guidelines/instructions. I faced this issue myself and solved it only by guessing that rultor always uses the .rultor.yml file from the master branch.

[yegor256]

@Slach this is how it should work, according to #1039 But it's not fully implemented, as far as I can tell.

[0crat]

@yegor256 please, pay attention to this issue

[yegor256]

@Slach this code doesn't do anything, but it should actually fetch and merge: https://github.com/yegor256/rultor/blob/1.64.1/src/main/java/com/rultor/profiles/Profiles.java#L96-L99

[extsoft]

I have a similar behavior for Rultor. I mean the Rultor follows masters .rultor.yml and ignores changes from the forked branch (see bees-hive/elegant-git#136 (comment); the testing is failed as a new version of docker image is not used). @yegor256 @driver733 do I need to create an additional issue about it (this issue is silent for 2 years)?

[dgroup]

@yegor256 there might be security issue here, as someone in pull request may add

script: |-
   ...
   env
   ...
   cat your.assets 

and your variables or assets will be available in logs...

Be very careful with such type of feature requests...

[driver733]

@extsoft As pointed out by @dgroup, I think that Rultor should use only the master branch config.

[extsoft]

@driver733 I understand the security risks and they should be handled as well.

However, from a functional point of view, I update the branch's config with an incompatible change. And the behavior I described should happen only in the branches that have the new changes, but all other branches should behave in the correspondence of their own config - it's like other CI servers work.

Now, If I push an incompatible change to master, all other branches will fail until they pull master's changes.

And I can't submit a task that updates the Rultor config and does some changes in one pull request. I must split. But this makes review procedure more complex.

Again. I understand that there may be a security issue. But this is a non-functional requirement, and it should be handled properly. And this issue is about a feature request. So, security requirements should be a part of the feature implementation as well as other non-functional requirements.

@dgroup @driver733 does it make sense?

[driver733]

@extsoft You're right, it makes sense.

I am using Github Actions and it works the following way:

1. CI uses config in the according branch
2. Repository forks are not permitted to access secrets.

I think this kind of behavior is the most preferable.

[pnatashap]

@driver733 @yegor256 now it is by design feature. may be this should be added to documentation? there are many questions about it. And now fail can not be changed at all. #1459