4 ms·

I’ve used this a bunch; I actually don’t know how else you’d write and test a GitHub action. Do people just push them and hope they work and push more commits w

I’ve used this a bunch; I actually don’t know how else you’d write and test a GitHub action. Do people just push them and hope they work and push more commits with “fix” as the message until it works?

easrng 4y ago
yeah i also use other incredibly informative messages like: - oh oops - fix for real this time - will this actually work? - this probably won't fix it - a
- yjftsjthsd-h 4y ago
  Yeah, but with one word messages you can pass it on the command line without quotes: git commit . -m fix
  - reilly3000 4y ago
    TIL. Thanks!
  - easrng 4y ago
    i usually write my actions in the web editor, but i do use -m when committing from git itself pretty much every time
- DeWilde 4y ago
  I just commit --amend and the push -f to not waste brainpower on messages.
motoxpro 4y ago
You've described my workflow perfectly. Edit: Downvoters, please help me.
deleted 4y ago
[deleted]
yjftsjthsd-h 4y ago
> Do people just push them and hope they work and push more commits with “fix” as the message until it works? Unironically yes. It's awful, it's ugly, but it works with no extra setup, effort, or cost (other than feeling dirty for a few minutes).
plonk 4y ago
I add a workflow like this: - write the main job in a Python/PowerShell/Bash script that runs locally, - write a workflow that sets up the environment (AWS login), installs dependencies (using GitHub's facilities for that) and calls the script (often passing values using GitHub Secrets), - push the workflow with a "push" trigger on a feature branch (for fast testing), - push 30 fixup commits to fix all the small syntax errors, logic mistakes, and GHA idiosyncrasies I hadn't thought of, - remove the push trigger, - do an interactive rebase to squash all the fixups, - force-push and merge. It works pretty well and can be easily used locally or in other CI/CD systems.
- pindab0ter 4y ago
  > - push 30 fixup commits to fix all the small syntax errors, logic mistakes, and GHA idiosyncrasies I hadn't thought of, I don't have a lot of experience with GitHub Actions, but is there really no better way to do this?
  - plonk 4y ago
    The only way to actually run the workflow is to push the code and trigger the workflow somehow. And you can't push code without committing it since this is git. You could write the workflow correctly the first time. Good luck. It's not one language, you're writing PowerShell scripts inside a bunch of YAML files that reference each other with relative paths and need to call installers that were never written for unattended installs. The only way I can make it work is through trial and error. GHA really feels like it's trying to cobble up a CI/CD pipeline from a million different pieces that were designed for entirely different purposes. It works, if you spend enough weeks on it, but it will never be pleasant to configure. I can understand why they didn't even try to make it reproducible on the users' workstations, it can break if basically any part of your system's configuration, filesystem, or environment deviates from the runners. That's obviously not entirely GitHub's fault and the service is very practical once it's set up. My advice is to depend on GHA for their useful features (caching, Secrets, parallel jobs) and do everything else in your own scripts or in Docker.
  - deleted 4y ago
    [deleted]
deathanatos 4y ago
git add […] && EDITOR=true git commit --amend && git push -f […] (You don't have to open a PR / the usual history rewriting consequences don't apply if you're just pushing to Actions to see how it reacts.) But alternatively, if you find yourself doing this a lot and it's really the code of the step that you're debugging (vs. debugging how the workflow interacts with Actions itself) I try to keep my jobs' steps pretty simple: - run: ci/thing.sh … specifically so that I can run the step locally. It's usually much faster. (And on a MBP, doesn't incur the costs of virtualization, at the cost of needing to port to macOS. Usually worth it.)
- gilnaa 4y ago
  EDITOR=true is clever! Git has --no-edit as well, btw
  - masklinn 4y ago
    And usefully it also has `-e` (`--edit`), so you can create an alias of amend = commit —-amend —-no-edit and if you need to edit the commit message alongside merging new changes in HEAD, > git amend -e
- xorcist 4y ago
  To avoid editing the commit message you can use: -C <commit>, --reuse-message=<commit> Take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when creating the commit. In the above example, commit can simply be "HEAD", when doing the amend commit: git commit -C HEAD --amend
warpech 4y ago
We use a repo fork for CI workflow experiments. Once it's tested, we push the workflow changes to the main repo.

easrng 4y ago

yeah i also use other incredibly informative messages like: - oh oops - fix for real this time - will this actually work? - this probably won't fix it - a

yjftsjthsd-h 4y ago
Yeah, but with one word messages you can pass it on the command line without quotes: git commit . -m fix
- reilly3000 4y ago
  TIL. Thanks!
- easrng 4y ago
  i usually write my actions in the web editor, but i do use -m when committing from git itself pretty much every time
DeWilde 4y ago
I just commit --amend and the push -f to not waste brainpower on messages.

motoxpro 4y ago

You've described my workflow perfectly. Edit: Downvoters, please help me.

deleted 4y ago

[deleted]

yjftsjthsd-h 4y ago

> Do people just push them and hope they work and push more commits with “fix” as the message until it works? Unironically yes. It's awful, it's ugly, but it works with no extra setup, effort, or cost (other than feeling dirty for a few minutes).

plonk 4y ago

I add a workflow like this: - write the main job in a Python/PowerShell/Bash script that runs locally, - write a workflow that sets up the environment (AWS login), installs dependencies (using GitHub's facilities for that) and calls the script (often passing values using GitHub Secrets), - push the workflow with a "push" trigger on a feature branch (for fast testing), - push 30 fixup commits to fix all the small syntax errors, logic mistakes, and GHA idiosyncrasies I hadn't thought of, - remove the push trigger, - do an interactive rebase to squash all the fixups, - force-push and merge. It works pretty well and can be easily used locally or in other CI/CD systems.

pindab0ter 4y ago
> - push 30 fixup commits to fix all the small syntax errors, logic mistakes, and GHA idiosyncrasies I hadn't thought of, I don't have a lot of experience with GitHub Actions, but is there really no better way to do this?
- plonk 4y ago
  The only way to actually run the workflow is to push the code and trigger the workflow somehow. And you can't push code without committing it since this is git. You could write the workflow correctly the first time. Good luck. It's not one language, you're writing PowerShell scripts inside a bunch of YAML files that reference each other with relative paths and need to call installers that were never written for unattended installs. The only way I can make it work is through trial and error. GHA really feels like it's trying to cobble up a CI/CD pipeline from a million different pieces that were designed for entirely different purposes. It works, if you spend enough weeks on it, but it will never be pleasant to configure. I can understand why they didn't even try to make it reproducible on the users' workstations, it can break if basically any part of your system's configuration, filesystem, or environment deviates from the runners. That's obviously not entirely GitHub's fault and the service is very practical once it's set up. My advice is to depend on GHA for their useful features (caching, Secrets, parallel jobs) and do everything else in your own scripts or in Docker.
- deleted 4y ago
  [deleted]

deathanatos 4y ago

git add […] && EDITOR=true git commit --amend && git push -f […] (You don't have to open a PR / the usual history rewriting consequences don't apply if you're just pushing to Actions to see how it reacts.) But alternatively, if you find yourself doing this a lot and it's really the code of the step that you're debugging (vs. debugging how the workflow interacts with Actions itself) I try to keep my jobs' steps pretty simple: - run: ci/thing.sh … specifically so that I can run the step locally. It's usually much faster. (And on a MBP, doesn't incur the costs of virtualization, at the cost of needing to port to macOS. Usually worth it.)

gilnaa 4y ago
EDITOR=true is clever! Git has --no-edit as well, btw
- masklinn 4y ago
  And usefully it also has `-e` (`--edit`), so you can create an alias of amend = commit —-amend —-no-edit and if you need to edit the commit message alongside merging new changes in HEAD, > git amend -e
xorcist 4y ago
To avoid editing the commit message you can use: -C <commit>, --reuse-message=<commit> Take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when creating the commit. In the above example, commit can simply be "HEAD", when doing the amend commit: git commit -C HEAD --amend

warpech 4y ago

We use a repo fork for CI workflow experiments. Once it's tested, we push the workflow changes to the main repo.