GitHub Actions concurrency broke my process, as we would push commits and want to prove they have all built.
But now with Concurrency, GitHub cancels builds on previous commits as soon as a new commit is pushed.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
Is there a away to completely disable it?
Or even better, have it configurable per branch?
As documented "Any previously pending in the concurrency group will be canceled". In others words, the queue is limited in one. Somewhat useless. To permit parallel execution just not use 'concurrency' term on action.
Related
Like the title. Seems like both ways should work but child workflow seems easier.
It’s strongly recommended to always use activity to start new workflow and never use ChildWorkflow until the reset feature is working with Child Workflow https://github.com/uber/cadence/issues/3914
https://github.com/temporalio/temporal/issues/3141
To get result back to parent from child workflow, use signal. To link the two workflows, use search attributes when starting new workflows.
As Quanzheng said, if you need to use Reset, then Child Workflows are not currently an option.
Apart from that issue, the semantics of Child Workflows are quite different from starting a new workflow via an Activity.
The primary differences are that:
By default, Terminations and Cancellations are propagated to Child Workflows, although this can be overridden at Child Workflow creation time. This behavior is possible to implement with co-equal Workflows, but requires a careful Workflow implementation which never terminates without terminating its children.
Waiting for a Child Workflow to complete is directly supported in the Temporal API, whereas waiting for an arbitrary Workflow is not. See this issue.
Whether you need either of those capabilities, and whether you use Reset, should tell you if Child Workflows are appropriate to your use-case.
Team,
What is the exact use case to use continueAsNew?
As we have support for CronSchedule to do periodic activities, I don't know the scenario to use this.
Are we having this to give backward compatibility
There are many scenarios besides cron that require always running workflows. For example, a workflow that listens for external events and keeps some aggregated state. Such workflow will eventually run out of the history size limit. To support such workflow processing an unlimited number of events, it has to call continue as new periodically.
I have set up a pipeline which deploys to QA and PROD environments, with a pre-deployment approval before going to PROD. I tried to set up the pipeline so that if another release is sent through before the approval happens, it will cancel the prior release with pending approval. I used the "Deploy latest and cancel the others" option in Deployment Queue Settings for the first step/stage. However, this doesn't seem to have any effect.
At first I thought it was just because of the pending approval. But I did some additional tests and found that, even if the release is running and not awaiting approval, it is not canceled. I suspect this is because it is designed to only cancel queued releases and not ongoing releases. But if that is so, is it possible to cancel a release that is in progress if a new one comes behind it?
FYI I already checked this answer, but as I mentioned, is is not cancelling in progress releases (though for some reason it seems to work in this exact use case for that OP).
Ultimately, I just want to replace a pending release if a newer release is created before it finishes. Please let me know if there is a way to do this?
Edit: Just to clarify on the accepted answer, there were two issues. In my first runs, I didn't have Deploy latest and cancel the others checked on every stage, so that particular stage was not cancelling. Then after checking this option, it wasn't working because I wasn't letting the pipeline run to the same stage, rather I was cancelling the new release after I saw the old one didn't immediately cancel. I was under the impression that the release would be cancelled immediately, but it's not until the new release gets to the same stage that the old stage awaiting approval would be cancelled. Once I let the pipeline run through, the pending approval stage cancelled as expected. So really, that option seems to be tied to the stage, not to the entire release. Just wanted to provide some additional context to the answer.
I suspect this is because it is designed to only cancel queued releases and not ongoing releases.
Yes, your suspect is correct. It can only cancel the queued releases, but not the in progress one.
Also, this option still work fine for me at present. Not sure how do you configure this option on your side. For me, I set Maximum number of parallel deployments as 1 while the option Deploy latest and cancel the others is selected.
Then you will see the canceled releases display such message:
Ultimately, I just want to replace a pending release if a newer
release is created before it finishes.
If the pending release means the one which is pending on approval, you can still make use of Deploy latest and cancel the others option to achieve that.
But if it represent the in progress one, I'm afraid it does not supported now. You can think about this design from the perspective of the product actual use. For example, there has other release are currently being deploy while a new release is ready for deployment. If we interrupt the ongoing deployment process suddenly, I think it is bad for product stability, which is why we can only cancel the queued release, not the one being deployed.
In my ServiceNow workflow for a catalog item, I have a stage for customer acceptance. When the customer rejects the item, it triggers a workflow event and rolls back the workflow to the point where it's waiting for a state again. Or at least, that's the idea. But no matter what I'm doing, the rolled back workflow skips the "Wait for condition" activity immediately.
This is a screenshot of the workflow section in question.
What am I doing wrong?
I know this is an old post but perhaps the below suggestion can help in similar cases:
The thing wit 'Wait for Condition' is that once it has been evaluated, it will not be checked again until there has been a new update to the record on which the workflow runs.
I assume this could be the cause here, one you roll back, if the record itself does not get updated, it skips that activity. You can easily check if that was the case by adding some activity after the roll back to e.g. set a worknote on the record or just 'run script' with the setForceUpdate() function (this updates the record without changing any fields values).
I'm not 100% sure it is the fix to the above problem as there could be many other factors involved and only small part of WF was posted, but definitely something worth checking.
I hope you found the solution by now!
In my current environment, we have a "clean" build machine, which has an exact copy of all committed changes, nothing more, nothing less.
And of course I have my own machine, with dozens of files in an "in-progress" state.
Often I need to build my application with only one change in place. For example, I've finished task ABC, and I want to build an EXE with only that change.
But of course I can't commit the change to the repository until it's tested.
Branching seems like overkill for this. What do you do in your environment to isolate changes for test builds and releases?
#Matt b: So while you wait for feedback on your change, what do you do? Are you always working on exactly one thing?
So you are asking how to handle working on multiple "tasks" at once, right? Except branching.
You can have multiple checkouts of the source on the local machine, suffixing the directory name with the name of the ticket you are working on. Just make sure to make changes in the right directory, depending on the task...
Mixing multiple tasks in one working copy / commit can get very confusing, especially if somebody needs to review your work later.
I prefer to make and test builds on my local machine/environment before committing or promoting any changes.
For your specific example, I would have checked out a clean copy of the source before starting task ABC, and after implementing ABC, created a build locally with that in it.
Something like that: git stash && ./bootstrap.sh && make tests :)
I try hard to make each "commit" operation represent a single, cohesive change. Sometimes it's a whole bug fix or whole feature, and sometimes it's a single small refactoring on the way to something bigger. There's no simple way to decide what a unit is here, just by gut feel. I also ask (beg!) my teammates to do the same.
When this is done well, you get a number of benefits:
You can write a high quality, detailed description for the change.
Reading the first line of the description of each change gives you a sense of the flow of the code.
The diffs of a change are easy to read & understand.
If a change introduces a bug / build break / other problem, it's easy to isolate, understand, and back out if necessary.
If I'm half-way through a change and decide to abort, I don't lose much.
If I'm not sure how to proceed next, I can spend a few minutes on each of several approaches, and then pick the one I like, discarding the others.
My coworkers pick up most of my changes sooner, dramatically simplifying the merge problem.
When I'm feeling stuck about a big problem, I can take a few small steps that I'm confident in, checking them in as I go, thereby making the big problem a little smaller.
Working like this can help reduce the need for small branches, since you take a small, confident step, validate it, and commit it, then repeat. I've talked about how to make the step small & confident, but for this to work, you also need to make validation phase go quickly. Having a strong battery of fast, fine-grained unit tests + high quality, fast application tests is key.
Teams that I have worked on before required code reviews before checking in; that adds latency, which interferes with my small-step work style. Making code reviews a high-urgency interrupt works; so does switching to pair programming.
Still, my brain seems to like heavy multitasking. To make that work, I still want multiple in-progress changes. I've used multiple branches, multiple local copies, multiple computers, and tools that make backups of pending changes. All of them can work. (And all of them are equivalent, implemented in different ways.) I think that multiple branches is my favorite, although you need a source control system that is good at spinning up new branches quickly & easily, without being a burden on the server. I've heard BitKeeper is good at this, but I haven't had a chance to check it out yet.