Skip to main content

You're a developer. It's 4:58pm, and you're on your way out of the office for the day, but right before you leave, you request a topic environment.

You get in at 8:00am the next day, and you find that it failed. You read the logs and say to yourself, "Oops, that was silly." You make your quick fix, and you're ready to try again, but now you can't.

The bad topic environment has to be deleted before it can be rebuilt.

You trigger the deletion, but that takes a long time. (An hour? I haven't timed it.) Now, while you're waiting for the broken topic environment to delete itself, you're either twiddling your thumbs, or you add this to your mental load, go off and do something else, and risk forgetting to come back to it.

In the best case, this turned an 8:05am redeployment into a ~9:00am redeployment. I hope your customer didn’t need this right away.

If a topic environment fails, I would like a setting I can select to delete it automatically if there's a failure so that environment slot can be available for a new build when the fix is ready.

I also wouldn’t mind an email notification when it’s ready, regardless whether it succeeded or failed.

<comment deleted>

Hi @durette ,

I believe and enhancement to the life cycle experience is on it’s way with 24R2 to enable notifications for all jobs which i think is something we needed for a while. 

No idea on the other. Good idea nevertheless

Cheers. 

Here’s another idea along these lines. Sometimes you do need the environment to stay running because the error isn’t obvious, and you need to dive into the database to figure out what’s going on. Let’s say you’ve made your fix, but now you need to first delete the environment and recreate it from the same branch. I could work more efficiently if there was one single command that issued both jobs in sequence.

 

This would actually be more useful than my first idea because you don’t know in advance what kind of troubleshooting will be required.

I get what you’re saying and agree. 

In the meantime, I’ve worked around the long waits by creating another copy of my branch with a slightly different name.  Only works if there happens to be another free topic environment.

Yep, clunky.  But if you’re in a pants-on-fire situation, it could work.

Hi,
I’ve already created Ideas for this - vote for them, if you can and hope for implementation with me.

BuildPlace - Order environments creation options | IFS Community
Build Place Logs Order and pagination | IFS Community
Automate SU application when there are no modifications | IFS Community
Build Place Time | IFS Community
Build Place - Unix Timestamp replacement | IFS Community
Automatical resolve of DNS problem in BP environment order | IFS Community
BuildPlace - Add statuses of environment or env. creation job: "Warning" / "Partially failed" / "Import failed" | IFS Community
BP environments info - eg. used SanityBuild | IFS Community
BuildPlace Refresh buton or Notification | IFS Community

BR
Filip

and BTW, I’m usually push corrected branch with another name, so TOP environment could be ordered immediately.

If you create another branch, you lose your commit history, and that circumvents one major reason why we’re using source control in the first place. I can’t accept that workaround.

 

Imagine if an electrician rewired your house but didn’t label the circuit breakers. Your lights will probably work, but I don’t like this idea of not leaving breadcrumbs for future troubleshooting.

 

As a full-time employee at a customer site, I have to support the messes I create. I’m incentivized to care about such nonfunctional requirements.

I am not creating new branch. I only push same branch under original and new unique name. Then order topic environment for new name, which is allowed because only name is checked and after success delete it and continue under original name, nothing is lost.

I am not creating new branch. I only push same branch under original and new unique name. Then order topic environment for new name, which is allowed because only name is checked and after success delete it and continue under original name, nothing is lost.

Is this what you mean?

git checkout 'topic/me/M-ABC123-Do_Something'
git push origin 'topic/me/M-ABC123-Do_Something'
git push origin 'topic/me/M-ABC123-Do_Something_Clone'

 

@durette did you create an idea for this? I’d like to give an Upvote, but I can’t do that here since it’s a normal post and not an Idea.

Reply


Terms & ConditionsCookie settings