I wanted to delete an old release template we used for testing to clean up Release Management a bit. But when I tried to deactivate the template, I got the following message:
To deactivate this release template, any releases that use this
template must have one of the following statuses: Released, Abandoned
Alright, that message makes sense... there must be a few unfinished releases that I need to finish, either by completing the process or abandoning it. When I went to the list of pending releases though, there are a bunch of them in the Rejected state that I can neither retry nor abandon. For example:
Now I can't delete the old, obsolete template, because I can't find a way to abandon these rejected releases. What should I do to delete the template?
Make sure you are or are in the group that is responsible for the Validation of the stage.
I had a similar issue even though I am a Release Manager, but when I made myself the Validator of the stage that it failed/rejected on, it allowed me to access the Retry/Restart/Abandon buttons for the rejected releases.
Configure Paths / Release Paths / [Path name]:
This can get out of sync if you have a domain username change like I did. It hadn't propagated all the way through our system yet, so the Release Administration group didn't include my new guid. So I assigned my new User to the Validator role and the buttons appeared on the Release window.
Related
We have a project in Octopus that has been configured to release to an environment on a schedule.
In the process definition we use a step template for Slack to send the team a notification when a release takes place. We would like to avoid sending this Slack message if the release was fired by the schedule - rather than user initiated.
I was hoping there would be a system variable that we could check before running the Slack step - but I can't seem to find anything documented as such, and google didn't turn anything up.
TIA
If you are using Octopus 2019.5.0 or later, there are two variables that will be populated if the deployment was created by a trigger.
Octopus.Deployment.Trigger.Id
Octopus.Deployment.Trigger.Name
You can see the details at https://github.com/OctopusDeploy/Issues/issues/5462
For your Slack step, you can use this run condition to skip it if the trigger ID is populated.
#{unless Octopus.Deployment.Trigger.Id}True#{/unless}
I hope that helps!
following on from this question:
GWT detect GAE version changes and reload
I would like to further clarify some things.
I have an enterprise app (GWT 2.4 & GAEJ 1.6.4 - using GWT-RPC) that my users typically run all day in their browsers, indeed some don't bother refreshing the browser from day to day. I make new releases on a pretty regular basis, so am trying to streamline the process for minimal impact to my users. - Not all releases concern all users, so I'd like to minimize the number of restarts.
I was hoping it might be possible to do the following. Categorize my releases as follows:
1) releases that will cause an IncompatibleRemoteServiceException to be thrown
and 2) those that don't : i.e. only affect the server, or client but not the RPC interface.
Then I could make lots of changes to the client and server without affecting the interface between the two. As long as I don't make a modification to the RPC interface, presumably I can change server code and or client code and the exception won't be thrown? Right? or will any redeployment of GAE cause an old client to get an IncompatibleRemoteServiceException ?
If I was able to do that I could batch up interface busting changes into fairly infrequent releases and notify my users a restart will be required.
many thanks for any help.
I needed an answer pretty quick so I thought I'd just do some good old fashioned testing to see what's possible. Hopefully this will be useful for others with production systems using GWT-RPC.
Goal is to be able to release updates / fixes without requiring all connected browsers to refresh. Turns out there is quite a lot you can do.
So, after my testing, here's what you can and can't do:
no problem
add a new call to a RemoteService
just update some code on the server e.g. simple bug fix, redeploy
just update some client (GWT) code and redeploy (of course anyone wanting new client functionality will have to refresh browser, but others are unaffected)
limited problems
add a parameter to an existing RemoteService method - this one is interesting, that particular call will throw "IncompatibleRemoteServiceException" (of course) but all others calls to the same Remote Service or other Remote Services (Impl's) are unaffected.
Add a new type (as a parameter) to any method within a RemoteService - this is the most interesting one, and is what led me to do this testing. It will render that whole RemoteService out of date for existing clients with IncompatibleRemoteServiceException. However you can still use other RemoteServices. - I need to do some more testing here to fully understand or perhaps someone else knows more?
so if you know what you're doing you can do quite a lot without having to bother your users with refreshes or release announcements.
I want a automatic update notification in my application. A message box should appear which tells that an update is available, if user wants then it can download the latest version in downloads folder of windows. Nothing else (user will install it manually) not application.
-I'm using Installshield so no Click once solution.
Thanks
If you want an out-of-the-box solution to this problem you're likely to be disappointed. I haven't found anything that works except ClickOnce, and I dislike it. I did find this:
http://windowsclient.net/articles/appupdater.aspx
My solution was to roll my own. It's actually not that difficult. I wrote a small bootstrapper application that first checks for updates, downloads them if necessary, and then launches my application in a new AppDomain. Pretty easy.
If you want to check for updates while your app is running, you need to write and add a component/class to your project that performs that task, and informs the user (MessageBox or whatever) that an update is available. If they choose to perform the update then you need to launch your bootstrapper (so it can fetch the updates) and kill your current process.
All of this is very possible with a little time and some custom code. It's not as difficult as it sounds. The biggest thing is determining how configurable you want your custom solution to be because that can affect when/where your bootstrapper goes to look for updates (I built mine to look for updates on a network share).
http://autoupdatewpf.codeplex.com/
i found one. This one is quite simple and solve the purpose.
I am currently running a SL3 project where we are in a highly iterative development mode with about 25 active test customers. I am making small changes at a clip of about 4 new builds per day. It is important to know this application is mission critical line of business for these 25 people, it is the tool they use all day to do their work so they are using it constantly and often launch their browser and the app in the morning and never close it until the end of the day.
The challenge is that when I make an update to the application I have no clean way to notify the users, in most cases this is ok as it is rare that I introduce a data contract change or something that would be a classic 'breaking' change to the app/service. Users keep plugging along and will get the change next time they refresh.
Right now we have resorted to emailing everyone and telling them to force refresh or close the browser and log back in.
Surely there is a better way...
Right now my train of thought is to have a method on the server that compares client xap versions and determines if the client being used is the most up to date, if so I will notify the user and make them update.
What have you done to solve this problem?
One way of doing it is to use a push mechanism (I used Kaazing Websoocket Gateway but any would do). When a new version of the XAP is released a message (either manually entered into the system by admin or automated triggered by XAP file change event) would be sent to all the clients. In the simplest scenario some notification would be shown to a user (telling him that a new version is released and the application needs to refresh) and then the app would refresh (by simply reloading the page) saving user's state if necessary.
If I would do this I would just keep it simple. A configuration value in web.config and a corresponding service method that simply returns that value (the value itself could be anything, but a counter is probably wise). Then you could have your Silverlight app poll that service method at regular intervals. Whenever the value changes (which you would do manually when you deploy a new version), just pop up a dialog telling the user to refresh the browser or log in/out. This way you don't have to force them to refresh every time. If you go with the idea of comparing xap file versions they will always be required to refresh, even for non-breaking changes.
If you want to take it further you could come up with some sort of mechanism to distinguish between different severity levels. For instance, if the new config value would contain the string "update_forced", you could force the users to reload the app by logging them out automatically (a little harsh, perhaps). If it contains the string "update_recommended", just show a little icon at the top right corner saying that there is a new version and that they should upgrade in their own time.
Granted, this was targeted at Silverlight 3, but with the PollingDuplex client and such in the newer versions of Silverlight, you could publish an "Update Now" bit to the clients, and build a mechanism in the client to alert the user that there is an update that is now out... that they should update it shortly, etc. You may even be able, through serialization and such, to save the state that they are in when they close the app to reload it.
We've done stuff similar with a LOB app that we built, so that as users are changing things, the rest of the userbase sees those changes immediately. Next up will be putting the flags in to change authorization and upgrades "on the fly" if you will.
I want to create a centralized Release Management server, for our customers but in my tests I'm not able to secure that our components will be safe from change mistakes. For example:
My test was like that:
User 1 - Release Manager (with all permissions)
User 2 - Ordinary user (just permission for approvals)
Logged with my User 1 - Release Manager (with all permissions)
First of all I ensured that only Release Managers will have access, and be able to see that release template:
I created a new component:
Then I logged with my User 2 - Ordinary user (just permission for approvals)
Firstly I can't see the release template I set permissions above in the release template list. Then I went to the components list and I'm able to see the same component, and even change it.
The main problem is that after done that, it impacts the releases for all release templates that contains that Component.
I hope to be wrong, and that someone should clarify it to me, that we may secure somehow all components with permission and so on. Any ideas?
Adding security for components is on our backlog. Thanks for the feedback. vNext components do not have tool or execution command stored in them. So, they are a little safer from this issue. Nevertheless, they do have configuration, and you would want to protect that configuration. This feature will be added sometime this year.