11–20 of 238 posts
How is this not resolved?
Easily bypassing security controls is a major security issue.
Yes, you need to convince someone to use your SHA, but social engineering is usually the easy part.
I don't see how you love something that makes you jump through these hoops: > In this particular case, it took me 4 separate commits (and 4 failed releases) to debug the various small errors I made: not using ${{ ... }}5 where I needed to, forgetting a needs: relationship, &c
We use Github Actions and we just don't have any issues with it outside the first time we set it up for each repo. Then we make 100s of commits a week and it does its thing and our work goes live a few seconds later. That's why I love it. Could things be better? Of course; that's how software is--and this should resonate with most folks on this site. But just because some product isn't infallible doesn't mean we can'…
Wow, computers doing what they're supposed to do. Pretty impressive ...
The UX on GH actions is crap, other CI/CD solutions give you way more control and tooling. GH really needs to step up their game on this one.
I don't see how you love something that makes you jump through these hoops: > In this particular case, it took me 4 separate commits (and 4 failed releases) to debug the various small errors I made: not using ${{ ... }}5 where I needed to, forgetting a needs: relationship, &c
There's tools like Act[0] that tries to solve this, but this has been an issue with CI systems since they were invented. [0] https://github.com/nektos/act
shell: run_workflow name=MyJob in=MyWorkflow.yml params={}
Earlier quoted context omitted.
Isn't that just programming? That's not much different than saying you forgot a bracket and had to make another commit to make it work. Granted, it would be nice if they had some linter.
This is a usecase where chatgpt works great! I usually pass this kind of ops DSL in gpt and it will find my mistakes. Github actions and graphanaQL code, oof, they just click for me.
The git commit, push, wait loop is terrible UX. Users deserve portable pipelines that run anywhere, including their local machines. I understand Act [1] goes some way to solving this headache but it's by and large not a true representation. There are many pipelines you can't run locally, because they're production, for example, but there's no reason why we can't capture these workflows to run them locally at less-cri…
There was a project to allow you to run the pipelines locally so you could do the edit-run-debug loop on your own private environment without committing. It was, of course, canned.
https://github.com/microsoft/azure-pipelines-agent/pull/2687...
However, there are tools to improve QOL. For example:
https://marketplace.visualstudio.com/items?itemName=ms-azure...
A vscode extension that's syntax-aware.
Now, I'll be a bit controversial: if they'd used XML instead of YAML, you could have an xmlns declaration up-top that would give you validation in most decent code editors without user intervention. XML is awful, but it has a lot of useful features that we gave up when we threw the baby out with the bathwater.
I don't see how you love something that makes you jump through these hoops: > In this particular case, it took me 4 separate commits (and 4 failed releases) to debug the various small errors I made: not using ${{ ... }}5 where I needed to, forgetting a needs: relationship, &c
Yeah, I wouldn’t want to use any automation that you can’t also easily and quickly test locally.
They canned it.
https://github.com/microsoft/azure-pipelines-agent/pull/2687...
I'd like to know if my builds are getting slower over time. I'd be able to detect flaky tests automatically.
It seems basic, but I know third-party solutions exist for this. It's out of the box in Circle CI and Buildkite and feels like it should be here.