vyadh / teamcity-deployment-dashboard Goto Github PK

Hello,

I see 1.10.0 is the newest version but on the plugin page on jetbrains it's showing 1.9.0 as the newest version.

Can we have add a link to the project name to go to that project name?

In #3 we allowed ignoring metadata parts of the build, but it doesn't really go far enough. We should be consistent with the use of properties for project and environment, which falls back on TeamCity concepts when not set.

This would allow specifying the TeamCity build number in any format, and being able to target a version format specifically for the plugin.

Hey!
We have only one deployment with one parameter which include multi select environment values e.g. %hosts% = node1,node2,node3 and etc. Dashboard works fine only if we choose only one value. In dashboard we set Environment Property hosts and Environments: all values comma separated with Multi-Environment Build Configurations enabled.
Any chance you can add this feature?

Thanks!

We have several Projects with longer branch names (16+ characters) with 6+ Environments in the grid which results in the branch names overlapping both the Project names and other branch names in every Environment column making it unreadable. It would be nice to cutoff this text, wrap it or reduce the size so that there is no overlapping.

TeamCity has the concept of 'Deployment' build configuration: https://www.jetbrains.com/help/teamcity/2019.1/deployment-build-configuration.html

Can it somehow be used in the plugin?

As you know docker support swarm mode, this means that you can define deployment of services with relevant versions in docker-compose file in YAML format.
For more information pl refer to https://docs.docker.com/engine/reference/commandline/stack_deploy/

So that I be able to deploy docker stack to docker swarm cluster using single command only, (e.g.: _docker stack deploy --compose-file docker-compose.yml vossibility) in TeamCity build configuration with type Deployment.

Question: How can I setup TeamCity Deployment Dashboard using docker stack deployment?

Is there a way to remove 'old/redundant' items from displaying on the Deployment Dashboard?
WE have a Deployment Dashboard that has been in play for a number of years and over time there are a few old projects that we would like to remove from it - Is there any way to do this?

Console output:

FAIL src/util/dateTimes.test.js
  ● time is formatted to the correct time zone

    expect(received).toBe(expected) // Object.is equality

    Expected: "7:30:00 pm"
    Received: "6:30:00 pm"

      28 |   let timeToday = date + 'T18:30:00Z' // As from server in UTC
      29 |
    > 30 |   expect(format(timeToday, timeFormatter)).toBe('7:30:00 pm') // as BST
         |                                            ^
      31 | })
      32 |

      at Object.<anonymous> (src/util/dateTimes.test.js:30:44)

Docker:
Server: Docker Engine - Community
Version: 20.10.0

Env:
GMT+03 (Minsk)
git bash
Windows 10 20H2 v19042

Removing single broken test helps, and build creates a .zip

Occasionally there can be deployments which are manually adjusted or otherwise different because of production concerns. It would be useful for true dashboard to allow some customisation here.

Some ideas:

• Picking up colours from a property
• Reading tags to customise output
• Ability to mark a deployment as cancelled
• Using properties to highlight differences, e.g. deployment is to different region

