Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure that branch has been updated to point off of master #35

Closed
atlantisbot opened this issue Mar 6, 2018 · 9 comments
Closed

Ensure that branch has been updated to point off of master #35

atlantisbot opened this issue Mar 6, 2018 · 9 comments
Labels
feature New functionality/enhancement

Comments

@atlantisbot
Copy link

Issue by @lkysow
Tuesday Sep 05, 2017 at 01:54 GMT
Migrated from hootsuite/atlantis#143
Why was it migrated?


Right now we don't check whether a branch has been updated to the latest master. We should just error out if it hasn't, otherwise the plan will be weird.

@atlantisbot
Copy link
Author

Comment by @grobie
Thursday Feb 15, 2018 at 17:36 GMT


That wouldn't work well for us. While we don't have a company-wide monorepo, we do have one for all infrastructure changes. There can be tens of unrelated commits in the same repository per hour.

A better approach would be to ensure that the commit of the latest applied state is in the history of the current commit. I'll explain that tomorrow in our call.

@atlantisbot
Copy link
Author

Comment by @lkysow
Thursday Feb 15, 2018 at 21:21 GMT


Ahh interesting, I should have thought of that. Right now Atlantis just uses a file-based key-value store which is "okay" to lose because all it records are locks. It might be dangerous to rely on that store for looking up commit => state information.

At some point we'll move to an actual DB which might enable that better. I agree that that would be the most exact way to ensure the pull request is up to date.

@majormoses
Copy link
Contributor

I think there is some middle ground here since at least in the case of github that is a type of branch protection. If its enabled we should honor it and not allow the plan to run and otherwise give people enough rope to hang themselves.

@sstarcher
Copy link

I think it would be great to attempt to auto-rebase on master. This is a feature that a tool like Jenkins supports.

@majormoses
Copy link
Contributor

Ya auto rebase off master when possible would be awesome.

@sstarcher
Copy link

@lkysow should this issue be closed as won't fix due to #374 being rejected in preference for custom workflows?

@lkysow
Copy link
Member

lkysow commented Dec 7, 2018

The original issue was about warning users if they were generating a plan from a pull request that was out of date with master. This hasn't been solved so I don't think it makes sense to close the issue.

Even with the warning, we have to find a way to deal with the case of users who don't use master as the default branch.

@sstarcher
Copy link

Sure, the branch could be configurable, but if you just supported rebasing onto whatever that branch is out of the box it would resolve both cases. I don't understand how this is a desirable feature, but #374 was not

@majormoses
Copy link
Contributor

We can query the repo for the name of the default_branch: https://developer.github.com/v3/repos/#get

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement
Projects
None yet
Development

No branches or pull requests

4 participants