rultor

rultor copied to clipboard

see https://github.com/Slach/test_tasks/pull/5#issuecomment-305800306 i added sudo to my rultor.yml but when rulton run install he used old instruction without sudo why?

@yegor256 please, pay attention to this issue

@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.

@Slach this is how it should work, according to https://github.com/yegor256/rultor/issues/1039 But it's not fully implemented, as far as I can tell.

@yegor256 please, pay attention to this issue

@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

I have a similar behavior for Rultor. I mean the Rultor follows masters .rultor.yml and ignores changes from the forked branch (see https://github.com/bees-hive/elegant-git/pull/136#issuecomment-505442323; 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)?

@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...

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

@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?

@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.

@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