#[SOLVED] Applying changes on my computer (--apply-changes) or, default mode, run in --dry-run

1 messages · Page 1 of 1 (latest)

fair sparrow
#

Hi all

I'm not yet sure it's a good idee... but I would like to add a flag like --apply-changes to my Dagger call like f.i.

dagger call --source-directory=/app/src/python --apply-changes black

The purpose is to replace all my custom scripts and use Dagger everywhere i.e. on my computer and too, on my GitLab CI.

On the CI; no discussion, a formatting tool like Python Black should run in a dry-run mode. Show the differences and exit. For sure.

On my computer, right now, I've thus plenty of make commands like make black, make php-cs-fixer, make shellformat, ...

With the idea of abandoning these scripts and just using Dagger for everything, I wonder if it wouldn't be a good idea to add an --apply-changes flag that I could use locally.

That flag will be False by default (I didn't have find a way to add a default value ; the doc https://docs.dagger.io/api/arguments/#directories-and-files only gives examples for Files or Directories)

Is this a good idea ? I've mixed feelings but yeah, I think it'll be better to maintain two code base (Dagger and ton of scripts)

Do you have any ideas that could help me achieve this goal?

Many thanks!

Arguments | Dagger

Dagger Functions, just like regular functions, can accept arguments. In addition to basic types (string, boolean, integer, arrays...), Dagger also defines powerful core types which Dagger Functions can use for their arguments, such as Directory, Container, Service, Secret, and many more.

fair sparrow
#

UP...

Do you have any advice?

I'm about to replace my CI with Dagger and I use formatting tools such as ruff (Python), shellfmt (Bash), php-cs-fixer (PHP) to detect formatting issues.

My current Dagger jobs and I'd like to be able to; ideal situation, allow my colleagues and I to do a dagger call php-cs-fixer --apply on their machine so that changes in the codebase are saved in the codebase.

Something like dagger call php-cs-fixer just to check (--dry-run) and --apply to save changes on the host system.

What do you think? It would allow me to simplify my processes.

Thanks

hot cove
#

@fair sparrow - Couldn't you add your own arg like --run and have the user or your script add dry or apply as a value?

So your command would look something like this:

dagger call php-cs-fixer --run dry

or

dagger call php-cs-fixer --run apply

Your function (using TypeScript) would look like this?

@func()
async phpCsFixer (run: string = "dry") { // dry is the default
  // do something
}

I believe that should work.

fair sparrow
#

Hi Scott.

Thanks for your answer.

The main problem is : the change should be reflected on my host. Doing the change inside Dagger is easy to do. But nothing is reflected on my host.

For instance, I jump in the container (using terminal() ) and there I run touch myfile.txt. The file is created in the container, I want to have the file also on my host (like we do using a volume with Docker)

hot cove
#

I believe that directory is "shared" between the container Dagger creates and your host.

#

But, I'm not 100% certain. I've not used this feature yet myself. 🙂

#

What language are you writing your modules in?

fair sparrow
hot cove
#

@fair sparrow - I believe with_mounted_directory() is what you need.

#

But, what has that to do wtih the flag you were asking about?

fair sparrow
fair sparrow
hot cove
#

If the mounted directory doesn't work, then I'm not sure how to get the result you are asking for. Maybe via the export?

From a CI process perspective, why do you need a container to run the formatting?

fair sparrow
#

Because it would be nice to be able to report formating issues (from the CI) then let team members to run, on their local computer, the same dagger call but, then, with the --apply flag

hot cove
#

In a good CI process, you wouldn't allow incorrectly formatted code into the repo to begin with. You'd have a pre-commit hook and run your formatting tool then. That's the better time for the dev to get the feedback they've formatted something wrong. They should also have the rules set up in their IDE/Editor, so they are caught even earlier.

fair sparrow
#

I fully understand that, from a CI perspective, it's a non sense... I'm just trying to reduce our workflow by reusing the same dagger script. (ideal situation)

fair sparrow
fair sparrow
hot cove
#

Exactly. If the dev "works around" the commit hook somehow, you'd still want a formatting check, but it would only be a check. You'd fail the PR directly because of the code formatting error and not actually format the code for the dev. At least I wouldn't. I believe you have to make it painful for devs being purposely sloppy. 😛

#

And, the dev would need the tools locally to format with. Hmm... and that could be a Dagger module. Hmm... maybe there is a module already built for this purpose (or similar), which might show us what is needed. Let me look.

fair sparrow
#

I'm running plenty of tools like shell format, phpcsfixer, php code sniffer, Rectorphp, prospector, ruff, markdownlint,... 😉

hot cove
#

I'm looking for a better example.

#

Seems like you can just return the directory as a result of the task ran in the container. 🤔

#

I'm also still trying to get my mind wrapped around the Dagger paradigm. Hehehe... 😄

hot cove
#

In my quest to understand Dagger better, I found this in the docs.

This Dagger Function returns a "just-in-time container" - a transient artifact generated by stringing together calls to the Dagger API using program code. Dagger is commonly used to produce artifacts like these, including binary files, containers, generated code or documentation, lint or vulnerability scan reports, and so on.

So, for sure your need to get the results back from the container must be possible. 🙂

fair sparrow
#

Thank you Scott, I still didn't succeed... I've created a new topic, more concise.

fair sparrow
#

@hot cove : youhou! @loud panther has pointed my error. My function should return a Directory (more info here #1342075271884570625 message)

Now I have everything in my hands to implement my --dry-run mode (the one for the GitLab CI) and the --apply mode (the one my team member will run from their host to make changes to their code)

#

[SOLVED] Applying changes on my computer (--apply-changes) or, default mode, run in --dry-run