And take into account branch when deciding which build is old (i.e. the latest change on develop branch should show up as latest even if there is a feature branch build that is newer deployed to a different env

Currently it's a bit tricky to configure the dashboard. For instance it is not clear that only build configurations of Deployment type are considered. Seems it's not stated anywhere in the UI.

Maybe it would be better to have some preview of the dashboard right on the configuration page, or at least show what build configurations are matched by the provided criteria and why.

Currently the environment lookup is case sensitive, which seems unnecessarily restrictive. If the environment is 'dev', 'DEV', or 'Dev' they should be treated the same. Particularly important when showing environments across projects and teams where consistency is harder to achieve.

The case of the environment displayed should be as those specified in the configuration of the dashboard and would need to be normalised when read from build data. This would allow better user facing labels, e.g. a code of 'uat' can become 'UAT' and 'develop' can become 'Develop' when shown.

Hello Vyadh!

Its me again.

Still trying to setup you awesome plugin. But i'm stuck again.

Now its shows proper branch that was deployed, but only in last deployed environment
For example i deploy BAC-*** branch to 'highload' env:

After that i deploy master (i aslo tried to deploy the same BAC-*** branch) branch to 'master' env.
Now dashboard shows status only for 'master' (last deployed) env.

Project structure looks like this:

Dashboard enabled for "Deploy" subproject and "hosts" env is configured also here in "Configuration Parameters"
Dashboard settings for this project:

Plugin is updated to the last 1.4.0 version.

What is the significants between the bright and faded icons?
There seems to be no rhyme or reason for it.

We do deploy multiple envs in one build and its pretty convenient. List of envs is a Select parameter. Values are comma separated (but its configurable)

The form size seems to be fixed, when I increase the size of the browser windows the form or report stays the same size.

Long project names take-up multiple lines.

Hello Vyadh!
Trying to set up your awesome plugin, but i'm stuck.
I have a project with below settings:

I want to see a branch name on dashboard. So after deploying master branch i tried to deploy tagged branch 1.0.2

Branch name appears on dashboard while it was deploying

But after deploy branch name on dashboard changed to "master" again

What i'm doing wrong?

Currently using WebLinks.getViewResultsUrl(build), which uses the TeamCity setting in 'Administration / Global Settings / Server URL'. If the TeamCity server has not been configured correctly with the DNS name, clicking on a build will change the base URL and the user will have to login again.

To avoid this issue, try using RelativeWebLinks so it doesn't matter how TC is configured.

Seems this plugin expects that environments are separated by comma without any spaces.
For instance it does not work if environments are defined as:
env1, env2, env3

Note: the space after the environment name.

Hey!
First of all many thanks for this great project!
We are using production env in different project because of security reasons. Any chance you can add possibilities to take environments from different projects? For example by project ID + env.param.

The majority of my projects use two build configs (master and branch) that deploy to the same environments.
The Master build config is used for normal release cycle deployments.
The Branch build config is used primary for hotfix release cycle deployments.

Both build configs deploy to:
project = A
environment = TEST

It seems this plugin displays the first, or last, version it finds, for each project-environment.
It should display the most recent deployment according to the build date.

If the last build of Master was deployed yesterday and the last build of Branch was deployed this morning...
The Plugin should display the Branch's version info.

If the last build of Master was deployed yesterday and last build of Branch was deployed last month...
The Plugin should display the Master's version info.

Some deployments show the date and others just show the time.
Looks like a bug of some short

Two things that I would like to see:

• Making this applicable to all builds, not just Build configurations of type deployments. Is there any reason it has to be deployment build configs?
• Being able to switch off the highlighting of the latest "version".

My use case: We have a "project" that collects higher-level test suites running in a multitude of environments. It would be great to have a dashboard that displays the current status of each of those. This pretty much permits us to do that, though the two features above are "annoyances" for that use-case.

Is this something you might consider fixing, accept a PR for, or would it be better to fork the dashboard for our own needs?

Currently the plugin shows parameters in the configuration as literal values that it finds. However, it may be that this is a reference to a parameter than references other parameters. For example, a parameter for "version" might be:

%version_number%+%build.counter%

These references are not resolved, which means configuration needs to output what has been computed in a literal way, which complicates TeamCity configuration. It also prevents use of parameters from earlier in the build chain - which is often the build number you're interested in.

Should support this scenario, but at the same time avoid performance regressions when no parameters are present.

Personal builds are currently shown, but they look like any other build other than what has been specified in the version number.

It would be better to show personal builds quite differently as this effects what is being tested in a monolithic environment.

We need to build the frontend via NPM and the backend via Gradle. Ideally the build would be all orchestrated by Gradle, but currently the two parts are separate and the way to do it is not documented, so that at least should be fixed in the short term.

The build is roughly the equivalent of doing the following after a clean checkout:

cd frontend
npm install
set CI=true && npm test
npm run build

cd ..
cp -R frontend/build/* server/src/main/resources/buildServerResources
gradle serverPlugin

mv server/build/distributions/server.zip ./deployment-dashboard.zip

It would be helpful to add a view or list of previous deployments for a specific project/environment. This would be useful in order to help identify the specific build number that was deployed at specific point in time for a multi-environment deployment build configuration. Right now only the most recent deployment to an environment can be identified.

The plugin currently uses semver to calculate what is the latest build, and either highlights/fades out deployments.

However, if you're not using the exact version number through different environments, the plugin does not highlight deployments as expected. For example, if you leave the build numbers for each deployment as independently incrementing.

A simple way to solve this is to assume that the semver part comes first, and anything after is just metadata. We could do this by ignoring anything after a space in the version string.

We should also better document how this works in the readme.