• exu@feditown.comEnglish
    7·
    7 hours ago

    That’s why I use a separate branch. Use rebase or reset depending on what exactly you need to clean up when it’s working.

  • pivot_root@lemmy.world
    22·
    14 hours ago

    Solution:

    git commit --amend
git push --force

    Problem:

    The process of discovering best practices on how to keep a clean git history is a goddamned challenge.

      • pivot_root@lemmy.world
        2·
        13 hours ago

        I didn’t want to make it sound too scary 😉

        Seriously, though, git really needs an option to treat --force as --force-with-lease. In the exceedingly rare occasion where I might want to completely overwrite a branch, it should be extra explicit by having to type something like --force-and-overwrite.

        • Ephera@lemmy.mlEnglish
          2·
          7 hours ago

          Yeah, I virtually only use --force for moving tags around (which one could definitely argue isn’t really a thing you should be doing regularly either)…

    • leMe@lemmy.dbzer0.com
      2·
      7 hours ago

      lots of people already pointed out tools to (kind of) dry run locally. they are great to figure out cryptic error messages.

      however, if you have issues with the complexity of the whole pipeline, it is usually easier to just execute the whole pipeline. for that we have the branch prefix cicd/ and treat these exactly as main/master and develop (except the very last deployment step). that way we can see where a whole pipeline will go. and when it is finally doing what it should, we can squash it before merge -> have a nice history.

      • NotSteve_@piefed.caEnglish
        5·
        14 hours ago

        I’ve spent so much time trying to get act working well enough that it’s easier to use than pushing to remote but it gets really difficult when you involve things like AWS services (especially when the tokens to push to ECR aren’t available to me as a lowly dev). Localstack can help but the container registry functionality is locked behind the paid version

      • dangling_cat@piefed.blahaj.zoneEnglish
        6·
        15 hours ago

        The DX of this project is not ideal at all. Like, they are using a different image than GitHub provided, so you get different errors when you deploy… which defeats the entire purpose! That’s if you figured out how to run it locally in the first place after weird errors.

    • mesa@piefed.socialEnglish
      15·
      16 hours ago

      Circleci, Travis, and gitlab all allow you to ssh into the box you are trying your scripts on and fix it there. Much easier and takes a lot less time. Github actions have an unofficial way of doing it and is…not the best. Actions is actually one of the worst CIs I’m my experience.

      • azertyfun@sh.itjust.works
        1·
        13 hours ago

        For gitlab this is only correct with a shell executor which is to be avoided in the general case in favor of a docker or k8s executor for isolation&repeatability.

        Those you can actually run locally with gitlab-runner, but then you won’t have all your gitlab instance’s CI variables so it’s a PITA if you need a CI token which you probably do if you actually make decent use of gitlab’s features.

        In most cases I just end up committing my changes to avoid the headache. :!git commit --amend --no-edit && git push -f goes pretty dang fast and 60 % of the time third time’s the charm.

        • mesa@piefed.socialEnglish
          2·
          13 hours ago

          Why avoid the shell executor on docker? I did 4years of gitlab back a bit ago. It was super simple. But I haven’t kept up since work maintains actions and Travis. And there’s a way nowadays to inject the env or pull from a secret server-ish.

          All ci is basically the same. Or at least for a while.

          • azertyfun@sh.itjust.works
            1·
            6 hours ago

            Ideally you’d use the docker executor with a dind service instead of docker commands in the shell. You’ll have better isolation (e.g. no conflicts from open port forwards) and better forward-compatibility (the pipeline won’t break every time a major upgrade is applied to the runner because the docker - especially compose - CLI is unstable).

    • Ephera@lemmy.mlEnglish
      1·
      13 hours ago

      Yeah, we always try to automate as much as possible with generic language build tooling and scripts, so that ideally the call in the runner is just a single command, which can also be triggered locally.

      Unfortunately, if you want to be able to re-run intermediate steps, then you do need to inform the runner of what you’re doing and deal with the whole complexity of up-/downloading intermediate results.