Skip to content
This repository has been archived by the owner on Dec 26, 2023. It is now read-only.

FR: only auto-apply default branch #395

Closed
pat-s opened this issue Apr 19, 2023 · 7 comments
Closed

FR: only auto-apply default branch #395

pat-s opened this issue Apr 19, 2023 · 7 comments

Comments

@pat-s
Copy link
Contributor

pat-s commented Apr 19, 2023

In TF cloud the default is to only run "auto apply" on the default branch, i.e. runs triggered from PRs only do a speculative plan.

This is indeed very good and important when working with PRs/reviews as otherwise these would be auto-applied on first push otherwise.

Also, when having auto-apply off, one is currently always required to go to OTF and explicitly apply a run on the default branch - which sometimes should just apply silently in the background.

@leg100
Copy link
Owner

leg100 commented Apr 20, 2023

Hello @pat-s, could you elaborate further? I'm not sure what it is you're requesting.

Also, when having auto-apply off, one is currently always required to go to OTF and explicitly apply a run on the default branch - which sometimes should just apply silently in the background.

Is this not what you would expect? If auto-apply is off then one has to manually apply a run.

@pat-s
Copy link
Contributor Author

pat-s commented Apr 21, 2023

I guess in a nutshell: make it configurable which branches use auto-apply.

Background: I would like to have auto-apply on the default branch (e.g. when merging PRs or pushing directly to it) and have plan-only runs on all other branches.
Otherwise feature branches would directly apply resource changes on push, which is not desired.

The above is also the (default ?) behavior in TFC.

image

@leg100
Copy link
Owner

leg100 commented Apr 21, 2023

How about: add the ability to set the default branch?

TFC gives you this option:

image

Applies are only permitted on that branch.

@pat-s
Copy link
Contributor Author

pat-s commented Apr 22, 2023

Applies are only permitted on that branch.

I think it would be great not to be too strict, i.e. applies should be possible on non-default branches but by default only to a plan-only run.

In some scenarios we do applies on feature-branches to see if something is working out and then just redeploy main to get back to our "sweet spot" (in our dev environment). I think this is quite common workflow approach.

So summarizing it again, my proposal is as follows:

  • Have auto-apply only enabled for the default branch
  • Do plan-only runs on non-default branches
  • Allow/do not block applies on non-default branches

@leg100
Copy link
Owner

leg100 commented Apr 25, 2023

This PR is still unclear in my mind. The title is "FR: only auto-apply default branch". But this is how OTF currently works: if auto-apply is enabled on a workspace, then it'll take effect only on the default branch.

Then you say "I guess in a nutshell: make it configurable which branches use auto-apply.". But that is the opposite of what you ask for in the PR title.

And lastly you propose:

  • Have auto-apply only enabled for the default branch
  • Do plan-only runs on non-default branches
  • Allow/do not block applies on non-default branches

Again, the current behaviour of OTF already matches your first two proposals.

So, to cut this PR down to what it is proposing to change, is it just?:

  • Allow/do not block applies on non-default branches

@pat-s
Copy link
Contributor Author

pat-s commented Apr 27, 2023

Sorry for the confusion!

if auto-apply is enabled on a workspace, then it'll take effect only on the default branch.

Correct, for all other branches, no run is started or can even be triggered from the UI. Only from local applies. I can't recall my thought process of the previous comments anymore 😅

Allow/do not block applies on non-default branches

This is definitely something that would be great to have. I agree the FR could be changed to this.

Coupled with this comes the wish of being able to auto-run "plan-only" runs on pushes to non-default branches.

I guess it makes more sense to close this issue and open one (or two) new ones with a clear description based on the wishes of this comment of mine?

@leg100
Copy link
Owner

leg100 commented May 1, 2023

I guess it makes more sense to close this issue and open one (or two) new ones with a clear description based on the wishes of this comment of mine?

Yes, I think that would make sense.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants