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

feat: Add pattern matching support to atlantis plan/apply -d flag #2742

Closed
wants to merge 4 commits into from
Closed

Conversation

jmediald-te
Copy link

@jmediald-te jmediald-te commented Nov 30, 2022

what

  • This PR adds support for filepath pattern matching expressions to the -d/--dir flag in atlantis plan/apply commands. The user must use the --enable-regexp-cmd server configuration flag to activate this feature.

  • When we run atlantis plan/apply -d <pattern>, atlantis will behave exactly the same way as when running atlantis plan/apply. The only difference is that it will only plan/apply the projects whose relative dir matches with the specified pattern.

why

references

@jmediald-te jmediald-te requested a review from a team as a code owner November 30, 2022 19:39
@jamengual
Copy link
Contributor

thanks @jmediald-te for the contribution
could you add docs with examples and tests for this new flag?

@jamengual jamengual added feature New functionality/enhancement waiting-on-response Waiting for a response from the user labels Nov 30, 2022
@nitrocode
Copy link
Member

How is this different than --enable-regexp-cmd ?

@jmediald-te
Copy link
Author

Thanks for your response @jamengual. I will try to work on the docs/tests later.

@nitrocode - Based on the documentation, --enable-regexp-cmd allows us to use regular expressions when using the -p command. It is often the case where we do not have all projects defined in atlantis.yaml so the -p flag won't work. The atlantis apply/plan -f <pattern> command would be equivalent to atlantis apply/plan -d <pattern> if the -d flag had support for pattern matching.

@jamengual
Copy link
Contributor

jamengual commented Dec 1, 2022 via email

@jmediald-te
Copy link
Author

Makes a lot of sense. It will be more consistent.

I will work on that.

@nitrocode
Copy link
Member

nitrocode commented Dec 2, 2022

Related discussion in PR #2694 with @secustor. Unsure if you folks want to close your existing prs and create a new one or use an existing pr and/or work together?

See issue #259

@secustor
Copy link
Contributor

secustor commented Dec 2, 2022

@nitrocode I think this are two different use cases.

This PR is used to define the runs based on the folder structure. Ignoring defined projects if I'm not mistaken. Sry I'm on my mobile so I can't check the code reasonable.

My PR is about running all defined projects.

@nitrocode
Copy link
Member

@secustor as of today, you are technically correct about both prs, however the discussion has led back to a -d regexp. Both you and this pr author have attempted different solutions to the same problem. Since that is the case, i am suggesting that one of you drives the suggested solution using -d regexp and the other contributes as a pr reviewer (or author) so we can achieve the desired outcome 😄

@nitrocode nitrocode marked this pull request as draft December 5, 2022 03:31
@jmediald-te
Copy link
Author

Hey, sorry for my late reply. I have been very busy these days. I will be working on this today.

What I am doing is basically adding support for filepath pattern matching into the atlantis apply/plan -d flag. The pattern matching will only take into consideration the projects/plans that would be planned/applied by the current atlantis plan/apply (i.e. the project that are modifyed by the PR in the case of atlantis plan and the currently unapplied plans in the case of atlantis apply). At first, I created a new -f/--filter flag but as @jamengual mentioned it will be more consistent to add this functionality into the already existing -d flag.

If you want I can rename this PR to: feat: Add support for filepath pattern matching into atlantis plan/apply -d flag. Or create a new PR with the new name.

@jmediald-te
Copy link
Author

I have just moved the functionality of the -f/--filter flag to the already existing -d flag. In order for this to work the user needs to use --enable-regexp-cmd.

@@ -332,6 +342,15 @@ func (p *DefaultProjectCommandBuilder) buildPlanAllCommands(ctx *command.Context
ctx.Log.Debug("moduleInfo for %s (matching %q) = %v", repoDir, p.AutoDetectModuleFiles, moduleInfo)
modifiedProjects := p.ProjectFinder.DetermineProjects(ctx.Log, modifiedFiles, ctx.Pull.BaseRepo.FullName, repoDir, p.AutoplanFileList, moduleInfo)
ctx.Log.Info("automatically determined that there were %d projects modified in this pull request: %s", len(modifiedProjects), modifiedProjects)

if p.EnableRegExpCmd && cmd.RepoRelDir != "" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code looks to be the same as lines 303 to 309.

Can we encapsulate this into a function to keep the code as DRY as possible?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or is there a better way to structure this so we can run this block for both if and else blocks?

@@ -482,6 +501,14 @@ func (p *DefaultProjectCommandBuilder) buildAllProjectCommands(ctx *command.Cont
return nil, err
}

if p.EnableRegExpCmd && commentCmd.RepoRelDir != "" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another duplicated block here

return filteredProjects, nil
}

func filterValidProjects(projects []valid.Project, filter string) ([]valid.Project, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we combine both filterProjects and filterValidProjects ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only difference I see is models.Project and proj.Path vs valid.Project and proj.Dir

return filteredProjects, nil
}

func filterPlans(plans []PendingPlan, filter string) ([]PendingPlan, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could also be combined with the above 2 functions. Only thing I see here that's different is using PendingPlan and plan.RepoRelDir

@@ -112,6 +112,10 @@ func (c CommentCommand) IsForSpecificProject() bool {
return c.RepoRelDir != "" || c.Workspace != "" || c.ProjectName != ""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please re-word the PR summary and title to reflect that this is no longer using the -f flag and instead will add wildcard filtering using the existing -d flag

func (c CommentCommand) HasDirPatternMatching() bool {
return strings.Contains(c.RepoRelDir, "*") || strings.Contains(c.RepoRelDir, "?") || strings.Contains(c.RepoRelDir, "[") || strings.Contains(c.RepoRelDir, "]")
}

// CommandName returns the name of this command.
func (c CommentCommand) CommandName() command.Name {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add tests for the new functionality

@nitrocode nitrocode added the needs tests Change requires tests label Dec 5, 2022
@jmediald-te jmediald-te changed the title feat: Add -f flag to filter which directories to run apply/plan using patte… feat: Add pattern matching support to atlantis plan/apply -d flag Dec 6, 2022
@nitrocode
Copy link
Member

If we add a -d flag, we will have to also allow setting a unique workspace along with it for people that use workspaces.

The following should work

# should plan everything using the dev workspace
atlantis plan -d .* -w dev
# should plan everything using the prod workspace
atlantis plan -d .* -w prod
# should plan everything using the default workspace
atlantis plan -d .*

@nitrocode
Copy link
Member

@jmediald-te friendly ping here. We'd love to see this change in the next release if you have time.

@jmediald-te
Copy link
Author

Hey @nitrocode, sorry for my late reply. I have been out of office during the holiday break. I will be working on this soon.

@nitrocode
Copy link
Member

Hi @jmediald-te . Any update on this? We'd love to see this feature. It's currently the second highest feature requested. :)

https://github.com/runatlantis/atlantis/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@github-actions
Copy link

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

@github-actions github-actions bot added the Stale label Mar 26, 2023
@github-actions github-actions bot closed this Apr 27, 2023
@jamengual jamengual reopened this Apr 27, 2023
@github-actions github-actions bot removed the Stale label Apr 28, 2023
@github-actions
Copy link

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

@github-actions github-actions bot added the Stale label May 29, 2023
@github-actions github-actions bot closed this Jun 29, 2023
@jamengual jamengual reopened this Aug 18, 2023
@jamengual
Copy link
Contributor

if someone is willing to work on this and finish this pr , we will be happy to review

@github-actions github-actions bot removed the Stale label Aug 19, 2023
@github-actions
Copy link

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

@github-actions github-actions bot added the Stale label Sep 19, 2023
@jamengual
Copy link
Contributor

@jmediald-te do you think you can continue this work? Thanks.

@github-actions github-actions bot removed the Stale label Sep 28, 2023
@github-actions
Copy link

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

@github-actions github-actions bot added the Stale label Oct 29, 2023
@jrodante
Copy link

jrodante commented Nov 2, 2023

Would love to see this make it to the finish line, any updates on when work can be resumed on it?

@jamengual
Copy link
Contributor

The original committer has not responded in a while if you have time @jrodante and golango knowledge go for it.

@github-actions github-actions bot removed the Stale label Nov 3, 2023
@jamengual
Copy link
Contributor

if anyone is interested, please reopen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement needs tests Change requires tests waiting-on-response Waiting for a response from the user work-in-progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow supplying wildcard for dir
5 participants